[Bro] packet post-processor plugin

[Jeff Barber]

On Tue, May 19, 2015 at 4:58 PM, Aashish Sharma <asharma at lbl.gov> wrote:
> Why do you want to do this ? what is that your packet port-processor going to do that you think bro isn't doing for you?

First, I need to see every packet (including non-IP packets),
preferably *after* bro has had a chance to analyze them. Second, I'm
intending to interface to another existing system that (among other
things) collects network inventory; it's largely orthogonal to
protocol parsing (although informed by it which is why I would like to
see the Connection data).

>>    Maybe there's some obvious way to do this that I've overlooked?
>
> Yes, use scripting layer for your analysis. If you think a particular protocol parsing is deficient, instead of writing a packet post-processor, might as well write your new protocol parser.

I'm not adding a protocol parser. If/when I add one of those, I will
definitely do it the usual bro way.

I think the performance penalty of trying to do what I need to do in
bro script would be too high (if it were even possible). The bro
documentation warns about the overhead of new_packet, packet_contents
events, which would be the closest analog to what I need. It seems
clear to me that the need to marshal the various data into the form
needed by bro script is the primary source of the overhead and I'd
like to avoid that.


>
> Aashish
>
> On Tue, May 19, 2015 at 04:22:14PM -0400, Jeff Barber wrote:
>>
>>    Still a bro newbie, so I'm looking for some guidance.
>>    I'd like to add a packet post-processor to bro. It'll be written in C++.
>>    Essentially I'd like to see every packet that goes through bro, along with
>>    its Connection record (or the equivalent) if there is one. Ideally it would
>>    be structured it as a plugin.
>>    It looks like I could do it by triggering off of events like new_packet
>>    (although currently that only triggers for IP packets). However, IIUC, that
>>    still has bro packaging all the info up into a RecordVal, then I have to
>>    decode  it  in my plugin event handler. That seems like quite a bit of
>>    additional overhead on each packet.
>>    It looks like I might also be able to do it as a PktDumper but then I just
>>    get the raw packet data and I'd have to go re-parse headers and re-lookup
>>    connection info - redoing work that's already been done.
>>    What I'd really like is to simply get a call at the end of analysis for
>>    every packet, where I'd get passed a pointer to the packet data along with a
>>    pointer to the existing Connection record (if any). Maybe there's some
>>    obvious way to do this that I've overlooked?
>>    Anybody have advice for the best way to go? I'm willing to do work to make
>>    this happen, but also would prefer not to fork bro so looking for "right
>>    ways".
>>    TIA,
>>    Jeff
>
>> _______________________________________________
>> Bro mailing list
>> bro at bro-ids.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
>
> --
> Aashish Sharma  (asharma at lbl.gov)
> Cyber Security,
> Lawrence Berkeley National Laboratory
> http://go.lbl.gov/pgp-aashish
> Office: (510)-495-2680  Cell: (510)-612-7971