[Bro] A lower level interface

Shuai Hao haoscs at gmail.com
Tue Oct 10 11:06:51 PDT 2017

Thanks for your reply, Johanna.

Basically I am looking for an interface by which we can examine and extract
the features of byte stream (or strings) from the traffic (TCP payload),
and then we will feed the stream to our analyzer (e.g., via BinPac).
Currently I am looking at the tcp_contents; I think it might be sufficient
so I don't have to use tcp_packet or new_packet.

Although there is also a performance note for tcp_contents in the manual, I
assume that it would be better than using tcp_packet or new_packet (is this
true? I do care about the performance).

Thank you very much!



On Tue, Oct 10, 2017 at 1:01 PM, Johanna Amann <johanna at icir.org> wrote:

> Hi,
> > I've seen many discussions referring to the Bro as an alternative of
> > libnids.
> Out of curiosity - where did you see discussions like that?
> I do not really know much about libnids, but from the readme it seems that
> libnids is a library that mostly implements TCP reassembly. While this is
> a part of what Bro does, it only is a small part of it; obviously the
> main focus of Bro is on a different layer.
> > I wonder that can we use the similar lower-level interface similar
> > to libnids in Bro (e.g., for the tcp assembly)?
> I am not quite sure what you are looking for here, could you perhaps
> expand a bit on that?
> The lowest level access that you can get is probably by writing a custom
> (c++) analyzer that gets passed either the reassembled TCP payloads. (Or
> just the raw packets in case of UDP).
> > We would like to explore the string features of packets, while keeping
> > to leverage Bro's high-level events.
> You can use something like the new_packet events in Bro to get access to
> individual packet information. However, there is a performance penalty
> associated with this (script-level events are fairly expensive and usually
> there are a few per connection, not a few per packet).
> For anything carrying a significant amount of traffic that approach
> probably is not viable.
> It depends a bit on what you want to do - preprocessing in C++ and then
> bubbling up more high-level events should be a more realisitic choice.
> I hope this helps,
>  Johanna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20171010/4770ce16/attachment.html 

More information about the Bro mailing list