Thursday, January 10, 2008

How do I know if my Snort implementation is working?

How do I test Snort? How do I know if Snort is sniffing packets? How do I know if Snort is running properly? How do I generate a test alert with Snort? Recently, and over the years, I have regularly seen people join the #snort channel on freenode and post these very questions to the snort mailing lists. Perhaps this little article will index properly in the search engines and end their questions, this is of course assuming that they know how to use a search engine ;-).

There are really several ways of testing snort, some much more complex than others. Probably the most simple way is to define a custom rule that you can easily produce the traffic to trigger the alert. This can be done by creating a simple rule that looks for traffic of a certain type, to a certain address or many other ways but for the purposes of this article we will be looking for traffic to a certain address (as this tends to be the most easily produced). We begin by creating a custom rule either in a new rules file or by adding the rule into an existing rules file. To simplify this you can download the rule from the url below:

Once you have downloaded this rule file and added it to your snort.conf so that Snort has loaded it, simply generate traffic from the monitored network to one or more of the following hosts:,, This traffic can be of almost any type. I will typically browse via browser or telnet to a standard IRC port (at the time that I wrote this, these hosts were on the known C&C list) such as 6666, 6667 ....

Once this is done you will see the alerts being generated by snort (assuming that everything is configured properly).

As a second method, you can attempt to generate traffic that an existing snort rule can detect and alert on. To do this, I suggest using a tool such as Metasploit to generate actual attack traffic. You will want to test it against a host that you own, I certainly am not advocating attacking someones network with Metasploit from your network, this host should either be intended to be a test host, and/ or be immune to the attack. A simple example would be to enable the web-iis.rules from and launch an attack against one of your patched webservers from metasploit in an attempt to exploit MS01-23 using the Metasploit Framework Exploit. This will in-turn generate the WEB-IIS ISAPI .printer access alert to fire.

Either of those two methods should allow you to test your Snort installation, there are some other tcpreplay type tools that you can generate traffic from some signatures with, but by and large they are not effective tests.



fjcastano said...

Or you can use tools as Idswakeup.

JJC said...

Yes, there are a number of tools similar to IDSwakeup out there, but for the purposes of testing statefull connections etc, those simply will not get the job done, as they effectively forge traffic in an attempt to duplicate an attack. While this will work perfectly well for UDP and ICMP type alert generation it will not work for TCP...

Further, the last release of IDSWakeup is 30-Jan-2002, fairly dated.


JJC said...

Also, with the new snort releases and associated rules this will not work, as most rules have the flow: to_(server|client), established; keyword, even UDP (now that 2.8 has UDP flow handling). (thx dqoh)


fjcastano said...

Thanks for the observation JJC :)

Joel Esler said...

idswakeup ftl.

You need an actual attack tool (metasploit, canvas, etc) not a scanning tools (nessus, etc.)

my favorite method is the old
alert tcp any any -> any any (msg:"Shut this rule off, it works now; flow:stateless; sid:100000;)