Snort - the de facto standard for intrusion detection/prevention
the de facto standard for IPS  
Got Source? About Snort About Sourcefire Snort FAQ
Sourcefire Network Security - the creators of Snort
Snort News Snort Downloads Snort Rules Snort Docs Snort Training Snort Forums Snort Community Snort Store
Search Site
Search Rules
Account
email
password
not registered?
can't login?
user preferences
next up previous contents
Next: 2.4 Dynamic Modules Up: 2. Configuring Snort Previous: 2.2 Event Thresholding   Contents

Subsections


2.3 Output Modules

Output modules are new as of version 1.6. They allow Snort to be much more flexible in the formatting and presentation of output to its users. The output modules are run when the alert or logging subsystems of Snort are called, after the preprocessors and detection engine. The format of the directives in the rules file is very similar to that of the preprocessors.

Multiple output plugins may be specified in the Snort configuration file. When multiple plugins of the same type (log, alert) are specified, they are stacked and called in sequence when an event occurs. As with the standard logging and alerting systems, output plugins send their data to /var/log/snort by default or to a user directed directory (using the -l command line switch).

Output modules are loaded at runtime by specifying the output keyword in the rules file: 

output <name>: <options>

Figure: Output Module Configuration Example
\begin{figure}\begin{verbatim}output alert_syslog: log_auth log_alert\end{verbatim} \par\end{figure}


2.3.1 alert_syslog

This module sends alerts to the syslog facility (much like the -s command line switch). This module also allows the user to specify the logging facility and priority within the Snort rules file, giving users greater flexibility in logging alerts.

2.3.1.1 Available Keywords

2.3.1.1.1 Facilities

  • log_auth
  • log_authpriv
  • log_daemon
  • log_local0
  • log_local1
  • log_local2
  • log_local3
  • log_local4
  • log_local5
  • log_local6
  • log_local7
  • log_user

2.3.1.1.2 Priorities

  • log_emerg
  • log_alert
  • log_crit
  • log_err
  • log_warning
  • log_notice
  • log_info
  • log_debug

2.3.1.1.3 Options

  • log_cons
  • log_ndelay
  • log_perror
  • log_pid

2.3.1.2 Format 

alert_syslog: <facility> <priority> <options>

Note:   As WIN32 does not run syslog servers locally by default, a hostname and port can be passed as options. The default host is 127.0.0.1. The default port is 514. 

output alert_syslog: [host=<hostname[:<port>],] <facility> <priority> <options>

Figure: Syslog Configuration Example
\begin{figure}\begin{verbatim}output alert_syslog: 10.1.1.1:514, <facility> <priority> <options>\end{verbatim} \par\end{figure}

2.3.2 alert_fast

This will print Snort alerts in a quick one-line format to a specified output file. It is a faster alerting method than full alerts because it doesn't need to print all of the packet headers to the output file

2.3.2.1 Format 

alert_fast: <output filename>
Figure: Fast Alert Configuration
\begin{figure}\begin{verbatim}output alert_fast: alert.fast\end{verbatim} \par\end{figure}

2.3.3 alert_full

This will print Snort alert messages with full packet headers. The alerts will be written in the default logging directory (/var/log/snort) or in the logging directory specified at the command line.

Inside the logging directory, a directory will be created per IP. These files will be decoded packet dumps of the packets that triggered the alerts. The creation of these files slows Snort down considerably. This output method is discouraged for all but the lightest traffic situations.

2.3.3.1 Format 

alert_full: <output filename>
Figure: Full Alert Configuration
\begin{figure}\begin{verbatim}output alert_full: alert.full\end{verbatim} \par\end{figure}

2.3.4 alert_unixsock

Sets up a UNIX domain socket and sends alert reports to it. External programs/processes can listen in on this socket and receive Snort alert and packet data in real time. This is currently an experimental interface.

2.3.4.1 Format 

alert_unixsock
Figure: UNIXSock Alert Configuration
\begin{figure}\begin{verbatim}output alert_unixsock\end{verbatim} \par\end{figure}

2.3.5 log_tcpdump

The log_tcpdump module logs packets to a tcpdump-formatted file. This is useful for performing post-process analysis on collected traffic with the vast number of tools that are available for examining tcpdump-formatted files. This module only takes a single argument: the name of the output file. Note that the file name will have the UNIX timestamp in seconds appended the file name. This is so that data from separate Snort runs can be kept distinct.

2.3.5.1 Format 

log_tcpdump: <output filename>
Figure: Tcpdump Output Module Configuration Example
\begin{figure}\begin{verbatim}output log_tcpdump: snort.log\end{verbatim} \par\end{figure}


2.3.6 database

This module from Jed Pickel sends Snort data to a variety of SQL databases. More information on installing and configuring this module can be found on the [91]incident.org web page. The arguments to this plugin are the name of the database to be logged to and a parameter list. Parameters are specified with the format parameter = argument. see Figure [*] for example usage.

2.3.6.1 Format 

database: <log | alert>, <database type>, <parameter list>
The following parameters are available:

host
- Host to connect to. If a non-zero-length string is specified, TCP/IP communication is used. Without a host name, it will connect using a local UNIX domain socket.
port
- Port number to connect to at the server host, or socket filename extension for UNIX-domain connections.
dbname
- Database name
user
- Database username for authentication
password
- Password used if the database demands password authentication
sensor_name
- Specify your own name for this Snort sensor. If you do not specify a name, one will be generated automatically
encoding
- Because the packet payload and option data is binary, there is no one simple and portable way to store it in a database. Blobs are not used because they are not portable across databases. So i leave the encoding option to you. You can choose from the following options. Each has its own advantages and disadvantages:

