Bro and Fragmentation.

Zeek
1

Hi All,

Recently I was troubleshooting some fragmentation occurring in UDP DNS responses from our DNS servers, because of packet size > 1500 bytes.
The responses are completely valid, including 13 additional RR’s with 7 Authoritative records, hence exceeding the normal size of the packet, and getting fragmented into two packets.
When grep’ed the connection from the dns.log file in Bro, appeared that Bro logged two connections for the single fragmented DNS response:

2018-08-13T10:16:40-0400 C42pXn2GRPxmh8JRBd 74.220.198.174 19401 128.175.13.16 53 udp 34754 - upenn.edu 1 C_INTERNET 1
5 MX - - F F F F 1 - - F - -

2018-08-13T10:16:40-0400 CsFVfL2czxAmhLprqj 74.220.198.174 19401 128.175.13.16 53 udp 34754 - upenn.edu - - - -
0 NOERROR T F F F 0 cluster5a.us.messagelabs.com,cluster5.us.messagelabs.com, 900.000000,900.000000,900
.000000 F dns1.udel.edu,dns2.udel.edu,adns1.upenn.edu,sns-pb.isc.org,,adns3.upenn.edu,adns2.upenn.edu 128.91.254.22,2607:f470:1002::2:3,2607:f4
70:1003::3:c,,128.91.251.33,2607:f470:1001::1:a,128.91.3.128

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.

Any thoughts?

Thanks!
Fatema.

P.S: I can provide the pcap capture to the corresponding connection mentioned above.

2

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

3

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

4

If you are running with the default local.bro you will get a script loaded called tuning/packet-fragments.bro with this line in it...

redef frag_timeout = 5 min;

5 minutes is still a rather long time but at least it's not indefinite.

   .Seth