An alchemists view from the bar

Network Security Alchemy

DumbPig – Automated checking for Snort rulesets

with 3 comments

From time to time I have the honour of working with “special” snort rule-sets, ones that I’m not allowed to analyse or take away. I understand that some like to keep their detection closed, but when they have errors in them that ….

  • Prevent an import into the Sourcefire Defense Center
  • Cause detection to run like a pig
  • Incorrectly assign event priority
  • Behave in a completely different way to how the “expert writer” expected them to

… I have to sit up and bitch for a while. I also see the same problems again and again in public rule sets, so I wanted to make a way to automate my way out of pain.

Introducing DumbPig, “Because your rules are not so good actually”.

DumbPig parses a snort rule-set, and depending on command line options, will recommend “fixes” for dumb Snort rules.

Take these two dumb rules as examples:

alert ip any any -> any 53 (msg: “I found a scary DNS name woooo”; content: “woot”; sid: 1;)

drop tcp any -> $HOME_NET any (msg: “Communication with nasty host”; sid: 2; rev:1;)

Sid:1 above has some obvious problems for use in the real-world

  • The IP protocol header doesn’t have port numbers, it is common to see someone write a rule like this in an attempt to search for content in both TCP and UDP data. It is faster and correct to create two rules, one for TCP and one for UDP.
  • There isn’t a revision number, this makes it hard to track the rule through it’s evolution. This is required for importing to a Sourcefire Defense Center along with some other tools.
  • There is no classificaion data to equate what the discovery of this rule means to the user
  • There is no prioritization specification (partially due to the above)

Sid:2 Also has some other issues

  • It doesn’t do any deep-packet checks, what’s the point in wasting IPS cycles to do what a firewall or router can do much faster. This being said, Marty has recently added a Snort preprocessor for blacklisting, this rule would be a good candidate for use in this preproc.
[20:30:48]lward@drax~/Documents/Sourcefire/Tools/dumbpig$ ./

Usage dumbPig <args>
   -r or --rulefile  <rulefile>
   -s or --sensitivity <1-3> Sensitivity level, Higher the number, the higher the pass-grade
   -b or --blacklist       Enable blacklist output (see Marty's Blog post for details)
   -p or --pause           Pause for ENTER after each FAIL
   -w or --write           Filename to wite CLEAN rules to
   -q or --quiet           Suppress FAIL, only provide summary

It’s simple to use, just give it a rule file and inspect the output report. It also presents the rule in Snort multi-line format (escaped line breaks) to make it easy to read when things get complicated like the

[20:28:15]lward@drax~/Documents/Sourcefire/Tools/dumbpig$ ./ -r dumb.rules -s 3 -b

DumbPig version 0.1 -
Because I hate looking for the same dumb problems with "Private" snort rule-sets

  __,,    ( Dumb-pig says     )  
~(  oo ---( "ur rulz r not so )
  ''''    ( gud akshuly" *    )   

* Sensitivity level - 3/3
* Blacklist output ENABLED
* Processing File - dumb.rules
* Pause - 0
* Output clean rules to - 0
* Quite mode = 0

--- [FAIL] 1 on line 1 (dumb.rules) -----------------------------
 - IP rule with port number (or var that could be set to a port number).
   This is BAD and invalid syntax.
   The IP protocol doesn't have port numbers.
   If you want to inspect both UDP and TCP traffic on specific ports use two rules,
   its faster and valid syntax.
 - No revision number! Please add a rev: keyword
 - No classification specified - Please add a classtype to add correct priority rating

alert ip any any -> any 53  (
 msg:  "I found a scary DNS name woooo"; \
 content:  "woot"; \
 sid:  1; \
# alert ip any any -> any 53 (msg: "I found a scary DNS name woooo"; content: "woot"; sid: 1;)

--- [FAIL] 2 on line 2 (dumb.rules) -----------------------------
 - No classification specified - Please add a classtype to add correct priority rating
 - No deep packet checks? This rule looks more suited to a firewall or blacklist
 - IP rule without a content match. Put this in a firewall!

drop ip any -> $HOME_NET any  (
 msg:  "Communication with nasty host found"; \
 sid:  2; \
 rev: 1; \
# drop ip any -> $HOME_NET any (msg: "Communication with nasty host found"; sid: 2; rev:1;)

Add this lines to your snort.conf
preprocessor iplist: blacklist {  }
Total: 2 fails over 2 lines in dumb.rules
- Contact

Think of this as a preview release, give me feedback and find me bugs!

Download DumbPig here

Written by leonward

June 7, 2009 at 8:03 pm

Posted in Security, snort, Sourcefire

Tagged with

3 Responses

Subscribe to comments with RSS.

  1. lol, that sir.. is funny stuff!

    JJ Cummings

    June 16, 2009 at 5:23 pm

  2. About the rule “alert ip any any -> any 53 ..”, i wonder what do the “port fields” means for the IP protocol ???
    For sure they are not a port number but what is it ?

    the following rule in the default community-sip.rules triggers an alert on my snort:
    “alert ip any any -> any 5060 (msg:”COMMUNITY SIP TCP/IP message flooding directed to SIP proxy”…” but when i look at the traffic dump, not a single packet (udp or tcp) have dstport=5060 … so is it a case of “not so good rule actually” where the 5060 is totally ignored by snort ?


    May 15, 2011 at 8:46 pm

    • Yes, not such a good rule actually.

      This is another rule inline with my earlier DNS example. SIP runs over TCP or UDP, it should not be using ip for protocol.


      May 16, 2011 at 8:28 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: