Date: Mon, 27 Apr 2015 15:02:18 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-security@freebsd.org Subject: Re: Logging TCP anomalies Message-ID: <44745.1430172138@server1.tristatelogic.com> In-Reply-To: <44a8xte4i0.fsf@lowell-desk.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <44a8xte4i0.fsf@lowell-desk.lan>, Lowell Gilbert <freebsd-security-local@be-well.ilk.org> wrote: >"Ronald F. Guilmette" <rfg@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... 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? 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. Regards, rfg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44745.1430172138>