Sniff with Snort

Billions of data packets traverse through enterprise networks every day at the speed of light. Some packets are malicious; they're carefully designed to slip past firewalls and perimeter defenses and wreak havoc on any system in sight. You might have experienced the wrath of a packet-based attack such as Code Red, Nimda, SQL Slammer, and MSBlaster. All these malicious programs use trusted protocols (e.g., HTTP) or Microsoft networking traffic to carry out their dirty work. Blocking these protocols outright isn't an option, so organizations commonly use Network Intrusion Detection Systems (NIDSs) to detect this type of traffic as quickly as possible so that they can react accordingly.

A number of NIDSs are on the market, all with varying capabilities and price tags. Generally speaking, they all work well. I've been impressed with every commercial package I've had a chance to use. But what if your budget is limited and intrusion detection just isn't high enough on the priority list for your IT department? Fortunately, the open-source world offers a capable NIDS package called Snort. Unlike many open-source packages, this package runs on Windows.

Meet Snort
Martin Roesch originally developed Snort, which he released to the open-source development community under GNU General Public License (GPL). With a history going back to at least 1998, this flexible package has a long, proven track record. With contributions from open-source community members and network administrators around the world, Snort has grown into a very capable product. The current version of Snort can perform real-time traffic analysis and logging of IP traffic at Fast Ethernet and Gigabit Ethernet speeds.

Michael Davis originally brought Snort to the Windows community by porting Snort 1.7 to the Win32 platform. Since that time, Chris Reid has taken over the task of compiling the newer Snort versions into a prepackaged executable for easy implementation in the Windows world.

If you're unfamiliar with NIDS, think of it as a special breed of network sniffer. An NIDS dutifully watches every packet that comes across its interface, looking for specific data patterns within the payload of the packets, where malicious code typically resides. By using Snort to watch your networks, you can perform content searching and matching on every packet that traverses through your organization and detect a myriad of attacks and hostile traffic—all in real time.

Snort Prerequisites
At a bare minimum, you need a Windows system with at least one NIC to run Snort. Preferably, you should have two NICs: one that can sit in the network to be monitored and one that can sit in your production network and provide reporting. I said Windows system because you can run Snort not only on Windows 2000 Server or later but also on Windows XP Professional Edition, XP Home Edition, and Win2K Professional. A server license isn't required. Because I connect my XP Pro laptop to many different client networks daily, I typically run Snort as a service. Thus, it runs in the background, detecting any attacks that client networks are directing toward my system. In a way, Snort is acting as a portable sensor for me—it can act as an NIDS on any port I connect my laptop to.

If you're going to implement Snort in an organization, a low-end server can be a decent choice, depending on the size of your network. If you're dedicating the system to intrusion detection, you don't need a lot of horsepower for the box. For example, I've read stories about Snort nodes with 1GHz processors and 1GB of RAM on a FreeBSD platform effectively handling networks of 15,000 users and multiple T-3 (digital signal 3—DS3) WAN links. Because the Snort code is efficient, a lot of horsepower isn't necessary.

You need to determine where you want to place the NIDS on your network. Instinctively, your first thought might be to place it in front of your firewall. Although placing an NIDS at that location would collect the most results, it would also collect the most noise. Thus, you would receive a lot of alerts that provide little value. You shouldn't worry about what gets stopped in front of your firewall. Instead, you should care about what gets through your firewall. So, under most circumstances, placing Snort behind your firewall is a good start.

However, if you have users coming into your network through a VPN connection (either over the Internet or a wireless connection), you should think about placing your NIDS further behind your firewall, such as behind the VPN server or concentrator, where packets are decrypted as they exit the VPN tunnel. Otherwise, the NIDS will be blind to any attacks embedded in the VPN traffic because the packets that Snort is analyzing are encrypted. The same holds true for encrypted SMTP traffic, encrypted .zip files in email attachments, and other types of encrypted data.

Ideally, you should place the NIDS far enough back to get behind any components that are encrypting traffic but far enough forward to capture traffic across as many segments and subnets as possible. If you're operating in a switched network environment, your switch will likely need a diagnostic port that collects copies of all the packets going through your network. That way, the NIDS will have good visibility of all your network traffic.

Now that you know what Snort is and what you need to deploy it, you're ready to set up and test your NIDS. (For more information about Snort, check out the references in the Web-exclusive "Resources" box, http://www.winnetmag.com, InstantDoc ID 42606.) This process involves 7 steps:

Step 1. Install WinPcap
Because Snort is essentially a promiscuous-mode network sniffer, you need driver-level support. To provide this support, you can use WinPcap. Loris Degioanni created WinPcap as a port of the popular libpcap packet-capture driver commonly used in the UNIX world. WinPcap includes a kernel-level packet filter, a low-level DLL (packet.dll), and a high-level system-independent library (wpcap.dll, based on libpcap 0.6.2).

