9.4. Snort

The most popular open source NIDS is Snort. Snort has been around as an open source project for years. In 2002 Marty Roesch, the primary maintainer for Snort, started a for-profit company called Sourcefire. Sourcefire is a commercial IDS vendor that sells sensors and services based on Snort. Several Sourcefire employees still directly contribute to the Snort code base, and the public at large can still contribute to the Snort code as well. Sourcefire has value-added, proprietary software that goes beyond the "stock" Snort.

Snort has grown in popularity over the years. And as it has become more popular, it has also changed to fit the current NIDS needs. Originally a monolithic piece of software, Snort is now modular and adapts to suit different environments. Snort now makes use of preprocessors to speed up packet decoding and make the NIDS harder to evade. Snort also has different output options including flat files, various databases, and custom backends that allow high-speed sensors to operate more efficiently.

9.4.1. Sensor Hardware

The first step in setting up an NIDS sensor is choosing the right hardware. You will need to use a machine with enough horsepower to handle the amount of traffic you believe the sensor will handle, the size of the IDS signature set, the number of attacks you expect to see, as well as your tolerance for risk when it comes to potentially overdriving the host. As you can guess, there is no magic formula that says "use X processor with Y RAM and Z disk space" for an IDS sensor. In general, the more processor, memory, and disk, the better you will be. However, on a lightly loaded DSL-based network a Pentium-II class machine with 256MB of memory and a 10GB drive should be more than enough to run a NIDS sensor.

Your sensor will need at least two NIC cards. One card will connect to the network to be monitored and another to connect to for administrative connections. The network card used on the monitoring interface should be a high quality NIC capable of handling the amount of traffic on the sensor. For instance, the Intel NICs that use the fxp drivers are a good choice because the drivers are stable and the cards use hardware for much of the packet handling.

9.4.2. Host Lockdown

The next step in setting up an IDS sensor is to start with a secure initial build as described in Chapter 3. We emphasize, however, that an IDS host is a frontline security device. If it is compromised or made ineffective through a DoS attack, it's useless. An IDS needs to be secured just as a firewall or any other security-critical device would be.

Ideally, the only processes running on a Snort sensor are the core operating system components (such as init(8) and cron(8)), Snort, and some remote management capability like sshd(8). Further, the host should be firewalled to prevent any inbound traffic except ssh-based management traffic. To someone portscanning an IDS from an untrusted host, the sensor should look like a black hole. For extra security, you should consider not assigning an IP address to the interface on the monitored network. Without an IP address, an attacker has nothing to direct an attack against and serves as further security for the sensor.

9.4.3. Installing and Configuring Snort

Snort can be installed directly from the ports tree on both FreeBSD and OpenBSD. If you would rather install Snort by hand, the latest version can be downloaded from http://www.snort.org/. The Snort installation documents are largely self-explanatory and the port installs painlessly. One of the more important switches at compile time involves how you want to store alerts. By default, Snort stores attack information in flat files. It also has the ability to log to a database such as MySQL or MS-SQL. So, if you want to store alert information in a MySQL database, then use the --with-mysql flag at compile time.

Intrusion detection systems can generate huge logfiles. In fact, a common trick an attacker may play is to send a huge amount of traffic designed to trigger IDS events in an effort to obscure what is really going on. However, even on a good day, IDS logs can build rapidly. Ideally, you should dedicate a separate filesystem, /var/snort for example, to store Snort logfiles. This will isolate problems caused by runaway Snort logfiles.

There are several important configuration files for Snort. First, the snort.conf file controls all the core functionality of Snort including input and output mechanisms, information on local networks, and location of other configuration files. Within snort.conf you can indicate what networks are local (HOME_NET) and which ones are not (EXTERNAL_NET). This allows Snort to determine when traffic is originating from within your networks and when traffic originates from outside. By default, the local and external networks are set to any as shown below to indicate Snort really should not care what networks are where.

var HOME_NET any var EXTERNAL_NET any

