[Bro] Option to make Bro willing to decode http sessions not preceded by tcp handshake?

Kevin Branch kevin at branchnetconsulting.com
Thu Sep 1 10:19:04 PDT 2016


Thanks, Seth.  I appreciate the update on the issue.  For now I can
substantially mitigate this problem by increasing the pcap file rollover
size so that more often the entire stream to be extracted is in a single
pcap file to begin with.  All the same, it will be great when you all find
the time to implement stream resynchronization in the HTTP analyzer.

I have really grown to appreciate and lean on Bro more over the last few
years.  When I got started with Security Onion I saw Bro as an interesting
add-on alongside Snort/Suricata but now it's like a major part of the
engine of the whole NSM solution.  Thanks for all your great work on this!

Kevin

On Thu, Sep 1, 2016 at 10:28 AM, Seth Hall <seth at icir.org> wrote:

>
> > On Sep 1, 2016, at 9:54 AM, Kevin Branch <kevin at branchnetconsulting.com>
> wrote:
> >
> > I assume that Bro does not consider a stream of tcp/80 packets to be
> valid http traffic if the tcp handshake is missing.  Is there any way to
> ask Bro to be more forgiving about this?  Perhaps a no_sweat_the_handshake
> option?  If so, I believe it would substantially cut down on the number of
> capME failures experienced by Security Onion users.
>
> That change to the http analyzer has long been needed, but we haven't had
> the available time to implement it yet because we would need to implement a
> stream resynchronization mechanism for the HTTP analyzer and it's not
> trivial with the current analyzer.
>
>   .Seth
>
> --
> Seth Hall
> International Computer Science Institute
> (Bro) because everyone has a network
> http://www.bro.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20160901/5cf29693/attachment.html 


More information about the Bro mailing list