[Snort-devel] overlapping fragments

Chris Green cmg at ...402...
Tue May 21 16:19:02 EDT 2002

"Ashley Thomas" <athomas at ...1383...> writes:

> Hi,
> Overlapping fragments is known to be a misbehaviour. right ?
> So does the IDS need to 'try' to reassemble that set of fragments
> or just give an alert ??

Idealy it will alert and keep going.  One problem with overlapping
fragments is knowing how much of the attack has gotten through or
knowing that the attack was bogus because we got a fragment that the
remote host will never see.

As a matter of implementation, right now snort processes both the
individual fragment as well as a resassembled fragment favoring older
data when it comes time to overlap.

More realworld hosts do it that way. Eventually choosing a behavior
based on the remote host will be beneficial but once you see
overlapping fragments, you know something is up.

> What should be the ideal behaviour ?
> I think RFC does'nt restrict fragments to be non-overlapping...
> In some cases overlapping fragments can be legitimate, right.

They *could* be maybe possibly be legit traffic of a particularly
broken ip stack.  In an ideal world, all that traffic is normalized
before it gets to your real network hosts.

Too bad it's not an ideal world.

I have a bit more work to do on the TCP retransmission checksum
changed stuff but it's weird because the checksums are coming out a
little off in real world traffic ( the first frame is off by one but
the following retransmissions all have a different but identical to
each other checksum).

[ me also notes that sourceforge has started doing posting ads ]
Chris Green <cmg at ...402...>
This is my signature. There are many like it but this one is mine.

More information about the Snort-devel mailing list