You should set the HOME_NET variable to point to your internal networks. You can specify multiple (comma-separated) networks, but be sure you do not have any space in the variable. If your internal networks are 192.168.0.0/24 and 172.16.0.0/14, for instance, your HOME_NET variable would look like the following:

var HOME_NET [192.168.0.0/24,172.16.0.0/24]

The snort.conf file is well commented and contains more information on all the configuration options available to you. Similarly, the threshold.conf file allows for tuning the IDS to make it a bit quieter in the face of excessive alerts. Thresholds can be set to either limit the number of alerts, or completely suppress certain alerts or IP addresses. The threshold.conf file has a number of comments that will assist you in setting thresholds. However, for your first attempt, it's best to leave this file untouched.

Snort is a signature-based IDS system, meaning that it compares each packet against a set of rules to determine if that packet matches known malicious patterns. As is the nature of the security world, the definition of a "bad packet" changes from day to day. New attacks are discovered and new mechanisms for detecting attacks are created. Just as it is important to keep your anti-virus definitions up to date, you should keep your Snort rules current too. New Snort rules can be downloaded from http://www.snort.org/dl/rules/. Be sure to check the MD5 sum on the web site against the ruleset you've downloaded. You can then place the new rules files in your rules directory and restart Snort.

9.4.4. Containing Snort

As a front line security device, a NIDS sensor can be a target of attack. The obvious lockdown activities may not be sufficient to protect a Snort host from malicious code. There have been several vulnerabilities in Snort where a host could be compromised by traffic not even destined for it. Notably the CERT CA-2003-13 advisory discusses two vulnerabilities in Snort; one in the stream4 preprocessor and one in the RPC preprocessor. From the advisory:

[The vulnerabilities] allow remote attackers to execute arbitrary code with the privileges of the user running Snort, typically root. Please note that it is not necessary for the attacker to know the IP address of the Snort device they wish to attack; merely sending malicious traffic where it can be observed by an affected Snort sensor is sufficient to exploit these vulnerabilities.

While this vulnerability has been fixed in current versions of Snort, the prospect of this type of attack is troubling. So, what can be done to protect Snort?

First and foremost, Snort can drop privileges to an unprivileged user once it has started. To utilize this capability, create a snort user with attributes similar to the following:

Username   : snort Password   : <locked> Full Name  : Snort User Uid        : <next> Class      :  Groups     : snort  Home       : /home/snort Shell      : /sbin/nologin Locked     : yes

Note that the password should be a * in the password file, just like the other system accounts on the host. This ensures that the account is completely locked out. When starting snort, use the -u user flag to force it to drop privileges. Be sure that the directory in which you are storing your alerts (such as /var/log/snort) is writable by the snort user and group.

For even more security, Snort can be chrooted to prevent a successful attack from compromising the entire system. snort makes this easy by simply providing the -t flag at start time and specifying the root of the chroot(2). This kind of chroot is a bit of a poor man's chroot. Rather than running Snort explicitly through the chroot(8) utility, Snort chroots itself once it has started. Because of this, the easiest place to chroot it to is the log directory, by default /var/log/snort. If you attempt to chroot somewhere else, Snort has a hard time dealing with it. So, to chroot Snort in /var/log/snort and run as user snort, you would start Snort in the following manner:

% sudo snort -u snort -t /var/log/snort

With FreeBSD, Snort can be contained in a jail instead. FreeBSD jails were discussed thoroughly in Chapter 2.

9.4.5. Storing Events in Flat Files

By default, Snort stores alerts in flat files on a local filesystem, usually in /var/log/snort. This makes alerts easy to view and helps the administrator understand what is occurring on a host. In this mode, there is no real central host in the NIDS environment. The Snort sensor is really a standalone device that requires direct interaction to monitor. In small environments, this may be okay, but for larger installations, other capabilities are needed.

Snort makes a single alerts file that contains information on all traffic that tripped a rule in the Snort ruleset. To view the alerts in real time, you can use tail -f to watch the file as it grows. Here is a sample alert from an attack against an IIS server.

