From owner-freebsd-security@FreeBSD.ORG Mon Apr 27 19:57:19 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 0E5E1B8C for ; Mon, 27 Apr 2015 19:57:19 +0000 (UTC) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE383149E for ; Mon, 27 Apr 2015 19:57:18 +0000 (UTC) Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 5B.70.09370.D949E355; Mon, 27 Apr 2015 12:57:17 -0700 (PDT) X-AuditID: 11973e16-f79856d00000249a-2b-553e949ddda1 Received: from [17.149.227.61] (Unknown_Domain [17.149.227.61]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 46.65.22377.7A49E355; Mon, 27 Apr 2015 12:57:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: Logging TCP anomalies From: Charles Swiger In-Reply-To: <43372.1430159842@server1.tristatelogic.com> Date: Mon, 27 Apr 2015 12:57:16 -0700 Cc: freebsd-security@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <43372.1430159842@server1.tristatelogic.com> To: "Ronald F. Guilmette" X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUi2FAYrDt3il2owZ9f/BY9m56wWby6/IrN gcljxqf5LB73NzUyBzBFcdmkpOZklqUW6dslcGVcnD2HueAsV8W08//YGxhPc3QxcnBICJhI TH3H3cXICWSKSVy4t56ti5GLQ0hgL6NEf+8DdoiEicTHjx3sEImpTBKb5v1kBkkwC2hJ3Pj3 kgnE5hXQk3j09DFYg7CAksTLDYcZQRawCahJTJjIAxLmFLCUaJ++hxXEZhFQlVgyeRMLxBgF icnzv0ON1JZYtvA1M8RIK4lX55aC1QgJWEgsuXORHWSkiIChxPppzhDny0p83SoHcpmEwFdW iSN93xgnMArNQnLcLCTHzUKyYQEj8ypGodzEzBzdzDxzvcSCgpxUveT83E2MoOCdbie2g/Hh KqtDjAIcjEo8vAWTbUOFWBPLiitzDzFKc7AoifMuCbQLFRJITyxJzU5NLUgtii8qzUktPsTI xMEp1cBoZJkszDl5GUOBoqrtruP7jT8Z1Vycv+J/1/sXJh+4M6+eWl1lefyGsGmeD5uV1v3c D394XG25S80u1jm9OCuRFT/Nm3F+/d4VkiEWXBtdfudpC3TJ/pf8USsp7CbzeMOF0me1YqFr FxpdSBCbtdLVPnUG3zL1toBVe9S/NQY/+93xpX5Wn78SS3FGoqEWc1FxIgD0WtncPwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUiOPWxre7yKXahBme2M1n0bHrCZvHq8is2 ByaPGZ/ms3jc39TIHMAUxWWTkpqTWZZapG+XwJVxcfYc5oKzXBXTzv9jb2A8zdHFyMkhIWAi 8fFjBzuELSZx4d56ti5GLg4hgalMEpvm/WQGSTALaEnc+PeSCcTmFdCTePT0MViDsICSxMsN hxm7GDk42ATUJCZM5AEJcwpYSrRP38MKYrMIqEosmbyJBWKMgsTk+d+hRmpLLFv4mhlipJXE q3NLwWqEBCwklty5yA4yUkTAUGL9NGcQU0JAVuLrVrkJjPyzkNwzC8k9s5AMXcDIvIpRoCg1 J7HSWC+xoCAnVS85P3cTIyjcGgqDdzD+WWZ1iFGAg1GJh7dgsm2oEGtiWXFl7iFGCQ5mJRHe yZl2oUK8KYmVValF+fFFpTmpxYcYpTlYlMR5OyssQoUE0hNLUrNTUwtSi2CyTBycUg2MaywE jssvfPvoWMOO5gnBXI5Rzk/OTODymFIZrCIio2x77Iroin3mrrs+t7wxdTVzUPm6p7L1tPTv 6tW2b/texX3+X2a9W2VXjLOV9Rz3xPRMuWNfecPi3zALPJhwcX5Q7dqUqKVH3qvZ3V/KzDDl Wfp/Xb61mkEbFqnbzQpRsFXRz9m93bhHiaU4I9FQi7moOBEACf8sRzMCAAA= 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:57:19 -0000 On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette = wrote: > 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, Not normally. Such things can be visible in netstat -s output as = "completely duplicate packets", "packets with some dup. data", etc and maybe = enabling network debugging sysctls would give more visibility. They'd also = generate vast amounts of logging for normal network activity. > 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 or dropping = connections will break normal traffic. For that matter, an attacker could try to = spoof legit connections and your countermeasure would presumably zap the legit connection. Use a firewall which tracks connection state, drops out-of-window = packets, forces fragmented packet reassembly to be performed, uses protocol-aware proxies to validate the content of traffic where possible. Regards, --=20 -Chuck