[Bro] packet post-processor plugin
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 ) 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,
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 Hall
> International Computer Science Institute
> (Bro) because everyone has a network
More information about the Bro