Testing Rules

Problem

I have new rules and ideas for rules I want to test without causing problems for the production deployment. How can I use Snort to test itself?

Solution

There are actually a couple of answers to this question.

• Using the Snort command-line -T option is best for quick changes to production sensors. This option is usually placed as the last option at runtime to test a snort.conf file. For example, you finish reading this book and you want to ensure that you've set up Snort to output to a database.

snort -c /path/to/my/snort.conf -i Sniff_interface -l 

/log/snort/path -T

• With this in place, Snort makes a dry run of the parts of Snort and the enabled/disabled components of the conf file. If for example a rule had an error in it, an output module didn't have support enabled, or even if Snort couldn't log to the log directory, it would show up here. If there is a problem with the rule you wrote, Snort will warn you with a ^ at the closest point to the error. This is great if you are just getting into writing your own rules. It's also useful for experienced Snort users and administrators, because even the experts make mistakes sometimes.
• Out-of-band testing is the preferred method of testing Snort rules. Build a system with a similar setup to your production sensors to run Snort through a testing process before being deployed. This is great for testing what has changed between Snort versions, and even builds if you are customizing Snort source code.
• In-band testing requires you to set up an extra sensor on your production network. This way, when you want to test either rules or builds of Snort, you can test in the actual environment of your production network. If you feel like living on the edge, this is for you.

Discussion

For a full discussion of how to set up a testing infrastructure for Snort, check out the chapter on keeping Snort up to date in the Snort 2.1 book (Syngress). Solutions for a testing infrastructure for large and small organizations will differ with size, cost, and necessity.

See Also

Beale, Jay. Snort 2.1 Intrusion Detection. Rockland, MA: Syngress, 2004.

Open Source Testing Methodology (http://www.osstmm.org/)

Optimizing Rules