snort_agent.log shows the events like these:
Sending sguild (sock1a3e4b0) BYEventRcvd sock1ab1290 0 6 467035 REDACTED 1642 1642 {2016-04-29 15:13:23} 1 2200074 1 {SURICATA TCPv4 invalid checksum} {2016-04-29 15:13:23} 3 unknown {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
Sending sguild (sock1a3e4b0) BYEventRcvd sock1ab1290 0 6 467140 REDACTED 1741 1741 {2016-04-29 15:15:00} 1 2010937 2 {ET POLICY Suspicious inbound to mySQL port 3306} {2016-04-29 15:15:00} 2 bad-unknown {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
Yet other events have all their information such as this one:
Sending sguild (sock1a3e4b0) BYEventRcvd sock1ab1290 0 6 467143 REDACTED 1744 1744 {2016-04-29 15:15:03} 1 2008453 7 {ET SCAN Tomcat Auth Brute Force attempt (admin)} {2016-04-29 15:15:03} 1 unknown 169933106 10.X.X.X 169408870 10.X.X.X 6 4 5 0 151 0 0 0 0 45968 {} {} {} {} {} 51568 80 0 0 5 0 0 0 55766 0 {} {} 474554202F6367692D62696E2F61646D696E2F706172616D2E6367693F616374696F6E3D6C6973742667726F75703D416C61726D2E53746174757320485454502F312E300D0A417574686F72697A6174696F6E3A204261736963205957527461573436595752746157343D0D0A0D0A
After I updated this sensor I edited suricata.yaml to reflect local changes. I'm not sure what else is up.
Other updated sensors don't seem to be doing this. We do use vlan tagging and I made changes to mtu to account for this.
tcpdump output looks normal although I do have some suspicions the problem may be with my tap/span port. Any other things I should check for before bugging my network folks?
sostat output is attached.
Thanks.
As far as I know we don't have nor route any IPv6 traffic. To check I camped out on the line with tcpdump -ip6 and nothing came back.
I think data is not being parsed correctly. I am getting a boatload of other alerts on normal traffic between two hosts that I should not be because the data flow between those hosts does not route anywhere near where my tap would see it. (Not only that, that particular data flow is on a separate vlan.)
To confirm I camped out on the interface with tcpdump set to look for packets to/from the remote IP. Nothing comes back. If I don't see it on tcpdump, I can't imagine suricata parsing anything.
Since tcpdump looks good, I'm thinking we have scrambled bits somewhere else in the system.
> > Since tcpdump looks good, I'm thinking we have scrambled bits somewhere else in the system.
>
> If that particular data flow is on a separate vlan, did you include
> the vlan in your tcpdump bpf?
>
> Doug Burks
Resolved and case closed. This one was a bit of a headscratcher with the main oddity that it started around 0300 local time. The start time was a distraction as it pulled me off the trail that our network folks would have made any changes that could have triggered this.
It turned out we had a device that was tunneling other traffic to an analysis device. Suricata was happily digesting this traffic but since it was only partial flows it never showed complete information. Once I added the analysis device IP to bpf the problem went away.
Doug Burks
--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.