I just noticed my snort rules fired today on this, on a brand new ossim server I was testing. "shellcode x86 inc ebx noo" on with the source ip from Canada. Why might a brand new server, behind a firewall and a NAT router, see an alert like this coming from an external IP?

  • You should provide the snort rule that fired and if possible, a sample of the traffic (in anonymised format) otherwise your question is a little hard to answer and there's some guesswork in what you mean. I believe that it was the rule below that fired though, is that correct? alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any (msg:"GPL SHELLCODE x86 inc ebx NOOP"; content:"CCCCCCCCCCCCCCCCCCCCCCCC"; fast_pattern:only; classtype:shellcode-detect; sid:1390; rev:6;) – Mark Hillick Jun 17 '12 at 12:14
  • I would follow up with the question, "any ideas about what?" Who sent it? Why? What it is? We have no idea what you want help with. – schroeder Jun 18 '12 at 14:41
  • Unfortunately, this is too old for me to do much better on with the details. I must have had my notifications of replies not setup properly at the time because I just noticed that I never came back to this question after it got comments. Now reading the feedback, I just tried to clarify and generalize the question just in case others stumble upon this question. I recall at the time, and in subsequent investigations, that the IP I noticed "right out of the box" turned out to be related to Ubuntu updates. The answer left by @ScottPack would have helped me at the time both understand, and tweak – beauk Feb 12 '17 at 16:00

For sake of argument, let's assume you're referring to the rule mentioned by Mark in his comment. This works out well since when doing a full text search of your quoted text across all VRT and ET rules, it's the only one I found as well. It is sid 1390, found in the file shellcode,rules for those keeping track at home.

The full rule text is:

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

Thankfully, this is a nice and simple rule. For the same of analysis let's also assume that this device is on your border and the IP variables have been properly configured.

So, this rule gets checked against every IP packet that comes into your organization. Already it seems pretty noisy. It looks in the payload section of the packet for the a string containing 25 consecutive 'C' characters. The reason for this is that this character maps to the inc ebx instruction for the x86 architecture (as implied by the name of the rule). In the x86 architecture this instruction is functionally equivalent to NOP, and as such can be used as part of a NOOP slide, but is slightly less obvious.

This specific rule, and many of the shellcode rules in fact, are well known generators of false positives since they can often be generated by downloading binary files. The traditional tuning advice is to disable these rules on web ports.

So, depending on your risk threshold, you can either

  1. Disable the rules entirely
  2. Modify the rule to ignore packets on "web ports"

Disabling the rules is easy, and something you should be well acquainted with if you're attempting to make reasonable use of an IDS at all. Modification can be a little trickier.

Tuning By Port Filtering

Depending on your version of Snort, you should already have two variables set in your snort.conf that will be useful. One is HTTP_PORTS and the other is SHELLCODE_PORTS. By default, they're set to rather basic values.

# Ports you run web servers on
portvar HTTP_PORTS [80,8080]

# Ports you want to look for SHELLCODE on.

What I would recommend is changing HTTP_PORTS to whatever you actually use in your environment, and then setting SHELLCODE_PORTS to the inverse of that, so something like:

# Ports you run web servers on
portvar HTTP_PORTS [80,8080]

# Ports you want to look for SHELLCODE on.

Then you can modify the Snort signature to use the appropriate port variable.

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

So now this will exclude any data coming from an external web server, so say downloading an executable from a vendor website. It is best to keep in mind that since this rule is not stateful, a malicious attacker could craft their exploit in such a way as to avoid the rule.

Tuning By State Tracking

Alternatively, we could tighten up the rule by forcing it to be stateful instead. Let's remove the port restriction and tighten up the rule to only to outside initiated communication by adding the flow keyword, turning that rule into:

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

So now the rule will look for at least 25 consecutive 'C' characters on any outside initiated communication. So while we'll now see the cases where the malicious user spoofs their source ports, in an effort to bypass firewall restrictions, we will miss cases where the exploit code is downloaded from a local host.

Analysis Paralysis

In both cases, there are obvious ways to bypass the detection routine, so which direction you choose depends entirely on your risk profile and your threshold for acceptance.

Not the answer you're looking for? Browse other questions tagged or ask your own question.