[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