Linux Server Security (2nd Edition( [Electronic resources]

13.4. Snort

Integrity checkers are more like security camera tapes than burglar alarms. They aren''''t nearly as useful during an attack as they are afterward; 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 wirebefore 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 habilis: 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 expensive commercial IDSes, but in some cases is better and faster than them. 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 dependent 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.

Snort can stand alone, but there are many useful enhancement packages with names such as Barnyard, ACID, and Sguil. I''''ll discuss these after we get down and dirty with Snort.

13.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 distributions, 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).

13.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 2.2.0., but 2.3.0 should be out by the time you read this. 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 Linux 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.)

13.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 latest RPMs for snort and snort-mysql from a source such as http://www.snort.org/dl/binaries/RPMS/linux/ or http://dag.wieers.com/packages/snort/.

Snort can produce large amounts of output. Although you can scan the traditional output text logfiles, on a busy system, you might need the skills of an operator in The Matrix to make sense of them. This is where some Snort analysis tools are very helpful. Barnyard can connect the output of Snort to various tools and repositories, including databases. In this case, you would not need to build a version of Snort with database support. Let''''s start with a plain Snort installation and logfile output, then look into Barnyard, ACID, and the other add-ons. I also recommend you download the latest Snort ruleset: this is called snortrules-snapshot-CURRENT.tar.gz and is updated every 30 minutes on http://www.snort.org/dl/rules/.

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. The RPM installation will have installed a set of Snort rules. You can download the latest rules from http://www.snort.org/dl/rules/snortrules-snapshot-CURRENT.tar.gz, unpack the tarball, and copy the contents of the resulting directory, rules, to /etc/snort/rules.

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 the section "Configuring and Using Snort as an IDS." In addition to the appropriate Snort package or packages, you may need to update the Libpcap package on your system to the latest version. See the next section, "Compiling and installing Snort from source," for more information on Libpcap.

13.4.1.3 Compiling and installing Snort from source

If you run a flavor of Linux that is not Red Hat-derived, or if the available RPMs lag the latest source version, 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 an RPM or compile Libpcap from source at http://www.tcpdump.org before compiling Snort. To compile Libpcap, su to root, unpack the source tarball, change your working directory to the source directory (e.g., /usr/src/libpcap-0.8.3), 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). This applies whether you will have Snort log data directly to the database or filter through Barnyard first.

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-2.2.0), 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.)

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

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

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

13.4.1.4 Making Snort feel 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. You should copy into this directory (or, if you prefer, into /etc/snort), 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.

13.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-2.2.0, but the database scripts themselves cannot. You''''ll need to obtain and unpack the source tarball for those.) Example 13-9 shows the commands I used to create a MySQL database on my Red Hat system for Snort.

Example 13-9. Creating a MySQL database for Snort

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

13.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 13-10). The name of the Ethernet interface on which you wish to sniffthat is, the name reported by ifconfig -a, not the full path to its actual device fileshould follow the -i flag. (If your system has only one Ethernet interface, you can omit this flag altogether.)

Example 13-10. Invoking Snort as a sniffer

