faq.tex

This is the snapshot of Snot Latest Rules

 | Content       |             :
 | TCP Flags     |             :
 | ICMP Data     |
 | Payload Size  |
 | etc.          |
 |               |
  --------------- 
         |
         |
         |
   OTN  \|/
  -------V------
 | Chain Option |
 |              |
 | Content      |
 | TCP Flags    |
 | ICMP data    |
 | Payload Size |
 | etc.         |
 |              |
  -------------- 
         |
         |
 
\end{verbatim}

Rules with similar rule headers (i.e. all the CGI rules, the old stealth
port scan detection rules, most of the rules that focus on any single
service, etc) are grouped under a single RTN for the sake of efficiency
and the applicable OTNs are hung below them.  For instance, if you have
three rules like this:

\begin{verbatim}
alert tcp any any -> $HOME 80 (content: "foo"; msg: "foo";)
alert tcp any any -> $HOME 80 (content: "bar"; msg: "bar";)
alert tcp any any -> $HOME 80 (content: "baz"; msg: "baz";)
\end{verbatim}

They all get grouped under the same RTN and the OTNs are ``hung'' beneath
them like this:

\begin{verbatim}

  RTN
 --------------------
|  SIP: any          |
|  SP: any           |
|  DIP: $HOME        |
|  DP: 80            |
 -------------------- 
          |
          |
  OTN    \|/  
 ---------v----------
| content: foo       |
| msg: foo           |
 ---------------------
          |
          |
  OTN    \|/  
 ---------v----------
| content: bar       |
| msg: bar           |
 ---------------------
          |
          |
  OTN    \|/  
 ---------v----------
| content: baz       |
| msg: baz           |
 ---------------------
\end{verbatim}

This is an efficient way to do things because we only need to check the
data in the RTN once with this method.  There is actually another
dimension to this array: the function pointer list.  Each node in the
``array'' has a linked list of function pointers attached to it.  The
functions in this list are the tests that need to be done to determine
whether the data in the current packet matches the current rule node's
information.  Having this function pointer list gives us great
efficiency and flexibility: we don't need to perform tests for things
the current rule doesn't contain (e.g., ``any'' ports/IPs, packet content
on non-content rules, etc).  It also allows us to analyze the packet
with any function without having to make major modifications to the
whole program (which was the case in versions prior to version 1.5).

There are a couple of implications of this architecture.  For the sake
of this discussion on rules ordering, the one we're interested in is
that rule order is tricky to figure out.  For instance:

\begin{verbatim}
alert tcp any any -> $HOME 80 (content: "foo"; msg: "foo";)
alert tcp any any -> $HOME 1:1024 (flags: S; msg: "example";)
alert tcp any any -> $HOME 80 (flags: S; msg: "Port 80 SYN!";)
alert tcp any any -> $HOME 80 (content: "baz"; msg: "baz";)
\end{verbatim}

gets built like this:

\begin{verbatim}
        RTN                            RTN
 --------------------           --------------------
|  SIP: any          |         |  SIP: any          |
|  SP: any           |-------->|  SP: any           |
|  DIP: \$HOME        |         |  DIP: \$HOME        |
|  DP: 80            |         |  DP: 1-1024        |
 --------------------           --------------------
       |                              |
       |                              |
  OTN    \|/                            \|/
 ---------v----------           ---------v----------  
| content: foo       |         | flags: S           |
| msg: foo           |         | msg: example       |
 --------------------           --------------------
       |
       |
  OTN    \|/  
 ---------v----------
| flags: S           |
| msg: Port 80 SYN!  |
 --------------------
       |
       |
  OTN    \|/  
 ---------v----------
| content: baz       |
| msg: baz           |
 --------------------
\end{verbatim}

