Snort Configuration

Snort Output Plugin Configuration

You must add some information to the snort configuration file to enable database logging. The configuration file distributed with snort has some sample configuration lines. The configuration line will be of the following format:
   output database: [log | alert], [parameter list]
[log | alert]

REQUIRED. Specify to use the log or alert output facilities to store events in the database.

Note: Certain events generated by pre-processors (e.g. those created by spade and portscan) will only log correctly if the alert facility is used.

It is redundant and unnecessary to have an two instances, one an alert and the other log, of the output plugin logging to the same database. This configuration will cause two events to be logged in the database for every one detected by snort.

[type of database]

REQUIRED. The type database used to log the events. The possible values are mysql, postgresql, odbc, mssql, and oracle.

[parameter list]

The parameter list consists of key value pairs (See Table 4). The syntax of the parameter list is a series of key=value pairs each separated by a space.

The only parameter that is absolutely necessary is dbname. All other parameters are optional but may be necessary depending on the RDBMS configuration.

Table 4: Snort database output plugin arguments
Argument Description
dbname name of the logging database
host host on which the database is stored
port port number on which the database server is listening
user username with which to login into the database
password password of the specified user
sensor_name specifies a custom name (a human readable name) for this sensor. If a name is not specified, one is automatically generated using a combination of the sensor's IP address and the interface that that is being monitored.

In configurations where two instances of Snort are monitoring the same interface and logging to the same database, this variable in required and different sensor_names must be used.

encoding specified that packet and option payload encoding format

format description storage searching human readability
hex (default) hexadecimal encoding 2x binary representation easy not readable
base64 base64 encoding ~1.3x binary representation difficult not readable
ascii Binary is represented as an ascii string. Data will be lost if stored in this format. Non-ascii data is represented as a period ("."). slightly larger than binary easy text searching;
binary is impossible

Note: Binary data should be stored as a blob, but these are not portable across databases.

detail specifies the level of detail to log for every alert

full (default) log all details of a packet that caused an alert (including ip/tcp options and the payload)
fast log only a minimum amount of data. This level of detail will severely limit the potential of some analysis applications. The following fields are logged - (timestamp; signature; source and destination ip; source and destination port; tcp flags; and protocol)

ignore_bpf (Snort v1.9 only) Do we want to create a new sensor definition everytime the BPF filter is changed?

no | 0 (default) Create a new sensor definition if BPF filter has been modified
yes | 1 Ignore the BPF part when looking for the server definition

Example Snort configurations

Example 1
   output database: log, mysql, dbname=snort user=foo host=localhost password=xyz

   This example will log events to a "mysql" database named "snort" running 
   on "localhost" using the "foo" user with a password of "xyz"

Snort DB logging: Configuration
[ Home | < | > ]