alerts missing IP address

68 views
Skip to first unread message

Jeff Nucciarone

unread,
Apr 29, 2016, 11:24:05 AM4/29/16
to security-onion
One of my sensors picked up a new bad habit of reporting issues but leaving out any IP addresses. I have attached a copy of a partial screenshot demonstrating this.

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.

sguil.snapshot.jpg
sostat.txt

Doug Burks

unread,
Apr 29, 2016, 3:17:56 PM4/29/16
to securit...@googlegroups.com
Hi Jeff,

Could this be IPv6 traffic?
> --
> 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.



--
Doug Burks
Message has been deleted

Doug Burks

unread,
Apr 29, 2016, 3:39:06 PM4/29/16
to securit...@googlegroups.com
You could try searching for IPv6 addresses in the raw Bro logs in
/nsm/bro/logs/.

On Fri, Apr 29, 2016 at 3:25 PM, Jeff Nucciarone
<jeff.nu...@gmail.com> wrote:
> On Friday, April 29, 2016 at 3:17:56 PM UTC-4, Doug Burks wrote:
>> Hi Jeff,
>>
>> Could this be IPv6 traffic?
>
> Pardon my ignorance here, but how would I check for this? As far as I know we have no ipv6 traffic on our network.

Jeff Nucciarone

unread,
Apr 29, 2016, 3:47:40 PM4/29/16
to security-onion
On Friday, April 29, 2016 at 3:17:56 PM UTC-4, Doug Burks wrote:
> Hi Jeff,
>
> Could this be IPv6 traffic?

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.

Doug Burks

unread,
Apr 29, 2016, 4:00:02 PM4/29/16
to securit...@googlegroups.com
On Fri, Apr 29, 2016 at 3:47 PM, Jeff Nucciarone
<jeff.nu...@gmail.com> wrote:
> 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.

If that particular data flow is on a separate vlan, did you include
the vlan in your tcpdump bpf?

Doug Burks

Jeff Nucciarone

unread,
Apr 30, 2016, 8:33:55 AM4/30/16
to security-onion
On Friday, April 29, 2016 at 4:00:02 PM UTC-4, Doug Burks wrote:

> > 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.

Sunil Gupta

unread,
May 4, 2016, 2:13:45 PM5/4/16
to securit...@googlegroups.com
Doug,
I also notice alerts missing IP address information sometimes. Not sure if that can be due Sensor overload during that time ? 

Jeff, you can restrict the vlan traffic you like to monitor in the bpf.conf or have network folks apply configure the tap/span port with right vlans.

Thanks


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.



--
-Sunil
Reply all
Reply to author
Forward
0 new messages