Rule alert question

[sfear...@gmail.com]

The following rule seems to be alerting but I believe it should not be given how snort.conf is configured.

Rule

alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any (msg:"GPL SHELLCODE x86 inc ebx NOOP"; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; classtype:shellcode-detect; sid:2101390; rev:8;)

I'm seeing external IP address sources with source port 80 being flagged with this alert going towards internal RFC1918 address.

snort.conf

ipvar HOME_NET [192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]
ipvar EXTERNAL_NET any

Further down
# List of ports you want to look for SHELLCODE on.
portvar SHELLCODE_PORTS !80

Thanks,
Scott F.

[Joel Esler]

So you are observing return traffic?

> --
> 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 http://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.

[sfear...@gmail.com]

Well, it was traffic coming from a remote IP on port 80 to an internal client, so yes. My limited understanding of snort rules and the snort.conf leads me to believe that the rule shouldn't fire under these conditions due to the exclusion of port 80 from SHELLCODE_PORTS.

Do I need to modify the rule to use flow and track the state instead of it relying on only looking for content?

The traffic it alerted on were Linux servers reaching out to package servers, or updating their package lists. I'm curious how others handle this rule because it generates alerts that I have to filter through. The traffic is not malicious in this case.

Thanks,
Scott F.

[Doug Burks]

Replies inline.

On Thu, Jul 24, 2014 at 11:26 AM, <sfear...@gmail.com> wrote:
> Well, it was traffic coming from a remote IP on port 80 to an internal client, so yes. My limited understanding of snort rules and the snort.conf leads me to believe that the rule shouldn't fire under these conditions due to the exclusion of port 80 from SHELLCODE_PORTS.

Are you able to provide a (sanitized) ASCII transcript?

> Do I need to modify the rule to use flow and track the state instead of it relying on only looking for content?
>
> The traffic it alerted on were Linux servers reaching out to package servers, or updating their package lists. I'm curious how others handle this rule because it generates alerts that I have to filter through. The traffic is not malicious in this case.

Have you considered suppressing this alert for the package servers?
https://code.google.com/p/security-onion/wiki/ManagingAlerts#Suppressions


--
Doug Burks
http://securityonionsolutions.com

[sfear...@gmail.com]

Doug

Attached is a sanitized transcript. I realized after reading the transcript that it's showing my internal 10.10.10.10 reaching out. I did this by issuing a "sudo yum update" without actually going through with package update on one of the systems in our network. I should note that the actual alert in Sguil shows the remote side with port 80 as the source though.

I have considered the threshold.conf method, but unfortunately the repos are a pool of IP addresses so it would be difficult to add all of them, at least I think that's the case. Creating an internal package server would be desirable, but it's not something I can push for at this time.

I did some research and it seems the rule is fairly broad. I found a page where someone explained with example on how to modify the rule to only alert on traffic matching the content from an outside initiated connection.

This is what I considered adding to my local.rules while disabling the original.

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"GPL SHELLCODE x86 inc ebx NOOP"; flow:to_server,established; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; classtype:shellcode-detect; sid:9001390; rev:8;)

Thanks,
Scott F.

[Samson H]

> This is what I considered adding to my local.rules while disabling the original.
>
> alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"GPL SHELLCODE x86 inc ebx NOOP"; flow:to_server,established; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; classtype:shellcode-detect; sid:9001390; rev:8;)

I have the exact same issue as the original post. SGUIL seems to mix up the External IP and Internal IP for this rule. Once I examine the pcap I can see right away that my Internal IP (NOT the External IP) was the source and my Internal IP was in fact NOT using source port 80.

I am using this rule change you threw out to try in my environment in hopes it will cut down on some false positives.

Thanks for the post Guys