I noticed the capture-events.bro policy and loaded it; it has been generating an events.bst file in my logs directory with data inside of it. My question is: what can I get out of this file? Is this just a raw packet capture of anything that is flagged by a policy?
Also, I tried replaying the file using bro -R events.bst and it appears to be waiting for standard input. When I try and specify a policy to use on the command line it errors with:
[root@endace bro]# bin/bro -R /scratch/bro/logs/events.bst http
./site, line 1: error: read failed with "Is a directory"
I searched through the documentation and saw no reference to 'replay' 'events.bst' or even '.bst'.
Also, where can I get the start-capture-all script? Is this just a wrapper around tcpdump; or does it grab the data before/after bro looks at the stream? Unfortunately with the DAG capture cards I am testing with, only one application can read from the device at a single time. Any suggestions? Thanks!
I noticed the capture-events.bro policy and loaded it; it has been
generating an events.bst file in my logs directory with data inside of
it. My question is: what can I get out of this file? Is this just a
raw packet capture of anything that is flagged by a policy?
It's a capture of all events which were generated during run-time,
e.g., things like connection_established and http_request.
Events.bst contains all raised events including their timestamps and
parameters, so it's a very convenient way to understand what's going
on during operation (for large traffic streams it gets huge though
and may therefore be more suitable for smaller experiments).
You can display the contents of the file with the -x option:
Would you recommend using BRO_CREATE_TRACE_FILE=YES instead of event-capture.bro? Besides being in a raw tcpdump format, what other benefits does the trace file give me? Thanks!
The tracefile gives you a comprehensive view of the network
activity: it contains exactly the data on which Bro performed the
analysis; by refeeding the trace into Bro again, you get the same
results. The single most important advantage of a trace is that you
can manually examine it afterwards to see why Bro reported
something, in case the usual logs are not sufficient. If your
environmnent allows it (in terms of available resources, network
volume, and organisational restrictions), capturing a trace is a
good thing.
events.bst is a bit different: it does not contain the raw traffic
but a higher-level abstraction of it; you loose information as you
only see the data in a state when Bro has already performed its
first step of analysis (i.e. after a large reduction in volume).
This may or may not be sufficient to track things down, though
usually most of the data contained in events.bst ends up in some log
file anyway.
I usually do not routinely use capture-events with an operational
Bro. I Rather turn it on selectively if I need to understand how
exactly Bro generates events for some given input, e.g., to tweak a
policy script. Then it's really helpful as you exactly see what the
policy scripts see as well, including timing.
I use event-capture.bro mainly for debugging processing of external events sent to Bro via
Broccoli. For example, we convert syslog events to something bro understands and send them
to Bro for analysis via Broccoli.