bash-# snort -dvi eth0 Running in packet dump mode Log directory = /var/log/snort Initializing Network Interface eth0 --== Initializing Snort ==-- Initializing Output Plugins! Decoding Ethernet on interface eth0 --== Initialization Complete ==-- -*> Snort! <*- Version 2.2.0 (Build 30) By Martin Roesch (roesch@sourcefire.com, www.snort.org) 10/26-20:03:56.765707 192.168.1.103:50564 -> 192.168.1.100:80 TCP TTL:64 TOS:0x10 ID:39034 IpLen:20 DgmLen:60 DF ******S* Seq: 0x4D29A390 Ack: 0x0 Win: 0x8000 TcpLen: 40 TCP Options (6) => MSS: 1460 NOP WS: 0 NOP NOP TS: 2365589261 0 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 10/26-20:03:56.765771 192.168.1.100:80 -> 192.168.1.103:50564 TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:60 DF ***A**S* Seq: 0x30242F0E Ack: 0x4D29A391 Win: 0x16A0 TcpLen: 40 TCP Options (6) => MSS: 1460 NOP NOP TS: 29349972 2365589261 TCP Options => NOP WS: 0 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 10/26-20:03:56.766095 192.168.1.103:50564 -> 192.168.1.100:80 TCP TTL:64 TOS:0x10 ID:39035 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x4D29A391 Ack: 0x30242F0F Win: 0x8218 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2365589261 29349972 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 10/26-20:04:05.510033 192.168.1.103:50564 -> 192.168.1.100:80 TCP TTL:64 TOS:0x10 ID:39077 IpLen:20 DgmLen:78 DF ***AP*** Seq: 0x4D29A391 Ack: 0x30242F0F Win: 0x8218 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2365589278 29349972 47 45 54 20 2F 69 6E 64 65 78 2E 68 74 6D 6C 20 GET /indexl 48 54 54 50 2F 31 2E 31 0D 0A HTTP/1.1.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ If you aren''''t a TCP/IP guru, the first few packets listed in Example 13-10 probably don''''t make a lot of sense. Suffice it to say they show a TCP/IP "handshake" between the hosts 192.168.1.103 (the client in this transaction) and 192.168.1.100 (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/indexl. 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 wish to see packets to or from certain addresses only, 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.

13.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, specifies a directory to log to and 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 the local network, Snort will consider all other host IP addresses to be "clients" in any given transaction and will name host directories after those IP addresses. If both hosts in a given transaction are local, Snort will name a directory after the IP address 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.13 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.13.

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., 100 Mbps). This is because the file format for this mode is the tcpdump binary data format, which obviates the need to convert the binary packets into ASCII as is normally done in Packet Logging mode. Accordingly, when you use -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., snort-0324@2146.log) and will reside in the specified log directory. The binary logfile 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. (Don''''t forget to escape the @ sign with a backslash.):

bash-# snort -dv -r /var/log/snort/snort-0324\@2146.log 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.

13.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 the section "Making Snort feel at home after compiling and installing it," 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.

The snort.conf file typically contains these sections:

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.

13.4.4.1 Variable definitions

Snort''''s sample snort.conf file lists a number of variablessome 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.13.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.13.1 33.22.13.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.

13.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 Sidebar 13-6.

13.4.4.3 Output (postprocessor) plug-in statements

If you''''re going to log strictly to flat datafiles 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 13-9:

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

13.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 I''''d installed Snort RPMs instead, I wouldn''''t need to do this; I''''d need only to set the variable RULE_PATH to /etc/snort/rules, because the include statements in the RPM version of snort.conf look like this:

include $RULE_PATH/bad-traffic.rules Choose your rulesets 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 rulesets 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.

You are by no means limited to the rulesets 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.

13.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 rulesets. 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). The -z est option 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 are 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 write to alerts and portscan.log 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. For example:

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

13.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 13-11.

Example 13-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 across 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 across 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 across 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 13-12).

Example 13-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 Chapter 12) 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"; dsize: >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 having Swatch monitor Snort for specific events, it''''s 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.

13.4.4.7 Snort analyzers

To evaluate large streams of Snort output effectively, you''''ll find a database and a graphic frontend very useful.

Barnyard routes Snort output to various destinations, including databases, files, email, and display screens. It can run on a separate machine from the Snort server and does not need to be run as root. This improves security and performance. To communicate with Barnyard, Snort needs to output to the unified file format. The current tarball can be found under http://www.snort.org/dl/barnyard/.

The Analysis Console for Intrusion Databases (ACID) is a web-based frontend to Snort, written in PHP. Details are available at http://acidlab.sourceforge.net/ as well as http://www.andrew.cmu.edu/user/rdanyliw/snort/snortacidl. A guide to installing and configuring ACID is found at http://www.snort.org/docs/snort_acid_rh9.pdf.

Sguil is a GUI-based frontend to Snort, written in Tcl/Tk. See http://squil.sourceforge.net for details.

A recent web-based console is OpenAanval, the open source version of the commercial Aanval product. The latest version can be found under http://www.aanval.com/downloads/.

13.4.4.8 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/snapshot 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 v1.0, available at http://oinkmaster.sourceforge.net/. 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 ruleset. 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) to run every 30 minutes, but I recommend scheduling it to be run at least twice a day.