next up previous
Next: 4 Rules and Alerts Up: The Snort FAQ Previous: 2 Getting Started

Subsections

3 Configuring Snort


3.1 How do I setup snort on a `stealth' interface?

In *BSD and Linux:

ifconfig eth1 up

Solaris:

ifconfig eth1 plumb
ifconfig eth1 up

For NT/W2K/XP users, try the following:

NOTE: You are at your own risk if you follow these instructions. Editing your registry is DANGEROUS and should be done with extreme caution. Follow these steps at your OWN risk.

  1. Get your device's hex value. ('snort -W' works for this)
  2. open Regedt32
  3. Navigate to: HKEY_LOCAL_MACHINE$\backslash$SYSTEM$\backslash$CurrentControlSet$\backslash$Services$\backslash$Tcpip$\backslash$Parameters$\backslash$
    Interfaces$\backslash${XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
  4. Select the network card you wish to setup as the monitoring interface (this will be the {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} value).
  5. Set IPAddress:REG_MULTI_SZ: to null (Double click on the string, delete data in the Multi-String Editor, then click OK)
  6. Set SubnetMask:REG_MULTI_SZ: to null (Double click on the string, delete data in the Multi-String Editor, then click OK)
  7. Set DefaultGateway:REG_MULTI_SZ: to null (Double click on the string, delete data in the Multi-String Editor, then click OK)
  8. Close the Registry Editor, your changes will be saved automatically.
  9. In a command prompt, run 'ipconfig' to verify the interface does not have an IP bound to it.

If you do not recieve an IP address listing from the interface you modified, you are good to go. To run snort with the specified interface, use the -i flag such as 'snort -v -d -p -i1'

3.2 How do I setup a receive-only ethernet cable?

Use an ethernet tap, or build your own 'receive-only' ethernet cable. Anyway, here is the cable I use:

 LAN         Sniffer 
 1 -----\   /-- 1
 2 ---\ |   \-- 2
 3 ---+-*------ 3
 4 -  |       - 4
 5 -  |       - 5
 6 ---*-------- 6
 7 -          - 7
 8 -          - 8

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:

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.

  * []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
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.

3.3 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.

3.4 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:

var HOME_NET [10.1.1.0/24,192.168.1.0/24]

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.

preprocessor portscan: 0.0.0.0/0 5 3 portscan.log

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

3.5 How do I set EXTERNAL_NET?

Many people set EXTERNAL_NET to ``any''.

    var EXTERNAL_NET any
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.''

    var EXTERNAL_NET !$HOME_NET
This tells Snort to define EXTERNAL_NET as everything except HOME_NET. For most people this is the best thing to set it to.

3.6 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).

3.7 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.

3.8 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:

var HOME_NET [ 192.168.10.0/24, 10.1.1.1/16 ]

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):

var HOME_NET 10.1.1.0/24
include misc.rules
var HOME_NET 192.168.1.0/24
include misc.rules

3.9 How do I ignore traffic coming from a particular host or hosts?

There are two basic ways to ignore traffic from a host:

Details:
  1. Pass Rules:
  2. BPF Filters:

3.10 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.

3.11 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.

3.12 How do you get Snort to ignore some traffic?

Snort can be made to ignore traffic in a number of different ways:

  1. Specify bpf filters on the command line the tcpdump man page has a description of bpf filters.
  2. Use a pass rule
  3. The portscan preprocessor has it's own special exclusion list with the portscan-ignorehosts.rules file directive

3.13 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 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.

3.14 What the heck is a ``Stealth scan''?

A Stealth scan can refer to more than one type of scan.

3.15 What the heck is a SYNFIN scan?

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

3.16 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.

3.17 How does rule ordering work?

For $=>$ 2.0:

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

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 ``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'':

  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   |
 |               |    |        :       |
 | Content       |             :
 | TCP Flags     |             :
 | ICMP Data     |
 | Payload Size  |
 | etc.          |
 |               |
  --------------- 
         |
         |
         |
   OTN  \|/
  -------V------
 | Chain Option |
 |              |
 | Content      |
 | TCP Flags    |
 | ICMP data    |
 | Payload Size |
 | etc.         |
 |              |
  -------------- 
         |
         |

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:

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";)

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

  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           |
 ---------------------

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:

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";)

gets built like this:

        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           |
 --------------------

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.


3.18 How do I configure stream4?

Stream4 is an entirely new preprocessor that preforms two functions:

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.

preprocessor stream4: [noinspect], [keepstats], [timeout <seconds>], [memcap]

stream4_reassemble defaults:

Reassemble client: ACTIVE 
Reassemble server: INACTIVE 
Reassemble ports: 21 23 25 53 80 143 110 111 513 
Reassembly alerts: ACTIVE

There is a new command line switch that is used in concert with the stream4 code, ``-z''. The -z switch can take one of two arguments: ``est'' and ``all''. The ``all'' argument is the default if you don't specify anything and tells Snort to alert normally. If the -z switch is specified with the ``est'' argument, Snort will only alert (for TCP traffic) on streams that have been established via a three way handshake or streams where cooperative bidirectional activity has been observed (i.e. where some traffic went one way and something other than a RST or FIN was seen going back to the originator). With ``-z est'' turned on, Snort completely ignores TCP-based stick/snot ``attacks''.

3.19 Where does one obtain new/modifed rules? How do you merge them in?

New rules can be downloaded via CVS (see FAQ [*]) 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:

There is also this script that might be useful:

  * []#!/bin/sh
    ###########################################################################
    ####
    #
    # Das Skript zum Herunterladen und installieren neuer IDS-Signaturen.
    #
    ###########################################################################
    ####
    MAILTO="admin@mydomain.de"
    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
    $WGET $WGET_PARAMS $MD5_URL1
    "$ECHO" "Readout the checksum..."
    # MD5-Summe auslesen
    if [ -f /etc/snort/snortrules-stable.tar.gz.md5 ]
    then
             MD5SUM1=`grep MD5 \
                      /etc/snort/snortrules-stable.tar.gz.md5|awk 
    '{print $4}'`
    else
             "$ECHO" "Error! No MD5-file found"
             exit 1
    fi
    "$ECHO" "Generating our own checksum..."
    # MD5-Summe bilden
    if [ -f /etc/snort/snortrules-stable.tar.gz ]
    then
        MD5SUM2=`md5sum /etc/snort/snortrules-stable.tar.gz|awk '{print $1}'`
    else
             "$ECHO" "Error! No rules file found"
             exit 1
    fi
    if [ "$MD5SUM1" = "$MD5SUM2" ]
    then
             "$ECHO" "The MD5-Checksum fits!"
             "$ECHO" "$MD5SUM1"
             "$ECHO" "$MD5SUM2"
             "$ECHO" "$MD5SUM1" >> /etc/snort/snort.log
             "$ECHO" "$MD5SUM2" >> /etc/snort/snort.log
             "$ECHO" "Proceeding..."
    #        /bin/sleep 1
    else
             "$ECHO" "Error! Wrong checksum! Aborting!"
             "$ECHO" "Install rules manually!"
             "$ECHO" "$MD5SUM1" >> /etc/snort/snort.log
             "$ECHO" "$MD5SUM2" >> /etc/snort/snort.log
             exit 1
    fi
    # Extract the new rules
    if [ -f "/etc/snort/snortrules-stable.tar.gz" ]
    then
             "$ECHO" "Extracting Snort rules..."
             "$TAR" -xzvf /etc/snort/snortrules-stable.tar.gz -C /etc/snort
    else
             "$ECHO" "Lost the file! Something is wrong!"
             "$ECHO" "Aborting!!"
             exit 1
    fi
    # Deleting old rules
    # Existiert das Verzeichnis ueberhaupt?
    if [ -d "$RULESPATH" ]
    then
    #        /bin/rm "$RULESPATH"/*.rules
             /bin/mv -f /etc/snort/rules/*.rules "$RULESPATH"
             /bin/cp -f /etc/snort/rules/classification.config "$SNORTCFGPATH"
    else
             "$ECHO" "Missing rules-directory!"
             "$ECHO" "Aborting!"
             exit 1
    fi
     
    # Cleaning up...
    /bin/rm -rf /etc/snort/rules
    # Give everything to root
    /bin/chown root:root ${RULESPATH}/*
    }
    ###########################################################################
    ####
    #                                   M A I N                                      
    #
    ###########################################################################
    ####
    # Error handling first
    FCHK=$(/usr/bin/wget -spider -N -t 3 -T 5 "$SIGS_URL1" -P /etc/snort 2>&1)
    ERR_MSG=$("$ECHO" "$FCHK" | egrep -oi "failed error")
    # Log the error message explicitly
    "$ECHO" "$FCHK" >> /etc/snort/snort.log
    # If there is a word "failed" or "error" we break..
    if [ "$("$ECHO" "$FCHK"| grep -i "failed")" ] || \
       [ "$("$ECHO" "$FCHK"| grep -i "error")" ]
    then
             "$ECHO" "Error getting the files. The server seems to be not available."
             "$ECHO" "Error message:"
             "$ECHO" "$FCHK"
             "$ECHO" "Aborting!"
             exit 0
    fi
     
    "$ECHO" "Checking/getting files..."
    # First extract the wget message
    FCHK=$(/usr/bin/wget -spider -N -t 3 -T 5 "$SIGS_URL1" \
                                  -P /etc/snort 2>&1 | grep "not retrieving")
    /bin/date >> /etc/snort/snort.log
    "$ECHO" "Wget-output:"
    "$ECHO" $FCHK
    # Logging what we've done and when
    "$ECHO" "$FCHK" >> /etc/snort/snort.log
    if [ -z "$FCHK"  ]
    then
             "$ECHO" "The files on the server seem to be newer."
             "$ECHO" "We will get them now..."
             getrules
             # Reload rules
             "$SERVICE" snort reload
    #        restartsnort
    else
    #
            "$ECHO" "The signature files on the server are older or not newer."
             "$ECHO" "Doing nothing for now..."
             "$ECHO" "Checking if Snort is running...."
             checksnort
             exit 0
    fi
    # Send Email
    "$ECHO" -e "`ls -lA "$RULESPATH"`\n\nSnort running with PID $("$PIDOF"\
                "$SNORT")" | mail -s "Reloaded Snort signatures on $MACHINE"\
                "$MAILTO"
    ###########################################################################
    ####
    ###########################################################################
    ####
    exit 0
    #EOF


3.20 How do you get the latest Snort via cvs?

Snort can be checked out through anonymous (pserver) CVS with the following instruction set. The module you wish to check out must be specified as the modulename. When prompted for a password for anonymous, simply press the Enter key.

    cvs -d:pserver:anonymous@cvs.snort.org:/cvsroot login

    cvs -z3 -d:pserver:anonymous@cvs.snort.org:/cvsroot co snort
Updates from within the module's directory do not need the -d parameter.

You will need to issue the command ``sh ./autojunk.sh'' before starting ./configure.

3.21 How do I use a remote syslog machine?

Add the syslog switch, -s, and put this statement syslog.conf:

    auth.alert         @managmentserverIP

Look at your snort.conf file for more info on the facility and Priority settings.

Make sure you have syslogd on the management server configured to allow syslog over UDP. Under RedHat, you can do this by editing /etc/sysconfig/syslog and adding the following line:

    SYSLOGD_OPTIONS="-r -m 0"
This will start syslogd with the mark interval set to 0 (turning it off) and set it to receive network connections.

Then restart syslog. ``man syslogd'' for more info. You might also want to investigate syslog-ng
(http://www.balabit.hu/en/downloads/syslog-ng/).

Example invocation of snort:

    /usr/local/bin/snort -c /etc/snort/snort.conf -I -A full -s 192.168.0.2:514
    -i rl0
Note for Win32 users:

Frank Knobbe wrote a patch for Snort to allow you to use `-s $<$host$>$' on the command line under Windows without nullifying the snort.conf. In other words, Snort still uses all settings from snort.conf but in addition uses the host from `-s' to send syslog alerts to. You can find the patch at:

