Building a Distributed IDS (Plain Text)

Problem

You have to protect an organization's network infrastructure. How do you protect it with your Snort sensors at remote locations or even within a single building? As you will see in other chapters, Snort data can be displayed in several formats, such as web (ACID) and Windows applications (SnortCenter). How do you get the data from multiple sensors into one of these formats for analysis?

Solution

The simple solution is to use Snort's ability to log to a database. The function of logging to a database solves a couple of organization problems with IDS data, such as:

Storage of network IDS data

A database can store about two to four million full events in a MySQL database, for example.

Scalability

The database and events can grow from a small tower system to a complete storage array, if your organization can afford it.

We're using the database output postprocessor of Snort for this functionality. This example uses MySQL just because of its popularity and wealth of documentation on setup. Then we are going to be setting up Snort to log to a web frontend of ACID.

In addition, feel free to edit your MySQL databases and tweak your IDS databases, as MySQL has an entirely GPL licensing system. For clarification, check the following: http://www.mysql.com/company/legal/licensing/opensource-license.html.

Discussion

This example uses MySQL for the database and modifies the Snort source code to enable native MySQL connections. However, there are other database formats supported by Snort, such as PostgreSQL, Oracle, and even Microsoft SQL.

All the database systems have their differences, and some may be easier or harder for people to use and install. However, before building your database backend, consider its size and support. Consider the size, because you need to gauge how large your database is likely to get. Two to four million records is the max for MySQL, while several hundred million is the Oracle limit. Consider support, because you want to choose a database for your core IDS backend that's familiar to you and to other maintainers. Hardware and prices are another important consideration before you go call Oracle and Dell for your backends.

Client side

First, compile Snort on the sensor with database support.

./configure --with-mysql --your-other-options

Once built on the sensor, you need to configure the sensor's snort.conf file. In this example, the following line goes in your snort.conf file on each sensor.

output database: log, mysql, sensor_name=sensor_dmz dbname=aciddb user=snort_acid password=acidrocks host=10.0.0.2

The use of the keyword log versus alert is the difference between having only the signature events going into your database versus all eventseven those that use only the log facility.

Server side

Build MySQL and Apache if you are going to display your events to a web frontend. The ACID frontend can be seen in almost every IDS shop on some workstation or large screen.

Compile MySQL with the following options if you are building from source code:

./configure --with-mysqld-user= --with-libwrap= --make make install

The following is the Apache/SSL/PHP source build (some dependencies may need to be satisfied before the build will succeed):

#APACHE ./configure --prefix=/my/base/dir --enable-so --enable-ssl --with-ssl=/path/to/ssl #PHP (NEEDED FOR ACID TO WORK) ./configure --prefix=/path/to/apache/php --with-apxs2=/path/to/apache/bin --with-config-file-path=/path/to/apache/php --enable-sockets --with-sockets --with-mysql=/path/to/mysql --with-zlib --with-gd

We are going to skip the rest of the Apache setup for our database setup. The database now needs to be set up to use connections from the sensors. Let's start and create our database to use for Snort with its user.

If you didn't already create a user for MySQL to use, do so by using the following:

groupadd mysql useradd -g mysql mysql

Create the default database from the MySQL source directory:

scripts/mysql_install_db

Change ownership of the database directory to the mysql user:

chown -R mysql /usr/local/var chgrp -R mysql /usr/local/var

Copy the my-medium.cnf file out of the MySQL source directory to /usr/local:

cp support-files/my-medium.cnf /usr/local/var/my.cnf

Start the MySQL server in the background:

/usr/local/bin/mysqld_safe --user=mysql &

Log in to mysql:

/usr/local/bin/mysql

A good security practice is to require a password for the root MySQL user:

mysql> UPDATE user SET Password=PASSWORD('my_pass') WHERE users='root';

Apply the changes:

mysql> FLUSH PRIVILEGES;

Next, create the ACID database:

mysql> CREATE DATABASE ;

Create a user account for our sensors to use (unique for our sensors for the paranoid):

mysql> GRANT UPDATE,SELECT,INSERT on .* TO sensoracid@ IDENTIFIED BY 'sensorpassword';

Create a separate account for your web interface to use. This one has all privileges to help prune the database:

mysql> GRANT ALL PRIVILEGES on .* TO webfront@localhost IDENTIFIED BY 'webfrontpass';

Finally, restart the MySQL server with the new changes.

For more database tweaking, check out MySQL Reference Manual (O'Reilly) for more detailed MySQL information.

One word about the database output plug-in: as your sensors grow, you'll have geo-location considerations. Take a look at the output line from the snort.conf file. There is a keyword that's not normally used: sensor_name. If you don't use this keyword in your conf file, when the sensor changes its hostname or can't find its DNS name, the sensor and its data appear in the database as a new sensor. This can cause quite a bit of confusion on a large network like an ISP.

See Also

Other database Snort implementations

Online (http://www.snort.org) resources for database options and changes