Optimizing the System
One problem that you can have with a tool like ourmon or Snort is perfor-
mance. Performance problems can occur because the system has too much
load or there are many scanners, or possibly worst of all, because you are the
target of a large DDOS attack. So what can be done? Of course, you could
turn
filters off in ourmon, or you could give Snort less signatures. In other
words, you give the system less work to do. But that isn’t helping you get
your job done, and it also is not very secure. With ourmon you might turn
off a feature that otherwise might show an important anomaly. With Snort
you might turn off a signature that would otherwise have detected the next
SQL slammer attack. So in this section we will look at some ways to paral-
lelize the ourmon system. We should point out that some of these techniques
apply
to sniffers in general, not just the ourmon probe.
Before we discuss our speedup efforts, first look at Figure 9.1, which
shows the operating system architecture for the way packets are read by
sniffing applications such as ourmon’s probe.
Figure 9.1
Operating System Packet-Sniffing Architecture
Traditional operating systems such as FreeBSD and Linux have approaches
that differ in details but are actually pretty similar in the way packets arriving
www.syngress.com
334
Chapter 9 • Advanced Ourmon Techniques
Kernel
Network
Device
Driver
Packets from Network
Ourmon
Probe
Application
Operating System
Packet Queue
Interupt Priority Level
Application Priority Level
427_Botnet_09.qxd 1/8/07 4:45 PM Page 334
from the network are handed off to sniffing applications.The basic idea is that
the NIC may interrupt (or be read by polling, ultimately
driven from a hard-
ware clock interrupt) and then some number of packets are read in and
placed in operating system buffers (not shown).These buffers are then copied
to a ring buffer of a certain size inside the kernel. Conceptually the ring
buffer is a queue.The application can then use the read system call to read the
queued packets from the ring buffer and process them.This is actually a very
traditional operating system design model called the
producer-consumer model.
The producer
is the operating system, which includes both the NIC driver as
well as the ring buffer code that stuffs packets into the queue.The consumer
is the ourmon probe application.
One very general problem is that for important reasons, the operating
system will run before applications run; otherwise the operating system might
not be able to service the applications. Here this
could mean that the device
driver might be so busy stuffing packets into the ring buffer that the applica-
tion never gets to read any packets out of the ring buffer.This can easily
happen with a single-CPU system. Interrupts can also play a harmful role. If
too many packets are coming in too fast (say, with a small-packet DDOS
attack), the NIC might simply lock up the entire system.The system only
processes interrupts and more or less nothing else happens.This is a form of
deadlock called
livelock
(not dead, but not doing anything useful either). Now,
given
the big picture, let’s turn and look at various optimization techniques.
Buy a Dual-Core CPU for the Probe
One possible approach to parallelization is rather easy these days and is
becoming cheaper all the time. Both AMD and Intel now have computers
with dual-core processors.
Dual-core
means that with a symmetric multipro-
cessing (SMP) operating system, you will effectively run the NIC on one
CPU and the ourmon probe on the second.The
outcome is that you avoid
the situation where they are contending for one CPU (and the application
always loses).This can help a lot and should be standard practice for anyone
running an important sniffing application. If you get a dual-core CPU, make
sure that the operating system is actually using SMP! It won’t do you much
good if you have the hardware but forgot to enable the software.
Do'stlaringiz bilan baham: 