WinPcap, which is available for download at http://winpcap.polito.it, supports Windows Server 2003, XP, Win2K, Windows NT, Windows Me, and Windows 9x. WinPcap also supports an open-source packet sniffer called Ethereal, which is available at http://www.ethereal.com. You might find Ethereal useful when you're testing your Snort setup.

After you've downloaded the WinPcap installer, simply walk through the few installation screens it provides you. The most involved screen you'll see is the one in which you must agree to the license agreement.

Step 2. Install Snort
The next step is to install Snort. You can find the latest version at CodeCraft Consultants Web site (http://www.codecraftconsultants.com/snort.aspx) or the Snort.org Web site (http://www.snort.org). I recommend that you download Snort from CodeCraft Consultants because that Web site provides a self-installing executable. The installation program even walks you through the basic setup of Snort on your system. For this article, I used Snort 2.1.1, build 18, which was the most current version at the time. Since that time, later versions have been released.

When you run the installation program, the first dialog box in which you need to make a selection is Installation Options, which lets you configure the database to log to. If you intend to use a MySQL or ODBC-compliant database, you can leave the default selection, which Figure 1 shows. However, if you intend to log to a Microsoft SQL Server or Oracle database, you need to select the appropriate option and make sure you have the requisite client software installed on your system. For the purposes of this article, let's stick with the default selection.

Next, you need to choose the Snort components you want to install. The default selections, which Figure 2 shows, are fine, so I recommend that you leave those components selected and click Next. In the Choose Install Location dialog box, you must specify the directory in which you want to install Snort. After you enter the directory, you just need to click Next to finish the installation process.

Step 3. Test the Snort Installation
After the installation process completes, you need to test Snort to see how it's working. By default, the main executable for Snort needs to know two pieces of information to run: where to write its logs to and where to find the configuration file (i.e., snort.conf). You provide this information when you launch Snort from the command line by using the -l and -c switches, respectively. For example, the Snort command

snort -l F:snortlog  -c F:snortetcsnort.conf  -A console

tells Snort that it should write its logs to the F:snortlog directory and that it can find snort.conf in the F:snortetc directory. The -A switch tells Snort how to handle the alerts that it generates. In this instance, you're telling Snort to display the alerts on the console screen so that you can determine whether Snort is working properly. Note that, although this command appears on several lines here, you would enter it on one line in the command-shell window. (The same holds true for the other multiline commands in this article.) Also note that many of the Snort command-line switches are case sensitive, so you need to enter the switches exactly as they appear here.

If you have multiple network interfaces on your system, by default, Snort listens on the first one it finds. If you're uncertain about the order of your network interfaces, you can execute the Snort command with just the -W switch. Snort will then list the names and numbers of the network interfaces in the order in which it finds them. To instruct Snort to use a specific network interface, you need to add the -i switch followed by the interface number to the command that launches Snort. After you execute Snort, you should see a screen similar to the one that Figure 3 shows.

Assuming Snort is running, you can throw some interesting traffic past the NIDS to test the Snort sensor. One of the easiest ways to intentionally trip an alert is to try to access the command interpreter (cmd.exe) on a remote system as a part of an HTTP URL request—a common part of the Code Red and Nimda attacks. You can simulate this part of the attack by going to any specific URL and appending /cmd.exe at the end of your request. For example, going to http://www.a-website-that-I-can-trust.com/cmd.exe should cause your Snort sensor to log alerts in the command-shell window, as the first three alerts in Figure 4 show. These alerts also appear in F:snortlog.

Please be careful about the Web sites you target with this test. Technically, most Web site administrators would consider this type of activity a hacking attempt. Although that approach shouldn't be exploitable (unless the server is horribly misconfigured), I recommend running this test only against your own server or a server that you can trust and whose administrators are aware that you'll be doing this type of test.

If this test doesn't work or isn't an option, another way you can test your Snort installation is to send an abnormally large ping request to a server across your network or to the computer on which you're running Snort. For example, you might execute the Ping command

ping -l 32767 ip_address

where ip_address is the IP address of the server or Snort computer you're targeting. This command should send an abnormally large ping packet (32KB to be exact), which is definitely not routine behavior for the Ping command. Snort should pick up this packet activity, as the bottom eight alerts in Figure 4 show.

If you're seeing such alerts, you can start tuning Snort for your specific environment. If not, you need to go back and check your installation to see whether you've missed a step.

Step 4. Configure Snort
Snort stores its primary configuration in snort.conf, which is in the %systemdrive%snortetc directory by default. You can leave the file in this location or place it somewhere else, as long as you let Snort know where to find it by providing the appropriate path on the command line.

I could easily fill up this issue with details about all the intricate configuration options available in snort.conf. Snort is an amazingly powerful application. But, for now, let's stick with some of the basic options.

For Snort to determine the traffic coming into your network versus the traffic going out, you've got to tell Snort the hosts and IP addresses in your network. To provide this information, you set the HOME_NET variable in the snort.conf file. Find the line

var HOME_NET any

and replace any with your IP address range. You can specify one range, such as

var HOME_NET 192.168.0.1/24

or you can specify multiple ranges. For multiple ranges, you need to enclose the set of ranges in square brackets and separate each range with a comma. Don't include any spaces between the IP address ranges. For example, the line

var HOME_NET  [10.0.1.0/24,10.0.2.0/24,10.0.3.0/24]

tells Snort that subnets 10.0.1.0/24, 10.0.2.0/24, and 10.0.3.0/24 belong to your network. By default, Snort considers everything else outside the network. You can explicitly tell Snort the networks it should consider external by setting the EXTERNAL_NET variable. In the snort.config file, find the line

var EXTERNAL_NET any

and replace any with the IP address of the network you want Snort to consider external. Generally, though, I've found that leaving the EXTERNAL_NET variable set to any is a good place to start.

If you want to take the time, you can go so far as to tell Snort the types of servers you have in your environment and where to find those servers. You provide this information by setting the DNS_SERVERS, SMTP_SERVERS, HTTP_SERVERS, SQL_SERVERS, and TELNET_SERVERS variables in the snort.conf file. Find the lines

var DNS_SERVERS $HOME_NETvar SMTP_SERVERS $HOME_NETvar HTTP_SERVERS $HOME_NETvar SQL_SERVERS $HOME_NETvar TELNET_SERVERS $HOME_NETvar SNMP_SERVERS $HOME_NET

By default, all six server variables are set to $HOME_NET, which means that Snort will monitor all systems defined within your HOME_NET range for all types of attacks. If you have a small network and you don't mind a bit of extraneous noise, this configuration should work fine. However, if you have a large traffic stream to monitor, you'll want to fine-tune the Snort configuration so that Snort checks for only appropriate signatures against specific hosts. After all, there's no need to check for SQL buffer overrun attacks against a Web server that's running only Microsoft IIS. If you want to define specific classes of hosts, you need to replace $HOME_NET with the IP address range of the target servers, following the same format that you used for the HOME_NET variable. For example, for the DNS_SERVERS variable, you replace $HOME_NET with the IP address range for your DNS servers.

If you'd like to get even more specific, you can define which ports your servers use for specific applications. For example, if your Web servers use custom port 8080 for HTTP traffic instead of port 80 (the port typically used for Web servers and browsers), you can tell Snort to watch port 8080 by modifying the HTTP_PORTS variable. In snort.conf, find the line

var HTTP_PORTS 80

and change it to

var HTTP_PORTS 8080

Similarly, you can change the ports for Oracle (which you define with the ORACLE_PORTS variable) and other applications. Like the HTTP_PORTS variable, the ORACLE_PORTS variable is set to 80 by default. If your server uses port 1521 instead, you can change the line to

var ORACLE_PORTS 1521

As you can see, you can configure many options in snort.conf. You should look through snort.conf to find which values are most relevant to your environment and set them appropriately.

Step 5. Configure the Rules
One line that you'll see in snort.conf mentions the RULE_PATH variable. This line should look something like

var RULE_PATH ../rules

The ../rules option tells Snort that it can find the rules (i.e., signatures) in the directory called rules, which is at the same directory level as the Snort binaries. So, for example, if you install Snort in the default location F:snort, the Snort binaries are in F:snortbin and the rules are in F:snortrules. If you want to change the RULE_PATH variable you can, but the default installation should be fine.

Rules are the heart of Snort. They're the byte patterns, attack signatures, and other data types that trigger alerts when detected. By default, Snort comes with more than 1500 signatures right out of the box.

What does a rule look like? Here's what the cmd.exe rule, which you violated earlier with your Snort test, looks like: alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS cmd.exe access"; flow:to_server, established; content:"cmd.exe"; nocase; classtype:web-application-attack; sid:1002; rev:5;). Let's look at this rule's main components. The reference to $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS specifies that you're interested in seeing only the traffic coming from the outside world (as interpreted by EXTERNAL_NET) toward your network. The content: parameter tells Snort to search for the existence of the string cmd.exe in the data stream. If Snort finds this string, it generates the alert message that the msg: parameter specifies.

As the cmd.exe rule shows, rules are generally straightforward. You can create your own rules as needed to detect any type of traffic. For example, if you need to detect whether someone is remotely accessing a directory on your system through the command interpreter, you might search for the string volume in drive or volume serial number on ports where you wouldn't expect to see them, such as ports that handle traffic going out of your network. Numerous configuration options are possible with Snort because of its flexible rule-set approach.

Snort's 1500 rules are in various files according to the type of data being checked. For example, the cmd.exe rule is in the web-iis.rules file. If you don't have IIS running in your environment, you don't need to have Snort looking for IIS attacks. You can easily remove the entire web-iis.rules file from the configuration by finding and commenting out the line

include $RULE_PATH/web-iis.rules

in snort.conf. To comment out the line, you place a number sign (#) in front of it:

# include $RULE_PATH/web-iis.rules

By default, several types of rules files (e.g., icmp-info.rules, chat.rules) are already commented out in snort.conf. I've found that the default rule configuration in snort.conf works well. Enabling the rules that are disabled by default typically generates far too much useless noise.

Perhaps a rules file has a lot of valuable rules that you'd like to use, but a few individual rules are particularly noisy and generate too many useless alerts. You can disable a specific rule by commenting out that rule in the rules file. Snort will ignore that rule the next time it executes the file.

As new attacks are released, you'll need to update your rules files. The best resource for new Snort rules is the Snort.org Web site. That Web site doesn't have an automatic update, so you'll need to check for updates regularly and whenever a new serious vulnerability or exploit appears.

Step 6. Set Up the Alerts and Logs
As I mentioned earlier, Snort supports logging to MySQL, ODBC-compliant, SQL Server, and Oracle databases. You simply select the appropriate database type during the installation of Snort. For the purposes of keeping this article brief, let's move on to Snort's default text-file logging options and its ability to log to the Windows event log.

When you previously used the Snort command to start the NIDS, the -A console switch told Snort to display its alerts on screen. If you prefer to send the alerts to a text file, you can change this switch to either -A fast or -A full, depending on the type of logging you want. The full option provides a verbose amount of detail on multiple lines in a text file named alerts.ids in the log file directory path (which the -l switch defines). This logging type provides a rich level of detail, but in noisy networks, the detail is a bit much to work through visually. In noisy networks, you should use the fast option, which prompts Snort to post to alerts.ids a single line that provides the key details of the questionable traffic. Personally, I find the fast option easier to work with than the full option when I'm logging to a text file.

The current version of Snort lets you log to the Windows event log. Given that many organizations have already invested in centralized event monitoring, logging, and collection tools, this logging capability is a great add-on for Windows environments.

To send alerts to the Application event log of the system on which Snort is running, you use the -E switch (no options are necessary) instead of the -A switch. Figure 5 shows what a Snort event—in this case, the attempted cmd.exe exploit—looks like when it's been posted to the Application log. The Windows event provides the same level of detail as the console screen.

An NIDS doesn't do much good if you're looking at the event logs (or text logs) only once or twice a week. When something is happening on your network, you need to know as soon as possible. If you have a centralized event monitoring and management system, you can have new events generate notifications through email, a pager, or another medium. However, if you don't have a system like this in place, don't worry. NETIKUS.NET offers a wonderful freeware package called EventSentry Light that you can use to send notifications.

EventSentry Light, which you can download from http://www.netikus.net/products_downloads.html, is the trial version of EventSentry. Many thanks are due to the folks at EventSentry for making a freeware version of such a powerful application. Through EventSentry Light, you can have the system monitor your event logs and automatically email you the details about any Snort event posted to the log. Figure 6 shows the email message about the alerts for the attempted cmd.exe exploit. EventSentry Light emailed this message to me moments after I made the attack.

As I mentioned previously, Snort typically generates a lot of noise, which can cause your event logs to quickly fill up with notifications. Keep this fact in mind when you're making such decisions as how large to make the event log files and how you want to rotate them. To prevent EventSentry Light from cluttering up your mailbox with all of those alerts, you can implement a pattern-matching filter that specifically looks for key strings. For example, I set up a filter to search for the string [Priority: 1] in the text of events.

Step 7. Run as a Service
After Snort is up and running, you'll probably want to run it as a service instead of logging on to the desktop each time you need to start the program. If you launch Snort with the /SERVICE and /INSTALL parameters (along with the other command-line parameters you would typically use), Snort configures itself as a Windows service. As such, it'll start automatically when Windows starts, without any user intervention.

The Next Level: Add-Ons

Snort is a full-featured application. However, you might encounter situations in which you need to take your Snort installation to the next level. For example, if you have multiple NIDSs spread throughout your network, you might prefer to use a GUI to manage Snort. Add-ons that provide this capability include Engage Security's IDScenter and Activeworx's IDS Policy Manager. Or, suppose that you need to do some data mining on your alert data. One add-on that lets you review and analyze logged data is Carnegie Mellon University's Analysis Console for Intrusion Databases (ACID).

Knock Out Attacks
Snort is a highly capable application that's kind to your IT budget. If you pair Snort with a powerful event monitoring application such as EventSentry Light, you've got the one-two punch to knock out attacks on your network before they can do significant harm.