Using IDS rules to test Snort

system is working properly.

Is your new Snort system running too quietly? Whether you're new to using Snort or you've deployed it on a new platform -- a low-noise level may have you worried. It could be a tightly-tuned (or too tightly-tuned) system, or you may have the IDS residing on a quiet network segment. Fortunately, several methods exist for testing Snort over the wire to ensure it's working properly in your environment.

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 ifconfig ; and in Windows, use snort -W . Then, use snort –vi (interface name) ; for example snort –vi eth1 in Linux or snort –vi 2 in Windows, to tell Snort which NIC to sniff. If everything is working you'll get a stream of packet header information (similar to tcpdump/windump) scrolling up the screen faster than you can read it. Press CTRL-C to stop the capture and review packet statistics such as the number of packets analyzed, a breakdown by protocol, fragmentation and more. Also experiment with the –d (dump) and –q (quiet) switches to see how they affect the output.

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;)

The first two Snort rules should generate an alert upon seeing any IP or ICMP packet, respectively. Since they will trigger on almost every single packet on the network these aren't rules you want to run on a heavily loaded production segment! Run them on a smaller or test segment if necessary. The last rule is a copy of SID (rule) 499 (Note that Snort.org reserves SID 1-1,000,000 for "official" rules. See the Snort User's Manual at Snort.org) modified to make it much more loose to increase alert generation for our testing purposes. Normally you'll want to avoid loose rules since they lead to false positives. Also, the original rule has been deprecated and is in the deleted.rules file. To use the modified rule above, ping -s 1024 {target host} (Linux) or ping -l 1024 (target host) (Windows). If none of these tests work, then Snort likely isn't working and/or packets aren't getting through. Don't forget to remove your test rules when you are finished.

Finally, Snort has a test switch (-T), which allows you to easily test proposed changes to your configuration. You can run a command like snort -c /etc/snort/snort.conf -T , and read the output to see if the configuration works. Snort will also set a return code of 0 if it worked and anything else (usually a 1) if it failed. This can be illustrated by running one of these two commands: snort -c /etc/snort/snort.conf -T & echo "Return code: $?" (Linux) or snort -c ./Snort.conf -T & echo Return code: %ERRORLEVEL% (Windows). Since you can always run more than one copy of Snort, you can keep one instance running, make and test configuration changes using another, and then stop the production process and immediately restart it to implement your changes once they are tested.

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

  Introduction
  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
 

ABOUT THE AUTHOR: