faq.tex

This is the snapshot of Snot Latest Rules

\begin{verbatim}
 LAN         Sniffer 
 1 -----\   /-- 1
 2 ---\ |   \-- 2
 3 ---+-*------ 3
 4 -  |       - 4
 5 -  |       - 5
 6 ---*-------- 6
 7 -          - 7
 8 -          - 8
\end{verbatim}

Basically, 1 and 2 on the sniffer side are connected, 3 and 6 
straight through to the LAN. 1 and 2 on the LAN side connect to 3 and 
6 respectively. This fakes a link on both ends but only allows 
traffic from the LAN to the sniffer. It also causes the 'incoming' 
traffic to be sent back to the LAN, so this cable only works well on 
a hub. You can use it on a switch but you will get ...err... 
interesting results. Since the switch receives the packets back in on 
the port it sent them out, the MAC table gets confused and after a 
short while devices start to drop off the switch. Works like a charm 
on a hub though. 

Another method which uses a capacitor and should work on 100mbs links:

    \htmladdnormallink{http://www.geocities.com/samngms/sniffing\_cable}{http://www.geocities.com/samngms/sniffing_cable}

And another:

    The UTP Y-Cable specified by Joe Lyman:

A less noisy option: it involves a couple of cat 5 cables and a single speed
hub. The idea is to use the rcv cables for the wire going to the sniffer box
and use the xmit cables from another hub port. This will give you a link light
and allow your sniffer to rcv only. Cannot xmit because the xmit cables are not
connected. This has been successfully used on netgear single speed hubs. It
wont work on dual speed hubs due to the negotiation of speed.

Pin outs. They are reversed in the picture in order to prevent lines from
crossing, and I only included the pins used.

\begin{verbatim}
  * []HUB PORT 1             HUB PORT 2

       -----             -----

       x x r r                r r x x

       6 3 2 1                1 2 3 6

       | | | |                    | |

       | | | ----------- |

       | | -------------

       | |

       | |

       | |

       | |

       6 3 2 1

       r r x x

       ----

       SNIFFER

        x = xmit

        r = rcv
\end{verbatim}
You could make it a single cable by adding a battery to simulate the voltage
from the xmit cables on the nic, but batteries die.

It's not recommended to cut the transmit side, shunt it to ground (pin 2). Some
OS's will disable the interface if PIN 1 does not indicate a completed circuit.

\subsection{What are HOME\_NET and EXTERNAL\_NET?}

HOME\_NET and EXTERNAL\_NET are standard variable names that all of the Snort.org
rules use. HOME\_NET refers to the network(s) that you want to protect, where
EXTERNAL\_NET is the network(s) that you think attacks would come from.

\subsection{My network spans multiple subnets.  How do I define HOME\_NET?}

Snort 1.7 supports IP lists.  You can assign a number of addresses to
a single variable.  For example:

\begin{verbatim}var HOME_NET [10.1.1.0/24,192.168.1.0/24]\end{verbatim}

NOTE: Not all preprocessors support IP lists at this time.  Unless
otherwise stated, assume that any preprocessor using an IP list variable
will use the first value as the HOME\_NET.  The portscan preprocessor
is an example.  To catch all detectable portscans, pass 0.0.0.0/0 in
as the first parameter.

\begin{verbatim}preprocessor portscan: 0.0.0.0/0 5 3 portscan.log\end{verbatim}

Use the portscan-ignorehosts preprocessor to fine tune and ignore
traffic from noisy, trusted machines.

\subsection{How do I set EXTERNAL\_NET?}

Many people set EXTERNAL\_NET to ``any''.
\begin{verbatim}
    var EXTERNAL_NET any
\end{verbatim}
By setting it to ``any'' Snort will alert you on any traffic matching a rule
coming into or leaving your network.

To cut down on the work that Snort has to do, many people set it to ``not
HOME\_NET.''
\begin{verbatim}
    var EXTERNAL_NET !$HOME_NET
\end{verbatim}
This tells Snort to define EXTERNAL\_NET as everything except HOME\_NET. For most
people this is the best thing to set it to.

\subsection{How can I run Snort on multiple interfaces simultaneously?}

LINUX: If you aren't running snort on linux 2.1.x/2.2.x kernel (with LPF
available) the only way is to run multiple instances of snort, one instance per
interface (with the -i option specifying the interface). However for linux
2.1.x/2.2.x and higher you can use libpcap library with S. Krahmer's patch
which allows you to specify 'any' as interface name. In this case snort will be
able to process traffic coming to all interfaces.

