If you're using wireless network adapters, be aware that WinPcap works with some 802.11b network adapters, but the results might not be what you would expect. Because 802.11b packets are the only packets that an 802.11b network adapter recognizes, you can sniff only wireless traffic. In addition, Snort sees only the traffic destined for the wireless NIC, which means you only see packets with the IDS's IP address as the destination and broadcast packets. WinPcap doesn't put 802.11b network adapters into the mode needed to see all the packets sent over the wireless network. If you want to see all traffic, you need to use a regular Ethernet network adapter.
Logging mode. Next, you need to test the logging mode. To determine whether you can log packets, you use the sniffing mode's command with the -l parameter. You use this parameter to specify the folder in which you want to store the packets. For example, if you want to store all packets in a folder named Log, you run the command
snort -dev -l log
Snort places the packets in subfolders named after the packet's source IP address. In the subfolder, Snort groups the packets according to their TCP stream number. With this logging arrangement, you can easily find the traffic coming from a particular computer. However, logging packets this way takes up a lot of room on the hard disk because the packets are written in text format. In addition, you can't look at traffic from multiple computers at the same time and analyzing the packets is difficult.
A better solution is to log the packets to a single file in tcpdump binary format with the command
snort -dev -b -l log
To read the packets, you run the command
snort -dev -r log/snort-date@time.log
where date and time correspond to the date and time the logging started. You can filter the packet data based on criteria such as the source or destination IP address, a protocol, or a port number. The Snort documentation contains all the details about how to write a filter.
Intrusion-detection mode. The intrusion-detection mode differs from the other modes because Snort compares a list of rules with each packet. If the packet matches the rules' triggering criteria, Snort executes the specified corresponding action. The possible actions are pass (Snort ignores the packet and stops applying rules), log (Snort places the packet in the log directory), and alert (Snort signals an alert condition and places the packet in the log file). Under Windows, Snort can write alerts to the Application event log, but a better way to see alerts is to set up a syslog monitor. A syslog monitor provides alerts in realtime.
Syslog is a Linux program that listens for messages from other applications. Several companies have ported syslog to Windows. For example, Kiwi Enterprises' Kiwi Syslog Daemon (http://www.kiwisyslog.com) is a simple syslog daemon at a good price—free.
To test Snort's intrusion-detection mode, download and install Kiwi Syslog Daemon. To log alerts to an IDS running syslog, you use the command
snort -dev -s syslog_IP_address -c snort.conf
where syslog_IP_address is the IP address of the syslog system. Snort.conf is a sample rule file that will alert you when most of the common attacks (e.g., port scans, Code Red) occur. The Snort Web site has a large database of rules that cover a wide range of intrusion exploits, and the documentation includes a helpful section about how to write custom rules. Play with snort.conf to learn how rules work, then write a rule file that's customized for your IDS.
When a packet matches the triggering criteria in a rule that has an alert action, Snort sends the specified text message to the syslog server. Although the Kiwi Syslog Daemon works well for testing Snort, you'll probably find that you need a more powerful reporting tool. With a commercial syslog application, you can email alerts to administrators and text pagers.
Capacity Planning
A common question about Snort is "How much traffic can Snort handle?" The answer depends on several variables. If you're just sniffing traffic, Snort can handle a full 100Mbps network load on a server with an 800MHz CPU. If you don't want to lose packets, the NIC needs to be a server-quality card. My preference is to use midrange, server-class 3Com cards. In addition, don't use the command console for sniffing busy networks because Windows has a limit on how fast it can update the console. The best way to sniff a busy network is to log the packets in binary format to a disk file, then use Snort, WinDump, tcpdump, Ethereal, or any other tcpdump-compatible packet analyzer to look at the contents of the file.
If you use Snort in intrusion-detection mode, the total load it can handle depends on the number, complexity, and types of rules you want it to process. Typically, rules that search for a series of characters in the packet take longer to process than rules that look at single bits or specific bytes. As the number of rules increases, plan to increase the CPU speed and the amount of memory in the system. No estimates exist for how fast the CPU needs to be to handle a given number of rules; therefore, you might want to take advantage of the low cost for 2GHz CPUs and RAM and build a fast system from the outset.
The Next Step
I've only touched briefly on Snort's basic features. In its basic configuration, Snort catches the most common network attacks and offers a good evaluation of what's happening on your network. The next step is to explore the rich language for creating rules. The ability to tailor Snort to your environment is what makes Snort such a powerful, useful tool. Start out by becoming familiar with the standard set of rules, then experiment with your own rules. You might be surprised at everything that was happening without your knowing about it.