[Bro] packet post-processor plugin

Gilbert Clark gc355804 at ohio.edu
Thu May 21 10:37:57 PDT 2015


It does sound like an analyzer might not completely work after all...

One option here might be to duplicate / filter the stuff an 
analyzer-based solution won't support (e.g. via either a custom packet 
source or something like [1]) and forward it to a one-off application 
written to parse / gather information from that specific type of 
traffic.  The advantage I see there is that it might let bro do most of 
the heavy lifting for the complex stuff, and might also yield faster 
per-packet performance numbers for the other stuff (since the one-off 
doubles as a fast-path processor for those specific types of traffic).  
Once bro adds support for the stuff that's interesting, then look at 
taking the one-off code and making it part of the bro plugin proper.

Just a thought,
Gilbert

[1] https://github.com/bro/packet-bricks

On 5/20/2015 9:30 PM, Seth Hall wrote:
>> On May 20, 2015, at 5:26 PM, Jeff Barber <jbarber at computer.org> wrote:
>>
>>> What does handle mean in this context?
>> A primary goal is just to identify the endpoints represented by the
>> various layers in the packet: mac addresses, vlan tag, layer3 proto,
>> IP addresses, IP proto, TCP/UDP ports, etc.
> Ohhhh, now this whole thread makes sense.  There has been some discussion internally and on the bro-dev list lately about how to expose that information to scripts in a way that doesn’t overload Bro.  Unfortunately there isn’t a timeline yet on actually implementing what has been discussed.
>
>    .Seth
>
> --
> Seth Hall
> International Computer Science Institute
> (Bro) because everyone has a network
> http://www.bro.org/
>



More information about the Bro mailing list