From owner-freebsd-security@FreeBSD.ORG Mon Apr 27 22:12:44 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3600DC25 for ; Mon, 27 Apr 2015 22:12:44 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 1CB731606 for ; Mon, 27 Apr 2015 22:12:43 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 69AB63AEF8 for ; Mon, 27 Apr 2015 15:12:43 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies In-Reply-To: Date: Mon, 27 Apr 2015 15:12:43 -0700 Message-ID: <44814.1430172763@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:12:44 -0000 In message , Charles Swiger wrote: >On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette wrot >e: ... >> 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.) > >You need to be able to distinguish normal dup packets Yes. 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. 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. 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). >For that matter, an attacker could try to spoof >legit connections and your countermeasure would presumably zap the legit >connection. Doesn't that reduce down to essentially the problem of guessing TCP sequence numbers? My understanding is that that is a fundamentally hard problem. (I hope so anyway.) And thus, the probability of what you just suggested approaches zero. If I'm wrong, then I would be more than happy to be corrected/enlightened. Regards, rfg