[**] [119:2:1] (http_inspect) DOUBLE DECODING ATTACK [**] [Classification: Web Application Attack] [Priority: 1]  11/01-20:29:19.163907 192.168.0.99:52571 -> 192.168.0.10:80 TCP TTL:64 TOS:0x0 ID:5115 IpLen:20 DgmLen:212 DF ***AP*** Seq: 0x71850B78  Ack: 0xCBB1AFB1  Win: 0xFFFF  TcpLen: 32 TCP Options (3) => NOP NOP TS: 549495890 43275571

The first line indicates the type of attack this alert was for. In this case, the attack was a double decoding attack that attempts to exploit a weakness in IIS's Unicode decoder. The second line indicates that this is a web application attack and it is of the highest priority. Priority 1 means that the attack, if successful, would likely result in compromise of the host. The third line indicates the time the attack occurred and the source and destination IP addresses. The final group of lines provides low level information about the packet. This can be useful if you are doing low-level analysis of an attack. But in the case of a web attack such as this one, the extra packet information is not all that helpful.

Beyond the monolithic alerts file, Snort also creates a directory for each source host that generates an alert. Within that directory, Snort will create a file for each flow between the source and destination host. Here we see that three different hosts have been sending attacks through our network.

% ls -al /var/log/snort total 76 drwxr-xr-x  3 snort  snort    512 Nov  1 02:16 . drwxr-xr-x  3 root   snort   1536 Nov  1 03:02 .. drwx------  2 snort  snort    512 Nov  1 20:54 10.0.0.1 drwx------  2 snort  snort    512 Nov  1 20:54 192.168.0.56 drwx------  2 snort  snort    512 Nov  1 20:54 192.168.0.99 -rw-------  1 snort  snort  70646 Nov  1 20:55 alert

Within the 192.168.0.99 directory we see the files corresponding to each flow.

% sudo ls -al /var/log/snort/192.168.0.99/ total 16 drwx------  2 snort  snort   512 Nov  1 20:54 . drwxr-xr-x  3 snort  snort   512 Nov  1 02:16 .. -rw-------  1 snort  snort  1044 Nov  1 02:16 TCP:49455-80 -rw-------  1 snort  snort  1044 Nov  1 02:16 TCP:49536-80 -rw-------  1 snort  snort  1041 Nov  1 20:54 TCP:52571-80 -rw-------  1 snort  snort  1041 Nov  1 20:54 TCP:52600-80 -rw-------  1 snort  snort  1038 Nov  1 20:54 TCP:52601-80 -rw-------  1 snort  snort  1041 Nov  1 20:54 TCP:52610-80

In this case, we can see there have been six different attacks the Snort sensor has detected. The filenames indicate the protocol (in this case TCP), the source port, and the destination port. All of these attacks target the web server on port 80.

9.4.6. Storing Events in MySQL

If you are looking to deploy more than one sensor, you should look beyond the default flat file capability of Snort. By using a database server connected to an internal network, multiple IDS can log alert information to a single source giving you a one-stop shop to examine alerts and monitor your network. Using a database server also has a security benefit. By running the server on a host inside your network (i.e., not running it on a sensor itself) and protecting it from the outside world, you no longer have to interact directly with the IDS sensors to analyze events. This allows for the sensors to be locked down to a greater extent and further limits your external exposure.

The first step is to install a database like MySQL. MySQL is an open source and mature database used for a variety of applications. It is widely supported and has a number of different options in the ports tree. You can install the appropriate MySQL port or build MySQL by hand. Installation instructions are plentiful online.

Properly installing MySQL and securely configuring it is a complex topic and beyond the scope of this chapter. However it is important that your database server, like any other host and application in your network, be configured and deployed securely. For more information on MySQL database security see http://dev.mysql.com/doc/mysql/en/Security.html.

After MySQL is installed, configured, and running on your system, you must create a database to hold the Snort alerts.

