From owner-freebsd-security@FreeBSD.ORG Tue Apr 28 14:42:23 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F09F0ED4 for ; Tue, 28 Apr 2015 14:42:22 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id A91BD1705 for ; Tue, 28 Apr 2015 14:42:22 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id 1728233C1E; Tue, 28 Apr 2015 10:42:16 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id EC67F39843; Tue, 28 Apr 2015 10:42:14 -0400 (EDT) From: Lowell Gilbert To: "Ronald F. Guilmette" Cc: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies References: <44745.1430172138@server1.tristatelogic.com> Date: Tue, 28 Apr 2015 10:42:14 -0400 In-Reply-To: <44745.1430172138@server1.tristatelogic.com> (Ronald F. Guilmette's message of "Mon, 27 Apr 2015 15:02:18 -0700") Message-ID: <44iocge2m1.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 14:42:23 -0000 "Ronald F. Guilmette" writes: > In message <44a8xte4i0.fsf@lowell-desk.lan>, > Lowell Gilbert wrote: > >>"Ronald F. Guilmette" 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.