Note that all three of the port 80 rules will be checked before the
``1:1024'' rule due to the order in which the applicable RTN has been
created.  This is because the rules parser builds the first chain header
for port 80 traffic and sticks it on the rules list, then on the next
rule it sees that a new chain header is required, so it gets built and
put in place.  In this case you would intuitively expect to get the
``example'' message and never see the ``Port 80 SYN!,'' but the opposite is
true.

\subsection{How do I configure stream4?}
\label{stream4}

Stream4 is an entirely new preprocessor that preforms two functions:

\begin{itemize}
\item Stateful inspection of TCP sessions
\item TCP stream reassembly
\end{itemize}

Marty implemented stream4 out of the desire to have more robust stream reassembly capabilities and the desire to defeat the latest ``stateless attacks'' that have been coming out against Snort (c.f. stick and snot).  Stream4 is written with the intent to let Snort be able to handle performing stream reassembly for ``enterprise class'' users, people who need to track and reassemble more than 256 streams simultaneously.  Marty optimized the code fairly extensively to be robust, stable, and fast.  The testing and calculations I've performed lead me to be fairly confident that stream4 can provide full stream reassembly for several thousand simultaneous connections and stateful inspection for upwards of 64,000 simultaneous sessions.

Stream4 is a large and complex piece of code (almost 2000 lines) and there are a lot of options associated with its runtime configuration, so I'll go over them here.

\begin{verbatim}
preprocessor stream4: [noinspect], [keepstats], [timeout <seconds>], [memcap]
\end{verbatim}

stream4\_reassemble defaults: 
\begin{verbatim}
Reassemble client: ACTIVE 
Reassemble server: INACTIVE 
Reassemble ports: 21 23 25 53 80 143 110 111 513 
Reassembly alerts: ACTIVE 
\end{verbatim}


\subsection{Where does one obtain new/modifed rules? How do you merge them in?}

New rules can be downloaded via CVS \myref{cvs} or, alternatively, may be 
found at www.snort.org. There is a mailing list dedicated to Snort rules, 
called snort-sigs hosted at Sourceforge.

