How to use shared object rules in Snort

Service providers can learn how to get shared object rules working on Snort sensors.

This Content Component encountered an error

Service provider takeaway: A Sourcefire security advisory has made using shared object rules in Snort easier for service providers.

Shared object (SO) rules were introduced in Snort 2.6.0 in early 2006 to provide a means to obscure the exact detection mechanism used in the rule and allow for more flexible detection criteria. However, for the most part, organizations have continued to rely upon traditional Snort rules. This may be about to change, in light of a recent security advisory from Sourcefire. Let's take a look at how to get shared object rules working on Snort sensors.

The first Sourcefire Vulnerability Research Team (VRT) security advisory of 2008 included the following:

"The structure of the "so_rules" directory inside the rule packages has changed. The following is a break out of the new directory structure:

 so_rules/ src/ precompiled/ 
 
  / 
  
   / 
   
     Where: 
    
      is one of the following values: a. CentOS-4.6 b. CentOS-5.1 c. FC-5 d. OSX-10.4 e. ubuntu-6.01.1 
     
       is one of the following values: a. i386 
      
        is one of the following values a. 2.6.1.5 b. 2.7.0 c. 2.8.0.1
       
There have been no changes to the src/ directory layout from previous packages.
The reason for this change is two fold. First, due to contract terms with some 3rd party research organizations, a small number of VRT certified rules will now only be delivered as binaries. This change applies only to SO rules. Non-SO rules will not be affected. Additionally, because of this change and to better serve the Snort community the VRT will pre compile the "SO" rules so they are easier to use on the various platforms utilized by the snort community and the VRT subscribers.
If your platform / distribution is not currently listed above this does not mean these shared objects won't work on your platform. Numerous Linux distributions share common libc versions and it is possible that one of the above distributions and platforms will work on your system. If none of the above combinations work on your platform, please send a note to the snort-sigs mailing list so we can determine the need for additional platforms and distributions to be added to the list of supported platforms."
Preparing a platform
In most Snort Reports I use FreeBSD as my operating system. In this Snort Report I use CentOS 5.1. You'll see why later.
I install CentOS 5.1 but don't select any additional packages during the installation process. I use yum to add the following packages prior to compiling Snort:
 # yum install gcc # yum install libpcap-devel # yum install pcre-devel
I download and extract snort-2.8.0.1.tar.gz to /usr/local/src and ran ./configure, make and make install.
 # ./configure --enable-dynamic-plugin --prefix=/usr/local/snort-2.8.0.1 # make # make install
I download the Sourcefire VRT registered users rule set for CURRENT dated 2007-12-17 in /usr/local/src/snort-2.8.0.1 and verify the MD5 hash.
 # md5sum snortrules-snapshot-CURRENT.tar.gz 789a4a1f244827aa1fe34367554fa0ce snortrules-snapshot-CURRENT.tar.gz
