| 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. | 