My Life With Porkchop

I’ve been riding the Snort-bus for a long time now, it’s a basic building block of any NSM I cobble together and I have great trust in it to do what I expect it to do.

That said, I have never run it inline outside of a PoC lab, not that you can’t, I just haven’t.

Why Tune Snort

If you are already running Snort and ostensibly using Pulledpork for rule management and even using a pre-configured ruleset (I like Balanced) do you even need to tune Snort?

Yes and No.

It is not imperative, Snort will run fine as is, no doubt, but it may also spend it’s days and nights processing rules against network traffic unnecessarily. For example; say a group of enabled rules looks for attacks against a DEC MicroVax and after looking high and low, you have concluded you do not have one on your network. Do you still need that rule? No, you do not, and you especially do not if that rule is run often and is expensive i.e. uses an unreasonable amount of compute to do nothing useful.

This is where profiling comes in, seek out the expensive rules and determine their utility and tune accordingly.

First up…

How to Start Profiling

Edit snort.conf and look for these lines:

config profile_rules: print 25, sort avg_ticks, filename rule_stats.txt append

config profile_preprocs: print 10, sort avg_ticks, filename preproc_stats.txt append

Uncomment and edit them as you see fit, the above config will log the top 25 worst performing rules and top 10 most resource intensive preprocessors whenever Snort restarts. We’re not overly concerned with the preprocessors at present.

In this instance I am appending to the log files (rather than overwriting) to monitor rules over time. After some time goes by, let’s say a month or so, you can sort out the log with some sloppy shell fu:

cat rule_stats.txt | awk '{ print $2 }' | sort | uniq -c | sort -nr | head 10

This will give you an idea of which rules are not only poor performers, but are also being set off more frequently.

One thing to keep in mind, some rules are greedy, and by that I mean they run against all kinds of packet traffic being initially matched with wide reaching any->any or similar expressions. Combine that with expensive PCRE type content matching and you are likely to have an expensive rule.

Style - Profile

(If you missed the Beastie Boys ref, today is a sad day)

timestamp: 1608035316
Rule Profile Statistics (worst 25 rules)
==========================================================
   Num      SID GID Rev     Checks   Matches    Alerts           Microsecs  Avg/Check  Avg/Match Avg/Nonmatch   Disabled
   ===      === === ===     ======   =======    ======           =========  =========  ========= ============   ========
     1    30144   1   4          4         0         0                 593      148.5        0.0        148.5          0
     2    36018   1   2        139         0         0               14991      107.9        0.0        107.9          0
     3    27607   1   3          2         0         0                 186       93.3        0.0         93.3          0
     4    30956   1   2       8908         0         0              801936       90.0        0.0         90.0          0
     5    38485   1   2         13         0         0                1160       89.2        0.0         89.2          0

Excerpt from Snort manual:

The columns represent:

Number (rank)
Sig ID
Generator ID
Checks (number of times rule was evaluated after fast pattern match within portgroup or any-$>$any rules)
Matches (number of times ALL rule options matched, will be high for rules that have no options)
Alerts (number of alerts generated from this rule)
CPU Ticks
Avg Ticks per Check
Avg Ticks per Match
Avg Ticks per Nonmatch

The best candidates for a closer look with be rules that not only use higher Ticks, but those that get Checked often, especially if they do not Match.

In this case 30956 is a good example of something worth looking into:

grep 30956 /usr/local/etc/snort/rules/snort.rules

alert tcp $EXTERNAL_NET $FILE_DATA_PORTS -> $HOME_NET any (msg:"BROWSER-IE Microsoft Internet Explorer deleted object memory corruption attempt"; flow:to_client,established; file_data; content:"<dir"; nocase; content:"<sub"; nocase; content:"fireEvent"; nocase; content:"onfocus"; within:20; content:"attachEvent"; nocase; content:"onfocusout"; within:20; nocase; content:"attachEvent"; distance:0; nocase; content:"onfocusout"; within:20; nocase; metadata:policy balanced-ips drop, policy max-detect-ips drop, policy security-ips drop, service ftp-data, service http, service imap, service pop3; reference:cve,2014-0310; reference:url,technet.microsoft.com/en-us/security/bulletin/MS14-029; classtype:attempted-user; sid:30956; rev:2;

MS14-029 - hopefully patched long ago, hopefully you’re not even running IE in your environment in 2021. I would say this is a great candidate for a disablesid.conf entry in pulledpork.