http://www.snort.org/dl/contrib/patches/win32syslog/

3.22 How do I build this ACID thing?

Read carefully through all the docs for each package. Getting ACID to work is a lot of work, since it depends on many packages. You need a working Apache, a working PHP, a working GD (and the many libraries GD depends on), the ADODB package, and Phplot. This is a lot of stuff to configure.

A typical sequence to get this all working on Solaris 8: Use some binary packages from a trusted Sun freeware site (sunfreeware.com). The most problems were with PHP and the GD library. GD itself needs a bunch of packages and libraries to work also. It needs the libpng stuff, the libjpeg stuff (if you want jpeg), etc, etc. Read through the readme for GD. So you either need to get these and compile them also, or get some binary packages. PHP is the most difficult thing to get compiled correctly. The PHP package needs to be compiled with lots of ``-with'' flags for GD to work properly, otherwise it gets lots of run-time unresolved reference errors. Just using a ``with'' for GD isn't sufficient. You also need to "with" each library which GD uses also, or PHP can't find the functions it needs. Here's the ``configure'' line you can use to get PHP working:

    ./configure --with-mysql --with-apxs=/usr/apache/bin/apxs --with-gd
    --enable-sockets --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/local/
    lib --with-zlib-dir=/usr/local/lib --with-xpm-dir=/usr/local/lib
These `with' statements basically have the effect of the Makefile including -L and -R statements for each library so that both the compile and run time linkers can find all the functions needed to find in the Apache module environment. Apache doesn't seem to consult the LD_LIBRARY_PATH when running a module (or PHP doesn't, or there's some config item in the Apache conf files, but you can just use the ``withs'').

Basically, you need to work from the bottom up. So you need to obtain/compile any libraries that GD needs and install them, and any libraries/packages those packages need. Then once you get GD compiled properly and installed, compile PHP. Then make a PHP script that calls phpinfo() (this is referenced in the ACID install) and carefully examine the page produced. Once satisfied PHP is working, then the 'foundation' is ready for the other stuff. Install PHplot and run a few of the tests. If they succeed, then install ADODB and ACID, tweak the config files, and it should all work. (heh, heh)

Also make sure you read the ACID FAQ on the web site. There's some stuff not in the ACID install guide that should probably be there. Namely the fact that the PHP ``register_globals'' option must be turned on in the php.ini file (it's off in the default PHP configurations).

ACID FAQ: http://www.andrew.cmu.edu/~rdanyliw/snort/acid_faq.html


next up previous
Next: 4 Rules and Alerts Up: The Snort FAQ Previous: 2 Getting Started
QA Team 2007-02-27