I extract the rules into the /usr/local/src/snort-2.8.0.1 directory. This process creates a directory called so_rules. It contains these files:
 [root@centos51 so_rules]# ls -al total 312 drwxr-xr-x 2 1210 1210 4096 Dec 17 16:19 . drwxrwxrwx 13 root root 4096 Jan 21 20:53 .. -rw-r--r-- 1 1210 1210 6704 Dec 17 16:19 bad-traffic_pgm-nak-overflow.c -rw-r--r-- 1 1210 1210 368 Dec 17 16:19 bad-traffic.rules -rw-r--r-- 1 1210 1210 1783 Dec 17 16:19 category-build.pl -rw-r--r-- 1 1210 1210 4721 Dec 17 16:19 dos_igmpv3.c -rw-r--r-- 1 1210 1210 4030 Dec 17 16:19 dos_ms06-32.c -rw-r--r-- 1 1210 1210 650 Dec 17 16:19 dos.rules -rw-r--r-- 1 1210 1210 4042 Dec 17 16:19 exploit_dhcp-option-overflow.c -rw-r--r-- 1 1210 1210 7729 Dec 17 16:19 exploit_imail-ldap.c -rw-r--r-- 1 1210 1210 914 Dec 17 16:19 exploit.rules -rw-r--r-- 1 1210 1210 12552 Dec 17 16:19 exploit_squid-ntlm-auth.c -rw-r--r-- 1 1210 1210 1169 Dec 17 16:19 Makefile -rw-r--r-- 1 1210 1210 1342 Dec 17 16:19 Makefile.OSX -rw-r--r-- 1 1210 1210 881 Dec 17 16:19 _meta.c -rw-r--r-- 1 1210 1210 602 Dec 17 16:19 _meta.h -rw-r--r-- 1 1210 1210 6659 Dec 17 16:19 misc_mozilla-sslv2-cmk.c -rw-r--r-- 1 1210 1210 5500 Dec 17 16:19 misc_mysql-com-table-dump.c -rw-r--r-- 1 1210 1210 706 Dec 17 16:19 misc.rules -rw-r--r-- 1 1210 1210 255 Dec 17 16:19 netbios.rules -rw-r--r-- 1 1210 1210 8570 Dec 17 16:19 netbios_writex.c -rw-r--r-- 1 1210 1210 337 Dec 17 16:19 nntp.rules -rw-r--r-- 1 1210 1210 5786 Dec 17 16:19 nntp_xhdr-bo.c -rw-r--r-- 1 1210 1210 261 Dec 17 16:19 p2p.rules -rw-r--r-- 1 1210 1210 5025 Dec 17 16:19 p2p_winny.c -rw-r--r-- 1 1210 1210 9056 Dec 17 16:19 smtp_exchange-base64.c -rw-r--r-- 1 1210 1210 6029 Dec 17 16:19 smtp_ipswitch-rcptto-overflow.c -rw-r--r-- 1 1210 1210 684 Dec 17 16:19 smtp.rules -rw-r--r-- 1 1210 1210 157 Dec 17 16:19 test.conf -rw-r--r-- 1 1210 1210 7910 Dec 17 16:19 web-client_quicktimejpeg-underflow.c -rw-r--r-- 1 1210 1210 326 Dec 17 16:19 web-client.rules

Let's take a look at a few of these files, starting with nntp.rules.
SO rules
 # cat nntp.rules ## Autogenerated skeleton rules file. Do NOT edit by hand #alert tcp $EXTERNAL_NET 119 -> $HOME_NET any (msg:"NNTP XHDR buffer overflow attempt"; metadata: engine shared, soid 3|12636; sid:12636; gid:3; rev:1; classtype:attempted-user; reference:url,www.microsoft.com/technet/security/bulletin/ms07-056.mspx; reference:cve,2007-3897; )

If you're familiar with traditional Snort rules, this nntp.rules
More information
Learn more about Snort rules and shared object rules.
 
 
 file looks different. You may notice the "metadata" tag. The "engine shared" portion tells Snort this is a shared library rule. The "soid" portion indicates the Shared Library Rule Generator and SID follow. Here we see those values are 3 (meaning "snort dynamic alert" as listed in gen-msg.map) and 12636, which is the Snort ID for this rule.
You might wonder how this rule detects anything. There's no content match, and the only item of interest in the header is source port 119 TCP.
The real work is done in the file nntp_xhdr-bo.c. Let's look at portions of this file for introductory purposes:
 /* * NNTP XHDR buffer overflow attempt * * Copyright (C) 2007 Sourcefire, Inc. All Rights Reserved * * Written by Patrick Mullen 
 
  
Notice this file relies on two header files:
 #include "sf_snort_plugin_api.h" #include "sf_snort_packet.h"
Here we see the rule header:
 Rule ruleNNTP_XHDR_BO = { /* rule header */ { IPPROTO_TCP, /* proto */ EXTERNAL_NET, /* SRCIP */ "119", /* SRCPORT */ 0, /* DIRECTION */ HOME_NET, /* DSTIP */ "any", /* DSTPORT */ },

That matches looking for source port 119 TCP as we saw earlier. If you continue reviewing the contents of nntp_xhdr-bo.c you'll see more C code.
Putting SO rules to work
What do we do with this? If you run "make" in the so_rules directory, several new files appear. Looking specifically for output related to nntp, you see the following:
 building nntp ... cc -c -ggdb -I. -I.. -I../.. -I../src/dynamic-preprocessors/include/ -I/usr/include -I../src/dynamic-examples/dynamic-rule/ -fPIC -D DETECTION_LIB_NAME=\"nntp\" -o nntp.o nntp.c cc -c -ggdb -I. -I.. -I../.. -I../src/dynamic-preprocessors/include/ -I/usr/include -I../src/dynamic-examples/dynamic-rule/ -fPIC -D DETECTION_LIB_NAME=\"nntp\" -o _meta.o _meta.c done

