427 Botnet fm qxd

www.syngress.com
336
Chapter 9 • Advanced Ourmon Techniques
427_Botnet_09.qxd 1/8/07 4:45 PM Page 336

---

in it to make them bigger.You need to do this based on data gathered with
the 
pkts filter
pictured in Figure 6.1. If you see that you consistently have
drops and these drops are in the thousands, that could mean that the probe is
not getting to run enough and packets are piling up in the kernel buffer but
not getting read out in time. So, find the ourmon.sh script used to start
ourmon. For example, on FreeBSD or Linux, the ourmon startup script used
to boot the probe might exist in one of the following spots (make sure you
modify the one you actually use):
■
FreeBSD/Linux
/home/mrourmon/bin/ourmon.sh or
/usr/local/mrourmon/bin/ourmon.sh (depending on the install
directory)
■
FreeBSD
/usr/local/etc/rc.d/ourmon.sh (boot startup directory)
■
Linux
/etc/initd/ourmon.sh (boot startup directory)
Edit the script and find the two parameters just before the ourmon probe
(called 
ourmon
) is started.This will be in the function called 
start_om()
. For
example, on a FreeBSD 5.X system, you might see the following:
start_om()
{
sysctl -w debug.bpf_bufsize=8388608
sysctl -w debug.bpf_maxbufsize=8388608
On both Linux and FreeBSD, two 
sysctl
command calls are used to set the size
of the kernel buffer. Stop ourmon, modify the two calls, and then restart
ourmon. Here we want to change both instances of 8388608 to twice as big,
say, 16777216. What you have done is increase the size of the kernel buffer
from 8 megabytes to 16 megabytes. Don’t be shy about the size here. Sixteen
megabytes in a modern computer is nothing in terms of size. See if this
change has a positive effect on the drops; sometimes it will prove effective, but
sometimes you simply don’t have enough CPU horsepower.
Reduce Interrupts
If a DDoS attack shows up, your ourmon or Snort probe might be having a
bad day at the office. Most modern NICs will not turn one packet into one