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>
output alert_syslog: log_auth log_alert
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.
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>
output alert_syslog: 10.1.1.1:514, <facility> <priority> <options>
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 and because it logs to only 1 file.
output alert_fast: [<filename> ["packet"] [<limit>]]
<limit> ::= <number>[('G'|'M'|K')]
![[*]](crossref.png)
for more information.
output alert_fast: alert.fast
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.
output alert_full: [<filename> [<limit>]]
<limit> ::= <number>[('G'|'M'|K')]
for more information.
output alert_full: alert.full
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.
alert_unixsock
output alert_unixsock
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.
output log_tcpdump: [<filename> [<limit>]]
<limit> ::= <number>[('G'|'M'|K')]
for more information.
output log_tcpdump: snort.log
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.
database: <log | alert>, <database type>, <parameter list>
The following parameters are available:
1.3x the size of the binary
,
)
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
|
The csv output plugin allows alert data to be written in a format easily importable to a database. The output fields and their order may be customized.
output alert_csv: [<filename> [<format> [<limit>]]]
<format> ::= "default"|<list>
<list> ::= <field>(,<field>)*
<field> ::= "dst"|"src"|"ttl" ...
<limit> ::= <number>[('G'|'M'|K')]
for more information.
output alert_csv: /var/log/alert.csv default
output alert_csv: /var/log/alert.csv timestamp, msg
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.
|
output alert_unified: <base file name> [, <limit <file size limit in MB>]
output log_unified: <base file name> [, <limit <file size limit in MB>]
output alert_unified: snort.alert, limit 128
output log_unified: snort.log, limit 128
The unified2 output plugin is a replacement for the unified output plugin. It
has the same performance characteristics, but a slightly different logging
format. See section on unified logging for more information.
Unified2 can work in one of three modes, packet logging, alert logging, or true unified logging. Packet logging includes a capture of the entire packet and is specified with log_unified2. Likewise, alert logging will only log events and is specified with alert_unified2. To include both logging styles in a single, unified file, simply specify unified2.
When MPLS support is turned on, MPLS labels can be included in unified2 events. Use option mpls_event_types to enable this. If option mpls_event_types is not used, then MPLS labels will be not be included in unified2 events.
|
Note:
By default, unified 2 files have the file creation time (in Unix Epoch format) appended to each file when it is created.
|
output alert_unified2: \
filename <base filename> [, <limit <size in MB>] [, nostamp] [, mpls_event_types]
output log_unified2: \
filename <base filename> [, <limit <size in MB>] [, nostamp]
output unified2: \
filename <base file name> [, <limit <size in MB>] [, nostamp] [, mpls_event_types]
output alert_unified2: filename snort.alert, limit 128, nostamp
output log_unified2: filename snort.log, limit 128, nostamp
output unified2: filename merged.log, limit 128, nostamp
output unified2: filename merged.log, limit 128, nostamp, mpls_event_types
|
Note:
support to use alert_prelude is not built in by default. To use alert_prelude, snort must be built with the -enable-prelude argument 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/.
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>]
output alert_prelude: profile=snort info=4 low=3 medium=2
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.
output log_null
output log_null # like using snort -n
ruletype info {
type alert
output alert_fast: info.alert
output log_null
}
|
Note:
Support to use alert_aruba_action is not built in by default. To use alert_aruba_action, snort must be built with the -enable-aruba argument passed to ./configure.
|
Communicates with an Aruba Networks wireless mobility controller to change the status of authenticated users. This allows Snort to take action against users on the Aruba controller to control their network privilege levels.
For more information on Aruba Networks access control, see http://www.arubanetworks.com/.
output alert_aruba_action: \
<controller address> <secrettype> <secret> <action>
The following parameters are required:
output alert_aruba_action: \
10.3.9.6 cleartext foobar setrole:quarantine_role
This section pertains to logs produced by alert_fast, alert_full, alert_csv, and log_tcpdump. unified and unified2 also may be given limits. Those limits are described in the respective sections.
When a configured limit is reached, the current log is closed and a new log is opened with a UNIX timestamp appended to the configured log name.
Limits are configured as follows:
<limit> ::= <number>[(<gb>|<mb>|<kb>)]
<gb> ::= 'G'|'g'
<mb> ::= 'M'|'m'
<kb> ::= 'K'|'k'
Rollover will occur at most once per second so if limit is too small for logging rate, limit will be exceeded. Rollover works correctly if snort is stopped/restarted.