Instead of just nntp.rules and nntp_xhdr-bo.c, we have:
 # ls -al nntp* -rw-r--r-- 1 root root 116 Jan 21 21:31 nntp.c -rw-r--r-- 1 root root 5140 Jan 21 21:31 nntp.o -rw-r--r-- 1 1210 1210 335 Jan 21 21:31 nntp.rules -rwxr-xr-x 1 root root 21608 Jan 21 21:31 nntp.so -rw-r--r-- 1 1210 1210 5786 Dec 17 16:19 nntp_xhdr-bo.c -rw-r--r-- 1 root root 12356 Jan 21 21:31 nntp_xhdr-bo.o
The file command tells us more about these:
 # file nntp* nntp.c: ASCII C program text nntp.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped nntp.rules: ASCII text nntp.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped nntp_xhdr-bo.c: ASCII C program text nntp_xhdr-bo.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
Remember, we started with nntp.rules and nntp_xhdr-bo.c. In reality, we could've simply started with nntp_xhdr-bo.c, as would be the case if we were writing our own Snort shared object rule. I'll return to that possibility later.
The make command created all of the new files: nntp.c, nntp.o, nntp.so and nntp_xhdr-bo.o.
The file nntp.c is very simple:
 #include "sf_snort_plugin_api.h" extern Rule ruleNNTP_XHDR_BO; Rule *rules[] = { &ruleNNTP_XHDR_BO, NULL };

The file nntp.o is an object file generated by the compiler. We can run the nm utility to display symbols, or the names of variables and functions in the object file nntp.o.
 # nm nntp.o U ruleNNTP_XHDR_BO 00000000 D rules
The U flag means "the symbol is undefined." The D flag means "the symbol is in the initialized data section." I only run nm here to demonstrate the nature of the file.
The file nntp.so is a shared object, also called a shared library. It'll be used to call the NNTP_XHDR_BO rule when Snort is started. In fact, nntp.so is the actual SO rule file that will be called upon when we start Snort. The file nntp_xhdr-bo.o is an object file created from the nntp_xhdr-bo.c file.
We're ready to see if Snort will include the SO rule nntp.rules when it starts.
Configuring Snort
To use the new shared object rule, we need to adjust the snort.conf file. You can do this by replacing the entries related to dynamic rules in the snort.conf file with entries reflecting your Snort installation or by commenting out the existing entries for dynamic rules in snort.conf and calling the right switches at runtime.
I comment out all of the references to dynamic capabilities in the snort.conf file and use runtime switches. I create a copy of the snort.conf file called snort.conf.2.8.0.1 and make changes there.
To see the runtime options for dynamic rules, I run snort -h (or check the Snort main page and manual):
 --dynamic-engine-lib 
 
   Load a dynamic detection engine --dynamic-engine-lib-dir 
  
    Load all dynamic engines from directory --dynamic-detection-lib 
   
     Load a dynamic rules library --dynamic-detection-lib-dir 
    
      Load all dynamic rules libraries from directory --dump-dynamic-rules 
     
       Creates stub rule files of all loaded rules libraries --dynamic-preprocessor-lib 
      
        Load a dynamic preprocessor library --dynamic-preprocessor-lib-dir 
       
         Load all dynamic preprocessor libraries from directory
        
