This chapter is from the book
This chapter is from the book
This chapter is from the book
Output Plugins
Snort's output plugins are the means Snort has to get intrusion data to you. The purpose of the output plugins is to dump alerting data to another resource or file. Multiple outputting plugins can be activated to perform different functions. Loads of external applications—some even built exclusively for Snort—are designed to read Snort's output and manage intrusion data. Chapters 6 and 11 examine some of these applications.
Output plugins can be a major bottleneck for Snort. Snort can read and process packets quickly, but bogs down when trying to write to a slow database or over a network. Database output plugins are not used in high-bandwidth environments. It is recommended to configure Snort to spool to unified format and let Snort's unified log application, Barnyard, take over. Snort has 12 output plugins that push out data in different formats.
Alert_fast
Alert_fast is the quick and dirty outputting mechanism for Snort. It spits out alerts in a one-line file as fast as the detection engine can spawn them. With Alert_fast Snort does not write packet headers, making it a fast but brief method of logging. Alert_fast takes one configuration option.
[filename] is simply the name of the file for Alert_fast to log to. The log is created in the default logging directory (/var/log/snort) or the directory specified.
Alert_full
This is a somewhat antiquated logging facility for Snort, but still useful for low- bandwidth networks. Alert_full creates a directory for each IP that generates an alert and fills it with decoded packet dumps. It includes the packet headers in the dumps, unlike Alert_fast. It has one configuration option.
[filename] is simply the name of the file for Alert_full to log to. The log is created in the default logging directory (/var/log/snort) or the directory specified.
Alert_smb
Alert_smb is another antiquated output plugin. It sends windows SMB requests to Windows machines. If you take perverse pleasure in clearing message boxes hour after hour, this plugin is for you. Alert_smb sends alerting information in the clear, and executes an external binary with root privileges, making it a security risk in and of itself. Alert_smb has one configuration option.
[alertworkstationlist] is a file listing workstation to be notified. The format of the workstation file is a list of the NETBIOS names of the hosts, one per line.
Alert_unixsock
This plugin sets up a Unix domain socket and sends alerts to it. External programs/processes can listen in on this socket and receive Snort alert and packet data in real time. This plugin does not work with Windows installations, for obvious reasons. Alert_unixsock has no configuration options.
Log_tcpdump
Log_tcpdump logs packets to the famous tcpdump file format. There exists a wide assortment of applications and tools designed to read tcpdump output. This module enables you to use them in conjunction with Snort. Log_tcpdump has one configuration option.
[filename] is the name of the output file. The [filename] will have the <month><date>@<time> prepended to it. This is to keep data from separate Snort runs distinct.
CSV
The CSV plugin outputs to a comma delimited file. CSV files are easily imported into other databases and spreadsheets. The data separated by commas can be organized in any manner required. You can use CSV to write as few as one field or all 24. CSV takes two configuration options.
[filename]
This is the name of the output file.
[default | field list]
Here you can list out the fields in your desired order. The possible fields are:
You can modify this list to output the fields you want in the order you desire. If you specify default, CSV outputs a comma-separated file in the preceding order.
XML
The XML plugin allows you to log to Simple Network Markup Language (SNML). SNML can be used to collect data from many different sensors in a single management database. The XML plugin logs via encrypted or plain text HTTP sessions. XML has a unique sanitization feature. With the santization feature enabled, all IP addresses will be outputted with the mask, XXX.XXX.XXX.XXX. You can then anonymously submit your intrusion data for review by other entities, such as the CERT/CC (check http://www.cert.org for more information). CERT/CC can use this data to predict trends and monitor malicious activity on a global scale. The XML plugin has a good number of configuration options.
log or alert
This is used to specify whether to attach the XML output plugin to the log or alert facility. Certain rules are set to "alert" while others are set to "log"; this option outputs the chosen rule type.
parameter list
This option is a monster list of possible parameters for configuring XML to function in the way you want it to. Parameters are set in the familiar name=value pair. A list of names and descriptions follows:
file—Filename for XML output. If this is the only parameter entered, it writes to disk, to a local file.
protocol—Used to specify the protocol for logging to a remote host. Possible values are
n http—Send output via HTTP posts; requires file parameter
n -https—Send via encrypted HTTPS posts; requires file, cert, and key parameters
n -tcp—Send via a TCP port; requires an external application to listen to the TCP port
host—The remote host to send logs to.
cert—The client certificate to be used for HTTPS communication.
sanitize—An IP address range with netmask combination. The range specified will be sanitized. You can use this option several times to sanitize multiple ranges. With any alerts that are sanitized, packet payloads are not logged.
hex—Include this name with no value to store binary data in hex.
base64—Include this name with no value to store binary data in base64 encoding.
ascii—Include this name with no value to store binary data in human-readable ASCII encoding.
detail—Can be either full or fast. With full you log all details of the packet that Snort has available. Fast logs only timestamp, signature, source and destination IPs, source and destination ports, TCP flags, and protocol.
Alert_syslog
Alert_syslog writes to the syslog facility. A syslog server can be used to collect logging information from a variety of different devices not related to Snort, such as routers, firewalls, Web servers, and so on. Inputting Snort intrusion data into a syslog server can vastly aid in event correlation and problem identification. Writing alerting data to syslog can be used in conjunction with other tools to perform real-time alerting and notification. Alert_syslog is one of the most popular outputting plugins.
This plugin cannot be used to log to a remote syslog server if the sensor is installed on a Windows machine. You must use the command-line option for syslog (-s) to write to a remote syslog server. Alert_syslog supports the standard three syslog configuration options.
facility
This is the facility parameter that will be assigned to Alert_syslog output in the syslog server. The default is LOG_AUTH. You may want to use LOG_AUTHPRIV if others will be working with the syslog server but should not have access to intrusion data.
priority
This is the priority parameter that will be assigned to Alert_syslog output in the syslog server. The default is LOG_ALERT. This setting is a good fit for alerts; it is included with other critical events.
options
This is the option parameter that will be assigned to Alert_syslog output in the syslog server. The default is not assigned. You can use options to write directly to the console, or to log Snort's process ID with each alert. The options parameter can be used to identify multiple Snort processes on a single machine.
Database
The database output plugin logs directly to a relational database of your choice. It supports MySQL, PostgreSQL, Oracle, and UnixODBC-compliant databases such as SAPdb. Outputting to a relational database makes large amounts of intrusion data accessible. When the database plugin is placed into a database, alerts can be sorted, searched for, and prioritized in an organized manner. There are several applications that use the intrusion data in a relational database to create a management GUI. Snort data is written to the database in the table structure shown in Figure 3.3.
)
Figure
3.3 Snort database structure.
The database plugin can serve as a bottleneck in even moderately saturated networks. The plugin itself is not a bottleneck; rather, the database being written to is. When the database plugin writes to the chosen database, it must wait until the database is ready for another write. Writing to a remote database over a network can exacerbate the problem.
The database plugin has three options.
log or alert
This option lets you write alert or log data to the selected database. Remember, you can enable as many output plugins as you wish. To write both alert and log data to the same database, activate the database plugin twice, once with alert and once with log.
mysql or postgresql or unixodbc or mssql
This is the type of database you are going to write to. You can write to MySQL, PostgreSQL, Oracle, Microsoft's SQL Server, and UnixODBC-compliant databases.
parameter list
This list contains the name=value pairs required to successfully write to a database. The names and descriptions are as follows:
host—This is the host where the database resides. Set to localhost if connecting to a database local to Snort.
port—The port number to connect at the remote database host.
dbname—The database username required to log in to the database.
password—The password required to authenticate to the database.
sensor_name—The name you want given to this sensor or Snort process in the database.
hex—Include this name with no value to store binary data in hex. This is the default.
base64—Include this name with no value to store binary data in base64 encoding.
ascii—Include this name with no value to store binary data in human-readable ASCII encoding.
detail—Can be either full or fast. With full you log all details of the packet that Snort has available. Fast logs only timestamp, signature, source and destination IPs, source and destination ports, TCP flags, and protocol.
Unified
The unified output plugin is designed specifically for speed. It is the fastest possible method of outputting Snort intrusion data. Unified writes intrusion data to its own binary format. It outputs two files: an alert file and a packet log file. The alert file contains a summary of the alert, including only the source and destination IP addresses, the protocol, the source and destination ports, and the alert message id. The log file contains the full packet information.
The purpose of the unified plugin is to allow data to be pushed out of Snort as fast as possible and to outsource plugins to a dedicated application. The application, Barnyard, reads unified output and sends data to other plugins, namely database output plugins. This gives Snort the luxury of not having to wait for a slower database to be ready to accept more input.
Unlike other plugins, the unified plugin is enabled with two different commands. The alert_unified command outputs alert data and the log_unified command outputs log data. Each produces a file that has a time signature (monthday@hourminute-) prepended to it. They both have one configuration option.
limit [maximum size]
The maximum size to which a file is allowed to grow. Default is 128MB.