From owner-freebsd-security@FreeBSD.ORG Mon Apr 27 19:49:25 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 7EEDD6EA for ; Mon, 27 Apr 2015 19:49:25 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 595601325 for ; Mon, 27 Apr 2015 19:49:25 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id 027E533C24; Mon, 27 Apr 2015 15:49:13 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id 48AFC39843; Mon, 27 Apr 2015 15:49:11 -0400 (EDT) From: Lowell Gilbert To: "Ronald F. Guilmette" Cc: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies References: <43372.1430159842@server1.tristatelogic.com> Date: Mon, 27 Apr 2015 15:49:11 -0400 In-Reply-To: <43372.1430159842@server1.tristatelogic.com> (Ronald F. Guilmette's message of "Mon, 27 Apr 2015 11:37:22 -0700") Message-ID: <44a8xte4i0.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: Mon, 27 Apr 2015 19:49:25 -0000 "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, so I wouldn't expect to see it be a standard part of the TCP stack. Such a check would be better implemented as an optional application of an API like BPF.