11.4 Snort

Integrity checkers can serve as burglar alarms. But as such, they aren't nearly as useful during an attack as they are afterwards: usually by the time the bad guys start changing files on a system, the attack has succeeded. This is because integrity checking is limited to the local system: it involves local files, not network packets. For more proactive intrusion detection ("intrusion in progress" or "attempted intrusion" detection), we need to monitor attempted and pending attacks while they're still on the wire -- before they make landfall on our systems.

The undisputed champion Open Source NIDS is Snort. Snort is a marvelous, versatile thing. First, as a packet sniffer (or, if you prefer the more formal term, "protocol analyzer"), Snort is to tcpdump what Homo sapiens is to Homo habilus: same basic genetic material, better brain. As a packet sniffer, Snort is extraordinarily fast, thorough, and user friendly (or at least geek friendly).

Second, Snort is a packet logger. Snort can preserve complete audit trails of network traffic, trails that name names and encase evidence in (figurative) acrylic blocks.

Third, Snort is a 100% customizable network Intrusion Detection System with both a library of contributed attack signatures ("rules") and a user-configurable rule engine. Snort not only holds its own with, but in some cases is better and faster than expensive commercial IDSes. In this regard, Snort is the GIMP, Apache, and Nessus of IDSes.

Unlike some commercial IDSes, it's possible to write your own Snort rules and even your own inspection engines ("Snort plug-ins"). In this way, you're not dependant on anyone else to provide you with rules when a new exploit comes to your attention: you can write your own rules quickly and easily (provided you know something about TCP/IP networking, but that's a prerequisite of running any NIDS). This is an important feature, since new attacks are invented and reported all the time.

11.4.1 Obtaining, Compiling, and Installing Snort

Red Hat, Debian, and SuSE all provide binary packages of Snort in the current versions of their respective distributions. Of the three, however, only SuSE ships a Snort package recent enough to support Snort v1.8's new rule format.

Since each new version of Snort is more sophisticated and therefore more effective at detecting suspicious network activity, I strongly recommend that you either obtain and compile the latest Snort source code or use the latest binary packages provided by the Snort team rather than those that come with your Linux distribution (even if you run SuSE).

11.4.1.1 Getting Snort source code and binaries

The official home and source of Snort code, binaries, rules, documentation, etc. is http://www.snort.org. Being an actively developed application, Snort has both stable and development code branches; as of this writing, the latest stable version is 1.8.4 and the latest development (experimental) version is 1.9.-beta0. Naturally, you should stick to the stable versions if you intend to run Snort on production (or otherwise important) systems.

If you navigate to the Snort web site's downloads page, you'll see links to the latest source tarballs. If you continue on to the site's binaries page, you'll find Snort binaries for Solaris, FreeBSD, and Windows (that's right, Snort runs on Windows!). Navigate to the RPMS page for current RPM packages for Red Hat and its derivatives (Mandrake, etc.). (To the best of my knowledge, these RPMs do not work on SuSE systems.)

11.4.1.2 Installing Snort RPMs

If you choose to install RPMs, you'll need at least one snort, which is a package of Snort's documentation, configuration files, and a bare-bones version of the snort binary itself. If you want a snort binary with support for MySQL databases, SNMP traps, or other advanced features, you'll also need one of the other RPMs on this page (snort-snmp, snort-mysql, etc.).

For example, to install Snort with MySQL support using RPMs, you'd need to get the packages snort-1.8.4-1snort.i386.rpm and snort-mysql-1.8.4-1snort.i386.rpm from http://www.snort.org/dl/binaries/. (Note that current version numbers may be different by the time you read this). I also recommend you download the latest Snort rule set: this is called snortrules.tar.gz and is updated every 30 minutes on http://www.snort.org/dl/signatures/.

Install the snort base package before you install the "features" package. The base package will set up Snort's directories and install a bare-bones snort binary, /usr/sbin/snort-plain, pointed to by the symbolic link /usr/sbin/snort. If you install a feature package, it will add an additional binary (e.g., /usr/sbin/snort-mysql) and point the symbolic link /usr/sbin/snort to it rather than to /usr/sbin/snort-plain. In addition, you should unpack snortrules.tar.gz and copy the resulting directory, rules, to /etc/snort.

The additional package will not configure Snort to use the added features; you'll need to do that manually by editing /etc/snort/snort.conf. We'll cover Snort configuration later, in Section 11.4.4.

In addition to the appropriate Snort package or packages, you may also need to update the Libpcap package on your system to the latest version. See Section 11.4.1.3, for more information on Libpcap.

11.4.1.3 Compiling and installing Snort from source

If you run a non-Red Hat-derived flavor of Linux, you'll probably need to compile Snort from source. This is neither difficult nor time consuming, provided you've got a few prerequisites.

Before installing Snort, you should make sure you've installed Tcpdump's Libpcap. Since this is used by Tcpdump, Ethereal, Nmap, and other network tools, your distribution probably includes a package for Libpcap's source headers, typically called libpcap-devel. If so, check your distribution's "Update" site to make sure you've got the latest package version.

If your distribution doesn't have a Libpcap package, you'll need to download and compile Libpcap from http://www.tcpdump.org before compiling Snort. To compile Libpcap, su to root, unpack its source tarball, change your working directory to the source directory (e.g., /usr/src/libpcap-0.4), and run these commands:

bash-# ./configure
bash-# make && make install

Make sure the files pcap-namedb.h and pcap.h are copied into /usr/local/include/ and that bpf.h is copied into /usr/local/include/net/.

In addition to Libpcap, you'll also need to install the database application (if any) you want Snort to log to, including the appropriate header files. For example, if you intend to run Snort with MySQL on a Red Hat system, you'll need to have the packages mysql and mysql-server installed (to create and run the database) and also mysql-devel (to compile Snort with MySQL support).

Once these things are in place, you can compile Snort. Unpack the tarball, change your working directory to the Snort source's root (e.g., /usr/src/snort-1.8.4), and run the configure script, including flags to enable any special features. (To see a list of available configure flags and options, run ./configure -- help.)

Everything you do with Snort, from compiling or configuring it to running it, you must do as root. Only root can run a network interface in "promiscuous" mode, an absolute requirement of Snort.

For example, to configure your source build for a MySQL-enabled snort binary, you'd enter this:

bash-# ./configure --with-mysql

Next, build Snort. Since most potential errors will come up beforehand when you run the configure script, you can do this with a single command:

bash-# make && make install

What Are Advanced Features? Snort supports both preprocessing and postprocessing plug-ins that greatly extend Snort's functionality. Preprocessing plug-ins, which act on incoming packets, generally enhance Snort's intrusion-detection potential, whereas postprocessing plug-ins, which act on events identified by snort and its preprocessor plug-ins, generally focus on reporting and alerting. Some of Snort v1.8.4's preprocessor plug-ins are installed and enabled by default: frag2 Reassembles packet fragments and detects fragment attacks stream4 Reassembles TCP (data) streams, detects TCP scans http_decode Cleans up HTTP requests, parses for certain HTTP attacks rpc_decode Decodes RPC requests and parses them for attacks bo Detects activity by default installations of Back Orifice telnet_decode Decodes Telnet transactions and parses them for attacks portscan Detects various types of port scans No postprocessor plug-ins are enabled by default, however. Support for these must be specified at compile time and explicitly enabled/configured afterwards. These are two of the more popular postprocessor plug-ins: database Sends Snort data to one of several databases specified at compile time (MySQL, PostGreSQL, UnixODBC, or MS-SQL). Especially useful if you intend to archive Snort IDS logs for forensic or analytical purposes or use the ACID real-time Snort analyzer. trap-snmp Sends Snort alerts as SNMP traps to an SNMP listener. In addition to Snort itself, its plug-ins, and ACID (whose home page is http://www.cert.org/kb/acid), there are other useful external Snort utilities. See the Snort home page at http://www.snort.org for more information.

This will build Snort and, upon successful compilation, install its binaries and manpages. It will not, however, build Snort's operating environment.

11.4.1.4 Making Snort at home after compiling and installing it

You'll probably want to keep your Snort configuration files in one directory; most RPM packages (and therefore most users) use /etc/snort/. Create this directory and make sure only root can read and write the files therein. Copy the files snort.conf and classification.config included with the Snort source code into this directory.

I recommend you keep your rules in a single directory, too; I use /etc/snort/rules. Into this directory (or, if you prefer, into /etc/snort), you should copy the source distribution's rules files: backdoor.rules, bad-traffic.rules, etc. You can use the ones included in the Snort tarball, but I recommend that you instead download snortrules.tar.gz from http://www.snort.org/dl/signatures/ and use these, since they're updated far more frequently than the Snort source distribution itself is.

Finally, the standard place to have Snort record its logs is /var/log/snort. Create this directory and make sure that it too is readable and writable only for root. Everything that goes in here will be created by Snort as needed.

11.4.1.5 Creating a database for Snort

If you're going to use a database with Snort, there's one more thing you'll need to do before you use Snort: create a new database, and possibly a new database user account, for Snort to use. The Snort source code's contrib directory includes scripts to create databases of the supported types: create_mssql, create_mysql, create_oracle.sql, and create_postgresql.

If you're like me and blissfully ignorant of the finer points of database administration, don't worry: the source code also includes instructions (in the file README.database) on using these scripts to set up a Snort database. (If you installed RPMs, this file can be found in /usr/share/doc/snort-1.8.4, but the database scripts themselves cannot. You'll need to obtain and unpack the source tarball for those.)

Example 11-9 shows the commands I used to create a MySQL database on my Red Hat system for Snort.

Example 11-9. Creating a MySQL database for Snort

bash-# echo "CREATE DATABASE snort;" | mysql -u snortsql -p 
Enter password: <ENTER> 
bash-# cd /usr/src/snort-1.8.4 
bash-# mysql snort < ./contrib/create_mysql 

Note that in Example 11-9, I used a non-root account I'd created, called "snortsql." On a publicly accessible or multiuser system it's essential that you not use root as your Snort database account. Refer to your database's documentation for instructions on setting up database users and using your database securely.

11.4.2 Using Snort as a Packet Sniffer

Snort is extremely useful as a network diagnostic tool and, in fact, can be used as a real-time packet sniffer with no prior configuration. Simply invoke the command snort with its "decode," "verbose" (display-to-screen), and "interface" flags: -d, -v, and -i, respectively (see Example 11-10). The name of the Ethernet interface on which you wish to sniff — that is, the name reported by ifconfig -a, not the full path to its actual device file — should follow the -i flag. (If your system has only one Ethernet interface, you can omit this flag altogether.)

Example 11-10. Invoking Snort as a sniffer

bash-# snort -dvi eth0
Log directory = /var/log/snort

Initializing Network Interface eth0


        --== Initializing Snort ==--
Checking PID path...
PATH_VARRUN is set to /var/run/ on this operating system
PID stat checked out ok, PID set to /var/run/
Writing PID file to "/var/run/"
Decoding Ethernet on interface eth0

--== Initialization Complete ==--


-*> Snort! <*-
Version 1.8.3 (Build 88)
By Martin Roesch ([email protected], www.snort.org)
03/22-22:25:26.041707 192.168.100.20:1052 -> 10.10.117.13:80
TCP TTL:63 TOS:0x10 ID:10528 IpLen:20 DgmLen:60 DF
******S* Seq: 0x8651A4AB  Ack: 0x0  Win: 0x16D0  TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 1805707 0 NOP WS: 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


03/22-22:25:26.046576 10.10.117.13:80 -> 192.168.100.20:1052
TCP TTL:64 TOS:0x0 ID:33016 IpLen:20 DgmLen:60 DF
***A**S* Seq: 0x6D4A1B04  Ack: 0x8651A4AC  Win: 0x7D78  TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 63072524 1805707 NOP
TCP Options => WS: 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


03/22-22:25:26.047354 192.168.100.20:1052 -> 10.10.117.13:80
TCP TTL:63 TOS:0x10 ID:10529 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x8651A4AC  Ack: 0x6D4A1B05  Win: 0x16D0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 1805707 63072524

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


03/22-22:25:44.282136 192.168.100.20:1052 -> 10.10.117.13:80
TCP TTL:63 TOS:0x10 ID:10530 IpLen:20 DgmLen:95 DF
***AP*** Seq: 0x8651A4AC  Ack: 0x6D4A1B05  Win: 0x16D0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 1807530 63072524

If you aren't a TCP/IP guru, the first few packets listed in Example 11-10 probably don't make a lot of sense. Suffice it to say they show a TCP/IP "handshake" between the hosts 192.168.100.20 (the client in this transaction) and 10.10.117.13 (the server). The client is connecting to TCP port 80 on the server, so this is an HTTP transaction.

Sure enough, the last packet contains an HTTP get command requesting the URL http://www.polkatistas.org/index.html. Even the uninitiated can appreciate this packet: in the column to the right of the block of hexadecimal numbers that constitute the packet's data payload, Snort displays the data in ASCII. In this way, you can watch not only the sequences of packets in network transactions, but their content as well (assuming nothing's encrypted). Packet sniffing is hardly new, but Snort's output is particularly easy to follow.

Naturally, how much traffic Snort sees depends on your network topology. If the interface on which you're sniffing is connected to a hub, Snort will see all packets sent to and from all hosts connected to that hub. If the interface is connected to a switch or a bridge, Snort will only see packets destined for or originating from that particular interface. (High-end switches, however, often support mirroring; if yours does, it may be possible to configure the switch to send copies of all packets from all ports to your Snort host's port.)

If you only wish to see packets to or from certain addresses, packets of certain protocols, etc., Snort supports the same "primitives" (display filters) as tcpdump. For example, to sniff only those packets sent to or from the host 192.168.100.200, I could use:

bash-# snort -dv host 192.168.100.200

Or to sniff everything except Secure Shell packets (remembering that SSH servers listen on TCP port 22), I could use:

bash-# snort -dv not port 22

See Snort's official documentation for more information on these primitives and on the other options you can use in Sniffer Mode.

11.4.3 Using Snort as a Packet Logger

You can, if you wish, run Snort in Sniffer Mode and redirect its output into a text file. But this isn't recommended: if you want to minimize dropped packets, you should forego writing them to the screen and instead tell Snort to write directly to a log directory. You can do so by invoking Snort like this:

bash-# snort -d -l ./snort/ -h  10.10.20.0/24 

As with Sniffer mode, the -d flag tells Snort to decode packets' data payloads. The -l flag, however, is the one which, by specifying a directory to log to, puts Snort into Packet Capture mode. If the directory you specify doesn't exist, Snort will exit with an error.

The -h flag allows you to specify your "home network." Snort creates a new directory for each host it observes and prefers to do so in a "client-centric" manner: for example, if you tell Snort that addresses within 10.10.20.0/24 are local network, Snort will consider all other host IPs to be "clients" in any given transaction and will name host directories after those host IPs. If both hosts in a given transaction are local, Snort will name a directory after the IP using the higher listening port or, if those are the same, after the higher IP address.

This sounds very abstract and maybe even arbitrary, but remember that Snort is first and foremost a security tool: if you're logging packets to identify attacks or monitor connections from untrusted systems, it makes sense to group those transaction logs by external IP address. For example, if the host 44.33.22.11 attacks one of your systems, it will be much easier to analyze that attack if each relevant transaction is logged to a different file in the directory 44.33.22.11.

If you'd like Snort to log to a single file instead, that's possible, too, by using the -b flag. In fact, doing so greatly improves Snort's performance and is recommended if you need to monitor a fast network (e.g., 100Mbps). This is because the supported file format for this mode is Tcpdump's binary data format, which obviates the need to convert the binary packets into ASCII as is normally done in Packet Logging Mode. Accordingly, when using -b, it isn't necessary to specify the -h flag (Snort won't be naming any directories) or the -d flag (Snort won't be decoding anything either — it will be saving entire packets verbatim). For example:

bash-# snort -l /var/log/snort/ -b

will tell Snort to log all packets to a binary Tcpdump file, which will be named with the string snort followed by a timestamp (e.g., [email protected]) and will reside in the specified log directory. The binary log file won't be human-readable like Snort's default logs, but it will be readable with snort, tcpdump, ethereal, or any other program that understands Tcpdump files.

To "replay" the file (convert it to ASCII and display it) with Snort, use the -r flag:

bash-# snort -dv -r /var/log/snort/snort-0324\@2146.log

(Don't forget to escape the @ sign with a backslash.) As you can see, this is actually a use of Snort's Sniffer Mode: you can decode the packets with the -d flag, display them to the screen with the -v flag, etc. You can also filter the output using Tcpdump primitives, as described in the previous section.

11.4.4 Configuring and Using Snort as an IDS

Finally we arrive at Snort's real purpose in life: intrusion detection. Unlike Sniffer Mode or Packet Logging Mode, Snort's IDS Mode requires some preconfiguration. As I suggested earlier in Section 11.4.1.4, you can keep Snort's main configuration file, snort.conf, in /etc/snort and its rules in /etc/snort/rules.

Or you can keep them elsewhere; Snort is not hardcoded to expect its configuration in any set place. Furthermore, through support of the include statement, Snort configuration is modular: rules are include files that Snort merges into snort.conf at runtime.

snort.conf usually takes this form:

• Variable definitions

• Preprocessor plug-in statements

• Output (postprocessor) statements

• Rules (in practice, usually include statements referring to rule files)

Let's discuss these sections one at a time.

11.4.4.1 Variable definitions

Snort's sample snort.conf file lists a number of variables — some defined with default values and all accompanied by comments that make this section mostly self-explanatory. Of particular note, however, are these two variables:

var HOME_NET 33.22.11.0/24,10.9.0.0/16,etc.

HOME_NET specifies which IP address spaces should be considered local. This is the only comma-delimited variable; also, there should be no spaces between values.

var DNS_SERVERS 33.22.11.1 33.22.11.32 etc.

Normal DNS activity sometimes resembles port scans; therefore, the portscan plug-in disregards such activity when it involves IP addresses listed in this space-delimited variable.

11.4.4.2 Preprocessor plug-in statements

Like Snort variables, the preprocessor statements are well commented, including examples illustrating the parameters they can take. Some of these parameters are useful in minimizing false positives. For a list of preprocessors that are enabled by default, see the sidebar "What Are These Advanced Features?"

11.4.4.3 Output (postprocessor) plug-in statements

If you're going to log strictly to flat data files or Tcpdump binary files, you don't need to define or uncomment an output statement. If you're going to have Snort log to a database or send SNMP traps, however, you'll need to uncomment and configure one or more of these statements. Continuing my MySQL example, here's the output statement I use on the Red Hat system from Example 11-9:

output database: log, mysql, user=root dbname=snort host=localhost

11.4.4.4 Rules

You can specify Snort rules directly, or you can keep them in separate files referred to in snort.conf by include statements. I strongly recommend you do the latter, for a very important reason: Snort's developers and contributors refine and augment the official collection of Snort rule files on an ongoing basis, and they're therefore updated on the Snort download site every 30 minutes. It makes a lot of sense to keep these rules separate from the rest of your snort.conf file, which won't change nearly so often.

If you put the rules files in a different directory than the one in which snort.conf resides, you'll need either to set the variable RULE_PATH accordingly (if you installed Snort from RPMs) or to edit the include statements themselves.

For example, if I compiled Snort and copied its RULES files to /etc/snort/rules, in the default snort.conf file, I'd change the line:

include bad-traffic.rules

to read:

include /etc/snort/rules/bad-traffic.rules

and so on for all include statements.

If instead I'd installed Snort RPMs, I wouldn't need to do this; I'd only need to set the variable RULE_PATH to /etc/snort/rules, since the include statements in the RPM version of snort.conf look like this:

include $RULE_PATH/bad-traffic.rules

Choose your rule sets carefully: the more rules you match packets against, the greater the chance that Snort will drop packets during periods of heavy network traffic. If your network has no web servers, for example, you can view a larger amount of traffic by commenting out all include statements involving web rules (unless you want Snort to log even completely futile attacks).

In addition, you may need to fine tune one or more rule files themselves. The include statements for the rule sets shellcode.rules, policy.rules, info.rules, backdoor.rules, and virus.rules are commented out by default, for just that reason. Don't enable these until you've adjusted them to match your environment and needs.

Where Should NIDS Probes Go? In most organizations, there are three general areas to consider placing NIDS probes (listening hosts): on the internal network, on the DMZ network, and outside of the firewall altogether. Outside of the firewall you'll get the most false positives, but you'll also be more likely to see unsuccessful attacks, port scans, and other "preincident" activity. In the DMZ, you'll potentially see all attacks that make it past the firewall toward your publicly available servers, but you'll also see many false positives. On the internal network, you shouldn't see many false positives at all; needless to say, any (real) attacks that make it that far will be worth following up on immediately (even though at that point, the alerts will probably come too late to do much good, except as forensic data). In any case, as I mentioned earlier, your NIDS probe won't see anything unless: The LAN to which it's connected uses a switch with a mirror port. The LAN uses a shared medium such as a hub. You can insert a hub or "network tap" at a crucial choke point — e.g., immediately between the firewall and the internal network to which it's connected (which won't catch attacks between internal hosts, but will hopefully catch attacks to or from the Internet). Particularly in the case of the last bulleted item, the probe must be placed in a physically secure location.

You are by no means limited to the rule sets that come with Snort and already have include lines in snort.conf: you're free to write your own rules and include them as well. The Snort Users Manual, included with Snort as a PDF file, has detailed and straightforward instructions for writing your own Snort rules. You'll need to understand TCP/IP networking to write effective rules, however, even armed with this documentation.

11.4.4.5 Starting snort in IDS mode

Once you've configured snort.conf, you can start snort. I'd recommend just one more preparatory step, though, especially if you're new to Snort: invoke snort with the -T flag to test your configuration. For example, to test /etc/snort/snort.conf, use the command:

bash-# snort -T -c /etc/snort/snort.conf

This will cause snort to parse its configuration file (as specified after the -c flag) and any included rule sets. It then prints any errors it finds to the standard output, along with some useful information about which plug-ins are running and with what settings. Regardless of the outcome of the tests (i.e., successful or not), snort will then exit.

When you and Snort are both happy with your configuration, you can start Snort for real:

bash-# snort -Dd -z est -c /etc/snort/snort.conf

Two of these flags, -d and -c, we've used previously (to tell Snort to decode packet data and to use the specified configuration file, respectively). The other two are new: -D tells Snort to run in Daemon Mode (i.e., as a background process with no output to the screen other than a few startup messages). -z est tells Snort's streams4 preprocessor plug-in to ignore TCP packets that aren't part of established sessions, which makes your Snort system much less susceptible to spoofing attacks and certain Denial of Service attacks.

In IDS mode, Snort behaves similarly to Packet Logging mode, in that logged transactions will be written to subdirectories of /var/log/snort. The subdirectories are named after the IP addresses of the "client" systems in those transactions. In IDS mode, however, only packets from transactions that trigger Snort alerts (based on Snort's rules) will be logged. Alerts will be logged to the file /var/log/snort/alert; packet-headers from port scans will be logged to /var/log/portscan.log.

As with Packet Logging mode, you may wish to use the -b flag when running Snort in IDS mode on a fast and/or very busy network. This will cause alerts and portscan.log to be written to as normal, but packets themselves will be logged to a binary file. You can additionally streamline Snort's alert messages by specifying Fast Alert mode via the -A flag, e.g.:

bash-# snort -b -A fast -c /etc/snort/snort.conf

11.4.4.6 Testing Snort and watching its logs

Once Snort is running, you'll probably be curious to see how it responds to attacks and scans. One simple test you can run is a simple port scan using Nmap (see Chapter 3). Snort should write several entries to /var/log/snort/alert, similar to those shown in Example 11-11.

Example 11-11. Port-scan entries in /var/log/snort/alert

[**] [100:2:1] spp_portscan: portscan status from 192.168.100.20: 7 connections acr
oss 1 hosts: TCP(7), UDP(0) [**]
03/25-23:05:21.524291

[**] [100:2:1] spp_portscan: portscan status from 192.168.100.20: 7 connections acr
oss 1 hosts: TCP(7), UDP(0) [**]
03/25-23:05:43.057380

[**] [100:2:1] spp_portscan: portscan status from 192.168.100.20: 7 connections acr
oss 1 hosts: TCP(7), UDP(0) [**]
03/25-23:05:53.635274

[**] [100:2:1] spp_portscan: portscan status from 192.168.100.20: 6 connections acr
oss 1 hosts: TCP(6), UDP(0) [**]
03/25-23:19:17.615096

[**] [100:3:1] spp_portscan: End of portscan from 192.168.100.20: TOTAL time(43s) h
osts(1) TCP(27) UDP(0) [**]
03/25-23:19:21.657371

In the case of port scans, Snort won't log complete packets in subdirectories of /var/log/snort; rather, its portscan plug-in logs the scan packets' headers to /var/log/portscan.log (Example 11-12).

Example 11-12. Some packet headers logged to /var/log/snort/portscan.log

Mar 25 23:05:46 192.168.100.20:60126 -> 10.10.117.13:751 SYN ******S*
Mar 25 23:05:53 192.168.100.20:60120 -> 10.10.117.13:310 SYN ******S*
Mar 25 23:05:53 192.168.100.20:60121 -> 10.10.117.13:323 SYN ******S*
Mar 25 23:05:53 192.168.100.20:60122 -> 10.10.117.13:41 SYN ******S*

As soon as Snort is running to your satisfaction, you need to start monitoring Snort's alert log (/var/log/snort/alert) for activity. Naturally, you can do this manually with good old less or tail, but those methods don't scale very well.

Instead, I recommend you use Swatch (as described in the previous chapter) to monitor Snort's logs automatically for events about which you're concerned. If you'd like to know what these events will look like in the logs without triggering a test alert for each and every rule, all you need to do is browse through the Rules files included in your /etc/snort/snort.conf file and take note of their msg: fields.

For example, the first rule in the rules file, misc.rules, detects large ICMP packets and looks like this:

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"MISC Large ICMP Packet"; dsi
ze: >800; reference:arachnids,246; classtype:bad-unknown; sid:499; rev:1;)

Any time this rule is triggered by a large ICMP packet, it logs the message "MISC Large ICMP Packet" to /var/snort/alert. To receive notification from Swatch every time this rule fires, simply configure Swatch to watch /var/snort/alert for the phrase "Large ICMP Packet."

In addition to Swatch monitoring Snort for specific events, it's also a good idea to set up a cron/anacron job in /etc/cron.daily to email you a snapshot of part or all of /var/log/snort/alert, or even just the bottom 50 lines or so. That way you'll not only receive real-time alerts of specific events from Snort; you'll also be regularly notified of activity Swatch doesn't catch.

11.4.4.7 Updating Snort's rules automatically

The last tip I'll offer on Snort use is a reminder that the Snort team refreshes the official collection of contributed and tested Snort rules every 30 minutes, 24 hours a day, 7 days a week. That doesn't mean the rules change that frequently; it means that every 30 minutes, the current rules in the Snort CVS tree are recopied to the Snort web site. Thus, any change that anyone on the Snort team makes to those rules at any time will be propagated to http://www.snort.org/dl/snapshots/ within 30 minutes.

Several people have written different scripts you can use to download and update Snort rules automatically on your own system. Many of these scripts target the attack database at Max Vision's arachNIDS project site and are therefore available there (http://www.whitehats.com/ids/).

Since the arachNIDS site has been unavailable at various times, you might also consider one alternative to arachNIDS-oriented scripts: Andreas ...stling's script Oinkmaster v0.2, available at http://www.algonet.se/~nitzer/oinkmaster/. This script automatically downloads the latest "official" rules from http://www.snort.org, filters out ones not relevant to your site, and updates your local rule set. It comes with documentation in the form of a README file and is written in Perl, so it's easy to customize and fine tune for your needs.

Note that the precise download path to the current Snort rules has changed since Oinkmaster's last update; you'll need to edit Oinkmaster to target http://www.snort.org/dl/snapshots/snortrules.tar.gz rather than http://snort.sourcefire.com/downloads/snortrules.tar.gz. This URL is set in Oinkmaster's url variable.

You probably don't need to schedule Oinkmaster (or whatever script you choose to use) every 30 minutes, but I recommend scheduling it to be run at least twice a day.