Date: Mon, 27 Apr 2015 20:52:09 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies Message-ID: <46186.1430193129@server1.tristatelogic.com> In-Reply-To: <BB5EBE66-1CD7-41B8-8740-1E1BD052DDA4@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <BB5EBE66-1CD7-41B8-8740-1E1BD052DDA4@mac.com>, Charles Swiger <cswiger@mac.com> wrote: >On Apr 27, 2015, at 3:12 PM, Ronald F. Guilmette <rfg@tristatelogic.com> >wrote: >> 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. So, the question becomes: How common is THAT scenario, in practice? And if it is reasonably uncommon, then might it still be worthwhile to at least _log_ cases where two back-to-back TCP packets arrive in succession, where both have an identical squence number, but where they have different lengths and/or checksums (thus indicating possible or perhaps even probably funny business)? Also, although I don't even pretend to be a expert with respect to either TCP or the software stacks that implement it, I must nontheless ask if the exact kind of check I proposed could perhaps be implemented at some level of the protocol stack which is subsequent to fragmented packet reassembly (thereby eliminating as a problem the specific scenario you raised). >>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-- I'm sorry, but I do not grasp what it is that you are driving at, exactly. May I ask you, with respect, if you could state the issue in a different way that I might understand? >> 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. While I am quite certainly not nearly enough of an expert to be able to in any way take issue with what you've just said, I ceratinly would like to ask you to elaborate further on these scenarios... and whether they atre likely to be at all common, in practice... if you wouldn't mind. >>> For that matter, an attacker could try to spoof >>> legit connections and your countermeasure would presumably zap the >>> legit connection. We seem to be in agreement that the possibility of a nefarious attacker, with evil intent, being able to successfully pull off exactly such spoofing is predicated upon his having direct access to the wire... in which case I personally feel and believe that the victim may have vastly more serious problems to worry about than just abruptly dropped TCP connections. Regards, rfg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46186.1430193129>