Suricata events never contain source or destination ip addresses?

[Ian]

For whatever reason, events from the "Suricata" ruleset (as opposed to ET or ET PRO) never contain a source or destination ip address.

For instance, these rules:
"SURICATA UDP packet too small"
"SURICATA IPv4 invalid checksum"
"SURICATA UDPv4 invalid checksum"
"SURICATA UDP invalid header length"

If I try to pivot to wireshark from Sguil, nothing happens.

Is this just a strange bug with my system, or is it doing this for everyone?

[Wes]

Ian,

Does this display the same behavior ((No source or destination IP address) in ELSA for each alert type, or just Sguil?

Are you able to attach a screenshot?

Thanks,
Wes

[Ian]

Wes,

I've attached a screenshot from Sguil. As there's no ip addres, I'm unable to pivot into elsa. Can you give me a query to run that should capture this?

I've tried queries like "program='snort'" but the time/date stamp in elsa always seems to be a day behind with the results.

I tried this query too "sig_sid='1:2200073:2'" but got no records found.

I'll query elsa tomorrow to see if the results change.

[Wes]

Ian,

Are you monitoring IPv6 traffic? I don't believe Sguil (DB) is capable of this yet.

You may be able to try the following query in ELSA to see if you are able to get what you are looking for:

class=SNORT "-" groupby:sig_msg

..then navigate to the desired entry.

You may want also to take a look at the following:
https://groups.google.com/d/msg/security-onion/a8NBcIAOwFU/O8ahwncgBQAJ

Is this behavior specific to only certain types of alerts, or to all alerts you see in Sguil?

Thanks,
Wes

[Ian]

Okay, I waited a few days for ELSA to catch up. Those events are nowhere to be found using your query. (I set the from date to 2016-09-13 just in case)

Yes, we do have some ipv6 traffic, although that interface has been shut off at the gateway due to performance reasons. Would the rule "SURICATA IPv4 invalid checksum" trigger for ipv6 traffic?

If I use squert instead of Sguil, the src and dst ip addresses are 0.0.0.0, so maybe it was just a gui glitch. I've seen other gui glitches when sguil disconnects and reconnects (duplicate events sometimes appear).

Is there a folder somewhere I can grep to find the log file that should contains these events? Maybe ELSA is having trouble parsing the data? In order for squery/sguil to have records in sql, it would have had to look at these same log files, right?

[Wes]

Ian,

I would think that the invalid checksum rule for IPv4 would not trigger on IPv6 traffic, but I have not had a chance to look into it much.

You may want to take a look at the following to get an idea of where certain things are written to disk, etc:

https://github.com/Security-Onion-Solutions/security-onion/wiki/Architecture
https://github.com/Security-Onion-Solutions/security-onion/wiki/Help

barnyard2 outputs alerts from Snort/Suricata's unified2 logs to snort_agent (to go to sguild -- where Sguil/Squert connect to to pull back data from securityonion_db).

barnyard2 also outputs alerts to syslog (and syslog-ng), which is a source for ELSA to pull data into it's database vi a syslog-ng (/etc/syslog-ng/syslog.conf).

You can read more about output of the alerts by Suricata here (I don't believe all are implemented by SO):

https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricatayaml#Event-output

You can see whatever has reached sguild by setting 'DEBUG' to '2' in /etc/nsm/securityonion/sguild.conf (then restarting services) and taking a look in /var/log/nsm/securityonion/sguild.log.

Thanks,
Wes