Optimizing Rules

Problem

How can I speed up my rules to perform better and identify attacks faster?

Solution

Snort rules use several recursion loops to detect possible evasion attempts. The trick to optimizing rules is to make them specific enough that they can detect matches with as few passes as possible.

One possible solution is to use several discrete or single hit keywords at the beginning of your rules to help limit the times through the engine. For example, as mentioned before, if you can write your signatures to use the HEX values of the packets rather than the ASCII translations. Then Snort need only run the packet through the engine once the first time through without having to run the packet through the ASCII translation engine, and then pass it back through the rules engine.

Discussion

We'll start with a rule to detect the MS-ITS subprotocol exploit, and then optimize it.

alert tcp any any -> any any (msg:"Possible browser hijacking"; 

content:"ms-its:mhtml:file"; content:"chm"; flags:A+; classtype:

bad-unknown; rev:4;)

First, add a filter to the rule so it only examines packets with a large enough payload size. A window of greater than 64-bytes long should only display packets that have a TCP payload.

Alert tcp any any -> any any (msg:"Possible browser hijacking"; 

dsize>64; content:"ms-its:mhtml:file"; content:"chm"; flags:A+; 

classtype: attempted-admin; rev:5;)

Then make the payload a little more accurate, by ssing the keyword within.

Alert tcp any any -> any any (msg:"Possible browser hijacking"; 

dsize>64; content:"ms-its:mhtml:file"; content:"chm"; within:10; 

flags:A+; classtype: attempted-admin; rev:6;)

Now pull the rule over the flow keyword for one last bit of accuracy.

Alert tcp any any -> any any (msg:"Possible browser hijacking"; 

dsize>64; content:"ms-its:mhtml:file"; content:"chm"; within:10;

flow:established,to_server; classtype: attempted-admin; rev:7;)

Now this rule has several very specific parameters that have to be met on the first pass through the engine, or else the alarm will fail, thus dropping out of the several pass sequence.

Keep in mind when creating rules that the more specific your rules, the faster they will process through the Snort engine and the less load on the Snort engine they will place. If you place less of a load on the Snort engine, it's less likely to drop connections and logs.

See Also

Beale, Jay. Snort 2.1 Intrusion Detection. Rockland, MA: Syngress, 2004.

Snort-sigs mailing list and posts by Brian Caswell

Blocking Attacks in Real Time