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>
index | next in thread | previous in thread | raw e-mail
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, rfghome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46186.1430193129>