% echo "CREATE DATABASE snort;" | mysql -u root -p

The database needs to be have tables created to match the schema Snort is expecting. The Snort distribution contains SQL statements that will automatically create all the proper tables. If you installed Snort from ports, the MySQL-specific SQL statements will be in a file called create_mysql within the ports directory tree.

% mysql -D snort -u root -p < /usr/ports/security/snort/work/snort- XX /contrib/create_mysql 

Next, we will want to access the MySQL database as a user other than root. Note that a database user is not the same as an operating system user. However, it is convenient to have the usernames for the operating system be the same as the database to make things more consistent. When you grant a user access to a table in MySQL, a database user with the same name is automatically created. So first we will configure MySQL to allow a Snort user to INSERT and SELECT on the entire Snort database and UPDATE on the sensor table. UPDATE is required so sensors can be brought online automatically.

% mysql  > grant INSERT,SELECT on snort.* to  snort@localhost;  > grant INSERT,SELECT,UPDATE on snort.sensor to  snort@localhost;  > exit;  % mysqladmin -u snort password  password 

Finally, the remote Snort sensor needs to be configured to export the alerts to the MySQL database host. In the snort.conf file, look for a series of commented-out output database directives. Add the following line in that area of the configuration file.

output database: log, mysql, user=snort password=snort dbname=snort host=remotehost

Restart the Snort sensor process and you should be all set. If there is a firewall between your Snort sensor and your database, you will need to open up the MySQL port (TCP 3306) between the sensor and the database server. Snort is now logging to the remote database. The README.database has much more information about using snort with database backends. Further, there are a whole series of README files in the Snort distribution that provide valuable insight on a variety of topics including optimization, alternate operating systems, and HTTP inspection.

There are downsides to logging your IDS events to a central database server. Now, rather than having events logged locally, they are going over the network. With busy IDS sensors, this may result in excessive amounts of network traffic. Or, it may result in overtaxing the database server. You will have to appropriately plan for the amount of IDS traffic you expect to receive on your worst days. The database server needs to be able to receive the number of events and allow you to make queries. This means the server needs to have enough processing power, RAM, disk space, and network capacity. Also the network must have enough capacity, including any intermediary firewalls. In some cases, a completely separate network used to collect IDS data may be the solution.

9.4.7. Snort with PF

The firewall PF has the ability to forward packets to a specialized log interface, pflog0. Packets sent to pflog0 are basically pcap(3) formatted and can be viewed or sniffed by pcap aware applications. Snort can be listen on the pflog0 interface just like any other interface on the system. This capability opens up a variety of interesting possibilities.

If you are logging all denied traffic on your firewall, Snort will be able to identitfy attacks that are in this denied traffic. To log denied traffic, you can use the following in your pf.conf file:

block in log all

This sounds useful but may actually prevent you from seeing certain attacks. Snort will alarm on attacks and scans that only require one packet per session to be detected. For instance, a portscan or a packet that has strange header values will cause Snort to send an alert. However, most TCP-based attacks will not trigger a Snort event. The reason is simple: TCP-based attacks need to complete the TCP three-way handshake in order to send the malicious data. However, if the firewall blocks the initial connection request, thereby preventing the TCP session from being established, Snort will never see any malicious data.

As an example, consider a Unicode attack against a Microsoft IIS web server. The attack host needs to create a valid TCP session and then send a malformed HTTP request to the vulnerable server. If your firewall blocks the initial SYN packet and logs it to pflog0, the attack host will never get a chance to send the malformed HTTP request.

Conversely, your PF firewall could permit and log traffic to a host you are attempting to monitor. Snort could monitor this traffic and watch for attacks targeting that host. Since the traffic is allowed, you no longer have the problem with not detecting TCP-based attacks. In your pf.conf file you could add the following to capture all allowed traffic:

pass in log all from any to any keep state

Using Snort to monitor packets on pflog0 is an interesting capability. Normally, you will not need to use Snort in this manner. However, there are times when this trick may come in very handy.