From owner-freebsd-security@FreeBSD.ORG Mon Apr 27 22:02:19 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 8C26B9B5 for ; Mon, 27 Apr 2015 22:02:19 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 71F2B148A for ; Mon, 27 Apr 2015 22:02:18 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 5BAD73ADE4 for ; Mon, 27 Apr 2015 15:02:18 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies In-Reply-To: <44a8xte4i0.fsf@lowell-desk.lan> Date: Mon, 27 Apr 2015 15:02:18 -0700 Message-ID: <44745.1430172138@server1.tristatelogic.com> 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: Mon, 27 Apr 2015 22:02:19 -0000 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? 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. Regards, rfg