The folks at Sourcefire have been working hard at creating the next generation of Snort. Martin Roesch, captain of the brave development team, is boldly taking Snort where no pig has gone before. Cyberspace, the final frontier. Seriously, the core framework for Snort is being rewritten from the ground up. With Snort turning ten in November, the development effort is about adding capabilities to Snort while allowing the current functionality, along with all the rules that have been developed over the years, to continue to work. Need more power from the engines? The Sourcefire development team is working on it. In a world where network throughput is ever increasing, the new architecture is compartmentalizing Snort’s subsystems. Snort will be multithreaded to take advantage of multi-core platforms. Marty predicts, “You’ll be running Snort on bigger and faster networks, so in version 3 we made it easier to add hardware acceleration to it.”
The Three Wise Men Speak
As readers of this blog know, I have been looking at the Bro IDS. I hope to shortly release a post on setting up Bro 1.4, which was released this Friday. It will be interesting to watch these two IDS/IPS progress in the upcoming year. With two such development efforts, it was somewhat surprising to read the news release from the Open Information Security Foundation (OIS) that “OISF Receives Grant Funding for Open Source Next Generation IDS/IPS.” Good to see that innovation is occurring in an area of security previously given up for dead (see post, “IDS/IPS: The Mark Twain of the Security World“).
For cutting edge knowledge on Snort 3 development, Martin Roesch, Leon Ward, and Richard Bejtlich are three wise men who can provide greater insight. Fortunately, they have all written posts on Snort 3:
- Snort 3 Architecture Series Part 1: Overview by Martin Roesch
- Snort 3.0 Architecture Series Part 2: Changes and Betas by Martin Roesch
- Snort 3.0 Architecture Series Part 3: The command shell by Martin Roesch
- Snort 3 Beta on Ubuntu / Debian Installation by Leon Ward
- Using SnortSP and Snort 2.8.2 by Richard Bejtlich
- The power of Snort 3.0 by Richard Bejtlich
Overview
In this post, we will be installing Snort 2.8.3.1, the Snort Security Platform (SnortSP), and the Snort 3 analytical engine. Please see Martin Roesch’s, Leon Ward’s, and Richard Bejtlich’s posts for more in-depth discussion. I am going to discuss a few basic concepts of the Snort 3 architecture, go through installation, and discuss some configuration and operation of the software. I plan on following this post with a another concerning the setup and installation of Bro 1.4. I will follow that post with an analysis of results from the two systems. At some point, we will discuss integration of results into RTIR.
The Snort 3 architecture consists of the software framework, called the Snort Security Platform (SnortSP) and engines. Sometimes SnortSP will be referred to as “the framework” or just “framework.” SnortSP is designed to perform basically as an “operating system” for packet-based network security applications, providing common functionality that all programs need. For example, it operates on the data source performing such functions as acquiring the data (DAQ), decoding, flow normalization, IP defragmentation, and stream reassembly. SnortSP is composed of the action system, attribute management system (AMS), and the dispatcher. It allows you the ability to interact with the system through the command shell and snortd. From a developer’s point of view, SnortSP is what gathers data and handles any evasive techniques or other conditions that occur in suspicious and malicious traffic. SnortSP normalizes the data and then provides this cleaned up data to the engines for inspection. The engines are analysis modules that plug into SnortSP. Sometimes the engines will be referred to as “engine modules,” “analytics modules,” or simply the “analytics.” Multiple engines can run simultaneously. Here is a reference diagram.
Some of the major features of Snort 3 include:
- Shell-based user interface with embedded scripting language
- Native IPv6, MPLS and GRE support
- Native support for inline operation
- More subsystem plugin types such as data acquisition modules, decoders and traffic analyzers
- Multithreaded execution model – multiple analysis engines may operate simultaneously on the same traffic
- Performance increases
SnortSP comes with a Snort 2.8.2 detection engine implemented as a SnortSP engine module. Annother engine that is being developed is an network contextually aware engine that will allow Snort to understand what it is defending. Marty describes network context as, “essentially data about the environment that is being defended by Snort, the composition of the hosts in the network as well as the local network composition.” The idea is that no longer will you have to manually teach Snort rules. Marty reports “You teach Snort what the network looks like so it can defend itself accordingly. It tunes itself. My end goal is to have a self-tuning protection engine.” Richard provides insight into another upcoming engine, “SnortSP is expected to support a new engine called Policy Enforcement Point (PEP), a stateless (yes, not stateful) firewall that integrates with Sourcefire’s other products. Any engine running on the SnortSP will be able to call PEP to enforce access control decisions, assuming the sensor/IPS is in a place to take such actions.” It will be very interesting to see what engines are developed. This is the power of the design, giving Snort 3 the ability to grow to meet the needs of the security community.
Installation and Configuration
Generally, it is smart to start with what you know and determine expected results. We will begin with setting up and installing the latest stable version of Snort (Snort 2.8.3.1). Once it is configure and running, we will use some test data consisting of actual attacks that occurred in 2001. This allows us to develop a baseline of expected results. After that, we will move on to installing SnortSP, which comes with a implemented version of Snort 2.8.2 detection engine. First, you will need to have libpcre version 6.0 or greater installed.
PCRE (pcre-7.8)
The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl 5. If you can install PCRE via a port specific to your operating system, that is the best way to install in order to avoid having to keep the software up-to-date. Below are the instructions for installing the software from source.
root# cd /usr/local/src /usr/local/src root# wget \ http://downloads.sourceforge.net/pcre/pcre-7.8.tar.gz?modtime=1220617433&big_mirror=0 /usr/local/src root# tar xzf pcre-7.8.tar.gz /usr/local/src root# cd pcre-7.8 /usr/local/src/pcre-7.8 root# ./configure --prefix=/usr/local/pcre /usr/local/src/pcre-7.8 root# make /usr/local/src/pcre-7.8 root# make test /usr/local/src/pcre-7.8 root# make install |
Libpcap and Large Files Support
Under some OSs, you need to compile libpcap and Snort to support large files (files large than 2G). Since the source code of libpcap will be needed for this configuration, we are going to install the resulting libpcap under /usr/local/snort. If the libpcap installed on your system does not produce an error, skip this step. You will want to follow these steps only if you get the following error when running Snort with a large file:
root# ls -lh /data/ids/full2.pcap -rw-r--r-- 1 root root 12G Oct 26 10:01 /data/ids/full2.pcap root# /usr/local/snort/bin/snort -o -A none -c /usr/local/snort/conf/snort.conf -l /logs/snort/logs \ -r /data/ids/full2.pcap Error getting stat on pcap file: /data/ids/full2.pcap: Value too large for defined data type RROR: Error getting pcaps Fatal Error, Quitting.. |
First, we need to compile large file support into libpcap. As mentioned above, we will install the libraries under /usr/local/snort.
root# cd /usr/local/src /usr/local/src root# wget http://www.tcpdump.org/release/libpcap-0.9.8.tar.gz /usr/local/src root# wget http://www.tcpdump.org/release/libpcap-0.9.8.tar.gz.sig /usr/local/src root# wget http://www.tcpdump.org/tcpdump-workers.asc /usr/local/src root# gpg --import tcpdump-workers.asc gpg: key 89E917F3: "tcpdump.org (SIGNING KEY) |
In the next section, we will discuss how to install Snort with and without large file support.
Snort (snort-2.8.3.1)
The latest release of Snort, as of this writing, is Snort 2.8.3.1. Below we will get the software, verify, configure, and install the software under the /usr/local/snort area. Please adjust this to your environment. Reminder to Mac OS X and FreeBSD users, use the md5 command instead of md5sum.
root# cd /usr/local/src /usr/local/src root# wget http://www.snort.org/dl/snort-2.8.3.1.tar.gz /usr/local/src root# wget http://www.snort.org/dl/snort-2.8.3.1.tar.gz.md5 /usr/local/src root# cat snort-2.8.3.1.tar.gz.md5 f7c03b322dae31dafc45756630f2946c snort-2.8.3.1.tar.gz /usr/local/src root# md5sum snort-2.8.3.1.tar.gz f7c03b322dae31dafc45756630f2946c snort-2.8.3.1.tar.gz /usr/local/src root# tar xzf snort-2.8.3.1.tar.gz /usr/local/src root# cd snort-2.8.3.1 |
We are going to add in support to place alerts into a MySQL database. If MYSQL installed by the system, you can use the “–with-mysql” configuration option. In a previous post, “Introduction to MySQL,” we went through the installation of MySQL into the /usr/local/mysql directory. For such an installation, the –with-mysql-includes=/usr/local/mysql/include and –with-mysql-libraries=/usr/local/mysql/lib command options must be used. In order to use the dynamic plugin libraries, Snort needs to be able to find libmysqlclient.so. On some operating systems, you may have problems. Adding LDFLAGS=”-L/usr/local/mysql/lib/mysql” should work. If you do not need to compile in large file support, you can do the compilation simply with the command:
/usr/local/src/snort-2.8.3.1 root# ./configure --prefix=/usr/local/snort \ --with-libpcre-includes=/usr/local/pcre/include \ --with-libpcre-libraries=/usr/local/pcre/lib \ --with-mysql-includes=/usr/local/mysql/include\ --with-mysql-libraries=/usr/local/mysql/lib |
For adding in large file support, and having Snort use the libpcap installed under /usr/local/snort, do that with the following command:
/usr/local/src/snort-2.8.3.1 root# CFLAGS="-D_LARGEFILE_SOURCE \ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" \ ./configure --prefix=/usr/local/snort --with-libpcap-includes=/usr/localsnort/include \ --with-libpcap-libraries=/usr/local/snort/lib \ --with-libpcre-includes=/usr/local/pcre/include \ --with-libpcre-libraries=/usr/local/pcre/lib \ --with-mysql-includes=/usr/local/mysql/include\ --with-mysql-libraries=/usr/local/mysql/lib |
After you configure Snort (with or without large file support), you continue to make and install it.
/usr/local/src/snort-2.8.3.1 root# make
/usr/local/src/snort-2.8.3.1 root# make check
/usr/local/src/snort-2.8.3.1 root# make install
/usr/local/src/snort-2.8.3.1 root# mkdir -p /usr/local/snort/etc
/usr/local/src/snort-2.8.3.1 root# cp etc/* /usr/local/snort/etc
/usr/local/src/snort-2.8.3.1 root# /usr/local/snort/bin/snort -V
,,_ -*> Snort! < *-
o" )~ Version 2.8.3.1 (Build 17)
'''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html
(C) Copyright 1998-2008 Sourcefire Inc., et al.
Using PCRE version: 7.8 2008-09-05
|
Rules
Now we need some rules. For this example we will get the rules from the Snort and the Emerging Threats site. You will need to register for the rules at the Snort site. Do consider subscribing for the latest up-to-date rules. Registered users can only access rules 30 days after their release.
root# cd /usr/local/src /usr/local/src root# wget http://www.emergingthreats.net/rules/emerging.rules.tar.gz /usr/local/src root# tar xzf emerging.rules.tar.gz /usr/local/src root# mkdir -p /usr/local/snort/rules /usr/local/src root# mv rules/* /usr/local/snort/rules /usr/local/src root# rmdir rules /usr/local/src root# wget \ http://www.snort.org/pub-bin/downloads.cgi/\ Download/vrt_os/snortrules-snapshot-CURRENT.tar.gz /usr/local/src root# md5sum snortrules-snapshot-CURRENT.tar.gz 184aed405da3f1043b82d81c98122237 snortrules-snapshot-CURRENT.tar.gz /usr/local/src root# mv snortrules-snapshot-CURRENT.tar.gz /usr/local/snort/ /usr/local/src root# cd /usr/local/snort/ /usr/local/snort root# tar xzf snortrules-snapshot-CURRENT.tar.gz /usr/local/snort root# rm snortrules-snapshot-CURRENT.tar.gz /usr/local/snort root# vi /usr/local/snort/etc/snort.conf |
Modify /usr/local/snort/etc/snort.conf to your environment. Make sure the RULE_PATH is set to /usr/local/snort/rules. If you wish to use the emerging threat rules, add:
include $RULE_PATH/emerging.conf
in the /usr/local/snort/etc/snort.conf file. Do not forget to adjust dynamicpreprocessor file and dynamicengine path. Mac OS X users will need to use the dynamic libraries. Uncomment the Mac OS X lines in the Snort configuration file.
Keeping Rules Current
If you want to setup a process to keep your rules as up-to-date as possible from the snort site, you will want to use the program Oinkmaster.
root# cd /usr/local/src /usr/local/src root# wget http://prdownloads.sourceforge.net/oinkmaster/oinkmaster-2.0.tar.gz?download /usr/local/src root# md5sum oinkmaster-2.0.tar.gz d2a1b56f51cf40e919c63206ca4ec8f8 oinkmaster-2.0.tar.gz /usr/local/src root# tar xzf oinkmaster-2.0.tar.gz /usr/local/src root# cd oinkmaster-2.0 /usr/local/src/oinkmaster-2.0 root# cp oinkmaster.pl /usr/local/snort/bin /usr/local/src/oinkmaster-2.0 root# cp oinkmaster.conf /usr/local/snort/etc |
Modify /usr/local/snort/etc/oinkmaster.conf changing “url=” to the location where you want rules to be archived. The URL will also require a Oink Code, which is available once you register with Snort and log into your account. Multiple URLs can be specified for multiple files. You can have Oinkmaster pull down rules from Snort and Emerging Threats. I use oinkmaster to pull down the latest rules, place them in new rules directory (ex: /usr/local/snort/new-rules), backup the previously rules, and send email about what is new. Some rules may have negative impact on Snort’s operation. It is unwise to automatically update the rules without review. Below, the backup/archive area is the directory /usr/local/snort/archive. Modify /usr/local/snort/bin/oinkmaster.pl to know where oinkmaster.conf is located. At that point you are ready to use oinkmaster to update your rules.
/usr/local/src/oinkmaster-2.0 root# mkdir /usr/local/snort/archive /usr/local/src/oinkmaster-2.0 root# vi /usr/local/snort/bin/oinkmaster.pl /usr/local/src/oinkmaster-2.0 root# vi /usr/local/snort/etc/oinkmaster.conf /usr/local/src/oinkmaster-2.0 root# /usr/local/snort/bin/oinkmaster.pl \ -o /usr/local/snortr/new-rules -b /usr/local/snort/archive /usr/local/src/oinkmaster-2.0 root# crontab -l 10 6 * * * /usr/local/snort/bin/oinkmaster.pl -o /usr/local/snort/new-rules -b /usr/local/snort/archive \ | Mail -s "Snort Rule Updates" abbot@securitymonks.com 2>&1 |
For automatic updates, set up a cron job that runs the above command and email the results.
Testing Snort Using Attack Data
Leon Ward has made available a pcap file containing attacks that occurred back in 2001 against a honeypot. If you have other data that will produce interesting results, please feel free to use that.
root# mkdir -p /data/ids/tcpdump root# cd /data/ids/tcpdump /data/ids/tcpdump root# wget rm-rf.co.uk/downloads/Honeynet-RFP-iis.tgz /data/ids/tcpdump root# tar xzf Honeynet-RFP-iis.tgz /data/ids/tcpdump root# /usr/local/snort/bin/snort -c /usr/local/snort/etc/snort.conf \ -A fast -l /data/ids/tcpdump -r ./Honeynet-RFP-iis.pcap /data/ids/tcpdump root# ls /data/ids/tcpdump/alert /data/ids/tcpdump/snort.log.* |
Two results files should get created. The file /data/ids/tcpdump/alert will contain the alerts and /data/ids/tcpdump/snort.log.<date>, which contains the pcaps of the detected events.
SnortSP
At this point we are ready to install SnortSP. The first step is to make sure the system has the required software installed, which includes:
- Libdnet 1.10 or higher
- A recent Libpcap
- Lua 5.1.1 or better
- Depending o the OS, a UUID library
The second step involves getting the software, verifying, configuring, and installing the security platform. The engine will be built in the next section.
root# cd /usr/local/src /usr/local/src root# wget http://www.snort.org/dl/prerelease/3.0.0-b2/\ snortsp-3.0.0b2.tar.gz /usr/local/src root# wget http://www.snort.org/dl/prerelease/3.0.0-b2/\ snortsp-3.0.0b2.tar.gz.md5 /usr/local/src root# wget http://www.snort.org/dl/prerelease/3.0.0-b2/\ snortsp-3.0.0b2.tar.gz.sig /usr/local/src root# cat snortsp-3.0.0b2.tar.gz.md5 4b2259c08ebe66cf63d91359996c93d9 snortsp-3.0.0b2.tar.gz /usr/local/src root# md5sum snortsp-3.0.0b2.tar.gz 4b2259c08ebe66cf63d91359996c93d9 snortsp-3.0.0b2.tar.gz /usr/local/src root# gpg --verify snortsp-3.0.0b2.tar.gz.sig snortsp-3.0.0b2.tar.gz gpg: Signature made Fri 18 Jul 2008 11:09:25 AM EDT using DSA key ID B10683B0 /usr/local/src root# gpg --keyserver pgpkeys.mit.edu --recv-key B10683B0 gpg: requesting key B10683B0 from hkp server pgpkeys.mit.edu gpg: key B10683B0: "Snort Release Team (Snort Release Team signing key) |
The next step is to configure, install, and test SnortSP installation. We will be using the /usr/local/snort area as the installation directory. Please adjust to your environment.
/usr/local/src root# tar xzf snortsp-3.0.0b2.tar.gz /usr/local/src root# cd snortsp-3.0.0b2 /usr/local/src/snortsp-3.0.0b2 root# ./configure --prefix=/usr/local/snort /usr/local/src/snortsp-3.0.0b2 root# make /usr/local/src/snortsp-3.0.0b2 root# make check /usr/local/src/snortsp-3.0.0b2 root# make install /usr/local/src/snortsp-3.0.0b2 root# mkdir -p /usr/local/snort/etc/SnortSP /usr/local/src/snortsp-3.0.0b2 root# cp etc/* /usr/local/snort/etc/SnortSP /usr/local/src/snortsp-3.0.0b2 root# /usr/local/snort/bin/snortsp -V SnortSP Version 3.0.0b2 |
Snort 2.8.2 Detection Engine
The next step is to install the Snort 2.8.2 detection engine. We will immediately shut it down with the ssp.shutdown() command. Please see previous sections “Libpcap and Large Files Support” and “PCRE (pcre-7.8).” I am going to include the configuration options for libpcap, pcre, and MySQL. Please adjust the configuration if necessary in the same way snort-2.8.3.1 was modified.
/usr/local/src/snortsp-3.0.0b2 root# cd src/analysis/snort
/usr/local/src/snortsp-3.0.0b2/src/analysis/snort root# ./configure --prefix=/usr/local/snort \
--with-platform-libraries=/usr/local/snort/lib/snortsp \
--with-platform-includes=/usr/local/snort/include \
--with-libpcap-includes=/usr/localsnort/include \
--with-libpcap-libraries=/usr/local/snort/lib \
--with-libpcre-includes=/usr/local/pcre/include \
--with-libpcre-libraries=/usr/local/pcre/lib \
--with-mysql-includes=/usr/local/mysql/include\
--with-mysql-libraries=/usr/local/mysql/lib
/usr/local/src/snortsp-3.0.0b2/src/analysis/snort root# make
/usr/local/src/snortsp-3.0.0b2/src/analysis/snort root# make check
/usr/local/src/snortsp-3.0.0b2/src/analysis/snort root# make install
/usr/local/src/snortsp-3.0.0b2 root# /usr/local/snort/bin/snortsp \
-L /usr/local/snort/etc/SnortSP/snort.lua
,,_ -*> SnortSP! < *-
o" )~ Version 3.0.0b2 (Build 9) [BETA]
'''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html
(C) Copyright 2008 Sourcefire Inc.
> Control thread running - 3086609296 (9501)
> ssp.shutdown()
/usr/local/src/snortsp-3.0.0b2 root#
|
The command “snortsp -L /usr/local/snort/etc/SnortSP/snort.lua” is telling snortsp to use the file “snort.lua“. Examine the file for definitions of functions. Below are a few example functions calls that may be of interest:
root# /usr/local/snort/bin/snortsp -L /usr/local/snort/etc/SnortSP/snort.lua
snort> ssp.help()
[*] SnortSP Commands:
help()
set_log_level( [debug|info|notice|warn|error|critical] )
shutdown()
Available subsystems within SnortSP have their own help() methods:
dsrc - Data Source
eng - Dispatcher/Engine
analyzer - Analytics Modules
output - Output Modules
For example: dsrc.help() will call the Data Source help function
snort> dsrc.help()
[*] Data Source Config Structure
|
Lua
Lua is a lightweight scripting language embedded in SnortSP. The Snort Detection Engine is configured via a conf file, but SnortSP is configured by a Lua file. The Snort conf file location is specified in the Lua file. In this section, we are going to be running the shell script sspiffy.sh. The program comes with the SnortSP package and it will convert Snort 2.8.x files into a Lua scripts and a new configuration file for SnortSP.
Previously, we ran snort 2.8.3.1 against the Honeynet-RFP-iis.pcap data with the command:
root# cd /data/ids/tcpdump /data/ids/tcpdump root# /usr/local/snort/bin/snort -c /usr/local/snort/etc/snort.conf \ -A fast -l /data/ids/tcpdump -r ./Honeynet-RFP-iis.pcap |
We are going to create and use /data/ids/logs where result log files will be kept. First, backup the snort configuration file and result files previously created with snort 2.3.8.1.
root# cd /usr/local/snort/etc /usr/local/snort/etc root# cp snort.conf snort.conf.orig /usr/local/snort/etc root# mkdir -p /data/ids/logs /usr/local/snort/etc root# mv /data/ids/tcpdump/alert /data/ids/logs/alert.orig /usr/local/snort/etc root# mv /data/ids/tcpdump/snort.log.* /data/ids/logs/ |
We defined dynamicpreprocessor and dynamicengine in snort configuration file (/usr/local/snort/etc/snort.conf) file, so we do not need to specify their location via command line with –dynamic-preprocessor-lib-dir and and –dynamic-engine-lib. We will use the /usr/local/snort/etc as our configuration directory. The script sspiffy.sh will create a new snort.conf file. To generate a Lua file to run SnortSP with snort, we would use sspiffy.sh as follows:
root# cd /usr/local/snort/etc /usr/local/snort/etc root# /usr/local/src/snortsp-3.0.0b2/sspiffy.sh \ /usr/local/snort -c /usr/local/snort/etc/snort.conf.orig \ -r /data/ids/tcpdump/Honeynet-RFP-iis.pcap -l /data/ids/logs -A fast Checking command line arguments ... snort.conf is a copy of /usr/local/snort/etc/snort.conf.orig.2 with the following changes: #SSP - set in lua: dynamicpreprocessor directory /usr/local/snort/lib/snort_dynamicpreprocessor/ #SSP - set in lua: dynamicengine /usr/local/snort/lib/snort_dynamicengine/libsf_engine.so #SSP - deleted: preprocessor frag3_global: max_frags 65536 #SSP - changed: preprocessor frag3_engine: policy first detect_anomalies snort.lua is the script that configures and executes SSP. To run SSP as configured: /usr/local/snort/bin/snortsp -L snort.lua -P |
The two files that were created in your current directory are snort.lua and snort.conf. Take a look at the files and modify them where appropriate. Make sure the full path to snort.conf is specified in snort.lua (conf=”/usr/local/snort/etc/snort.conf”). To run snortsp with the generated files, use the command:
/usr/local/snort/etc root# /usr/local/snort/bin/snortsp -L /usr/local/snort/etc/snort.lua |
Now go to the /data/ids/logs area and compare the alert file just generated with the alert.orig file generated by snort 2.8.3.1. The results do match. The differences between the files comes down to SnortSP alert file not including log entries for http_inspect.
Final Thoughts
The new Snort architecture is a very exciting design change that will help future versions of Snort respond quickly to an every changing security battleground. Besides the potential speed performance, along with the ability to take advantage of the multicore systems being developed, what I find particularly interesting is that the new architecture provides a framework where developers can build their applications. There is real potential here for intriguing development and flexibility. Different environments have different requirements and needs. Soon organizations will have the ability to choose from different engines resulting in custom configurations that best address each organization’s risks.
Everyone is looking for a turn key solution. People need to accept the fact that security is hard. By the time you find a solution, the problem has changed. With an ever changing attack vector, there are no turn key solutions that can do anything more than provide help. This is an important concept, because once accepting this fact, it changes a person’s view on viable solutions. That is what I like about the Snort 3 architecture. It is designed to be capable of being adjusted rapidly, which is a really cool concept. All security tools should be designed in such a manner. Our adversaries adjust quickly. We need to be able to also. On the eve of Snort turning ten, it is good to see that the Sourcefire team has been building such a promising IDS that will serve us well far into the future.
