An easy way to test your Snort rules

UPDATE: An updated version of this blog post is now available!

Have you ever wondered if your Snort rules are actually working after you have set up Snort?

You may have seen this line in your log file…

Oct 24 22:24:20 foo snort[4520]: 1745 Snort rules read

…but you may still be wondering if Snort can actually trigger alerts.

You could always let Snort run on a live network and hope that something shows up that would trigger an alert, but you might be waiting a long time, especially if you’ve accidentally misconfigured Snort so rules aren’t even being loaded in the first place!

Here’s a quick and easy way to test your Snort installation to confirm that it has loaded the Snort rules and can trigger alerts. Please note that the emphasis is on quick and easy; this is not meant to be a comprehensive guide to test each and every Snort rule that you have loaded!

The goal of this simple guide is to help you:

• Confirm that you have actually loaded some rules
• Ensure that your Snort setup can actually trigger alerts
• Confirm that you are logging alerts to the right file

I assume that you are using the official Snort rules from Sourcefire for this test, and that you have loaded all the rules as a starting point.

A lot of the rules are complex and there is no easy way to test each and every one of them. So what I have done is to pick two simple rules that you can use to test Snort by making it trigger both an outbound and inbound alert. Triggering an outbound alert is much easier so let’s start there.

Triggering an outbound alert

To trigger an outbound alert, simply run the following command from the host running Snort:

ftp http://$EXTERNAL_HOST/cmd.exe

Where $EXTERNAL_HOST is a host that you own or have permission to access for this exercise. Also, if for some reason you aren’t using a BSD system, you can always use wget or curl instead of ftp. :)

It does not matter if cmd.exe actually exists on that external host; Snort will see that you are attempting to download cmd.exe and should trigger the following Snort alert:

[**] [1:1002:15] WEB-IIS cmd.exe access [**]
[Classification: Web Application Attack] [Priority: 1] 
10/24-22:25:13.937084 x.x.x.x:42200 -> y.y.y.y:80
TCP TTL:56 TOS:0x0 ID:15236 IpLen:20 DgmLen:288 DF
***AP*** Seq: 0x1B16EAE9  Ack: 0x905BABE1  Win: 0x43E0  TcpLen: 32

On an OpenBSD system, that alert would appear in /var/snort/log/alert if you used the default settings in the Snort package.

Triggering an inbound alert

If you would like to test an inbound alert, it is slightly more complicated but still doable. You will first need to install a simple webserver. I like to install a simple lightweight webserver like thttpd. On OpenBSD you can do this by setting PKG_PATH and then run:

pkg_add thttpd

And then make thttpd listen in a dummy directory like:

mkdir /tmp/xyz
cd /tmp/xyz
thttpd -D -l /dev/stdout

Then, from an external host, run the following command:

ftp http://x.x.x.x/NessusTest

x.x.x.x in the above command is the “public” IP address of the Snort host. This should trigger the following alert:

[**] [1:2585:5] WEB-MISC nessus 2.x 404 probe [**]
[Classification: Attempted Information Leak] [Priority: 2] 
10/24-22:26:06.355207 y.y.y.y:63514 -> x.x.x.x:80
TCP TTL:64 TOS:0x0 ID:2995 IpLen:20 DgmLen:362 DF
***AP*** Seq: 0x44C5AC41  Ack: 0x4D9B5997  Win: 0x43E0  TcpLen: 32
[Xref => http://cgi.nessus.org/plugins/dump.php3?id=10386]

When you are done with the test, make sure to stop thttpd by pressing Ctrl+C to break out of it.

That’s all there is to it! Before deploying Snort in an actual production environment, please remember to carefully review your Snort rules to pick those that are applicable to your environment, and tweak your Snort configuration file accordingly.

Have fun!