snort_manual.tex

This is the snapshot of Snot Latest Rules

\subsection{NIDS Mode Output Options}

There are a number of ways to configure the output of Snort in NIDS
mode. The default logging and alerting mechanisms are to log in decoded
ASCII format and use full alerts. The full alert
mechanism prints out the alert message in addition to the full packet
headers. There are several other alert output modes available at the
command line, as well as two logging facilities.

Alert modes are somewhat more complex. There are seven alert modes available
at the command line: full, fast, socket, syslog, console, cmg, and
none. Six of these modes are accessed with the -A command line switch.
These options are:

\begin{tabular}{| l | p{5.4in} |}
\hline
{\bf Option} & {\bf Description}\\
\hline
\hline
{\tt -A fast} & Fast alert mode. Writes the alert in a simple format with a timestamp, alert message, source
and destination IPs/ports.\\
\hline
{\tt -A full} & Full alert mode. This is the default alert mode and will be used automatically if you do not specify a mode.\\
\hline
{\tt -A unsock} & Sends alerts to a UNIX socket that another program can listen on.\\
\hline
{\tt -A none} & Turns off alerting.\\
\hline
{\tt -A console} & Sends ``fast-style'' alerts to the console (screen).\\
\hline
{\tt -A cmg} & Generates ``cmg style'' alerts.\\
\hline
\end{tabular}

Packets can be logged to their default decoded ASCII format or to
a binary log file via the -b command line switch. To disable
packet logging altogether, use the -N command line switch.

For output modes available through the configuration file, see Section
\ref{output config}.

\begin{note}
Command line logging options override any output options specified 
in the configuration file. This allows debugging of configuration 
issues quickly via the command line.
\end{note}

To send alerts to syslog, use the -s switch. The default facilities
for the syslog alerting mechanism are LOG\_AUTHPRIV and LOG\_ALERT.
If you want to configure other facilities for syslog output, use the
output plugin directives in the rules files. See Section \ref{alert syslog lable}
for more details on configuring syslog output.

For example, use the following command line to log to default (decoded ASCII) facility and send alerts to syslog: 

\begin{verbatim}
./snort -c snort.conf -l ./log -h 192.168.1.0/24 -s
\end{verbatim}

As another example, use the following command line to log to the default facility in /var/log/snort and send alerts to a
fast alert file: 

\begin{verbatim}
./snort -c snort.conf -A fast -h 192.168.1.0/24
\end{verbatim}

\subsection{Understanding Standard Alert Output}

When Snort generates an alert message, it will usually look like the following:
 
 \begin{verbatim}	 
  [**] [116:56:1] (snort_decoder): T/TCP Detected [**]
 \end{verbatim}
  	 
  The first number is the Generator ID, this tells the user what
  component of Snort generated this alert. For a list of GIDs, please read
  etc/generators in the Snort source. In this case, we know that this event
  came from the ``decode'' (116) component of Snort.
  	 
  The second number is the Snort ID (sometimes referred to as
  Signature ID). For a list of preprocessor SIDs, please see
  etc/gen-msg.map.  Rule-based SIDs are written directly into the rules
  with the \emph{sid} option. In this case, \emph{56} represents a T/TCP event.
  	 
  The third number is the revision ID. This number is primarily
  used when writing signatures, as each rendition of the rule should
  increment this number with the \emph{rev} option.



\subsection{High Performance Configuration}

If you want Snort to go \emph{fast} (like keep up with a 1000 Mbps connection),
you need to use unified logging and a unified log reader such as
\emph{barnyard}.  This allows Snort to log alerts in a binary form as fast as
possible while another program performs the slow actions, such as writing to a
database.

If you want a text file that's easily parsable, but still somewhat fast, try
using binary logging with the ``fast'' output mechanism. 

This will log packets in tcpdump format and produce minimal alerts. For
example:

\begin{center}
\begin{verbatim}
./snort -b -A fast -c snort.conf
\end{verbatim}
\end{center}

\subsection{Changing Alert Order}

The default way in which Snort applies its rules to packets may not be
appropriate for all installations.  The Alert rules are applied first, then the
Pass rules, and finally, Log rules are applied. This sequence is somewhat
counterintuitive, but it's a more foolproof method than allowing a user to
write a hundred alert rules that are then disabled by an errant pass rule.  For
more information on rule types, see Section \ref{rules action section}.

If you know what you're doing, you can use the -o switch to change the default
rule application behavior to apply Pass rules, then Alert rules, then Log
rules:
\begin{center}
\begin{verbatim}
./snort -d -h 192.168.1.0/24 -l ./log -c snort.conf -o
\end{verbatim}
\end{center}

As of Snort 2.6.0, the command line flags \texttt{--alert-before-pass}
and \texttt{--treat-drop-as-alert} were added to handle changes to rule
ordering and fix an issue when pass and drop rules were not always
enforced.  The \texttt{--alert-before-pass} option forces alert rules
to take affect in favor of a pass rule.  The \texttt{--treat-drop-as-alert}
causes drop, sdrop, and reject rules and any associated alerts to be logged
as alerts, rather then the normal action.  This allows use of an inline
policy with passive/IDS mode.

Additionally, the \texttt{--process-all-events} option causes Snort to
process every event associated with a packet, while taking the actions
based on the rules ordering.  Without this option (default case), only
the events for the first action based on rules ordering are processed.

\begin{note}
Pass rules are special cases here, in that the event processing is
terminated when a pass rule is encountered, regardless of the use of
\texttt{--process-all-events}.
\end{note}

\begin{note}
The additions with Snort 2.6.0 will result in the deprecation of the
-o switch in a future release.
\end{note}

\section{Inline Mode\label{Snort Inline}}

