Re: Logging TCP anomalies
On Mon, Apr 27, 2015 at 03:12:43PM -0700, Ronald F. Guilmette wrote: > > In message , > Charles Swiger wrote: > > >On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette > >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). ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Logging TCP anomalies
On Tue, April 28, 2015 01:12, Ronald F. Guilmette wrote: > > In message , > Charles Swiger wrote: > >>On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette >>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 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Logging TCP anomalies
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 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org > " > ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Logging TCP anomalies
"Ronald F. Guilmette" writes: > In message <44a8xte4i0@lowell-desk.lan>, > Lowell Gilbert wrote: > >>"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... > > It would surely be enlightening for me if you could elaborate on that > statement a bit. > > As I understand it, the problem is that two TCP packets, both having the > same sequence number, but with different lengths/content arrive at one > endpoint or the other of an established TCP connection within some > relatively brief period of time. (One of them is legit and the other, > fradulent.) > > Hypothetically, if for example, the FreeBSD TCP stack were to maintain, > for each TCP connection, a record of the sequence number of _just_ the > most recently received and accepted packet (32 bits), and also the length > of that same most-recently-received-and-accepted packet... let's just > say for convenience another 32 bits... then if the next subsequent > packet which arrives to that same socket endpoint contains (a) the > exact same sequence number as the immediately prior one, but also (b) > a different length, then could that packet not be then judged to be > indicative of a clear attempt at chicanery? Unfortunately not. Duplicated packets will (in most cases, but not all) have the same length as each other, but the sliding window can easily mean that a retransmission will include more data than the original. And on the other side, I'm concerned that you're actually making an *easier* attack possible by possibly dumping a connection based on what could be a lucky guess. Detecting these anomalies is something that most (all, I think, but I'm not motivated enough to check) stateful firewalls will be able to detect. And it's a good idea; even if the extra packets are happening for benign reasons, having a lot of them represents a bug somewhere in your network path, consuming extra network resources. > Please note that what I just described above requires only two additional > 32 bit words per TCP connection and only two additional 32-bit integer > comparisons operations per packet. Neither the amount of increased > memory nor the amount of incresed computation seem to me as being > particularly egregious, given the potential benefit of possibly catching > out this kind of funny business, when and if it occurs. In a forwarding path, you'd still see a measurable performance hit. And it's depending on a very specific set of symptoms that as far as I've been able to imagine, can only be produced by a attacker who would also be able to use the same resources for a variety of other attacks. And the attacker is already able to read some of your traffic *without* interfering with it. Strong encryption, applied at multiple levels, is the only reasonable engineering approach to issues like this. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: base/release/10.1.0/contrib/file vulnerabilities?
On Mon, Apr 27, 2015, at 03:34, Piotr Kubaj wrote: > Hi, > > I wrote about this vulnerability in January: > https://lists.freebsd.org/pipermail/freebsd-security/2015-January/008115.html > > There were only patches for stable. > There is an open PR as well https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198912 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
