Date: Mon, 27 Apr 2015 15:12:43 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies Message-ID: <44814.1430172763@server1.tristatelogic.com> In-Reply-To: <A83FB715-936E-4A43-AE2D-E76C32D0F7DE@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <A83FB715-936E-4A43-AE2D-E76C32D0F7DE@mac.com>, Charles Swiger <cswiger@mac.com> wrote: >On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette <rfg@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44814.1430172763>