I just now read the following TheRegister news article about detection of "Quantum Insert" funny business: http://www.theregister.co.uk/2015/04/23/detecting_nsa_style_hacking_tool_unsheathed/ 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.)
"Ronald F. Guilmette" <rfg at tristatelogic.com> 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.
On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette <rfg at tristatelogic.com> 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, -- -Chuck
Snort (and brethren) at the perimeter seem like a reasonable approach. http://seclists.org/snort/2015/q2/114 But, more likely to succeed will be SSL everywhere, and certificate pinning, since this is primarily a web-based attack: http://www.wired.com/2015/04/researchers-uncover-method-detect-nsa-quantum-insert-hacks/ Kurt On Mon, Apr 27, 2015 at 11:37 AM, Ronald F. Guilmette <rfg at tristatelogic.com> wrote:> > I just now read the following TheRegister news article about detection > of "Quantum Insert" funny business: > > > http://www.theregister.co.uk/2015/04/23/detecting_nsa_style_hacking_tool_unsheathed/ > > 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.) > _______________________________________________ > freebsd-security at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org > " >