mirror of
https://github.com/zeek/zeek.git
synced 2025-10-04 07:38:19 +00:00
144 lines
4.7 KiB
Text
144 lines
4.7 KiB
Text
|
|
@strong{NOTE: This chapter still a rough draft and incomplete}
|
|
|
|
If the link you are monitoring with Bro has
|
|
too many connections per second, or if you have too many policy
|
|
modules loaded, it is possible that Bro will not be able to keep
|
|
up, and that the Bro host will drop too many packets to be able to
|
|
perform accurate analysis.
|
|
|
|
A "rule of thumb" for Bro is that if CPU usage is < 50% and memory
|
|
use is < 70% of physical memory, than you should not have any worries.
|
|
|
|
Otherwise you might want to explore the tuning options below.
|
|
|
|
For sites with an extremely high load you might consider using multiple
|
|
Bro boxes, each configured to capture and analyze different types of traffic.
|
|
|
|
Note that the amount of CPU required by Bro is a function of both the number
|
|
of connections/second and the number of packets/second. So it's possible
|
|
that a large site (e.g., 2,000 hosts) on a slow link (e.g., 100 Mbps) would
|
|
still have performance issues because it has a very large
|
|
number of connections / second.
|
|
|
|
@menu
|
|
* Hardware and OS Tuning ::
|
|
* Bro Policy Tuning ::
|
|
@end menu
|
|
|
|
@node Hardware and OS Tuning
|
|
@section Hardware and OS Tuning
|
|
@cindex Hardware Tuning
|
|
@cindex OS Tuning
|
|
|
|
If your CPU load > 50% or your memory footprint is > 70% of physical
|
|
memory, an obvious solution is to buy a faster CPU or more memory.
|
|
|
|
If this is not possible, here are some other things to try.
|
|
|
|
@strong{FreeBSD}
|
|
|
|
First, check that your BPF buffer size is big enough. The Bro installation
|
|
script should set this correctly for you, but to test this, do:
|
|
@smallexample
|
|
sysctl debug.bpf_bufsize
|
|
sysctl debug.bpf_maxbufsize
|
|
@end smallexample
|
|
|
|
They should both be at least 4 MB.
|
|
|
|
Next, if your Bro host is capturing packets on 2 interfaces and you are
|
|
running FreeBSD, we provide a patched kernel that bonds both interfaces
|
|
into a single interface at the BPF level. This reduces CPU load considerably.
|
|
This patched kernel also increases the default per-process memory limits.
|
|
|
|
This kernel source is available for download at:
|
|
@smallexample
|
|
@uref{http://www.bro-ids.org/download/FreeBSD.4.10.bro.tgz}.
|
|
@end smallexample
|
|
|
|
To install this kernel and the BPF bonding utilites, type:
|
|
|
|
@smallexample
|
|
tar xfz fbsd.4.10.bond.tgz
|
|
cd FreeBSD-4-10-RELEASE/sys/i386/conf
|
|
/usr/sbin/config BRO
|
|
cd ../../compile/BRO
|
|
make depend
|
|
make
|
|
make install
|
|
|
|
cd FreeBSD-4-10-RELEASE/local/sbin/bpfbond/
|
|
make
|
|
make install
|
|
|
|
reboot
|
|
@end smallexample
|
|
|
|
For more instructions on rebuilding the kernel, see:
|
|
@uref{http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html}.
|
|
|
|
|
|
@strong{Linux}
|
|
|
|
Check that the net.core.rmem_max buffer is big enough. The Bro installation
|
|
script should set this correctly for you, but to test this, do:
|
|
@smallexample
|
|
sysctl net.core.rmem_max
|
|
@end smallexample
|
|
|
|
It should be at least 4 MB.
|
|
|
|
For heavy traffic load, the Linux version of libpcap has a hard time keeping up.
|
|
There are a couple a options available to improve Linux pcap performance.
|
|
These include:
|
|
|
|
Phil Wood's libpcap replacement: (see http://public.lanl.gov/cpw/)
|
|
Luca Deri's patch to fix libpcap issues. (see http://luca.ntop.org/Ring.pdf)
|
|
|
|
(Note that Phil Wood's version of libpcap seems to be buggy in non-blocking
|
|
mode. Build Bro using the --disable-selectloop option to disable non-blocking
|
|
mode if using this version of libpcap.)
|
|
|
|
|
|
@node Bro Policy Tuning
|
|
@section Bro Policy Tuning
|
|
@cindex Bro Policy Tuning
|
|
|
|
If the hardware and OS tuning solutions fail to bring your
|
|
CPU load or memory consumption under control, next you will
|
|
have to start turning off analyzers. Signatures are particularly CPU
|
|
and memory intensive,
|
|
so try turning it off or greatly reduce the number of signatures it
|
|
is processing. The HTTP analyzers are also CPU intensive. For example,
|
|
to turn off the HTTP reply analyzer, add the following lines at the beginning
|
|
of the file @code{$BROHOME/site/brohost.bro}, before any @@load commands.
|
|
|
|
@smallexample
|
|
@@unload http-reply
|
|
@end smallexample
|
|
|
|
Another solution is to modify libpcap filter for Bro. This is done
|
|
by adding @code{restrict_filters}. For example, to only capture SYN/FIN
|
|
packets from a large web proxy, you can do this:
|
|
|
|
@verbatim
|
|
redef restrict_filters += { ["not proxy outbound Web replies"] =
|
|
"not (host bigproxy.mysite.net and
|
|
src port 80 and (tcp[13] & 7 == 0))" };
|
|
@end verbatim
|
|
|
|
This filter will allow you to record the number and size of the HTTP replies,
|
|
but will not do further HTTP analysis.
|
|
|
|
Another way to reduce the CPU load of Bro analysis is to split the work
|
|
across two Bro hosts. An easy way to do this is to take the sum of the
|
|
source and destination IPs, and monitor even combinations
|
|
on one host and odd combinations on a second host.
|
|
|
|
For example:
|
|
|
|
@verbatim
|
|
redef restrict_filters += { ["capture even src/dest pairs only"] = "(ip[12:4] + ip[16:4]) & 1 == 0" };
|
|
@end verbatim
|
|
|