In message <A83FB715-936E-4A43-AE2D-E76C32D0F7DE at mac.com>, Charles Swiger <cswiger at mac.com> wrote:>On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette <rfg at tristatelogic.com> 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 packetsYes. 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
On Apr 27, 2015, at 3:12 PM, Ronald F. Guilmette <rfg at tristatelogic.com> wrote:> In message <A83FB715-936E-4A43-AE2D-E76C32D0F7DE at mac.com>, > Charles Swiger <cswiger at mac.com> wrote: >> On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette <rfg at tristatelogic.com> 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.) >> >> 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.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. > > Doesn't that reduce down to essentially the problem of guessing TCP > 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, -- -Chuck
On Tue, April 28, 2015 01:12, Ronald F. Guilmette wrote:> > In message <A83FB715-936E-4A43-AE2D-E76C32D0F7DE at mac.com>, > Charles Swiger <cswiger at mac.com> wrote: > >>On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette <rfg at tristatelogic.com> 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
On Mon, Apr 27, 2015 at 03:12:43PM -0700, Ronald F. Guilmette wrote:> > In message <A83FB715-936E-4A43-AE2D-E76C32D0F7DE at mac.com>, > Charles Swiger <cswiger at mac.com> wrote: > > >On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette <rfg at tristatelogic.com> 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.different lengths is legitime -- in case of sender resend-packets and reduce packet sizes (for example from differen interface with different MTU).