Let's see if we can run Snort and include our new nntp.so SO rule. First I define a variable to decrease the size of the directory paths I need to pass. I'm starting Snort from the directory where I extracted the source and rules (etc/ directory) so I don't need to copy various files into /usr/local/snort-2.8.0.1 as I would do in production. Snort's output follows:
 # SNORTLIB=/usr/local/snort-2.8.0.1/lib/; export SNORTLIB [root@centos51 ~]# cd /usr/local/src/snort-2.8.0.1/etc [root@centos51 etc]# /usr/local/snort-2.8.0.1/bin/ snort -c snort.conf.2.8.0.1 \ > --dynamic-engine-lib-dir=$SNORTLIB/snort_dynamicengine \ > --dynamic-detection-lib-dir=$SNORTLIB/snort_dynamicrules \ > --dynamic-preprocessor-lib-dir=$SNORTLIB/snort_dynamicpreprocessor \ > --dynamic-detection-lib=/usr/local/src/snort-2.8.0.1/so_rules/nntp.so \ > -l /tmp Running in IDS mode --== Initializing Snort ==-- Initializing Output Plugins! Initializing Preprocessors! Initializing Plug-ins! Parsing Rules file snort.conf.2.8.0.1 ...edited... Loading all dynamic engine libs from /usr/local/snort-2.8.0.1/lib/ snort_dynamicengine... Loading dynamic engine /usr/local/snort-2.8.0.1/lib/snort_dynamicengine/libsf_engine.so... done Finished Loading all dynamic engine libs from /usr/local/snort-2.8.0.1/lib/snort_dynamicengine Loading all dynamic detection libs from /usr/local/snort-2.8.0.1/lib/snort_dynamicrules... Loading dynamic detection library /usr/local/snort-2.8.0.1/lib/snort_dynamicrules/ lib_sfdynamic_example_rule.so... done Finished Loading all dynamic detection libs from /usr/local/snort-2.8.0.1/lib/snort_dynamicrules Loading dynamic detection library /usr/local/src/snort-2.8.0.1/ so_rules/nntp.so... done Loading all dynamic preprocessor libs from /usr/local/snort-2.8.0.1/lib/snort_dynamicpreprocessor... Loading dynamic preprocessor library /usr/local/snort-2.8.0.1/lib/snort_dynamicpreprocessor/ libsf_ftptelnet_preproc.so... done Loading dynamic preprocessor library /usr/local/snort-2.8.0.1/lib/snort_dynamicpreprocessor/ libsf_smtp_preproc.so... done Loading dynamic preprocessor library /usr/local/snort-2.8.0.1/lib/snort_dynamicpreprocessor/ lib_sfdynamic_preprocessor_example.so... done Loading dynamic preprocessor library /usr/local/snort-2.8.0.1/lib/snort_dynamicpreprocessor/ libsf_dns_preproc.so... done Loading dynamic preprocessor library /usr/local/snort-2.8.0.1/lib/snort_dynamicpreprocessor/ libsf_dcerpc_preproc.so... done Loading dynamic preprocessor library /usr/local/snort-2.8.0.1/lib/snort_dynamicpreprocessor/ libsf_ssh_preproc.so... done Finished Loading all dynamic preprocessor libs from /usr/local/snort-2.8.0.1/lib/snort_dynamicpreprocessor ...edited... Initializing rule chains... 8559 Snort rules read 8559 detection rules 0 decoder rules 0 preprocessor rules 8559 Option Chains linked into 493 Chain Headers 0 Dynamic rules ...edited... --== Initialization Complete ==-- ,,_ -*> Snort! <*- o" )~ Version 2.8.0.1 (Build 72) '''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html (C) Copyright 1998-2007 Sourcefire Inc., et al. Using PCRE version: 6.6 06-Feb-2006 Rules Engine: SF_SNORT_DETECTION_ENGINE Version 1.6 
 
   Rules Object: nntp Version 1.0 
  
    Rules Object: Snort_Dynamic_Rule_Example Version 1.0 
   
     Preprocessor Object: SF_SSH Version 1.0 
    
      Preprocessor Object: SF_DCERPC Version 1.0 
     
       Preprocessor Object: SF_DNS Version 1.0 
      
        Preprocessor Object: SF_Dynamic_Example_Preprocessor Version 1.0 
       
         Preprocessor Object: SF_SMTP Version 1.0 
        
          Preprocessor Object: SF_FTPTELNET Version 1.0 
         
           Not Using PCAP_FRAMES ^C Snort exiting

         
        
       
      
     
    
   
  
 

The key items for our purposes appear in the Rules Engine and Rules Object parts of the output. We can see our nntp Rules Object is loaded. The Snort_Dynamic_Rule_Example is loaded because we passed this configuration item at runtime:
 --dynamic-detection-lib-dir=$SNORTLIB/snort_dynamicrules
