bro: defragmentation

How long does Bro keep ip-fragments ?

Forever.

This isn't great - clearly there should be a user-controllable timeout.
However, if you set the timeout too low, then you become vulnerable to an
evasion attack. It's not clear what's a safe timeout value (some stacks
might use a fixed-size buffer, say, and ignore implementing a timer at
all). A project I'm working on with a student (Umesh Shankar) may wind
up assessing this further.

If someone wants to add a user-controllable timeout, that would be great.

    Vern

If we have a user-controllable timeout, will that be a timeout
for the whole datagram to reassemlbed
(ie within that 'N' secs all the fragments should be reassemled)

OR

will the timer be started again if we get another fragment within that
'N' secs.

-ashley

Hi,

As suggested by Vern, I have added a user controllable timeout for the
fragmentation reassembly part of Bro. I hope this will be useful.

While adding this feature, I have modified the following files:
Frag.cc
Frag.h
Sessions.cc
NetVar.cc
NetVar.h
policy/bro.init

I have attached the above files and their *diff* with the original
files (from version bro-pub-0.7a90)

All the files are attached a gzipped tar file.

The original version keeps the fragments in memory till it gets
fully reassembled (without a timeout). Therefore i tried the following
attack on it; ie.sent a large number of ip-fragments (without completing
the full datagram). It was seen that the memory consumed by bro increased
consistently till the machine crashed.

After the timer has been added, I have verified that it works the expected
way for fully reassembl-able fragments (nothing broken !) as well as it
removes the not re-assembled fragments after a user controlled timeout.

The implementaion has been done very much similar to how it has been done
for the tcp connection.
A timer (user defined) is started (in FragReassembler constructor) when it
gets a fragment for a new set < src ip, dst ip, ID, protocol > and if the
reassembly is not complete within the user specified timeout, the
resources allotted for this set is destroyed.

I have done testing of the same. Hope this is helpful.Please let me know
if there is any problems/modifications needed.

cheers
ashley

Hi,

As suggested by Vern, I have added a user controllable timeout for the
fragmentation reassembly part of Bro. I hope this will be useful.

While adding this feature, I have modified the following files:
Frag.cc
Frag.h
Sessions.cc
NetVar.cc
NetVar.h
policy/bro.init

I have attached the above files and their *diff* with the original
files (from version bro-pub-0.7a90)

All the files are attached a gzipped tar file.

The original version keeps the fragments in memory till it gets
fully reassembled (without a timeout). Therefore i tried the following
attack on it; ie.sent a large number of ip-fragments (without completing
the full datagram). It was seen that the memory consumed by bro increased
consistently till the machine crashed.

After the timer has been added, I have verified that it works the expected
way for fully reassembl-able fragments (nothing broken !) as well as it
removes the not re-assembled fragments after a user controlled timeout.

The implementaion has been done very much similar to how it has been done
for the tcp connection.
A timer (user defined) is started (in FragReassembler constructor) when it
gets a fragment for a new set < src ip, dst ip, ID, protocol > and if the
reassembly is not complete within the user specified timeout, the
resources allotted for this set is destroyed.

I have done testing of the same. Hope this is helpful.Please let me know
if there is any problems/modifications needed.

cheers
ashley

frag.tar.gz (17.8 KB)