interrupt. But remember that with a 1Gbit NIC, you
can potentially get
roughly 1.5 million small packets per second.Therefore, your host operating
system could lock up processing interrupts and nothing will get done. On
Linux it is likely that no operator actions are needed due to the kernel’s new
API (NAPI) architecture for network device drivers. NAPI was designed to
mitigate the livelock problem we mentioned previously. On the other hand,
with 6.X
FreeBSD systems, device polling might be turned on in the oper-
ating system and used with drivers that support it.The basic idea behind
device polling is that a particular device driver will no longer interrupt.
Instead, clock interrupts will cause the operating system itself to poll the
device for packets. Although we aren’t going to
explain BSD kernel configu-
ration here (one good place to start to learn about that is to look at the sup-
plied BSD documentation with a Web browser), the rough idea is as follows:
1. Configure the kernel by turning on device polling, and set the HZ
rate to 1k or 2k.The latter is better for high rates of packets.
options DEVICE_POLLING
options HZ=2000
2. Once the kernel is reinstalled and rebooted, turn
on the polling
option for the device. For example, if we have an Intel gigabit card
and the NIC’s interface name is
em,
the following will turn polling
on:
# ifconfig em0 polling
The result here might look something like Figure 6.2 in Chapter 6.
Without polling, the probe could not have captured this spike.
www.syngress.com
338
Chapter 9 • Advanced Ourmon Techniques
427_Botnet_09.qxd 1/8/07 4:45 PM Page 338
Summary
In this chapter we looked at various techniques that either help the analyst
reduce “the fog of war” or help make the ourmon system more efficient.
Efficiency might be needed in the face of attack or because the system is
doing too much work for the local computer platform.Techniques that help
with analysis
include the trigger mechanism, which helps us automatically
dump interesting packets to a tcpdump-style file, as well as the associated
event logging that goes with it. Event logging
gives us trigger-on and -off
messages and can include important ourmon system events. We also looked at
analysis of data files in the Web directory or the log directories.The logs are
not online, but they are used for some of the Web-based summarizations. In
addition, they can be searched and at times can provide important clues about
borderline behavior. Finally, we looked at various optimization techniques.
Most of these techniques are aimed at improving
the performance or robust-
ness of the front-end probe. If we make the probe faster, we can make it do
more work. Hopefully we can also make it more robust in the face of large-
scale DoS attacks.
Do'stlaringiz bilan baham: