> $ /usr/local/bin/bro08a70 -i xl1 -t /crusoe/dataL/bro.log bro.init mt
> Execution tracing ON.
> Segmentation fault (core dumped)
Egads, it appears that -t has been seriously broken, no doubt by the recent
changes I introduced to how Bro tracks line numbers to identify where
script values and functions occur. I'll put this on the near-term to-fix
list. Sorry about that.
Vern
> My strange question is,
> why if (I killed bro) and start tcpdump v381 (or 372 or snort or prelude)
> I read on interrupt fxp1 case : ~4200 interrupt
> this is not good because 4200 * 8 = 33.6Mbits
You shouldn't gauge it by number of interrupts since it's possible due
to processor load that in some cases you get mulitple packets per interface
and in others you don't. You could instead look at the statistics reported
by libpcap (though these can be untrustworthy) or record the traffic
using -w and then count just how many packets were captured.
Vern
Hi,
I started bro v0.8a70 current :
$ /usr/local/bin/bro08a70 -i xl1 -t /crusoe/dataL/bro.log bro.init mt
Execution tracing ON.
Segmentation fault (core dumped)
Program terminated with signal 11, Segmentation fault.
(gdb) where
#0 0x0808a461 in TraceState::LogTrace ()
#1 0x080c0814 in BuiltinFunc::Call ()
#2 0x080b19da in CallExpr::Eval ()
#3 0x0809da13 in Expr::InitVal ()
#4 0x0816eead in init_val ()
#5 0x0816f4f9 in make_var ()
#6 0x0816f6de in add_global ()
#7 0x08056a5a in yyparse ()
#8 0x0804d4b6 in main ()
#9 0x0804bcee in _start ()
I started bro on fbsd v4.9R.
Regards
Rmkml(a)Wanadoo.fr
Hi,
I little tested bro on my fbsd v49R box,
I send with tcpreplay on another box (linux) trafic 50Mbits (/8 for
MBytes) [Cross cable with two box]
and if I send 'systat 1 -vmstat' on freebsd,
I read on interrupt fxp1 case : ~6000-6500 interrupt
ok is good because 6500 * 8 = ~50Mbits
My strange question is,
why if (I killed bro) and start tcpdump v381 (or 372 or snort or prelude)
I read on interrupt fxp1 case : ~4200 interrupt
this is not good because 4200 * 8 = 33.6Mbits
I have many repeat this and same results.
same results if change sysctl bpf buf.
This is not a question to bro, but if anybody to explain me ?
I compiled bro 0.8a70 current with libpcap 081.
I compiled freebsd kernel with HZ=1000.
(my kernel not have polling compiled/enabled,
and my fxp1 have uniq irq)
Regards
Rmkml(a)Wanadoo.fr
Having a low-footprint version of Bro hasn't been part of our operational
needs, so it hasn't received attention. I imagine the current footprint
could be diminished a fair amount by compiling out various functionality,
and doing so shouldn't be too hard in most cases since quite a bit of it
is modularized/layered pretty cleanly. (You can get a sense of where some
of the memory is going by using statistics.bro and print-globals.bro) This
won't be something for which we'll have cycles available to work on, though.
Vern
I'm sure someone out there has done some performance profiling on Bro.
In just my rudimentary monitoring, I find that the running executable
requires anywhere from 5M to 7.2M of memory when running on my local
Linux host, looking at just my own network traffic. Size depends on
number of policies read. It looks to be fairly CPU-efficient in that it
hardly even registers on "top" when monitoring my local net.
I'm wondering if this memory footprint coincides with anyone else's
observations, and is there a way to reduce that footprint to something
smaller. I don't need Bro to have a huge policy, - however, what I want
may require all of Bro functionality. I'm just looking to do to attack
detection (and hopefully blocking) (like the latest 10 "worm" signatures
that may be available).
Regards,
David L. Sames
McAfee Research
15204 Omega Drive
Rockville, MD 20850
301.947.7189 | Direct
301.527.0482 | Fax
david_sames(a)nai.com | E-mail
<www.mcafeesecurity.com> | Web
> Possible receive bro events with syslog daemon ?
That's not the Bro model. Events are meant to be processed by event
handlers in your policy scripts. Those handlers might then decide to
execute "log" statements (or by calling the ALERT() function, which is
specified in policy/alert.bro), though, and *those* are sent via syslog.
Note, an event is *NOT* an alert, it's a description of some network
activity in security-neutral terms.
> possible coding function to convert all events in same function ?
> (and on this new function, choice syslog / stdout / stderr ...)
Not in a policy script, since events are strongly typed. The tracing
facility, "-t tracefile", let's you dump a list of all the events to a
given file. Note, on any good-sized network stream, this file gets
huge very fast.
Vern
Hi,
Possible receive bro events with syslog daemon ?
possible coding function to convert all events in same function ?
(and on this new function, choice syslog / stdout / stderr ...)
Regards
Rmkml(a)Wanadoo.fr
> possible send this file to me ?
I can, but first try the following. Your system may have "byacc" installed
on it in addition to bison. If so, try changing
YACC = bison -y
in the Makefile to
YACC = byacc
> and possible add this file to bro 08 current ?
I am reluctant to add complexity to the Bro distribution in order to work
around bugs in various operating system releases (except when they can be
incorporated as autoconf elements), as that's the path to ongoing maintenance
headaches ...
Vern
> I don't find this file on my freebsd box,
It is renamed by the Makefile. The Makefile steps will look like:
bif_parse.h bif_parse.cc: builtin-func.y bif_arg.h bif_type.def
$(YACC) $(YFLAGS) builtin-func.y
@mv y.tab.h bif_parse.h
@mv y.tab.c bif_parse.cc
so you'll find y.tab.c as bif_parse.cc.
That said, checking my email archives reveals that this is a FreeBSD 4.9
problem with its bison installation, and not a Bro problem, per the appended.
As a work-around, I can send you the bif_parse.cc that's generated using
my version of bison - that should build okay for you.
Vern
Date: Fri, 02 Jan 2004 09:22:46 -0800
From: Vern Paxson <vern(a)jaguar.icir.org>
Subject: Re: Error compiling bro-pub-0.8a58
To: Richard Bejtlich <richard_bejtlich(a)yahoo.com>
Well, the problem line is:
#if defined (__GNUC_MINOR__) && 2093 <= (__GNUC__ * 1000 + __GNUC_MINOR__)
__attribute__ ((__unused__))
#endif
but that's not anything from the Bro sources. It must be from your version
of bison (1.875), which is much more recent than the version I use. So I'm
afraid I can't help you further with untangling it - it's some sort of
configuration problem or mismatch w/ gcc version.
> I'm interested in Bro because I cite you as an IDS
> pioneer in a book I'm writing, and I'd like to briefly
> describe how to get Bro working on a FreeBSD system.
Great!
> I've only dabbled with Bro but I want to give the
> reader an easy guide to installation and basic use.
> Your install doc is quite thorough, but do you have a
> "rapid deployment" guide of sorts you could share?
There's a "Getting Started" section in the manual, but currently that's it.
Vern
