From owner-freebsd-security@FreeBSD.ORG Tue Apr 28 06:37:26 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 6B85AE72 for ; Tue, 28 Apr 2015 06:37:26 +0000 (UTC) Received: from nitrogen.nk99.org (nitrogen6.nk99.org [IPv6:2a01:4f8:140:21c6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 31F611C15 for ; Tue, 28 Apr 2015 06:37:25 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by nitrogen.nk99.org (Postfix) with ESMTP id 8D1542732E for ; Tue, 28 Apr 2015 06:37:23 +0000 (UTC) Received: from ::1 (proxying for 141.228.106.147) (SquirrelMail authenticated user nk@nk99.org) by localhost with HTTP; Tue, 28 Apr 2015 09:37:23 +0300 Message-ID: In-Reply-To: <44814.1430172763@server1.tristatelogic.com> References: <44814.1430172763@server1.tristatelogic.com> Date: Tue, 28 Apr 2015 09:37:23 +0300 Subject: Re: Logging TCP anomalies From: "Nerijus Krukauskas" To: freebsd-security@freebsd.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Tue, 28 Apr 2015 12:01:29 +0000 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 06:37:26 -0000 On Tue, April 28, 2015 01:12, Ronald F. Guilmette wrote: > > 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). Have you asked yourself a question on how long do you wait for that possible duplicate packet? TCP by design will accept first legitimate packet in sequence. When the duplicate arrives the connection state has already changed. Logging such an event is the most you can get, IMO. -- nk