[Bro] packet post-processor plugin
gc355804 at ohio.edu
Wed May 20 07:49:44 PDT 2015
Not claiming to be an expert, so Right Way (tm) is relative. This is
probably a terrible idea, but until there's a better one ... :)
I believe an analyzer plugin can get you access to the raw packets /
connection object on a per-packet basis. There's a video that explains
how to write analyzer plugins from a previous bro gathering ... can dig
up a link if google isn't helpful.
Offhand, I think my first attempt at doing this would go something like:
* Write the new analyzer to do what I wanted with the packets /
* Possibly build a little plugin that would allow me to register new
analyzers through script-land (sounds like something that should
already exist, but can't remember offhand ...)
* Write a connection hook that would use the register new analyzers
function to register my new analyzer to handle this connection
] Since we want this analyzer to run last, register my analyzer as
a child of all other analyzers currently assigned to this connection ...
The challenge, I think, would be interfacing with the external network
device from an analyzer. Doing that directly would be an issue ... so,
maybe create some kind of ring buffer to interface between:
* the main bro thread running the analyzer, and ...
* ... some kind of external thread that polled the ring buffer populated
by the analyzer
The external thread could then shoot gathered information from the local
bro instance to the interested network device.
Hope something in there is interesting / useful.
On 5/20/2015 7:30 AM, Jeff Barber wrote:
> 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.
>> 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
>>> Bro mailing list
>>> bro at bro-ids.org
>> Aashish Sharma (asharma at lbl.gov)
>> Cyber Security,
>> Lawrence Berkeley National Laboratory
>> Office: (510)-495-2680 Cell: (510)-612-7971
> Bro mailing list
> bro at bro-ids.org
More information about the Bro