19.5 Snort IDS Case Study

This section presents an example deployment of the Snort IDS (http://www.Snort.org). Snort used to be called a "lightweight IDS," but it has since progressed way beyond that stage, and there is nothing lightweight about it anymore. Snort might only be called lightweight if we're referring to the high efficiency of its detection engine and its small memory footprint. It is a full enterprise IDS that can be deployed in high-performance and distributed configurations that reach gigabit speeds.

The intrusion detection platform discussed in this section is based on a Linux OS, a Snort network IDS, a MySQL database, and an ACID analysis console. Any Linux distribution, such as Red Hat or Debian can be used. While ideally you should build a minimum Linux system from scratch (as is done by the commercial IDS vendors selling Unix-based IDSs), for small network deployment you might be able to get away with a "canned" Linux variant. The system has to be minimized (i.e., all unneeded software removed) and hardened .

You should have at least two network cards on the computer where Snort is deployed, since the sniffing interface (which picks up attacks) and the management interface (used for sensor event data management, rule updates, and configuration changes) must be separate. The main reason is that the sniffing interface has no IP address assigned to it. In Linux, it is easy to activate a network interface with no IP address by using a command such as ifconfig eth1 up . While not providing total security ( impossible by definition), this solution is much better than having a regular interface for detection.

While Snort and the database can be installed on one machine, in case of higher traffic load you might want to install the database, Snort, and a web server each on a different computer. The intermediate variant of this is Snort on one machine and the database and web server on a second computer.

In the case of a multi-machine setup, the components of the IDS are connected via a network and several security measures must be implemented. To protect traffic between the analyst workstation and a database, we'll use an SSL connection. To restrict access to the ACID-based console, we'll use a standard feature of the Apache web server, basic HTTP authentication via .htpasswd . The traffic between the Snort sensor and the database can also be tunneled over SSL or SSH.

19.5.1 System Setup

First, you should build a hardened Linux machine. For Red Hat Linux, either choose a Custom Install from the official (or unofficial !) CD set or minimize their existing workstation setup variant by removing all the GUI components (for remotely managed IDS boxes). Make sure that all the MySQL server packages (included on Red Hat CDs) are installed. The command:

 # rpm -U /mnt/cdrom/RedHat/RPMS/mysql*rpm 

will take care of it, provided the appropriate Linux CD is mounted in the CD-ROM drive.

In the case of Red Hat, several Snort RPM (Red Hat Package Manager) software packages can be downloaded from the Snort.org web site. You need Snort and the Snort-mysql packages for the described setup. Install the packages on your hardened system. If the RPM installed complains about dependencies, satisfy them by downloading the appropriate packages (the libpcap network packet library might be needed).

Add the ACID-IDS event viewing software to the machine. The ACID home page contains the software and the installation instructions (http://acidlab. sourceforge .net). ACID requires a web-graphing library for visual display of Snort alerts. The ACID package should be unpacked in a directory visible to the web server (on Red Hat, /var/www/html ). ACID can thus be deployed into /var/www/html/acid . The configuration file acid_conf.php is where all the configuration settings reside. No access control is built in, so you might need the standard .htpasswd to be created in /var/www/html/acid .

If the deployment option (such as Red Hat's workstation setup) did not include a web server, an Apache web server should be installed off the distribution CDs via:

 #  rpm -U /mnt/cdrom/RedHat/RPMS/apache*rpm  

After all the components are installed, it's time to configure the IDS. First, Snort must be configured to log to a database. Here is the list of instructions to do just that:

1. Start the MySQL database service via:

    #  /etc/init.d/mysql start  

2. Create the Snort database:

    #  echo "CREATE DATABASE Snort_db;"  mysql -u root -p  

3. Add the user to be used for database operations:

    #  adduser Snort  

4. Grant this user privileges to insert alert data into the database:

    #  echo "grant INSERT,SELECT on Snort_db.* to Snort@localhost;"   mysql -u root -p  

5. Using the script included with the Snort source distribution ( not with the binary RPM package), create the database data structures:

    #  cat ./contrib/create_mysql  mysql Snort_db  

6. Edit the Snort config files to log to a database. Namely, edit /etc/Snort.conf to contain:

    output database: log, mysql, user=Snort dbname=Snort_db host=localhost 

7. Edit the Snort startup script ( /etc/init.d/Snortd ) to have the following command to launch the Snort process:

    /usr/sbin/Snort -D -l /var/log/Snort -i $INTERFACE -c /etc/Snort/Snort.conf 

   Locations for Snort logs can be adjusted here.

Snort can now be started by the command:

 #  /etc/rc.d/init.d/Snortd start  

Your IDS is now configured and logging to a database. Test it as follows :

1. Test that the processes are running::

    #  ps ax grep Snort  grep -v grep  

   In a positive result, you will see a nonempty output.

On Linux, a simpler version of the same command exists:

 #  ps u `pidof Snort`  

2. Test that Snort detects the attacks on lynx http://www.someLOCALwebserver.com/cmd.exe and then run:

    #  tail /var/log/Snort/alert  

   If you get a positive result, you will see an alert message indicating an IIS web attack. Please, do not run this test using a remote server URL, but rather one of your own local machines. Make sure that the sensor can "see" the attack (i.e., that the connection takes place via a network monitored by Snort).

A port scan using nmap might suffice as a Snort test, provided that port scan detection is turned on and configured properly. In fact, many methods exist to trigger the IDS for testing. Some people prefer large ICMP packets (which can be cooked with a simple ping) or other tricks.

3. Test database logging:

    #  echo "SELECT count(*) FROM event"  mysql Snort_db -u root -p  

   If you get a positive result, you will see a nonzero alert count stored in the database.

19.5.2 Alert Viewing Setup

Now, it is time to configure alert viewing via ACID. ACID (Analysis Console for Intrusion Databases) is a PHP application that allows the analysis of Snort data stored in a database.

ACID must be allowed to access the database. Run the following command to enable it:

 #  echo "grant CREATE,INSERT,SELECT,UPDATE,DELETE on Snort_db.* to acid@localhost;"    mysql -u root -p  

For higher security, it is suggested that SSL be used for alert viewing. Deploy the appropriate SSL package from the Red Hat CDs via:

 #  rpm -U /mnt/cdrom/RedHat/RPMS/mod-ssl*rpm  

and restart Apache via /etc/init.d/httpd restart .

For even higher security, only the SSL connection should be allowed to the machine. A host firewall script for the iptables Linux firewall can be used to allow only TCP port 443 (HTTPS) and not TCP port 80 (HTTP).

Now, start the Apache web server and point your browser to the machine's IP management interface (or the localhost 127.0.0.1 address, if running the browser locally). The correct URL is http://www.yourSnortServer.com/acid . The ACID software will guide you through the initial setup options, provided you followed the above instructions. ACID can be used to view Snort IDS alerts in many different modes, perform searches, and access full packet payloads.

If a database setup is not desirable, you can simply forward all the alerts to syslog and then use log-analysis tools to comb through them. Several tools (such as Snortsnarf ) exist to summarize and view Snort events.

19.5.3 IDS Rule Tuning

A full discussion of IDS rule tuning is beyond the scope of this chapter. However, one approach is to enable all rules and spend several days flooded with alerts, analyzing them and reducing the ruleset accordingly . This route is more appropriate for internal network IDS deployment and small networks. Another solution is to narrow the ruleset to watch only "risky" services. This works better in a highly secure DMZ setup in which all machines are carefully audited and hardened. In this case, a CodeRed alert should raise absolutely no concern, since your Unix web server will not be vulnerable to such a trivial threat.

The following simple Snort site customization is a must before deploying on a production network: Snort's HOME_NET variable should be set to the IP range of the protected network. Taking this step increases performance dramatically, since Snort will only look at relevant parts of network traffic.