A look in that directory reveals these files. I've replaced:
 /usr/local/snort-2.8.0.1/lib//snort_dynamicrules/lib_sfdynamic_example
in the following output with PLACEHOLDER for readability.
 ]# file $SNORTLIB/snort_dynamicrules /usr/local/snort-2.8.0.1/lib//snort_dynamicrules: directory [root@centos51 etc]# file $SNORTLIB/snort_dynamicrules/* PLACEHOLDER.a: current ar archive PLACEHOLDER.la: ASCII English text PLACEHOLDER.so: symbolic link to `lib_sfdynamic_example_rule.so.0.0.0' PLACEHOLDER.0: symbolic link to `lib_sfdynamic_example_rule.so.0.0.0' PLACEHOLDER.so.0.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped

So far we seem to be making progress. Did the last invocation of Snort really include our new SO rule?
Including SO rules we compiled
It turns out we need to tell Snort where to find the nntp.rules "stub" file created when we ran "make" in the so_rules directory earlier.
I copy nntp.rules to the Snort rules directory as so_nntp.rules. This prevents a conflict with the normal nntp.rules file containing traditional Snort signatures.
 [root@centos51 snort-2.8.0.1]# cp so_rules/ nntp.rules rules/so_nntp.rules

Next I add the following to snort.conf.2.8.0.1:
 include $RULE_PATH/so_nntp.rules

Finally I rerun Snort using the method last shown.
 Running in IDS mode --== Initializing Snort ==-- Initializing Output Plugins! Initializing Preprocessors! Initializing Plug-ins! Parsing Rules file snort.conf.2.8.0.1 ...edited... Initializing rule chains... 8560 Snort rules read 8560 detection rules 0 decoder rules 0 preprocessor rules 8560 Option Chains linked into 493 Chain Headers 0 Dynamic rules ...edited... DynamicPlugin: Rule [3:109] not enabled in configuration, rule will not be used. DynamicPlugin: Rule [3:637] not enabled in configuration, rule will not be used. ...edited...

Previously we saw 8,559 Snort rules read. Now we have 8,560 and two errors. What's wrong?
It turns out we need to add a "stub" file for the example dynamic rules we invoked if we want to remove these errors. We can create this file if we invoke Snort by adding this switch:
 --dump-dynamic-rules=/tmp
The result appears next:
 ...edited... Dumping dynamic rules... Dumping dynamic rules for Library nntp 1.0.1 Dumping dynamic rules for Library Snort_Dynamic_Rule_Example 1.0.1 Finished dumping dynamic rules. ================================================== Snort received 0 packets ...edited... Snort exiting
We have two new files in /tmp now:
 # ls /tmp nntp.rules Snort_Dynamic_Rule_Example.rules
The first is identical to our so_nntp.rules file. Note that all of this is one line in the original, but here I've broken it for readability.
 [root@centos51 etc]# cat /tmp/nntp.rules # Autogenerated skeleton rules file. Do NOT edit by hand alert tcp $EXTERNAL_NET 119 -> $HOME_NET any (msg:"NNTP XHDR buffer overflow attempt"; metadata: engine shared, soid 3|12636; sid:12636; gid:3; rev:1; classtype:attempted-user; reference:url,www.microsoft.com/technet/security/bulletin/ms07-056.mspx; reference:cve,2007-3897; )

The second contains entries for gid 3 sid 109 and gid 3 sid 637:
 # cat /tmp/Snort_Dynamic_Rule_Example.rules # Autogenerated skeleton rules file. Do NOT edit by hand alert tcp $HOME_NET 12345:12346 -> $EXTERNAL_NET any (msg:"BACKDOOR netbus active"; metadata: engine shared, soid 3|109; sid:109; gid:3; rev:5; classtype:misc-activity; reference:arachnids,401; ) alert udp $EXTERNAL_NET any <> $HOME_NET any (msg:"SCAN Webtrends Scanner UDP Probe"; metadata: engine shared, soid 3|637; sid:637; gid:3; rev:3; classtype:attempted-recon; reference:arachnids,308; )