*BSD: Use the ``bridge'' interface to combine your nics into a logical
interface (bridge0).

\subsection{My IP address is assigned dynamically to my interface, can I use Snort with it?}

Yes.  With Snort 1.7 and later, $<$interface$>$\_ADDRESS variable is available.
The value of this variable will be always set to IP address/Netmask of the
interface which you run snort at. if interface goes down and up again (and
an IP address is reassigned) you will have to restart snort. For earlier
versions of snort numerous scripts to achieve the same result are
available.


\subsection{I have one network card and two aliases, how can I force Snort to ``listen'' on both addresses?}

If you're using at least version 1.7, you can specify an IP list like
this:

\begin{verbatim}var HOME_NET [ 192.168.10.0/24, 10.1.1.1/16 ]\end{verbatim}

If you're using something older (version 1.6.3-patch2 or whatever) you can
re-specify the HOME\_NET variable multiple times like this (for example):

\begin{verbatim}
var HOME_NET 10.1.1.0/24
include misc.rules
var HOME_NET 192.168.1.0/24
include misc.rules
\end{verbatim}

\subsection{How do I ignore traffic coming from a particular host or hosts?}

There are two basic ways to ignore traffic from a host:
\begin{itemize}
  \item Pass Rules
  \item BPF Filters
\end{itemize}
Details:
\begin{enumerate}
\item  Pass Rules:
      \begin{itemize}
      \item Advantages:
      	\begin{itemize}
         \item Gives you rule based control over the packets.
         \item Puts all your changes into 'one place'-snort.conf.
	\end{itemize}
      \item Disadvantages:
      	\begin{itemize}
        \item Reverses the Rule order, can cause some headaches in tracking down
        problems.
        \item One poorly written pass rule can 'blind' your whole network.
        \item The more specific the pass rule is, the more CPU snort needs to process
        it which may be important on loaded nets.
      \end{itemize}
      \item Example:

        For example to ignore ALL ICMP traffic from host <foo> using a pass
        rule:
		\begin{verbatim}
            pass icmp <foo> any -> $HOME_NET any
	    	\end{verbatim}
    \end{itemize}
\item  BPF Filters:
      \begin{itemize}
      \item Advantages:
      	\begin{itemize}
        \item Drops the packet at the BPF interface, which saves on processing.
        \item Speeds up Snort since it 'never sees' those packets.
	\end{itemize}
      \item Disadvantages:
      	\begin{itemize}
        \item Poorly constructed filters can 'blind-side' you.
	\end{itemize}
      \item Example:
      \begin{itemize}
       \item To ignore all traffic from 192.168.0.1:
	\begin{verbatim}
   snort <commandline options> not host 192.168.0.1
    	\end{verbatim}
       \item To ignore all ICMP ECHO-REQUESTS (pings) and ICMP-ECHO REPLY's (ping
        reply) from host $<$foo$>$:
	\begin{verbatim}
   snort <options> ``not ( (icmp[0] = 8 or icmp[0] = 0) and host <foo> )''
        \end{verbatim}
	\end{itemize}
    \end{itemize}
\end{enumerate}

\subsection{How do I get Snort to log the packet payload as well as the header?}

It depends on how your Snort configuration logs. If it logs in binary format,
you'll have to process the binary log in order to get cleartext. You also might
have ``-A $<$foo$>$'' on the command line. Command line options always take
override the .conf file.  

\subsection{Why are there no subdirectories under /var/log/snort for IP addresses?}

