I am new to bro and I’m trying to find out if there is an easy / automated way to identify the packets that triggered a notice/alarm. I am focused on offline-analysis. For example can you use a technique to read/write, ex. -r a.pcap -w b.pcap, where a.pcap contains all traffic and b.pcap contains all traffic that triggered an alarm or conversely all traffic that did not trigger an alarm? This would be similar to how snort writes a pcap log of suspect traffic. If this is not possible is there sufficient information in the logs to identify individual packets that triggered an alarm/notice? And are there any bundled tools for faciliating this process? I am focused on http traffic.
Essentialy my goal is to pass large sets of data through bro and segregate the traffic into either clean or suspect subsets. I have done some searching on the wiki but it seems that most of my leads bring me to the “Reference Manual: Missing Documentation” page.
I greatly appreciate any guidance you can provide!
Hi Rob,
I don't known if bro write (-w) exactly then snort,
but bro have another good options:
-all (http) log contains unix timestamp and http session number
-http log contains uri request and http code reply
-http mime extract/decoding/parsing (zip)
-dont miss binpac and dpd option for recognize http trafic on all port (require bpf filters)
-bro http/http-request/http-request-body/http-reply-body/http-body/http-request-header/http-reply-header option
-powerfull bro script language
Regards
Rmkml Crusoe-Researches.com
No, not really. The main reason is that at the point when the
decision is taken Bro doesn't really have the notion of packets
anymore, it's working at a higher semantic level and it's in general
not possible to go back and pinpoint individual packets which led to
the decision.
What often works well however is doing this at the connection/flow
level. Most alarms are associated with a particular connection and
once one has the 4-tuple of host & ports, one can extract the
connection's packet from the input. With an offline analysis, that
should be pretty straight-forward to do. For alarms not associated
with a connection, there's usually still at least a certain IP
involved and one could filter for that (depends on your application
whether that makes sense or not I guess).
There's also the "Time Machine"[1], which can buffer large amounts of
packets and provides an interface to, e.g., extract individual
packets from its buffers. The TM can also work offline from traces.