|< Day Day Up >|
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.
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:
The facility option specifies one of the standard syslog facilities and defaults to LOG_AUTH:
The priority option also specifies one of the syslog standard priorities and defaults to LOG_ALERT:
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):
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
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
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>
When configuring the particular database output plug-in, set the following parameters (there are no commas in the parameter list):
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:
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:
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:
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.
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:
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.
|< Day Day Up >|