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

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

Note that in Example 13-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 (and Chapter 8 in this book, if you''''re using MySQL) for instructions on setting up database users and using your database securely.

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.