There are some scripts/programs to help you with rule management:
\begin{itemize}
  \item oinkmaster: A simple Perl script to update the ruleset for you.

    \htmladdnormallink{http://www.algonet.se/~nitzer/oinkmaster/}{http://www.algonet.se/~nitzer/oinkmaster/}

  \item IDS Policy Manager: A win32 application that updates the ruleset
    using a GUI, then uploads your rulesets via scp.

    \htmladdnormallink{http://www.activeworx.com/idspm}{http://www.activeworx.com/idspm}

  \item snortpp: a program to merge multiple files into one master file sorted by
    SID.

    \htmladdnormallink{http://dragos.com/snortpp.tgz}{http://dragos.com/snortpp.tgz}
\end{itemize}

There is also this script that might be useful:
\begin{verbatim}
  * []#!/bin/sh
    ###########################################################################
    ####
    #
    # Das Skript zum Herunterladen und installieren neuer IDS-Signaturen.
    #
    ###########################################################################
    ####
    MAILTO="[e-mail]"
    MACHINE="machine1"
    #set -x
    SIGS_URL1="http://www.snort.org/dl/signatures/snortrules-stable.tar.gz"
    MD5_URL1="http://www.snort.org/dl/signatures/snortrules-stable.tar.gz.md5"
    WGET="/usr/bin/wget"
    #WGET_PARAMS="-N"
    WGET_PARAMS="-t 3 -T 5 -N -a /etc/snort/snort.log -P /etc/snort"
    # Wget parameters:
    #
    # -t            : Retries (here 3)
    # -N            : Get the file only if newer
    # -a            : Append the log messages to the specified file
    # -P            : Save the file to the specified directory
    # -T            : Timeout
    ECHO="/bin/echo"
    TAR="/bin/tar"
    KILL="/bin/kill"
    PIDOF="/sbin/pidof"
    SNORT="/usr/local/bin/snort"
    SNORTUSER="snort"
    SNORTGROUP="snort"
    KILLSIG="SIGUSR1"
    SERVICE="/sbin/service"

    # Where is the Snort configuration dir:
    RULESPATH="/etc/snort/snortrules"
    SNORTCFGPATH="/etc/snort"
    MD5SUM="/usr/bin/md5sum"
    MD5SUM_PARAMS=""

    # The list of sensor interfacec divided by blanks
    IFACES="eth0"

    ###########################################################################
    ####
    #                           F U N C T I O N S 
    #
    ###########################################################################
    ####
    ###########################################################################
    ####
    #    Die Funktion, die Snort fuer alle def. Interfaces auf dem System startet    
    #
    #
    #
    #     Um sie zu erweitern muss man zwei Dinge tun:                                
    #
    #     1. Die Parameterliste von Interfaces erweitern                              
    #
    # 2. Das Konfigurationsfile unter /etc/snort/snort.conf_ethX anlegen          #
    #
    #
    ###########################################################################
    ####
    restartsnort() {

    # Restarting Snort for all interfaces
    for i in $IFACES; do
             "$ECHO" "Setting up Snort for interface "$i""
             $ECHO "Restarting Snort..."
             #/usr/bin/killall snort
             if [ -f /var/run/snort_"$i".pid ]
             then
                     PID=$("$PIDOF" "$SNORT")
                     if [ -z "$PID" ]
                     then
                             "$SERVICE" snort restart
                     else
                             #`cat /var/run/snort_"$i".pid`
                            "$ECHO" "Restarting Snort running with PID "$PID" and reloading the rules..."
                            "$KILL" -s "$KILLSIG" "$PID"
                     fi
             else
                     "$ECHO" "No PID file for interface "$i" found under /var/
    run"
             fi
             "$ECHO" "Starting Snort"
             "$SNORT" -a -b -c "$SNORTCFGPATH""/snort.conf_""$i" -I -D -v 
    -i $i -u "$SNORTUSER" -g "$SNORTGROUP"
             PID=`cat /var/run/snort_"$i".pid`
             "$ECHO" "Snort running now with PID "$PID""
    done
    }
    ###########################################################################
    ####
    #     Die Funktion zum ueberpruefen, ob und wie Snort auf dem System laeuft     
    #
    ###########################################################################
    ####
    checksnort() {
    SNORTS=$("$PIDOF" "$SNORT" | wc -w | awk '{print $1}')
    SNORT_PIDS=$(/usr/bin/find /var/run -name snort\_eth[0-9]\.pid -ls | 
    wc -l | awk '{print $1}')
    "$ECHO" "Snort instances counted:  $SNORTS"
    "$ECHO" "Snort PID files found:    $SNORT_PIDS"
    
    # 1. Fall: Snort laeuft nicht oder PID-File nicht da:
    if [ "$SNORTS" = "0" -o "$SNORT_PIDS" = "0" ]
    then
             "$ECHO" "Snort seems to be down or no PID file there..."
             "$ECHO" "Restarting Snort for all Interfaces..."
             "$SERVICE" snort restart
    fi
    # 2. Fall: Anzahl der Instanzen ungleich der Anzahl der PID-Files
    if [ "$SNORTS" -gt "$SNORT_PIDS" ]
    then
             "$ECHO" "More Snort instances than found PID files..."
             "$ECHO" "Something is wrong outthere..."
             "$ECHO" "Stopping all Snort processes..."
    #        /usr/bin/killall -9 snort
            "$SERVICE" snort stop
            "$ECHO" "Hold on... Restarting Snort now..."
            "$SERVICE" snort restart
    fi
     
    # 3. Fall: Anzahl der Instanzen stimmt mit der Anzahl der PID-files ueberein
    }
    ###########################################################################
    ####
    ###########################################################################
    ####
    getrules() {
    # Get the rules, since we know that they are newer...
    $WGET $WGET_PARAMS $SIGS_URL1