<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!--Converted with LaTeX2HTML 2002-2-1 (1.71)
original version by: Nikos Drakos, CBLU, University of Leeds
* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>2.5 Output Modules</TITLE>
<META NAME="description" CONTENT="2.5 Output Modules">
<META NAME="keywords" CONTENT="snort_manual">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="LaTeX2HTML v2002-2-1">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
<LINK REL="STYLESHEET" HREF="snort_manual.css">
<LINK REL="previous" HREF="node14.html">
<LINK REL="up" HREF="node10.html">
<LINK REL="next" HREF="node16.html">
</HEAD>
<BODY >
<!--Navigation Panel-->
<A NAME="tex2html528"
HREF="node16.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
<A NAME="tex2html524"
HREF="node10.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A>
<A NAME="tex2html520"
HREF="node14.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A>
<A NAME="tex2html526"
HREF="node1.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>
<BR>
<B> Next:</B> <A NAME="tex2html529"
HREF="node16.html">3. Writing Snort Rules</A>
<B> Up:</B> <A NAME="tex2html525"
HREF="node10.html">2. Configuring Snort</A>
<B> Previous:</B> <A NAME="tex2html521"
HREF="node14.html">2.4 Snort Multi-Event Logging</A>
<B> <A NAME="tex2html527"
HREF="node1.html">Contents</A></B>
<BR>
<BR>
<!--End of Navigation Panel-->
<!--Table of Child-Links-->
<A NAME="CHILD_LINKS"><STRONG>Subsections</STRONG></A>
<UL>
<LI><A NAME="tex2html530"
HREF="node15.html#SECTION00351000000000000000">2.5.1 alert_syslog </A>
<UL>
<LI><A NAME="tex2html531"
HREF="node15.html#SECTION00351100000000000000">2.5.1.1 Available Keywords</A>
<LI><A NAME="tex2html532"
HREF="node15.html#SECTION00351200000000000000">2.5.1.2 Format</A>
</UL>
<BR>
<LI><A NAME="tex2html533"
HREF="node15.html#SECTION00352000000000000000">2.5.2 alert_fast</A>
<UL>
<LI><A NAME="tex2html534"
HREF="node15.html#SECTION00352100000000000000">2.5.2.1 Format</A>
</UL>
<BR>
<LI><A NAME="tex2html535"
HREF="node15.html#SECTION00353000000000000000">2.5.3 alert_full</A>
<UL>
<LI><A NAME="tex2html536"
HREF="node15.html#SECTION00353100000000000000">2.5.3.1 Format</A>
</UL>
<BR>
<LI><A NAME="tex2html537"
HREF="node15.html#SECTION00354000000000000000">2.5.4 alert_unixsock</A>
<UL>
<LI><A NAME="tex2html538"
HREF="node15.html#SECTION00354100000000000000">2.5.4.1 Format</A>
</UL>
<BR>
<LI><A NAME="tex2html539"
HREF="node15.html#SECTION00355000000000000000">2.5.5 log_tcpdump</A>
<UL>
<LI><A NAME="tex2html540"
HREF="node15.html#SECTION00355100000000000000">2.5.5.1 Format</A>
</UL>
<BR>
<LI><A NAME="tex2html541"
HREF="node15.html#SECTION00356000000000000000">2.5.6 database </A>
<UL>
<LI><A NAME="tex2html542"
HREF="node15.html#SECTION00356100000000000000">2.5.6.1 Format</A>
</UL>
<BR>
<LI><A NAME="tex2html543"
HREF="node15.html#SECTION00357000000000000000">2.5.7 csv</A>
<UL>
<LI><A NAME="tex2html544"
HREF="node15.html#SECTION00357100000000000000">2.5.7.1 Format</A>
</UL>
<BR>
<LI><A NAME="tex2html545"
HREF="node15.html#SECTION00358000000000000000">2.5.8 unified</A>
<UL>
<LI><A NAME="tex2html546"
HREF="node15.html#SECTION00358100000000000000">2.5.8.1 Format</A>
</UL>
<BR>
<LI><A NAME="tex2html547"
HREF="node15.html#SECTION00359000000000000000">2.5.9 log null</A>
<UL>
<LI><A NAME="tex2html548"
HREF="node15.html#SECTION00359100000000000000">2.5.9.1 Format</A>
</UL></UL>
<!--End of Table of Child-Links-->
<HR>
<H1><A NAME="SECTION00350000000000000000">
2.5 Output Modules</A>
</H1>
<P>
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.
<P>
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).
<P>
Output modules are loaded at runtime by specifying the output keyword
in the rules file:
<P>
<PRE>
output <name>: <options>
</PRE>
<P>
<DIV ALIGN="CENTER"><A NAME="output_config_example"></A><A NAME="2166"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure:</STRONG>
Output Module Configuration Example</CAPTION>
<TR><TD><IMG
WIDTH="323" HEIGHT="14" BORDER="0"
SRC="img20.png"
ALT="\begin{figure}\begin{verbatim}output alert_syslog: log_auth log_alert\end{verbatim}
\par\end{figure}"></TD></TR>
</TABLE>
</DIV>
<P>
<H2><A NAME="SECTION00351000000000000000"></A><A NAME="alert_syslog_lable"></A>
<BR>
2.5.1 alert_syslog
</H2>
<P>
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.
<P>
<H3><A NAME="SECTION00351100000000000000">
2.5.1.1 Available Keywords</A>
</H3>
<P>
<H4><A NAME="SECTION00351110000000000000">
2.5.1.1.1 Facilities</A>
</H4>
<P>
<UL>
<LI><TT>log_auth</TT>
</LI>
<LI><TT>log_authpriv</TT>
</LI>
<LI><TT>log_daemon</TT>
</LI>
<LI><TT>log_local0</TT>
</LI>
<LI><TT>log_local1</TT>
</LI>
<LI><TT>log_local2</TT>
</LI>
<LI><TT>log_local3</TT>
</LI>
<LI><TT>log_local4</TT>
</LI>
<LI><TT>log_local5</TT>
</LI>
<LI><TT>log_local6</TT>
</LI>
<LI><TT>log_local7</TT>
</LI>
<LI><TT>log_user</TT>
</LI>
</UL>
<P>
<H4><A NAME="SECTION00351120000000000000">
2.5.1.1.2 Priorities</A>
</H4>
<P>
<UL>
<LI><TT>log_emerg</TT>
</LI>
<LI><TT>log_alert</TT>
</LI>
<LI><TT>log_crit</TT>
</LI>
<LI><TT>log_err</TT>
</LI>
<LI><TT>log_warning</TT>
</LI>
<LI><TT>log_notice</TT>
</LI>
<LI><TT>log_info</TT>
</LI>
<LI><TT>log_debug</TT>
</LI>
</UL>
<P>
<H4><A NAME="SECTION00351130000000000000">
2.5.1.1.3 Options</A>
</H4>
<P>
<UL>
<LI><TT>log_cons</TT>
</LI>
<LI><TT>log_ndelay</TT>
</LI>
<LI><TT>log_perror</TT>
</LI>
<LI><TT>log_pid</TT>
</LI>
</UL>
<P>
<H3><A NAME="SECTION00351200000000000000">
2.5.1.2 Format</A>
</H3>
<P>
<PRE>
alert_syslog: <facility> <priority> <options>
</PRE>
<P>
<BR>
<BR><I>
<FONT SIZE="+4"><IMG
WIDTH="18" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
SRC="img3.png"
ALT="$\triangle$"> <FONT SIZE="+2"><IMG
WIDTH="8" HEIGHT="20" ALIGN="BOTTOM" BORDER="0"
SRC="img4.png"
ALT="$^!$"></FONT></FONT>
<FONT SIZE="+2">NOTE</FONT>
</I>
<DIV ALIGN="CENTER">
</DIV>
<P>
<DIV ALIGN="CENTER">
<BR>
</DIV>
<P>
<DIV ALIGN="CENTER">
<!-- MATH
$\fbox{
\usebox{
\savepar
}
}$
-->
<IMG
WIDTH="714" HEIGHT="76" ALIGN="MIDDLE" BORDER="0"
SRC="img5.png"
ALT="\fbox{
\usebox{
\savepar
}
}">
</DIV>
<P>
<DIV ALIGN="CENTER">
</DIV>
<P>
<PRE>
output alert_syslog: [host=<hostname[:<port>],] <facility> <priority> <options>
</PRE>
<P>
<DIV ALIGN="CENTER"><A NAME="syslog_example"></A><A NAME="2168"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure:</STRONG>
Syslog Configuration Example</CAPTION>
<TR><TD><IMG
WIDTH="550" HEIGHT="14" BORDER="0"
SRC="img21.png"
ALT="\begin{figure}\begin{verbatim}output alert_syslog: 10.1.1.1:514, <facility> <priority> <options>\end{verbatim}
\par\end{figure}"></TD></TR>
</TABLE>
</DIV>
<P>
<H2><A NAME="SECTION00352000000000000000">
2.5.2 alert_fast</A>
</H2>
<P>
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
<P>
<H3><A NAME="SECTION00352100000000000000">
2.5.2.1 Format</A>
</H3>
<P>
<PRE>
alert_fast: <output filename>
</PRE>
<DIV ALIGN="CENTER"><A NAME="fast_alert_configuration"></A><A NAME="2169"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure:</STRONG>
Fast Alert Configuration</CAPTION>
<TR><TD><IMG
WIDTH="240" HEIGHT="14" BORDER="0"
SRC="img22.png"
ALT="\begin{figure}\begin{verbatim}output alert_fast: alert.fast\end{verbatim}
\par\end{figure}"></TD></TR>
</TABLE>
</DIV>
<P>
<H2><A NAME="SECTION00353000000000000000">
2.5.3 alert_full</A>
</H2>
<P>
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.
<P>
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.
<P>
<H3><A NAME="SECTION00353100000000000000">
2.5.3.1 Format</A>
</H3>
<P>
<PRE>
alert_full: <output filename>
</PRE>
<DIV ALIGN="CENTER"><A NAME="full_alert_configuration"></A><A NAME="2170"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure:</STRONG>
Full Alert Configuration</CAPTION>
<TR><TD><IMG
WIDTH="241" HEIGHT="14" BORDER="0"
SRC="img23.png"
ALT="\begin{figure}\begin{verbatim}output alert_full: alert.full\end{verbatim}
\par\end{figure}"></TD></TR>
</TABLE>
</DIV>
<P>
<H2><A NAME="SECTION00354000000000000000">
2.5.4 alert_unixsock</A>
</H2>
<P>
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.
<P>
<H3><A NAME="SECTION00354100000000000000">
2.5.4.1 Format</A>
</H3>
<P>
<PRE>
alert_unixsock
</PRE>
<DIV ALIGN="CENTER"><A NAME="unixsock_configuration"></A><A NAME="2171"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure:</STRONG>
UNIXSock Alert Configuration</CAPTION>
<TR><TD><IMG
WIDTH="174" HEIGHT="14" BORDER="0"
SRC="img24.png"
ALT="\begin{figure}\begin{verbatim}output alert_unixsock\end{verbatim}
\par\end{figure}"></TD></TR>
</TABLE>
</DIV>
<P>
<H2><A NAME="SECTION00355000000000000000">
2.5.5 log_tcpdump</A>
</H2>
<P>
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.
<P>
<H3><A NAME="SECTION00355100000000000000">
2.5.5.1 Format</A>
</H3>
<P>
<PRE>
log_tcpdump: <output filename>
</PRE>
<DIV ALIGN="CENTER"><A NAME="tcpdump_output_configuration"></A><A NAME="2172"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure:</STRONG>
Tcpdump Output Module Configuration
Example</CAPTION>
<TR><TD><IMG
WIDTH="241" HEIGHT="14" BORDER="0"
SRC="img25.png"
ALT="\begin{figure}\begin{verbatim}output log_tcpdump: snort.log\end{verbatim}
\par\end{figure}"></TD></TR>
</TABLE>
</DIV>
<P>
<H2><A NAME="SECTION00356000000000000000"></A><A NAME="database_section"></A>
<BR>
2.5.6 database
</H2>
<P>
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 <A HREF="#database_output_config"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]" SRC="crossref.png"></A> for example usage.
<P>
<H3><A NAME="SECTION00356100000000000000">
2.5.6.1 Format</A>
</H3>
<P>
<PRE>
database: <log | alert>, <database type>, <parameter list>
</PRE>
The following parameters are available:
<P>
<DL>
<DD>
</DD>
<DT><STRONG><TT>host</TT></STRONG></DT>
<DD>- 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.
</DD>
<DT><STRONG><TT>port</TT></STRONG></DT>
<DD>- Port number to connect to at the server host, or socket filename extension for UNIX-domain connections.
</DD>
<DT><STRONG><TT>dbname</TT></STRONG></DT>
<DD>- Database name
</DD>
<DT><STRONG><TT>user</TT></STRONG></DT>
<DD>- Database username for authentication
</DD>
<DT><STRONG><TT>password</TT></STRONG></DT>
<DD>- Password used if the database demands password authentication
</DD>
<DT><STRONG><TT>sensor_name</TT></STRONG></DT>
<DD>- Specify your own name for this Snort sensor. If you do not specify a name, one will be generated automatically
</DD>
<DT><STRONG><TT>encoding</TT></STRONG></DT>
<DD>- 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:
<P>
<DL>
<DD>
</DD>
<DT><STRONG><TT>hex</TT></STRONG></DT>
<DD>(default) - Represent binary data as a hex string.
<P>
<DL>
<DD>
</DD>
<DT><STRONG>Storage requirements</STRONG></DT>
<DD>- 2x the size of the binary
</DD>
<DT><STRONG>Searchability</STRONG></DT>
<DD>- very good
</DD>
<DT><STRONG>Human readability</STRONG></DT>
<DD>- not readable unless you are a true geek, requires post processing
</DD>
</DL>
</DD>
<DT><STRONG><TT>base64</TT></STRONG></DT>
<DD>- Represent binary data as a base64 string.
<P>
<DL>
<DD>
</DD>
<DT><STRONG>Storage requirements</STRONG></DT>
<DD>- <IMG
WIDTH="16" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
SRC="img26.png"
ALT="$\sim$">1.3x the size of the binary
</DD>
<DT><STRONG>Searchability</STRONG></DT>
<DD>- impossible without post processing
</DD>
<DT><STRONG>Human readability</STRONG></DT>
<DD>- not readable requires post processing
</DD>
</DL>
<P>
</DD>
<DT><STRONG><TT>ascii</TT></STRONG></DT>
<DD>- 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.
<P>
<DL>
<DD>
</DD>
<DT><STRONG>Storage requirements</STRONG></DT>
<DD>- slightly larger than the binary because
some characters are escaped (&,<IMG
WIDTH="16" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
SRC="img1.png"
ALT="$<$">,<IMG
WIDTH="16" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
SRC="img2.png"
ALT="$>$">)
</DD>
<DT><STRONG>Searchability</STRONG></DT>
<DD>- very good for searching for a text string impossible
if you want to search for binary
</DD>
<DT><STRONG>human readability</STRONG></DT>
<DD>- very good
</DD>
</DL>
</DD>
</DL>
</DD>
<DT><STRONG><TT>detail</TT></STRONG></DT>
<DD>- How much detailed data do you want to store? The options
are:
<P>
<DL>
<DD>
</DD>
<DT><STRONG><TT>full</TT></STRONG></DT>
<DD>(default) - Log all details of a packet that caused an alert
(including IP/TCP options and the payload)
</DD>
<DT><STRONG><TT>fast</TT></STRONG></DT>
<DD>- 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: <TT>timestamp</TT>, <TT>signature</TT>, <TT>source ip</TT>, <TT>destination ip</TT>, <TT>source
port</TT>, <TT>destination port</TT>, <TT>tcp flags</TT>, and <TT>protocol</TT>)
</DD>
</DL>
</DD>
</DL>
Furthermore, there is a logging method and database type that must
be defined. There are two logging types available, <TT>log</TT> and <TT>alert</TT>.
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.
<P>
There are five database types available in the current version of the plugin.
These are <TT>mssql</TT>, <TT>mysql</TT>, <TT>postgresql</TT>, <TT>oracle</TT>, and <TT>odbc</TT>.
Set the type to match
the database you are using.
<P>
<BR>
<BR><I>
<FONT SIZE="+4"><IMG
WIDTH="18" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
SRC="img3.png"
ALT="$\triangle$"> <FONT SIZE="+2"><IMG
WIDTH="8" HEIGHT="20" ALIGN="BOTTOM" BORDER="0"
SRC="img4.png"
ALT="$^!$"></FONT></FONT>
<FONT SIZE="+2">NOTE</FONT>
</I>
<DIV ALIGN="CENTER">
</DIV>
<P>
<DIV ALIGN="CENTER">
<BR>
</DIV>
<P>
<DIV ALIGN="CENTER">
<!-- MATH
$\fbox{
\usebox{
\savepar
}
}$
-->
<IMG
WIDTH="714" HEIGHT="76" ALIGN="MIDDLE" BORDER="0"
SRC="img5.png"
ALT="\fbox{
\usebox{
\savepar
}
}">
</DIV>
<P>
<DIV ALIGN="CENTER">
</DIV>
<P>
<DIV ALIGN="CENTER"><A NAME="database_output_config"></A><A NAME="2174"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure:</STRONG>
Database Output Plugin Configuration</CAPTION>
<TR><TD><IMG
WIDTH="667" HEIGHT="14" BORDER="0"
SRC="img27.png"
ALT="\begin{figure}\begin{verbatim}output database: log, mysql, dbname=snort user=snort host=localhost password=xyz\end{verbatim}
\par\end{figure}"></TD></TR>
</TABLE>
</DIV>
<P>
<H2><A NAME="SECTION00357000000000000000">
2.5.7 csv</A>
</H2>
<P>
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.
<P>
The list of formatting options is below. If the formatting option
is default, the output is in the order the formatting option is listed.
<P>
<UL>
<LI><TT>timestamp</TT>
</LI>
<LI><TT>sig_generator</TT>
</LI>
<LI><TT>sig_id</TT>
</LI>
<LI><TT>sig_rev</TT>
</LI>
<LI><TT>msg</TT>
</LI>
<LI><TT>proto</TT>
</LI>
<LI><TT>src</TT>
</LI>
<LI><TT>srcport</TT>
</LI>
<LI><TT>dst</TT>
</LI>
<LI><TT>dstport</TT>
</LI>
<LI><TT>ethsrc</TT>
</LI>
<LI><TT>ethdst</TT>
</LI>
<LI><TT>ethlen</TT>
</LI>
<LI><TT>tcpflags</TT>
</LI>
<LI><TT>tcpseq</TT>
</LI>
<LI><TT>tcpack</TT>
</LI>
<LI><TT>tcplen</TT>
</LI>
<LI><TT>tcpwindow</TT>
</LI>
<LI><TT>ttl</TT>
</LI>
<LI><TT>tos</TT>
</LI>
<LI><TT>id</TT>
</LI>
<LI><TT>dgmlen</TT>
</LI>
<LI><TT>iplen</TT>
</LI>
<LI><TT>icmptype</TT>
</LI>
<LI><TT>icmpcode</TT>
</LI>
<LI><TT>icmpid</TT>
</LI>
<LI><TT>icmpseq</TT>
</LI>
</UL>
<P>
<H3><A NAME="SECTION00357100000000000000">
2.5.7.1 Format</A>
</H3>
<P>
<PRE>
output alert_csv: <filename> <format>
</PRE>
<DIV ALIGN="CENTER"><A NAME="csv_output_configuration"></A><A NAME="2175"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure:</STRONG>
CSV Output Configuration</CAPTION>
<TR><TD><IMG
WIDTH="425" HEIGHT="53" BORDER="0"
SRC="img28.png"
ALT="\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}"></TD></TR>
</TABLE>
</DIV>
<P>
<H2><A NAME="SECTION00358000000000000000">
2.5.8 unified</A>
</H2>
<P>
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.
<P>
The name <I>unified</I> is a misnomer, as the unified output plugin creates two
different files, an <I>alert</I> file, and a <I>log</I> 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 <I>spo_unified.h</I>.
<P>
<BR>
<BR><I>
<FONT SIZE="+4"><IMG
WIDTH="18" HEIGHT="30" ALIGN="MIDDLE" BORDER="0"
SRC="img3.png"
ALT="$\triangle$"> <FONT SIZE="+2"><IMG
WIDTH="8" HEIGHT="20" ALIGN="BOTTOM" BORDER="0"
SRC="img4.png"
ALT="$^!$"></FONT></FONT>
<FONT SIZE="+2">NOTE</FONT>
</I>
<DIV ALIGN="CENTER">
</DIV>
<P>
<DIV ALIGN="CENTER">
<BR>
</DIV>
<P>
<DIV ALIGN="CENTER">
<!-- MATH
$\fbox{
\usebox{
\savepar
}
}$
-->
<IMG
WIDTH="714" HEIGHT="76" ALIGN="MIDDLE" BORDER="0"
SRC="img5.png"
ALT="\fbox{
\usebox{
\savepar
}
}">
</DIV>
<P>
<DIV ALIGN="CENTER">
</DIV>
<P>
<H3><A NAME="SECTION00358100000000000000">
2.5.8.1 Format</A>
</H3>
<P>
<PRE>
output alert_unified: <base file name> [, <limit <file size limit in MB>]
output log_unified: <base file name> [, <limit <file size limit in MB>]
</PRE>
<P>
<DIV ALIGN="CENTER"><A NAME="unified_example"></A><A NAME="2176"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure:</STRONG>
Unified Configuration Example</CAPTION>
<TR><TD><IMG
WIDTH="366" HEIGHT="33" BORDER="0"
SRC="img29.png"
ALT="\begin{figure}\begin{verbatim}output alert_unified: snort.alert, limit 128
output log_unified: snort.log, limit 128\end{verbatim}
\end{figure}"></TD></TR>
</TABLE>
</DIV>
<P>
<H2><A NAME="SECTION00359000000000000000">
2.5.9 log null</A>
</H2>
<P>
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.
<P>
<H3><A NAME="SECTION00359100000000000000">
2.5.9.1 Format</A>
</H3>
<P>
<PRE>
output log_null
</PRE>
<DIV ALIGN="CENTER"><A NAME="log_null_usage_example"></A><A NAME="2177"></A>
<TABLE>
<CAPTION ALIGN="BOTTOM"><STRONG>Figure:</STRONG>
Log Null Usage Example</CAPTION>
<TR><TD><IMG
WIDTH="318" HEIGHT="126" BORDER="0"
SRC="img30.png"
ALT="\begin{figure}\begin{verbatim}output log_null ..."></TD></TR>
</TABLE>
</DIV>
<P>
<HR>
<!--Navigation Panel-->
<A NAME="tex2html528"
HREF="node16.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
<A NAME="tex2html524"
HREF="node10.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A>
<A NAME="tex2html520"
HREF="node14.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A>
<A NAME="tex2html526"
HREF="node1.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>
<BR>
<B> Next:</B> <A NAME="tex2html529"
HREF="node16.html">3. Writing Snort Rules</A>
<B> Up:</B> <A NAME="tex2html525"
HREF="node10.html">2. Configuring Snort</A>
<B> Previous:</B> <A NAME="tex2html521"
HREF="node14.html">2.4 Snort Multi-Event Logging</A>
<B> <A NAME="tex2html527"
HREF="node1.html">Contents</A></B>
<!--End of Navigation Panel-->
</BODY>
</HTML>
