freebsd security - Apr 2015 - Logging TCP anomalies

On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette <rfg at
tristatelogic.com> wrote:
> 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,
Not normally.  Such things can be visible in netstat -s output as
"completely
duplicate packets", "packets with some dup. data", etc and maybe
enabling
network debugging sysctls would give more visibility.  They'd also generate
vast amounts of logging for normal network activity.
> 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.)
You need to be able to distinguish normal dup packets or dropping connections
will break normal traffic.  For that matter, an attacker could try to spoof
legit connections and your countermeasure would presumably zap the legit
connection.

Use a firewall which tracks connection state, drops out-of-window packets,
forces fragmented packet reassembly to be performed, uses protocol-aware
proxies to validate the content of traffic where possible.

Regards,
-- 
-Chuck

In message <A83FB715-936E-4A43-AE2D-E76C32D0F7DE at mac.com>, 
Charles Swiger <cswiger at mac.com> wrote:
>On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette <rfg at
tristatelogic.com> wrot
>e:
...
>> 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.)
>
>You need to be able to distinguish normal dup packets
Yes.

As I understand it, (verbatim) duplicate packets can sometimes arrive at
an endpoint due simply to network anomalies.  However as I understand it,
those will typically have identical lengths and payloads.  If I read that
news article correctly, then the spoofed packets at issue will have the
same sequence numbers as legit ones, but different lengths and/or payloads.

It seems simple enough to detect instances when two packets with the
exact same sequence number but different lengths arrive at a given
endpoint in immediate proximity (in time).
>For that matter, an attacker could try to spoof
>legit connections and your countermeasure would presumably zap the legit
>connection.
Doesn't that reduce down to essentially the problem of guessing TCP 
sequence numbers?

My understanding is that that is a fundamentally hard problem.  (I hope
so anyway.)  And thus, the probability of what you just suggested
approaches zero.

If I'm wrong, then I would be more than happy to be corrected/enlightened.


Regards,
rfg