IPv6 alerts always have the same IP for the source and destination

1

Good morning,

We are running Suricata 4.1.8 with the ET PRO ruleset. Alerts with IPv4 are fine, but IPv6 alerts always have the source and destination IP the same. Here is an example (I have anonymized the IP). Any thoughts as to why?

(IPv6 Event)
sensor id: 0 event id: 135 event second: 1599745673 event microsecond: 711144
sig id: 2018959 gen id: 1 revision: 4 classification: 24
priority: 1 ip source: xxxx:4de0:ac19::1:44:44 ip destination: xxxx:4de0:ac19::1:44:44
src port: 80 dest port: 59713 protocol: 6 impact_flag: 0 blocked: 0

Thanks
Shane

2

Can you give us a bit more details about your setup especially the IPv6 part?

I have 5.0.3. running on an IPv6 network and it looks fine, so I would guess it’s just a configuration/network setup issue.

3

Thanks Andreas,

We have a Gigamon pushing IPv6 traffic to this sensor running Suricata 4.1.8. Suricata is configured to write alerts the fast output, like this:

Configure the type of alert (and other) logging you would like.

outputs:

a line based alerts log similar to Snort’s fast.log

  • fast:
    enabled: no
    filename: fast.log
    append: yes

Then barnyard picks up the alerts. When we look at the alerts the source and destination IP addresses are always the same. Looking at suricata.yaml, I do not see anything IPv6 specific. Our home net is defined correctly, our external_net variables is: EXTERNAL_NET: “!$HOME_NET”

I can post our suricata.yaml if that would be helpful. Here is a snippet of a raw alert (I anonymized the alert some):

(IPv6 Event)
sensor id: 1 event id: 2 event second: 1600155061 event microsecond: 774151
sig id: 2012811 gen id: 1 revision: 5 classification: 5
priority: 2 ip source: 2001:468:c80:xxxx:0:100:0:42 ip destination: 2001:468:c80:xxxx:0:100:0:42
src port: 43642 dest port: 53 protocol: 17 impact_flag: 0 blocked: 0

Thanks again,
Shane

4

The fast.log is not enabled if that’s a copy of your yaml :slight_smile: Feel free to attach the complete config (anonymize sensitive information).

Ideally you can enable eve output as well and show us the raw output produced by fast.log and/or eve json.

Another thing would be to craft a pcap and do a run with -r, ideally a pcap that you can share with us so we can confirm the issue.

5

Oops! I see what you mean now. :slight_smile: Looks like we use the snort.unified2. I will read in a pcap, hopefully this afternoon.

Shanesuricata.yaml (71.0 KB)

6

Keep in mind we deprecated unified2, see https://suricata-ids.org/about/deprecation-policy/ and for testing purpose would be helpful if you could provide the fast.log and eve.json. In theory it should be the same issue.

The configuration itself looks fine from a first glance.

7

Thank you so much for your help. Attached is the eve log. The eve log has the correct source and destination IP addresses.

Shaneeve.json (3.8 KB)

8

So this seems to be just an issue with the unified2. I recommend that you migrate to eve json output since unified2 won’t be supported in the futures and thus we won’t likely fix this issue.

I’m glad that overall it’s working correct.

9

Thanks Andreas! We have a very large network and Suricata handles the traffic incredibly well with surprisingly little processing power. It is amazing really.

Shane