hex
(default) - Represent binary data as a hex string.

Storage requirements
- 2x the size of the binary
Searchability
- very good
Human readability
- not readable unless you are a true geek, requires post processing
base64
- Represent binary data as a base64 string.

Storage requirements
- $\sim$1.3x the size of the binary
Searchability
- impossible without post processing
Human readability
- not readable requires post processing

ascii
- Represent binary data as an ASCII string. This is the only option where you will actually lose data. Non-ASCII Data is represented as a `.'. If you choose this option, then data for IP and TCP options will still be represented as hex because it does not make any sense for that data to be ASCII.

Storage requirements
- slightly larger than the binary because some characters are escaped (&,$<$,$>$)
Searchability
- very good for searching for a text string impossible if you want to search for binary
human readability
- very good
detail
- How much detailed data do you want to store? The options are:

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. You severely limit the potential of some analysis applications if you choose this option, but this is still the best choice for some applications. The following fields are logged: timestamp, signature, source ip, destination ip, source port, destination port, tcp flags, and protocol)
Furthermore, there is a logging method and database type that must be defined. There are two logging types available, log and alert. Setting the type to log attaches the database logging functionality to the log facility within the program. If you set the type to log, the plugin will be called on the log output chain. Setting the type to alert attaches the plugin to the alert output chain within the program.

There are five database types available in the current version of the plugin. These are mssql, mysql, postgresql, oracle, and odbc. Set the type to match the database you are using.

Note:   The database output plugin does not have the ability to handle alerts that are generated by using the tag keyword. See section [*] for more details.

Figure: Database Output Plugin Configuration
\begin{figure}\begin{verbatim}output database: log, mysql, dbname=snort user=snort host=localhost password=xyz\end{verbatim} \par\end{figure}

2.3.7 csv

The csv output plugin allows alert data to be written in a format easily importable to a database. The plugin requires 2 arguments: a full pathname to a file and the output formatting option.

The list of formatting options is below. If the formatting option is default, the output is in the order the formatting option is listed.

  • timestamp
  • sig_generator
  • sig_id
  • sig_rev
  • msg
  • proto
  • src
  • srcport
  • dst
  • dstport
  • ethsrc
  • ethdst
  • ethlen
  • tcpflags
  • tcpseq
  • tcpack
  • tcplen
  • tcpwindow
  • ttl
  • tos
  • id
  • dgmlen
  • iplen
  • icmptype
  • icmpcode
  • icmpid
  • icmpseq

2.3.7.1 Format 

output alert_csv: <filename> <format>
Figure: CSV Output Configuration
\begin{figure}\begin{verbatim}output alert_csv: /var/log/alert.csv defaultoutput alert_csv: /var/log/alert.csv timestamp, msg\end{verbatim} \par\end{figure}

2.3.8 unified

The unified output plugin is designed to be the fastest possible method of logging Snort events. The unified output plugin logs events in binary format, allowing another programs to handle complex logging mechanisms that would otherwise diminish the performance of Snort.

The name unified is a misnomer, as the unified output plugin creates two different files, an alert file, and a log file. The alert file contains the high-level details of an event (eg: IPs, protocol, port, message id). The log file contains the detailed packet information (a packet dump with the associated event ID). Both file types are written in a bimary format described in spo_unified.h.

Note:   Files have the file creation time (in Unix Epoch format) appended to each file when it is created.

2.3.8.1 Format 

output alert_unified: <base file name> [, <limit <file size limit in MB>]
output log_unified: <base file name> [, <limit <file size limit in MB>]

Figure: Unified Configuration Example
\begin{figure}\begin{verbatim}output alert_unified: snort.alert, limit 128 output log_unified: snort.log, limit 128\end{verbatim} \end{figure}

2.3.9 alert_prelude

Note:   support to use alert_prelude is not built in by default. To use alert_prelude, snort must be built with the -enable-prelude arguement passed to ./configure.

The alert_prelude output plugin is used to log to a Prelude database. For more information on Prelude, see http://www.prelude-ids.org/.

2.3.9.1 format 

output alert_prelude: profile <name of prelude profile> 
    [, info <priority number for info priority alerts>]
    [, low <priority number for low priority alerts>]
    [, medium <priority number for medium priority alerts>]
    [, high <priority number for high priority alerts>]

Figure: alert_prelude configuration example
\begin{figure}\begin{verbatim}output alert_prelude: profile snort, info 4, low 3, medium 2, high 1\end{verbatim} \end{figure}

2.3.10 log null

Sometimes it is useful to be able to create rules that will alert to certain types of traffic but will not cause packet log entries. In Snort 1.8.2, the log_null plugin was introduced. This is equivalent to using the -n command line option but it is able to work within a ruletype.

2.3.10.1 Format 

output log_null
Figure: Log Null Usage Example
\begin{figure}\begin{verbatim}output log_null ...

next up previous contents
Next: 2.4 Dynamic Modules Up: 2. Configuring Snort Previous: 2.2 Event Thresholding   Contents
Terms of Use | Privacy Policy | forum archives | site feedback ©2009 Snort and Sourcefire are registered trademarks of Sourcefire, Inc. All rights reserved.