I’ve been playing with Bro (1.3.2 dev release) on and off for a few weeks now. I like the idea of the product, the code looks good, and the scripting language quite powerful. Having said that I’m having a few problems.
I need a non-interactive install of Bro. I want to roll it out to a number of red-hat-based sensors, so the usual process that requires human interaction is not feasible/maintainable. My usual approach with other software on the sensors is to create an rpm with a default install and then check the box/network specific configuration out of svn over the top of the defaults.
The two-stage install (make install, make install-brolite) makes this a bit complicated. I tried separating out the parts of the install that need to be run on the target system and putting them in the rpm post install (creating bro user, checking kernel params). This involved chopping parts out of the makefile, running the perl scripts in the post, and disabling the prompts by accepting defaults in brolite. Unfortunately I never got all this to work properly.
I’m hoping that someone who understands the installation process better than me can either create an rpm or a install-non-interactive Makefile target that drops a default install on the box Happy to accept any other suggestions too.
I’m having some trouble debugging a simple policy file (I’d include it, but its on another network). I basically want to redefine some of the clear-passwords methods to reduce log noise by checking if this is a password we already know about, and to ignore IRC JOINs with no password.
it never drops into the debugger (and if you Ctrl-C it dies). But if I run
bro -d -r test.pcap brolite
it drops into the debugger fine. Help? My clear-passwords has the same load statements as the distributed version. Do I need something special to cause the debugger to break?
I’m at the stage where bro isn’t giving me any errors about the policy but it is not producing any output, at all, for any policy. Any hints?
I’ve been playing with Bro (1.3.2 dev release) on and off for a few weeks now. I like the idea of the product, the code looks good, and the scripting language quite powerful. Having said that I’m having a few problems.
I need a non-interactive install of Bro. I want to roll it out to a number of red-hat-based sensors, so the usual process that requires human interaction is not feasible/maintainable. My usual approach with other software on the sensors is to create an rpm with a default install and then check the box/network specific configuration out of svn over the top of the defaults.
The two-stage install (make install, make install-brolite) makes this a bit complicated. I tried separating out the parts of the install that need to be run on the target system and putting them in the rpm post install (creating bro user, checking kernel params). This involved chopping parts out of the makefile, running the perl scripts in the post, and disabling the prompts by accepting defaults in brolite. Unfortunately I never got all this to work properly.
I’m hoping that someone who understands the installation process better than me can either create an rpm or a install-non-interactive Makefile target that drops a default install on the box Happy to accept any other suggestions too.
I’m having some trouble debugging a simple policy file (I’d include it, but its on another network). I basically want to redefine some of the clear-passwords methods to reduce log noise by checking if this is a password we already know about, and to ignore IRC JOINs with no password.
it never drops into the debugger (and if you Ctrl-C it dies). But if I run
bro -d -r test.pcap brolite
it drops into the debugger fine. Help? My clear-passwords has the same load statements as the distributed version. Do I need something special to cause the debugger to break?
I’m at the stage where bro isn’t giving me any errors about the policy but it is not producing any output, at all, for any policy. Any hints?
1. I need a non-interactive install of Bro. I want to roll it out to a
I actually can't say much about the BroLite install (not very
familiar with the details of that), except that it's indeed not
really intended for non-interactive usage.
Our plan is to replace the current install process, as well as the
whole BroLite framework, with something based on the the Bro Cluster
setup. There's already prototype of this new scheme, see
Note that while the Blog posting talks about an "interactive shell",
the installation is actually non-interactive and the result should
work well with an rpm-plus-svn scheme as you sketch (I believe; if
not we should fix that). So, perhaps you could give this a try? Any
feedback is appreciated.
bro -d -r test.pcap local.clear-passwords
No, immediate idea. Can you please send the script?
I can't really comment on this as I'm not one of the Bro install gurus,
but perhaps someone who is will do so.
2. I'm having some trouble debugging a simple policy file (I'd include it,
but its on another network). I basically want to redefine some of the
clear-passwords methods to reduce log noise by checking if this is a
password we already know about, and to ignore IRC JOINs with no password.
If you're able at some point to send it along, I can probably help out
directly.
it never drops into the debugger (and if you Ctrl-C it dies). But if I run
Unfortunately the debugger has not been maintained and isn't reliable at
this point :-(. I'd definitely like to fix that, but to date it hasn't
been a high priority. I'd like to hear from any others who also would
make use of it. Offhand, I don't see any obvious problem with what you're
trying above.
I'm at the stage where bro isn't giving me any errors about the policy but
it is not producing any output, at all, for any policy. Any hints?
Try "bro -t tracefile ..." to generate an execution trace. When no output
gets produced, usually the problem is that no events are being generated
because the event engine isn't finding that you've defined the event
handlers it expects for turning on different forms of application analysis.
If the trace shows that the events are being generated, then annotating
your script with logging information will usually help zero in on the
problem quickly.
Thanks guys, that helps. Robin I’ll take a look at the cluster, looks like you have a standalone config in there, so that will have to do for the time being - won’t be getting any new boxes in the immediate future to make a real cluster.
Try “bro -t tracefile …” to generate an execution trace. When no output
gets produced, usually the problem is that no events are being generated
because the event engine isn’t finding that you’ve defined the event
handlers it expects for turning on different forms of application analysis.
If the trace shows that the events are being generated, then annotating
your script with logging information will usually help zero in on the
problem quickly.
Fair enough, I’ll give that a try. I liked the idea of the debugger because you could run through a fairly large pcap and fix most of the problems in one go rather than many repeated analysis runs. This way I’ll have to carve out a much smaller pcap that has the traffic to generate the needed events.
If I can’t get any further along like this I’ll move the config over and send it to the list.
Right, that's the idea: the standalone config is for a traditional,
single-box install. You don't need an actual cluster to use the new
framework (perhaps we should at some point rename the framework's
main script from "cluster" to something less specific).
Happy to accept any other suggestions too.