Thank you for the prompt response! I will look into the connections/flows.
On Tue, Nov 10, 2009 at 12:20 AM, Robin Sommer <robin(a)icir.org> wrote:
On Mon, Nov 09, 2009 at 14:03 -0500, you wrote:
I am new to bro and I'm trying to find out
if there is an easy /
way to identify the packets that triggered a
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
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", 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.
Robin Sommer * Phone +1 (510) 666-2886 * robin(a)icir.org
ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org