> What are the characteristics to look at when buying hardware to run Bro on?
Something that can run an OS that supports kernel BPF. E.g., FreeBSD,
NetBSD, BSDi, Tru64. There are no doubt others, and I believe there's
a kernel BPF port for Linux in the works, but I don't know if anyone
is shipping it.
> Which values do you suggest to monitor a 100Mbps link or a Gigabit link?
The key is not the link speed so much as the traffic volume over that
link, and, in particular, the volume of traffic accepted by the packet
filter. In the past, we've successfully monitored some medium-sized sites
(2000 users) with 400 MHz Pentiums running FreeBSD. You should have
a good amount of memory, say 256 MB or more. If you have a few hundred
users, then a vanilla 9 GB will probably work fine. If you have a lot
more, then larger drives. It also depends on how long a record you want
to keep on-line. (Experience shows you'll at least want a week, to allow
retrospective analysis of activity.) We use the CCD driver under FreeBSD
to stripe several drives together into one large, fast partition, and
also have an off-line archive machine that we keep everything other
than the raw traces for quite a ways back.
Vern
Hello everybody,
What are the characteristics to look at when buying hardware to run Bro on?
Which values do you suggest to monitor a 100Mbps link or a Gigabit link?
- processor clock frequency
- processor cache
- memory
- number/capacity of hard disks
Thanks
Eric
> I have experienced a similar problem before when using bro on linux (Do
> so at your own peril better to use *BSD). If the box your using it on is
> a router and there is no internet connectivity. This happens because bro
> needs to be able to resolve several host names present in the .bro files
> (if there unmodified)
> line 33 of hot calls for the resolution of ns.lbl.gov for instance. The
> resolution to this is to customize the .bro files for your site, the
> values in the .bro files are place holders (that was the intention
> right?) so that you can change the value to something site specific.
Thanks for the tip. Yes, the intention is that all the hostnames in
the .bro files are place holders, to illustrate how you might use the
various policy tables.
> On a somewhat related subject Mr. Paxon if you have finished the user
> manual I would be very interested in seeing it.
I haven't, but keep those letters coming, the thought that people are
interested in reading it does indeed help squeeze out the cycles for
working on it.
Vern
> Did somebody have information on the number of packets per second
> successfully processed by Bro?
It depends on how you want to cook the figure. It runs routinely on a link
here with about 12,000 pps sustained, and peaks of 18,000 pps. (Well, used
to; due to a topology change, the links I now routinely run it on have lower
rates.) But it filters out a whole lot of the traffic. The number quoted
in the revised Bro paper was one test showing it sustained 730 filtered
packets/sec sustained, with peaks of 1,200 pps, without drops (it's possible
it could have accommodated more, that was the highest-volume traffic stream
I had convenient). This was measured in 1998 on what is now very modest
Intel hardware. I haven't stressed tested it on higher streams, so don't
have a good upper figure. Clearly, I should do that, in my copious spare
time ...
Vern
Did somebody have information on the number of packets per second
successfully processed by Bro?
Stas Khirman
-----Original Message-----
From: Kyle C Quest [mailto:mazequest@hotmail.com]
Sent: Tuesday, July 25, 2000 7:41 AM
To: bro(a)lbl.gov
Subject: Re: Gigabit link monitoring
>What's crucial is the make-up of the traffic: how much is
there, how much
>of it matches the filter, and what sort of analysis has to
be performed
>for the captured traffic.
Right. I just assumed a high load gigabit network where one
bro
would need to do a lot of processing.
Anyway, having several bros monitoring different traffic
would
also help...
>We currently have several Bro's monitoring GigEther links.
They don't
>usually have trouble keeping up, and this is running on old
hardware.
>However, even LBL's access link is nowhere close to
saturated.
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at
http://www.hotmail.com
>What's crucial is the make-up of the traffic: how much is there, how much
>of it matches the filter, and what sort of analysis has to be performed
>for the captured traffic.
Right. I just assumed a high load gigabit network where one bro
would need to do a lot of processing.
Anyway, having several bros monitoring different traffic would
also help...
>We currently have several Bro's monitoring GigEther links. They don't
>usually have trouble keeping up, and this is running on old hardware.
>However, even LBL's access link is nowhere close to saturated.
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
> I am trying to run bro on a Linux 2.2.14 intel box. If I try to use any
> of the ".bro" file, I get this error :
>
> hot, line 33: internal error: NB-DNS error in DNS_Mgr::WaitForReplies
> Aborted
>
> Could anyone help me to correct this?
The message means that a call to nb_dns_activity() (in nb_dns.c) is
failing. Unfortunately, this problem isn't familiar to me, so you'll have
to use a debugger to find out what's going on. I don't know how difficult
that will be.
Vern
> Bro uses libpcap packet capture library... the library uses
> different ways to capture packets on various OS platforms...
> If I'm not mistaken, for fast networks it's better to use
> BSD derived operating systems (OpenBSD, FreeBSD...) because
> they use BPF packet filtering mechanism that is part of operating
> system... and as far as I know BPF provides the best performance...
Right.
> however, I'm sure that even BPF's performance would not be enough
> for gigabits network... Unless BPF+ replaced the original BPF
> implementation, there's no way bro can sustain gigabits speed.
What's crucial is the make-up of the traffic: how much is there, how much
of it matches the filter, and what sort of analysis has to be performed
for the captured traffic.
We currently have several Bro's monitoring GigEther links. They don't
usually have trouble keeping up, and this is running on old hardware.
However, even LBL's access link is nowhere close to saturated. (Bro on
that hardware could not keep up with a significantly higher traffic flow.
We have newer hardware coming in, though, which I'm betting can.) The one
trick we use is large kernel BPF buffers, and making sure that libpcap
doesn't limit the buffer size. This wasn't that important for 100 Mbps,
but is crucial for Gbps.
Vern
> This may seem a very naive question, but I would deeply appreciate it if
> someone could tell me where I could get a copy of bro for use in my masters
> project on network intrusion detection.
It's available from
ftp://ftp.ee.lbl.gov/.vp-bro-0.6-alpha.tar.gz
You'll need libpcap (also available from ftp.ee.lbl.gov) if your
system doesn't already come with it.
I'm working on a Bro user's manual, but it's not yet ready for pre-release.
Vern
Vern would be the best person to give an answer for this question...
but I can also help (in a way ;-])...
Bro uses libpcap packet capture library... the library uses
different ways to capture packets on various OS platforms...
If I'm not mistaken, for fast networks it's better to use
BSD derived operating systems (OpenBSD, FreeBSD...) because
they use BPF packet filtering mechanism that is part of operating
system... and as far as I know BPF provides the best performance...
however, I'm sure that even BPF's performance would not be enough
for gigabits network... Unless BPF+ replaced the original BPF
implementation, there's no way bro can sustain gigabits speed.
Anyways, if you choose to use bro, don't use Linux, because it
is possibly the slowest platform to run bro...
Kyle
=======================================================
>Dear Bro users,
>
>I am new to the field of intrusion detection. I would like to use
>Bro to monitor a Gigabit ethernet link. What type of hardware
>should I use in order to guarantee no packet filter drops?
>
>Regards,
>
>Eric Gauthier
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com