Snort 2.3.0 RC1 integrated the intrusion prevention system (IPS) capability of
\texttt{Snort Inline} into the official Snort project. \texttt{Snort Inline} obtains packets
from iptables instead of libpcap and then uses new rule types to help iptables
pass or drop packets based on Snort rules.  

In order for \texttt{Snort Inline} to work properly, you must download and compile the
iptables code to include ``make install-devel''
(\url{http://www.iptables.org}).  This will install the \texttt{libipq} library
that allows \texttt{Snort Inline} to interface with iptables.  Also, you must build and
install LibNet, which is available from \url{http://www.packetfactory.net}.

There are three rule types you can use when running Snort with \texttt{Snort Inline}:

\begin{itemize}
\item \textbf{drop} - The drop rule type will tell iptables to drop the packet and log it 
       via usual Snort means.
\item \textbf{reject} - The reject rule type will tell iptables to drop the packet, log it 
         via usual Snort means, and send a TCP reset if the protocol is 
         TCP or an icmp port unreachable if the protocol is UDP.
\item \textbf{sdrop} - The sdrop rule type will tell iptables to drop the packet.  Nothing
        is logged.
\end{itemize}

\begin{note}
You can also replace sections of the packet payload when using \texttt{Snort Inline}.
See Section \ref{ReplaceInline} for more information.
\end{note}

When using a \texttt{reject} rule, there are two options you can use to send
TCP resets:
\begin{itemize}

\item You can use a RAW socket (the default behavior for \texttt{Snort Inline}), in which case you must have an interface that has an IP address assigned to it. If there is not an interface with an IP address assigned with access to the source of the packet, the packet will be logged and the reset packet will never make it onto the network.

\item You can also now perform resets via a physical device when using iptables.  We take the indev name from ip\_queue and use this as the interface on which to send resets. We no longer need an IP loaded on the bridge, and can remain pretty stealthy as the \texttt{config layer2\_resets} in snort\_inline.conf takes a source MAC address which we substitue for the MAC of the bridge. For example:
\begin{verbatim}
config layer2resets
\end{verbatim}
tells \texttt{Snort Inline} to use layer2 resets and uses the MAC address of the bridge as the source MAC in the packet, and:
\begin{verbatim}
config layer2resets: 00:06:76:DD:5F:E3  
\end{verbatim}
will tell Snort Inline to use layer2 resets and uses the source MAC of 
00:06:76:DD:5F:E3 in the reset packet.

\item The command-line option \texttt{--disable-inline-initialization} can be
used to not initialize IPTables when in inline mode.  To be used with
command-line option \texttt{-T} to test for a valid configuration without
requiring opening inline devices and adversely affecting traffic flow.

\end{itemize}

\subsection{Snort Inline Rule Application Order\label{InlineRuleOrder}}

The current rule application order is: 
\begin{verbatim}
	->activation->dynamic->drop->sdrop->reject->alert->pass->log
\end{verbatim}
This will ensure that a drop rule has precedence over an alert or log rule.
You can use the -o flag to change the rule application order to:
\begin{verbatim}
	->activation->dynamic->pass->drop->sdrop->reject->alert->log
\end{verbatim}

\subsection{New STREAM4 Options for Use with Snort Inline\label{Stream4Inline}}

When using \texttt{Snort Inline}, you can use two additional stream4 options:

\begin{itemize}
\item \texttt{enforce\_state drop}
   
   Adding \texttt{drop} to the \texttt{enforce\_state} option causes Snort to
    drop TCP packets that are not associated with an existing TCP session, and
    that are not valid TCP initiators.

\item \texttt{midstream\_drop\_alerts} (no arguments)
   
   By default, when running in inline mode, Snort will silently drop any
    packets that are matched against a \texttt{drop} rule and considered
    to be part of a midstream session, instead of logging the alert as usual.
    This is to mitigate stick/snot type attacks when the user
    hasn't enabled the \texttt{enforce\_state} option.  If you want to log
    these drops, enable this option. Note
    that by enabling this option, you have opened yourself up to
    stick/snot-type attacks if you haven't also used the
    \texttt{enforce\_state} option.

\item \texttt{disable\_session\_blocking} (no arguments)

   By default, when running in inline mode, Snort will block all traffic
    on a TCP session after it is told to drop a non-stateless packet on
    that session. Enable this option if you don't want Snort to exhibit
    this default behavior.

\end{itemize}

For more information about Stream4, see Section \ref{stream 4 section}.

\subsection{Replacing Packets with Snort Inline\label{ReplaceInline}}

Additionally, Jed Haile's content replace code allows you to modify packets
before they leave the network.  For example:

\begin{verbatim}
alert tcp any any <> any 80 (msg: "tcp replace"; content:"GET"; replace:"BET";)
alert udp any any <> any 53 (msg: "udp replace"; \
    content: "yahoo"; replace: "xxxxx";)
\end{verbatim}

These rules will comb TCP port 80 traffic looking for GET, and UDP port 53
traffic looking for yahoo.  Once they are found, they are replaced with BET and
xxxxx, respectively.  The only catch is that the replace must be the same
length as the content.


\subsection{Installing Snort Inline\label{InlineInstall}}
To install Snort inline, use the following command:
\begin{verbatim}
./configure --enable-inline
make
make install
\end{verbatim} 


\subsection{Running Snort Inline}

First, you need to ensure that the ip\_queue module is loaded.  Then,
you need to send traffic to Snort Inline using the QUEUE target.  For
example:
\begin{verbatim}
iptables -A OUTPUT -p tcp --dport 80 -j QUEUE
\end{verbatim}
sends all TCP traffic leaving the firewall going to port 80 to the QUEUE
target.  This is what sends the packet from kernel space to user space 
(\texttt{Snort Inline}).  A quick way to get all outbound traffic going to the