I copy the file to the rules directory and add another entry to snort.conf.2.8.0.1:
 # cp /tmp/Snort_Dynamic_Rule_Example.rules ../rules/ include $RULE_PATH/Snort_Dynamic_Rule_Example.rules
When I run Snort again, I don't get the errors and my rule count has increased accordingly:
 Initializing rule chains... 8562 Snort rules read 8562 detection rules 0 decoder rules 0 preprocessor rules 8562 Option Chains linked into 495 Chain Headers 0 Dynamic rules
The rule count has increased by two again. This means we have one SO rule loaded by so_nntp.rules and two SO rules loaded by Snort_Dynamic_Rule_Example.rules.
Don't be confused by the line "0 Dynamic rules." Dynamic in this case refers to Dynamic/Activate rules, which are being phased out in favor of a combination of tagging and flowbits.
At the end of this process we have three shared object rules working in Snort.
Investigating SO rules compiled by Sourcefire
In addition to explaining the new directory structure of the SO rules Sourcefire provides, the rule advisory I mentioned previously also explains how Sourcefire created two SO rules to detect activity related to Microsoft Security Bulletin (MS08-001): "Shared object rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 3 and SIDs 13287 and 13288."
Since we are using CentOS 5.1, let's see what Sourcefire provides.
A look in the so_rules directory of the VRT Subscription rule set shows the following:
 bad-traffic.rules misc.rules p2p.rules src dos.rules netbios.rules precompiled web-client.rules exploit.rules nntp.rules smtp.rules
If we grep for 13287 or 13288 we will find which SO rules address MS08-001.
 grep 13287 * bad-traffic.rules:#alert ip any any <> any any (msg:"BAD-TRAFFIC Windows remote kernel tcp/ip igmp vulnerability exploit attempt"; metadata: engine shared, soid 3|13287; sid:13287; gid:3; rev:1; classtype:attempted-admin; reference:cve,2007-5348; reference:url,www.microsoft.com/technet/security/Bulletin/MS08-001.mspx; ) grep 13288 * bad-traffic.rules:#alert icmp $HOME_NET any <> 224.0.0.1 any (msg:"BAD-TRAFFIC Windows remote kernel tcp/ip icmp vulnerability exploit attempt"; metadata: engine shared, soid 3|13288; sid:13288; gid:3; rev:1; classtype:attempted-admin; reference:cve,2007-5354; reference:url,www.microsoft.com/technet/security/Bulletin/MS08-001.mspx; )

We see that bad-traffic.rules contains the SO rules for MS08-001. Remember that bad-traffic.rules (here the SO version, not the traditional bad-traffic.rules containing normal Snort signatures) is just a stub. We need to find a shared object file called bad-traffic.so precompiled by Sourcefire for our version of Snort and our OS.
A look in the so_rules/src directory shows the following:
 bad-traffic_pgm-nak-overflow.c misc_mozilla-sslv2-cmk.c category-build.pl misc_mysql-com-table-dump.c dos_igmpv3.c netbios_writex.c dos_ms06-32.c nntp_xhdr-bo.c exploit_dhcp-option-overflow.c p2p_winny.c exploit_imail-ldap.c smtp_exchange-base64.c exploit_squid-ntlm-auth.c smtp_ipswitch-rcptto-overflow.c Makefile test.conf _meta.c web-client_quicktimejpeg-underflow.c _meta.h
This is similar to the so_rules directory provided in the Sourcefire VRT registered user release. These are C source code for SO rules. You could run "make" in this directory as described earlier. However, none of these address MS08-001.
The so_rules/precompiled directory shows the five platforms for which Sourcefire compiles SO rules:
 CentOS-4.6 CentOS-5.0 FC-5 OSX-10.4 ubuntu-6.01.1
Since we are running Centos5.1 we'll look in that directory. Because we're running Snort 2.8.0.1, we choose that path too.
A look in the so_rules/precompiled/CentOS-5.0/i386/2.8.0.1 directory shows the following:
 bad-traffic.so exploit.so netbios.so p2p.so web-client.so dos.so misc.so nntp.so smtp.so
