Problem solve Get help with specific problems with your technologies, process and projects.

Understand the Snort IDS Concurrent Versions System and 2.7 Beta 1 installation

Value-added resellers (VARs) learn about the Snort IDS beta 1 installation and preprocessor, and get details on how to protect against vulnerabilities prior to beta 2 by using the Snort IDS Concurrent Versions System (CVS).

Welcome to the fourth Snort Report. It's been a busy month, with new versions of Snort IDS to try and more features...

to discuss. Let's start by installing the new Snort 2.7 beta 1. First make a directory into which Snort 2.7 beta 1 will be installed.

freebsd61-generic:/usr/local/src# mkdir /usr/local/snort-2.7.0.beta1

Next download and extract the beta archive into /usr/local/src.

Change into the /usr/local/src/snort-2.7.0.beta1 directory and configure Snort, then run make and make install.

When done Snort 2.7.0 beta 1 will be available as /usr/local/bin/snort-2.7.0.beta1/bin/snort, as shown below.

The major advance in Snort 2.7.0 beta 1 is Stream5, a new preprocessor replacing the Stream4 and Flow preprocessors. Stream5 enables additional target-based detection, similar to the ideas introduced by the Frag3 preprocessor. Whereas Frag3 addressed anomalies in IP, Stream5 looks particularly at odd behavior in TCP traffic. Expect to hear more about these features in future Snort Reports.

Bejtlich Snort Reports
Fundamentals and installation tips for the channel

Upgrading Snort and understanding snort.conf

Detecting events without rules

In addition to Snort 2.7.0 beta 1, Sourcefire also released Snort in response to a vulnerability in Snort's Distributed Computing Environment / Remote Procedure Call (DCE/RPC) preprocessor, introduced in Snort 2.6.1 last fall. DCE/RPC is a method by which one computer may interact with another, popularly implemented on Microsoft Windows systems. Sometimes DCE/RPC is used with the Server Message Block (SMB) protocol over port 445 TCP or 139 TCP, and at other times it can be directly invoked over port 135 TCP or UDP. Snort's DCE/RPC preprocessor offers defragmentation of certain types of DCE/RPC messages, and the incorrect handling of those messages resulted in a vulnerability in Snort 2.6.1,,, and 2.7.0 beta 1.

Sourcefire's advisory stated that Snort 2.7.0 beta 2 would contain a fix for this vulnerability. Is there anything that can be done prior to beta 2, besides commenting out the DCE/RPC preprocessor in snort.conf? The answer is yes -- the solution lies in the Snort Concurrent Versions System (CVS) tree.

Snort, like most open source projects, provides access to a concurrent versions system (CVS) repository. Snort's CVS tree can be found at A Web-enabled version at lets users browse the Snort source code to see changes in Snort, including alterations to dcerpc.c and smb_andx_decode.c reflecting patches for the DCE/RPC vulnerability.

Two days before this report was written, Sourcefire patched dcerpc.c and smb_andx_decode.c. Therefore, if we check out the latest version of Snort from CVS, we will have a version patched for the new vulnerability. First we log in to the CVS server and provide no password.

Next we check out the Snort tree using the SNORT_2_7_0 branch.

A look at the freebsd61-generic:/usr/local/src/snort directory does not reveal the configure script we expect to see with released versions of Snort. Therefore, we must create our own using the following procedure. On FreeBSD, we must add the Automake, Autoconf, and Libtool packages.

The default file looks like this:

# the list of commands that need to run before we do a compile
libtoolize --automake --copy
aclocal -I m4
automake --add-missing --copy

FreeBSD has installed the relevant tools using these names:


Rather than create symbolic links to the file names expects, I modify to reflect the files used by FreeBSD:

When finished, a configure script is now in the /usr/local/src/snort directory. Following our installation methodology, we create a directory into which the Snort CVS will be installed, then run configure, make, and make install.

A test of the Snort binary shows this is Snort 2.7.0 beta 2 (Build 14).

Using this process, you can track developments in Snort CVS at any time. You don't have to wait for Sourcefire to create a new release archive. However, you can not expect arbitrary CVS versions to be as stable or complete as released versions. Snort beta and CVS versions are best used for testing new features and should not be relied upon in production environments.

Note that in addition to the SNORT_2_7_0 branch we checked out of CVS, there is also a SNORT_2_6_1 branch. The 2.6.1 branch is the repository from which future versions of Snort 2.6.1 will be derived, such as (if necessary). You can browse this branch via the Web at this URL:

You can do the same for other branches, such as SNORT_2_7_0:

By now you are probably recognizing one of the great advantages of running open source software like Snort. With complete visibility into the source code, you can directly examine it for changes. This transparency is an excellent way to learn how the application functions and whether you can trust its design and implementation.

In the next Snort report we'll return to understanding the features of the Snort 2.6.x tree, specifically the introduction of dynamic preprocessors. In the reports that follow we'll finally enable some rules and show how Snort makes decisions that don't rely exclusively on preprocessors.

About the author
Richard Bejtlich is 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 last published in April 2007

Dig Deeper on Application security and data protection



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.