Date: Tue, 28 Apr 2015 10:42:14 -0400 From: Lowell Gilbert <freebsd-security-local@be-well.ilk.org> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies Message-ID: <44iocge2m1.fsf@lowell-desk.lan> In-Reply-To: <44745.1430172138@server1.tristatelogic.com> (Ronald F. Guilmette's message of "Mon, 27 Apr 2015 15:02:18 -0700") References: <44745.1430172138@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Ronald F. Guilmette" <rfg@tristatelogic.com> writes: > In message <44a8xte4i0.fsf@lowell-desk.lan>, > Lowell Gilbert <freebsd-security-local@be-well.ilk.org> wrote: > >>"Ronald F. Guilmette" <rfg@tristatelogic.com> writes: >> >>> 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, 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.) >> >>As far as I can see, no. This would be a non-trivial application of >>resources... > > It would surely be enlightening for me if you could elaborate on that > statement a bit. > > As I understand it, the problem is that two TCP packets, both having the > same sequence number, but with different lengths/content arrive at one > endpoint or the other of an established TCP connection within some > relatively brief period of time. (One of them is legit and the other, > fradulent.) > > Hypothetically, if for example, the FreeBSD TCP stack were to maintain, > for each TCP connection, a record of the sequence number of _just_ the > most recently received and accepted packet (32 bits), and also the length > of that same most-recently-received-and-accepted packet... let's just > say for convenience another 32 bits... then if the next subsequent > packet which arrives to that same socket endpoint contains (a) the > exact same sequence number as the immediately prior one, but also (b) > a different length, then could that packet not be then judged to be > indicative of a clear attempt at chicanery? Unfortunately not. Duplicated packets will (in most cases, but not all) have the same length as each other, but the sliding window can easily mean that a retransmission will include more data than the original. And on the other side, I'm concerned that you're actually making an *easier* attack possible by possibly dumping a connection based on what could be a lucky guess. Detecting these anomalies is something that most (all, I think, but I'm not motivated enough to check) stateful firewalls will be able to detect. And it's a good idea; even if the extra packets are happening for benign reasons, having a lot of them represents a bug somewhere in your network path, consuming extra network resources. > Please note that what I just described above requires only two additional > 32 bit words per TCP connection and only two additional 32-bit integer > comparisons operations per packet. Neither the amount of increased > memory nor the amount of incresed computation seem to me as being > particularly egregious, given the potential benefit of possibly catching > out this kind of funny business, when and if it occurs. In a forwarding path, you'd still see a measurable performance hit. And it's depending on a very specific set of symptoms that as far as I've been able to imagine, can only be produced by a attacker who would also be able to use the same resources for a variety of other attacks. And the attacker is already able to read some of your traffic *without* interfering with it. Strong encryption, applied at multiple levels, is the only reasonable engineering approach to issues like this.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44iocge2m1.fsf>