Logging TCP anomalies

[Lowell Gilbert]

"Ronald F. Guilmette" <rfg at tristatelogic.com> writes:

> In message <44a8xte4i0.fsf at lowell-desk.lan>, 
> Lowell Gilbert <freebsd-security-local at be-well.ilk.org> wrote:
>
>>"Ronald F. Guilmette" <rfg at tristatelogic.com> writes:
>>
>>> I am prompted to ask here whether or not FreeBSD performs any sort of
>>> logging of instances when "duplicate TCP packets but with different
>>> payloads" occurs, and/or whether FreeBSD provides any options which,
>>> for example, might automagically trigger a close of the relevant TCP
>>> connection when and if such an event is detected.  (Connection close
>>> seems to me to be one possible mitigation strategy, even if it might
>>> be viewed as rather ham-fisted by some.)
>>
>>As far as I can see, no. This would be a non-trivial application of
>>resources...
>
> It would surely be enlightening for me if you could elaborate on that
> statement a bit.
>
> As I understand it, the problem is that two TCP packets, both having the
> same sequence number, but with different lengths/content arrive at one
> endpoint or the other of an established TCP connection within some
> relatively brief period of time.  (One of them is legit and the other,
> fradulent.)
>
> Hypothetically, if for example, the FreeBSD TCP stack were to maintain,
> for each TCP connection, a record of the sequence number of _just_ the
> most recently received and accepted packet (32 bits), and also the length
> of that same most-recently-received-and-accepted packet... let's just
> say for convenience another 32 bits... then if the next subsequent
> packet which arrives to that same socket endpoint contains (a) the
> exact same sequence number as the immediately prior one, but also (b)
> a different length, then could that packet not be then judged to be
> indicative of a clear attempt at chicanery?

Unfortunately not. Duplicated packets will (in most cases, but not all)
have the same length as each other, but the sliding window can easily
mean that a retransmission will include more data than the original.

And on the other side, I'm concerned that you're actually making an
*easier* attack possible by possibly dumping a connection based on what
could be a lucky guess.

Detecting these anomalies is something that most (all, I think, but I'm
not motivated enough to check) stateful firewalls will be able to
detect. And it's a good idea; even if the extra packets are happening
for benign reasons, having a lot of them represents a bug somewhere in
your network path, consuming extra network resources.

> Please note that what I just described above requires only two additional
> 32 bit words per TCP connection and only two additional 32-bit integer
> comparisons operations per packet.  Neither the amount of increased
> memory nor the amount of incresed computation seem to me as being
> particularly egregious, given the potential benefit of possibly catching
> out this kind of funny business, when and if it occurs.

In a forwarding path, you'd still see a measurable performance hit. And
it's depending on a very specific set of symptoms that as far as I've
been able to imagine, can only be produced by a attacker who would also
be able to use the same resources for a variety of other attacks. And
the attacker is already able to read some of your traffic *without*
interfering with it.

Strong encryption, applied at multiple levels, is the only reasonable
engineering approach to issues like this.