EN:Snort/Rules/SO Rules
| You are here: | SO Rules
|
FAQ
Description
The following is a copy of an answer from Kevin Ross (kevross33 at googlemail.com). The original post is available here: http://lists.emergingthreats.net/pipermail/emerging-sigs/2009-July/003142.html
A Shared Object (SO) rule is a loadable Snort module that can quickly extend the detection capabilities of Snort. Beginning with Snort 2.6.0 an API to the detection engine was added that allows anyone familiar with the C programming language to quickly extended the detection capabilities of Snort. This allows for detection of vulnerabilities that could not be detected using the using the standard text based Snort rules language.
Additionally this functionality allows the Sourcefire VRT to release protected detection modules that cannot be reviewed without binary reverse engineering. Sourcefire refers to these protected detection modules as restricted SO rules.
Why are there restricted SO rules; I thought Snort was Open Source?
To protect Sourcefire customers, open-source users, and anyone using Snort, Sourcefire has joined numerous programs like Microsoft MAPP. These programs allow vendors like Microsoft to share vulnerability information with Sourcefire, sometimes before patches are available. This allows the Sourcefire VRT to prepare detection before attackers have time to figure out what the vulnerability is and how to exploit it. Since "restricted" detection modules contain sensitive information about the vulnerabilities they provide detection for, these modules have to be protected.This is why the restricted SO rules are not in plain text, and is also the reason the C source code is not shipped in the rules snapshots.
What is a Stub-Rule?
For Snort to correctly load SO rules it needs a bit of information about the SO rules it is attempting to load. This is the function of stub-rules; a stub-rule is a plain text rule that looks very much like a standard Snort rule. However, these stub-rules don't contain any detection keywords like "content, pcre, byte_jump, etc", they only contain informational Snort keywords like "sid, gid, soid, metadata, classtype, etc". Snort uses these stub rules to determine which SO rules you want activated in your detection policy.
If the stub-rule isn't in your rules files or in your snort.conf then Snort will not attempt to load the SO rule that is associated with it.
What is a pre-compiled SO rule?
Since there are restricted SO rules the only way to deliver some content is for the Sourcefire VRT to compile the restricted SO rules and only ship the binary versions of these files. Sourcefire refers to these binary modules as pre-compiled SO rules. Catchy huh?
What is a rules snapshot?
Sourcefire refers to the packages that end-users download from snort.org which contain the rules, pre-compiled SO rules, C source for some SO rules, and other supporting documentation for the rules as rule snapshots.
I'm compiling the SO rules from source why am I missing some rules?
Some SO rules are restricted from being shipped in source-code format. They are only shipped as pre-compiled SO rules. This is why building from source doesn't result in the same number of rules as are contained in the pre-compiled SO rules.
When I download the rules snapshot file I can't find the SIDs mentioned in the advisory?
If a rule was shipped as a restricted SO file you can't just grep or do a text search for the SID anymore. You'll need to actually load all the pre-compiled SO rules and dump out the stub rules to get all the necessary SID's for Snort to use in its detection policies.
Where do I find the stub rules file for SO rules?
To get all the necessary stub rules to use for the SO rules you'll need to configure Snort to load the SO rules and then run Snort with a command line option of "—dump-dynamic-rules <path>". This will dump out all the necessary stub rules for the SOs that are loaded.
Please see the Snort manual for how to include SO rules in your snort.conf.
What platforms are supported for pre-compiled SO rules?
The currently support platform list as of 10/28/08 is the following.
- Centos 4.6 – 32bit X86
- Centos 5.0 – 32bit X86
- Centos 5.0 – 64bit X86
- Fedora Core 5 – 32bit X86
- Fedora Core 9 – 32bit X86
- Fedora Core 9 – 64bit X86
- FreeBSD 7 – 32bit X86
- Red Hat Enterprise 5.0 – 64bit X86
- Ubuntu 6.01 – 32bit X86
- Ubuntu 8.04 – 64bit X86
What do I do if the rules snapshot file doesn't include a pre-compiled binary for my OS?
For the adventurous you can try any of the supported platforms listed above, and see if they work on your platform.If they don't you can send a message to snort-feedback at snort.org for potential inclusion in a future release.
Does the VRT have plans to add support for my OS?
Right now we are considering adding a few additional platforms.The following platforms will never have support, as Snort or SO rules are incompatible with that platform.This is not a complete list of incompatible platforms.
- Windows
- AIX
- Solaris/Sun on SPARC
- HP-UX
- SGI
- IRIX
Can you modify the SO rule stubs to change HOME_NET / EXTERNAL_NET and other attributes of the rule?
Yes, anything that is exported as part of the stub rule that is the same as a normal Snort rule can be modified, and works that same way the text snort rules work.
Compile SO rules
Environment
The following has been tested on a Debian 5.0 system, with following configuration:
- Snort version: 2.9.0.4
- Snort binary: /usr/local/bin/snort
- Snort configuration files: /usr/local/etc/snort/
- Snort rules files: /usr/local/etc/snort/rules/
Compilation
Download and uncompress the rules tarball. Adapt the following line with your oinkcode:
# cd /data/src/ # wget http://www.snort.org/reg-rules/snortrules-snapshot-2904.tar.gz/d2f0a619931521866jhvdkjhvd7893c3acf441ff83 \ -O snortrules-snapshot-2904.tar.gz # tar xzvf snortrules-snapshot-2904.tar.gz
Then copy all precompiled .so to snort_dynamicrules directory:
# cp so_rules/precompiled/Debian-5-0/i386/2.9.0.4/* /usr/local/lib/snort_dynamicrules/
Compile all SO rules with snort:
# snort -c /usr/local/etc/snort/snort.conf --dump-dynamic-rules=/usr/local/etc/snort/so_rules/
You should now have following rules in your so_rules/ directory:
# ls -l /usr/local/etc/snort/so_rules/ -rw-r--r-- 1 root staff 5888 avr 19 14:26 bad-traffic.rules -rw-r--r-- 1 root staff 426 avr 19 14:26 chat.rules -rw-r--r-- 1 root staff 8698 avr 19 14:26 dos.rules -rw-r--r-- 1 root staff 64790 avr 19 14:26 exploit.rules -rw-r--r-- 1 root staff 803 avr 19 14:26 icmp.rules -rw-r--r-- 1 root staff 373 avr 19 14:26 imap.rules -rw-r--r-- 1 root staff 2838 avr 19 14:26 misc.rules -rw-r--r-- 1 root staff 2077 avr 19 14:26 multimedia.rules -rw-r--r-- 1 root staff 48016 avr 19 14:26 netbios.rules -rw-r--r-- 1 root staff 334 avr 19 14:26 nntp.rules -rw-r--r-- 1 root staff 258 avr 19 14:26 p2p.rules -rw-r--r-- 1 root staff 400 avr 19 14:26 pop3.rules -rw-r--r-- 1 root staff 4278 avr 19 14:26 smtp.rules -rw-r--r-- 1 root staff 691 avr 19 14:26 snmp.rules -rw-r--r-- 1 root staff 16738 avr 19 14:26 specific-threats.rules -rw-r--r-- 1 root staff 1853 avr 19 14:26 sql.rules -rw-r--r-- 1 root staff 33112 avr 19 14:26 web-activex.rules -rw-r--r-- 1 root staff 123719 avr 19 14:26 web-client.rules -rw-r--r-- 1 root staff 1079 avr 19 14:26 web-iis.rules -rw-r--r-- 1 root staff 4567 avr 19 14:26 web-misc.rules
Include them at the end of your snort.conf file:
# dynamic library rules include $SO_RULE_PATH/bad-traffic.rules include $SO_RULE_PATH/chat.rules include $SO_RULE_PATH/dos.rules include $SO_RULE_PATH/exploit.rules include $SO_RULE_PATH/icmp.rules include $SO_RULE_PATH/imap.rules include $SO_RULE_PATH/misc.rules include $SO_RULE_PATH/multimedia.rules include $SO_RULE_PATH/netbios.rules include $SO_RULE_PATH/nntp.rules include $SO_RULE_PATH/p2p.rules include $SO_RULE_PATH/pop3.rules include $SO_RULE_PATH/smtp.rules include $SO_RULE_PATH/snmp.rules include $SO_RULE_PATH/specific-threats.rules include $SO_RULE_PATH/sql.rules include $SO_RULE_PATH/web-activex.rules include $SO_RULE_PATH/web-client.rules include $SO_RULE_PATH/web-iis.rules include $SO_RULE_PATH/web-misc.rules