Date: Tue, 28 Apr 2015 09:37:23 +0300 From: "Nerijus Krukauskas" <nk@nk99.org> To: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies Message-ID: <e1eaa7becabd4831664f3a222b61473e.squirrel@localhost> In-Reply-To: <44814.1430172763@server1.tristatelogic.com> References: <44814.1430172763@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, April 28, 2015 01:12, Ronald F. Guilmette wrote: > > In message <A83FB715-936E-4A43-AE2D-E76C32D0F7DE@mac.com>, > Charles Swiger <cswiger@mac.com> wrote: > >>On Apr 27, 2015, at 11:37 AM, Ronald F. Guilmette <rfg@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e1eaa7becabd4831664f3a222b61473e.squirrel>