[Bro] Bro and Fragmentation.

Michał Purzyński michalpurzynski1 at gmail.com
Sat Aug 18 18:47:27 PDT 2018


Correct me if I’m wrong, but those settings will keep IP fragments in memory indefinitely, subject to other timeouts, risking OOM.


> On 13 Aug 2018, at 10:16, Jon Siwek <jsiwek at corelight.com> wrote:
> 
> On Mon, Aug 13, 2018 at 11:03 AM fatema bannatwala
> <fatema.bannatwala at gmail.com> wrote:
> 
>> I verified the transaction ID ( 34754) with the one in the pcap capture of the same traffic from the firewall and was curious to know how Bro deals with the Fragmentation assembly and logging.
> 
> If valid IP fragments are received in a short enough interval then I'd
> expect Bro to reassemble them without such visible effects on
> application-layer logging.
> 
> The thing that's most suspicious in the logs here is that there's a
> different connection ID (C42pXn2GRPxmh8JRBd vs. CsFVfL2czxAmhLprqj),
> meaning something about these packets caused Bro to create separate
> connections and finding out why that happened would also implicitly
> answer the question of why fragmentation reassembly didn't happen
> (reassembly state is per-connection).
> 
> Some relevant script options to check:
> 
> const udp_inactivity_timeout = 1 min &redef;
> const frag_timeout = 0.0 sec &redef;
> 
> You could also check if there's any "weirds" related these connections
> for possible clues.
> 
> I can also help take a look at any pcaps you have to give a more
> definitive answer of what happened in this case.
> 
> - Jon
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro



More information about the Bro mailing list