What you will learn from this tip: Several methods for testing Snort over the wire to ensure the intrusion-detection system is working properly.
Is your new Snort system running too quietly? Whether you're
To start, you can run it in sniffer mode from the command line, which will confirm that the network card is working properly, a span port is enabled (see How to deal with switches and segments) and Snort is actually seeing traffic. In the case where you're using more than one network interface card (NIC) (see How to determine how many interfaces a sensor needs), you'll need to define the exact one for Snort to use. To find the name of the interface in Linux/Unix, use
You can manually check Snort using some simple test rules. In order for this test to work, you'll need to add one or more of these rules to your setup. The easiest way to do that is to add them to the bottom of your snort.conf file, though you could also create a test.rules file and 'include' that in snort.conf. You must also have the ability to send packets from a network defined as $EXTERNAL_NET into the network defined as $HOME_NET (see your snort.conf file and How to define Snort's configuration variables).
- alert ip any any -> any any (msg:"Got an IP Packet"; classtype:not-suspicious; sid:2000000; rev:1;)
- alert icmp any any -> any any (msg:"Got an ICMP Packet"; classtype:not-suspicious; sid:2000001; rev:1;)
- alert icmp any any -> any any (msg:"ICMP Large ICMP Packet"; dsize:>800; reference:arachnids,246; classtype:bad-unknown; sid:2000499; rev:4;)
Finally, Snort has a test switch (-T), which allows you to easily test proposed changes to your configuration. You can run a command like
One other note on testing Snort over the wire: Some older rules use TCP header flags to see if packets are part of an established TCP session. Newer rules use the established keyword (see Where to find Snort rules). In either case, you can't simply use Netcat to put the expected TCP packet payload out on the wire and expect Snort to "see" it -- the payload must appear as part of an established TCP session, in the appropriate direction, before Snort will trigger an alert. The "established" keyword is great for reducing false positives, but can be very confusing when trying to test Snort, which is why we used ICMP or custom rules above.
SNORT INTRUSION DETECTION AND PREVENTION GUIDE
Why Snort makes IDS worth the time and effort
How to identify and monitor network ports
How to handle network design with switches and segments
Where to place IDS network sensors
Finding an OS for Snort IDS sensors
How to determine network interface cards for IDS sensors
Modifying and writing custom Snort IDS rules
How to configure Snort variables
Where to find Snort IDS rules
How to automatically update Snort rules
How to decipher the Oinkcode for Snort VRT rules
Using IDS rules to test Snort
|JP Vossen, CISSP, is a Senior Security Engineer for Counterpane Internet Security. He is involved with various open source projects including Snort, and has previously worked as an information security consultant and systems engineer.|
This was first published in May 2005