427 Botnet fm qxd

Automated Packet Capture 
Regarding analysis, remember:The problem with anomaly detection is that
you might clearly see that an anomaly exists, but you might not have a good
explanation for it. For example, in Chapter 6, we discussed a rather horribly
graphic anomaly, but we didn’t explain how we resolved it.The anomaly was
an unprecedented packet count spike, but few, if any, details about who was
doing the attack, what kinds of packets were used, and what exactly was the
target.The attack described in Chapter 6 is an outstanding example of the
system presenting the analyst with an anomaly but not providing enough
clues to resolve the anomaly.
In the ourmon.conf file, it is possible to turn on various 
automated packet
capture triggers
. Roughly, this means that when some integer counter (say, the
number of scanners) hits a threshold of some sort (say, 60 hosts), ourmon will
record the next 
N
packets in a file.The file is a tcpdump file, meaning that it
can be replayed with any sniffer software that uses the well-known pcap
www.syngress.com
314
Chapter 9 • Advanced Ourmon Techniques
427_Botnet_09.qxd 1/8/07 4:45 PM Page 314

---

(www.libpcap.org) packet capture library.This is commonly used by tools like
ourmon, Snort, and, of course, tcpdump itself, which is an open-source net-
work sniffer (found at www.libpcap.org). WireShark (www.wireshark.org) is
another sniffer you might want to use.
In this chapter we discuss three ourmon triggers that are closely associated
with anomaly detection. However, before we explain the triggers and look at
sample trigger data, let’s first give a general overview of how the automated
packet capture feature operates. In the first place, all the triggers are turned off
when ourmon is installed.This is an advanced feature and not something you
want ourmon to do until you are ready for it. Automated packet capture can
be very useful for explaining what happened during an anomalous event. On
the downside, it imposes a lot of overhead on the probe system, primarily due
to file I/O during the normal ourmon probe sampling cycle time.
Roughly all the triggers have similar ourmon.conf syntax:
# trigger syntax
trigger_name threshold_count packet_count dump_directory
The trigger has a name that reflects its function. For example, as we see in
the following, a 
trigger_worm
trigger attempts to record packets from large
numbers of scanners. A trigger has a threshold that causes ourmon to start
storing packets when the threshold is exceeded.The threshold might be a
packet count, but it might be something else, too, such as a rate (for example,
bits/sec or packets/sec). Of course, this depends on exactly what type of
trigger is being used, as we will see when we examine details about specific
triggers.The 
packet_count
specifies the number of packets to store in the output
dump file.The 
dump_directory
is a directory name on the probe system that tells
the probe where to put the stored packets. Be sure to create this directory by
hand, because ourmon will not create it for you.The filename is automatically
constructed by ourmon and includes the 
trigger_name
and a timestamp so that
all the packet capture tcpdump files have a unique filename.
In general, all the triggers work like this:
1. In the config file, you turn on a trigger by putting in the config
parameters as described previously.