From owner-freebsd-security@FreeBSD.ORG Mon Apr 27 22:37:21 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 6D011EEB for ; Mon, 27 Apr 2015 22:37:21 +0000 (UTC) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 48CDE183F for ; Mon, 27 Apr 2015 22:37:20 +0000 (UTC) Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 61.3E.12430.A1ABE355; Mon, 27 Apr 2015 15:37:14 -0700 (PDT) X-AuditID: 11973e13-f79d56d00000308e-d2-553eba1a1a04 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 relay4.apple.com (Apple SCV relay) with SMTP id 2C.9C.09819.58ABE355; Mon, 27 Apr 2015 15:39:01 -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: <44814.1430172763@server1.tristatelogic.com> Date: Mon, 27 Apr 2015 15:37:13 -0700 Cc: freebsd-security@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <44814.1430172763@server1.tristatelogic.com> To: "Ronald F. Guilmette" X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUi2FAYriu1yy7U4MA/AYueTU/YLF5dfsXm wOQx49N8Fo/7mxqZA5iiuGxSUnMyy1KL9O0SuDLmLp3FVPBMtOL1sTtsDYzrBLsYOTkkBEwk ju15wwZhi0lcuLceyObiEBLYyyjxfPEtRpiiJ03H2CESU5kkLv9fzQqSYBbQkrjx7yUTiM0r oCfx6OljdhBbWEBJ4uWGw0DNHBxsAmoSEybygIQ5BSwlji6aAzaTRUBVYsm2U1BjFCQmz//O DGFrSyxb+JoZYqSVROuzb2AjhQQsJJ49O8gKMlJEwFBi/TRnEFNCQFbi61Y5iCu/skqc/SE3 gVFoFpLbZiG5bRaSBQsYmVcxCuUmZuboZuaZ6iUWFOSk6iXn525iBAXvdDvhHYynV1kdYhTg YFTi4V241zZUiDWxrLgy9xCjNAeLkjjvkkC7UCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M tZ2e5mvu2ZxyeszgfDN/pc1tyeCtbNXsrl8ZX07YsqpFurXlyD3RSZ9Sp0+R6z/PonnlFdvy G127ZfhORDq1+XyTs31xlf3xivWCwiWROer/D5xImCX97E7eF+EXvqFM09RXHLm9iMOtn2VJ Tol6qZLf8jmLHA69vDX/2SmR4IWrVJ7+PxDMosRSnJFoqMVcVJwIAATNlv0/AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUiOPWxrW7rLrtQg/VvjSx6Nj1hs3h1+RWb A5PHjE/zWTzub2pkDmCK4rJJSc3JLEst0rdL4MqYu3QWU8Ez0YrXx+6wNTCuE+xi5OSQEDCR eNJ0jB3CFpO4cG89WxcjF4eQwFQmicv/V7OCJJgFtCRu/HvJBGLzCuhJPHr6GKxBWEBJ4uWG w4xdjBwcbAJqEhMm8oCEOQUsJY4umsMIYrMIqEos2XYKaoyCxOT535khbG2JZQtfM0OMtJJo ffYNbKSQgIXEs2cHWUFGiggYSqyf5gxiSgjISnzdKjeBkX8WkntmIblnFpKhCxiZVzEKFKXm JFaa6CUWFOSk6iXn525iBIVbQ2H4DsZ/y6wOMQpwMCrx8BZMtg0VYk0sK67MPcQowcGsJMJ7 aotdqBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeZxUWoUIC6YklqdmpqQWpRTBZJg5OqQZGmes8 x91mbdNik1rNGsFtZhisE+J7/ufZrcc098279KbCeMZdl09x7g3rJ6by8z7cajDr89ylZ8NP TNaPjo8XbezN+f60+rjosZdeE69f99KpO8nJNttkvjZnaeP0ZHWxhaI8Loqm0ZXzZMPFVj4r zPzwssfW4MVvtbSGtTZzzRMnnuEsWpevxFKckWioxVxUnAgASWGHXDMCAAA= 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:37:21 -0000 On Apr 27, 2015, at 3:12 PM, Ronald F. Guilmette = wrote: > In message ,=20 > Charles Swiger wrote: >> On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette = wrote: >>> ... >>> 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.) >>=20 >> You need to be able to distinguish normal dup packets >=20 > Yes. >=20 > 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. Typically. But you can also have multipath transit where one path has a = different MTU than the other: a packet can get dup'ed and have one copy then get = fragmented when flowing through that different route. (Simply firing up your companies' VPN can be enough to cause such a = situation.) > 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. Yes. One can also go to town with mechanisms like having the inner = protocol checksum be invalid-- TSO hardware will tend to drop the packet with = very little visibility. > 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). It's much harder to tell whether that happens legitimately, is due to a = bug with the network stack, TSO, etc or is someone playing games with a = covert channel. >> For that matter, an attacker could try to spoof >> legit connections and your countermeasure would presumably zap the = legit >> connection. >=20 > Doesn't that reduce down to essentially the problem of guessing TCP=20 > sequence numbers? You have to guess or be able to observe the TCP connection tuple, IPID, = TCP sequence #. > 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. It's trivial if you can observe the traffic flowing past in transit. It's also fairly easy to guess if you know most or all of the connection = tuple info and the host is using a typical global linear IPID generation method, = because you only have to guess a sequence # within the open window. Regards, --=20 -Chuck