viniropke99
commented
4 years ago Hi, I'm having the same problem with yours when integrating Barnyard2 with Snort. It writes 0 in the IP_SRC table and an integer in decimal to represent IPv6 which, in my view, is incorrect.
04/04-21:46:25.532927 [] [1:1000001:1] Pacote ICMP detectado! [] [Classification: Generic ICMP event] [Priority: 3] {IPV6-ICMP} fe80:0000:0000:0000:0a00:27ff:fe36:b5ca -> fe80:0000:0000:0000:3170:bbf1:05dc:a5f8 04/04-21:46:25.533191 [] [1:1000001:1] Pacote ICMP detectado! [] [Classification: Generic ICMP event] [Priority: 3] {IPV6-ICMP} fe80:0000:0000:0000:3170:bbf1:05dc:a5f8 -> fe80:0000:0000:0000:0a00:27ff:fe36:b5ca
| sid | cid | ip_src | ip_dst | ip_ver | ip_hlen | ip_tos | ip_len | ip_id | ip_flags | ip_off | ip_ttl | ip_proto |
| 1 | 1 | 0 | 829471729 | 6 | 0 | 0 | 0 | 40 | 0 | 0 | 254 | 128 |
| 1 | 2 | 0 | 167782399 | 6 | 0 | 14 | 41035 | 40 | 0 | 0 | 254 | 128 |
Has anyone managed to resolve this error?
Hi firnsy,
i am using barnyard2 version 2.1.14 build 337 with ipv6 support enabled. For visualisation i use snorby in the actual version. I realized that snorby displays ipv6-adresses as wrong ipv4-adresses.
The cause seems to be, that barnyard2 handles ip-adresses as unsinged integers when writing them to the database. This works for ipv4 but obviously breaks with ipv6. I didn't find any commit or issue within the last years wich mentioned this behavior. I can't imagine that i'm the only one who runs in this problem.
Are there any plans to implement a different way of handling the ip-addresses? Of course, not only barnyard needs to be changed, but this is one part in the whole setup.
Greetings oscarminus