These are precompiled SO rules. The file bad-traffic.so is the SO rule file we need. In fact, if we run nm against it and grep for one of our MS08-001 Snort IDs (say 13287) we get some interesting results:
 # nm bad-traffic.so | grep 13287 00001200 D rule13287 000010f4 d rule13287byte_test2 00001160 d rule13287content1 00000720 T rule13287eval 000010e0 d rule13287ip_proto0 00001140 d rule13287option0 00001180 d rule13287option1 00001188 d rule13287option2 000011ac D rule13287options 00001190 d rule13287ref1 00001198 d rule13287ref2 000011a0 d rule13287refs
These symbols show that bad-traffic.so indeed addresses MS08-001.
You can also run the strings command to see mention of MS08-001.
Including SO rules compiled by Sourcefire
Now that we know we want to use the shared object version of bad-traffic.rules and the SO rule bad-traffic.so to detect MS08-001, let's add that to our Snort configuration. First I copy Sourcefire's VRT shared object version of bad-traffic.rules to our rules/ directory as vert-so-bad-traffic.rules. Next I copy the Sourcefire VRT shared object file bad-traffic.so to our so_rules/ directory as vrt-so-bad-traffic.so. (I don't want to overwrite the bad-traffic.so file I compiled myself.) Finally we need to add the following line to snort.conf.2.8.0.1:
 include $RULE_PATH/vrt-so-bad-traffic.rules
With these changes made we start Snort again.
 # cd /usr/local/src/snort-2.8.0.1/etc # SNORTLIB=/usr/local/snort-2.8.0.1/lib/ ; export SNORTLIB # /usr/local/snort-2.8.0.1/bin/snort -c snort.conf.2.8.0.1 \ > --dynamic-engine-lib-dir=$SNORTLIB/ snort_dynamicengine \ > --dynamic-detection-lib-dir=$SNORTLIB/ snort_dynamicrules \ > --dynamic-preprocessor-lib-dir=$SNORTLIB/ snort_dynamicpreprocessor \ > --dynamic-detection-lib=/usr/local/src/snort-2.8.0.1/ so_rules/nntp.so \ > --dynamic-detection-lib=/usr/local/src/snort-2.8.0.1/ so_rules/vrt-so-bad-traffic.so \ > -l /tmp

During startup I see this:
 ...truncated... Initializing rule chains... 8562 Snort rules read 8562 detection rules 0 decoder rules 0 preprocessor rules 8562 Option Chains linked into 495 Chain Headers 0 Dynamic rules ...edited... DynamicPlugin: Rule [3:13287] not enabled in configuration, rule will not be used. DynamicPlugin: Rule [3:13288] not enabled in configuration, rule will not be used. DynamicPlugin: Rule [3:8351] not enabled in configuration, rule will not be used. ...truncated...

What's the problem? It turns out the three rules in vrt-so-bad-traffic.rules are all commented out. If I uncomment them Snort works properly.
 ...edited... Initializing rule chains... 8565 Snort rules read 8565 detection rules 0 decoder rules 0 preprocessor rules 8565 Option Chains linked into 497 Chain Headers 0 Dynamic rules ...edited... Rules Engine: SF_SNORT_DETECTION_ENGINE Version 1.6 
 
   Rules Object: nntp Version 1.0 
  
    Rules Object: bad-traffic Version 1.0 
   
     Rules Object: Snort_Dynamic_Rule_Example Version 1.0 
    
      ...truncated...
     
The addition of the three rules (8,565 instead of 8,562) and the lack of errors show Snort is running with the new Sourcefire VRT SO rules for MS08-001.
Conclusion
This article has demonstrated how to use shared object rules in your environment. I've asked Sourcefire to precompile SO rules for FreeBSD 6.x and 7.x. At some point in the future I would like to take a deeper look at SO rules as well.
About the author
Richard Bejtlich is the founder of TaoSecurity, author of several books on network security monitoring, including
Extrusion Detection: Security Monitoring for Internal Intrusions, and operator of the TaoSecurity blog.
This was first published in February 2008

Dig deeper on Network security products, technologies, services

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

MicroscopeUK

SearchCloudProvider

SearchSecurity

SearchStorage

SearchNetworking

SearchCloudComputing

SearchConsumerization

SearchDataManagement

SearchBusinessAnalytics

Close