Date: Mon, 27 Apr 2015 15:37:13 -0700 From: Charles Swiger <cswiger@mac.com> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies Message-ID: <BB5EBE66-1CD7-41B8-8740-1E1BD052DDA4@mac.com> In-Reply-To: <44814.1430172763@server1.tristatelogic.com> References: <44814.1430172763@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 27, 2015, at 3:12 PM, Ronald F. Guilmette <rfg@tristatelogic.com> = wrote: > In message <A83FB715-936E-4A43-AE2D-E76C32D0F7DE@mac.com>,=20 > Charles Swiger <cswiger@mac.com> wrote: >> On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette = <rfg@tristatelogic.com> wrote: >>> ... >>> 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.) >>=20 >> You need to be able to distinguish normal dup packets >=20 > Yes. >=20 > 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. Typically. But you can also have multipath transit where one path has a = different MTU than the other: a packet can get dup'ed and have one copy then get = fragmented when flowing through that different route. (Simply firing up your companies' VPN can be enough to cause such a = situation.) > 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. Yes. One can also go to town with mechanisms like having the inner = protocol checksum be invalid-- TSO hardware will tend to drop the packet with = very little visibility. > 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). It's much harder to tell whether that happens legitimately, is due to a = bug with the network stack, TSO, etc or is someone playing games with a = covert channel. >> For that matter, an attacker could try to spoof >> legit connections and your countermeasure would presumably zap the = legit >> connection. >=20 > Doesn't that reduce down to essentially the problem of guessing TCP=20 > sequence numbers? You have to guess or be able to observe the TCP connection tuple, IPID, = TCP sequence #. > 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. It's trivial if you can observe the traffic flowing past in transit. It's also fairly easy to guess if you know most or all of the connection = tuple info and the host is using a typical global linear IPID generation method, = because you only have to guess a sequence # within the open window. Regards, --=20 -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BB5EBE66-1CD7-41B8-8740-1E1BD052DDA4>