How to use shared object rules in Snort

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:

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:

I download and extract snort-2.8.0.1.tar.gz to /usr/local/src and ran ./configure, make and 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.

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:

Let's take a look at a few of these files, starting with nntp.rules.

SO rules

If you're familiar with traditional Snort rules, this nntp.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:

Notice this file relies on two header files:

Here we see the rule header:

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:

Instead of just nntp.rules and nntp_xhdr-bo.c, we have:

The file command tells us more about these:

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:

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.

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):

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:

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:

A look in that directory reveals these files. I've replaced:

in the following output with PLACEHOLDER for readability.

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.

Next I add the following to snort.conf.2.8.0.1:

Finally I rerun Snort using the method last shown.

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:

The result appears next:

We have two new files in /tmp now:

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.

The second contains entries for gid 3 sid 109 and gid 3 sid 637:

I copy the file to the rules directory and add another entry to snort.conf.2.8.0.1:

When I run Snort again, I don't get the errors and my rule count has increased accordingly:

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:

If we grep for 13287 or 13288 we will find which SO rules address MS08-001.

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:

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:

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:

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:

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:

With these changes made we start Snort again.

During startup I see this:

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.

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.