It depends on how your snort configuration logs. If it logs in binary
format, you'll have to process the binary log in order to get cleartext.

\subsection{How do you get Snort to ignore some traffic?}

Snort can be made to ignore traffic in a number of different ways:
\begin{enumerate}
\item Specify bpf filters on the command line the tcpdump man page
 has a description of bpf filters.
\item Use a pass rule
\item The portscan preprocessor has it's own special exclusion list
 with the portscan-ignorehosts.rules file directive
\end{enumerate}

\subsection{Why does the portscan plugin log ``stealth'' packets even though the host is in the portscan-ignorehosts list? }

These types of tcp packets are inherently suspicious, no matter where
they are coming from.  The portscan detector was built with the assumption
that {\em stealth} packets should be reported, even from hosts which are not
monitored for portscanning.  An option to ignore ``stealth'' packets may be
added in the future.

\subsection{What the heck is a ``Stealth scan''?}

A Stealth scan can refer to more than one type of scan.
\begin{itemize}
  \item {\bf Half-Open or SYN scan:} Instead of completing the full TCP
    three-way-handshake a full connection is not made. A SYN packet is sent to
    the system and if a SYN/ACK packet is received it is assumed that the port
    on the system is active. In that case a RST/ACK will be sent which will
    determined the listening state the system is in. If a RST/ACK packet is
    received, it is assumed that the port on the system is not active.
  \item {\bf FIN scan:} According to RFC 793 a system should send back an RST for all TCP
    ports closed when they receive a FIN packet for a specific port.
  \item {\bf XMAS tree scan:} According to RFC 793 a system should send back an RST for
    all TCP ports closed when they receive a FIN/URG/PUSH packet for a specific
    port.
  \item {\bf NULL scan:} According to RFC 793 a system should send back an RST for all TCP
    ports closed when they receive a packet without any specified IP flags for
    a specific port.
  \item {\bf Slow scan:} Any of the above scans could be used as a slow scan. A slow scan
    is when the attacker sends packets at a {\bf very} slow rate. Sometimes these
    scans can be conducted over hours, days, or weeks. The idea is since they
    are so slow, the victim's security measures won't ``notice'' the scan.
\end{itemize}

\subsection{What the heck is a SYNFIN scan?}

SYNFIN scans got their name because there are both the SYN and FIN flags set.

\subsection{Which takes precedence, commandline or rule file ?}

The command line always gets precedence over the rules file.  If people
want to try stuff out quickly without having to manually edit the rules
file, they should be able to override many things from the command
line.  

\subsection{How does rule ordering work?}

{\bf For $=>$ 2.0:}

Please see the documents on v2.0 at:
\htmladdnormallink{http://www.snort.org/docs/\#devel}{http://www.snort.org/docs/\#devel}.

{\bf For $<=$ 1.9.X:}

Marty has answered this many times on the snort-users mailing list.  Here is
an excerpt from a post on Thu, 22 Feb 2001 00:31:53 -0500, titled {\em ``Re: 
[Snort-users] order of evaluation of rules.''}

Currently, the data structures that store Snort rule data are the
RuleTreeNodes (RTN) and the OptTreeNodes (OTN).  These data structs are
stored in a two dimensinal linked list structure with the RTNs forming
the top row of the ``Array'' and the OTNs forming the columns under the
RTNs.  Here's an ASCII illustration from the infamous ``lisapaper'':

\begin{verbatim}
  RTN                   RTN                    RTN           
  --------------        --------------         -----
 | Chain Header |      | Chain Header |      | Chai
 |              |      |              |      |
 | Src IP       |      | Src IP       |      | Src
 | Dst IP       |----->| Dst IP       |----->| Dst   .....
 | Src Port     |      | Src Port     |      | Src
 | Dst Port     |      | Dst Port     |      | Dst
 |              |      |              |      |
  --------------        --------------         -----
         |                     |
         |                     |
         |                     |
  OTN   \|/            OTN    \|/
  -------V------       --------V-------
 | Chain Option  |    | Chain Option   |
 |               |    |        :       |