5.4 Output Configurations

One of Snort's real strengths are the options available for output of alerts and other detection information. While running tail -f on the alert file in /var/log/snort certainly lets you see that alerts that Snort generates, using that information effectively requires more horsepower. Many Snort administrators use third-party applications to monitor and investigate the information generated by Snort. To do this, Snort must output the data a particular format. The output plug-ins perform this task. Note that using some of these plug-ins require the administrator to take some steps at the time that Snort is compiled. For example, to allow Snort to output to a MySQL database, a MySQL client needs to be installed on the Snort system and the --with-mysql option must be specified with the ../configure command. Some of these options are only available on a particular platform. For instance, only a Windows system can log directly to Microsoft SQL Server with the mssql plug-in (Unix-based systems must use ODBC with the odbc plug-in).

Multiple output plug-ins can be enabled, allowing a variety of tools to be employed by Snort administrators.

5.4.1 alert_syslog

Unix-based systems use the syslog facility to aggregate messages generated by one or more systems into a single place. There are a number of different ways that the Snort-generated information can be presented to the syslog. You can specify the facility used by Snort and also the priority assigned to entries generated by Snort.

The format of the this plug-in is:

Output alert_syslog: <facility> <Priority>

The facility option specifies one of the standard syslog facilities and defaults to LOG_AUTH:

LOG_AUTH

LOG_AUTHPRIV

LOG_DAEMON

LOG_LOCAL0

LOG_LOCAL1

LOG_LOCAL2

LOG_LOCAL3

LOG_LOCAL4

LOG_LOCAL5

LOG_LOCAL6

LOG_LOCAL7

LOG_USER

The priority option also specifies one of the syslog standard priorities and defaults to LOG_ALERT:

LOG_EMERG

LOG_ALERT

LOG_CRIT

LOG_ERR

LOG_WARNING

LOG_NOTICE

LOG_INFO

LOG_DEBUG

Here's a sample configuration for the alert_syslog output plug-in:

output alert_syslog: LOG_AUTH LOG_ALERT

Windows systems have the option of specifying a particular host in the config file (a Unix-based system can be configured at the operating system level to send a particular facility to a separate syslog server). To do this, specify a host and a port number in the following format (port number is optional):

Host=<host IP address>:<port number>

Here's an example of a Windows version of this output plug in's configuration:

output alert_syslog: host=10.10.10.100 LOG_AUTH LOG_ALERT

5.4.2 log_tcpdump

This logs packets to the tcpdump file format. There are a variety of applications that can read this format. The only option for this output plug in is the filename in which the information is written. A timestamp is prepended to the filename.

Here's a sample configuration for the log_tcpdump plug-in:

output log_tcpdump /var/log/snort/tcpdump.out

5.4.3 Database

The database plug-in allows you to write to a variety of relational databases either on the same system that Snort is running on or to another host on the network. When logging to a database, a great deal of information is recorded—including the alert, the hosts involved, and the actual packet that caused the alert—making discriminating between real alert and false positives much easier.

Sometimes logging to a busy database server can cause a bottleneck, since only one alert can be logged at a time. A dedicated, well-configured database server helps with this problem, as well as with tuning and thresholding effectively (see Chapter 9). The database schema that Snort uses can be found in Appendix A. The argument as to which database server is better devolves into a religious argument quickly. Personally, I prefer MySQL. It's open source, free (you can get paid support, too—details at MySQL), it's very fast, and it's very configurable. I have extensive experience with PostgreSQL and Microsoft SQL Server, too. Choose whichever you're most familiar with, since tuning the database server for performance pays dividends.

The database output plug-in takes the following format:

output database: <log|alert>, <database type>, <parameter list>

<log|alert>

Choose either log or alert here. log sends log information to the database, and alert sends the alert stream. Note that log includes alert information and the alert-generating packet information. log is the option I use most often. If you want to send both to a database, you need two output database lines, each specifying one of the options.

< database type>

This is where you specify what type of database you are logging to. Snort supports the following settings: mysql, postgresql, oracle, odbc, and mssql (Windows Snort systems only).

When configuring the particular database output plug-in, set the following parameters (there are no commas in the parameter list):

host

The IP address of the database server. If left blank, it goes to the local machine.

port

The port the database is listening on. You only need to specify this if a nonstandard port is being used.

dbname=<database name>

The type of database you are logging to (one from the list above).

user

The username Snort uses to log into the database.

password

The password used to log into the database.

sensor_name

A sensor name for this configuration (optional). Otherwise, the -I option at the command line uses the IP address of the sensor as the name.

encoding

The encoding used for logging to the database. You can specify hex (takes up less space, is searchable, but not easily read by people), base64 (smaller than plain text, not searchable, not human readable), or ascii (larger, searchable, human-readable). ascii is recommended.

detail

You can specify what detail level is used when sending information to the database. full will include all information that Snort gathers, including header and packet information. fast is a bit faster, but includes such a small amount of information—really just the alert name, source and destination addresses and ports, and a timestamp—that forensic analysis is very difficult. The full option is highly recommended.

5.4.3.1 MySQL

MySQL logging requires that database support be present on the system running Snort in the form of the MySQL client software and libraries. At the time Snort is installed, support for MySQL is included by adding the --with-mysql at configure time. Here's an example:

./configure --with-mysql

5.4.3.2 PostgreSQL

PostgrSQL logging requires that database support be present on the system running Snort in the form of the PostgreSQL client software and libraries. At the time Snort is installed, support for PostgreSQL is included by adding the --with-postgresql at configure time. Here's an example:

./configure --with-postresql

5.4.3.3 ODBC

ODBC logging requires that database support be present on the system running Snort in the form of the ODBC client software and libraries. At the time Snort is installed, support for MySQL is included by adding the --with-odbc at configure time. Here's an example:

./configure --with-odbc

5.4.3.4 MsSQL

This option is built-in for Windows systems running Snort. For Unix-based systems running Snort, ODBC is used to log to Microsoft SQL Server.

5.4.3.5 Oracle

Oracle logging requires that database support be present on the system running Snort in the form of the Oracle client software and libraries. At the time Snort is installed, support for Oracle is included by adding the --with-oracle at configure time. Here's an example:

./configure --with-oracle

5.4.4 unified

unified logs in the Unified Binary format. This is a very fast, compact format for logging designed to be used by Barnyard. The unified format will be discussed in Chapter 13 when strategies for high-demand environments are discussed.