Date: Fri, 21 Jan 2000 16:44:06 -0700 From: Brett Glass <brett@lariat.org> To: Matthew Dillon <dillon@apollo.backplane.com>, Warner Losh <imp@village.org> Cc: Darren Reed <avalon@coombs.anu.edu.au>, security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <4.2.2.20000121163937.01a51dc0@localhost> In-Reply-To: <200001212321.PAA64674@apollo.backplane.com> References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 04:21 PM 1/21/2000 , Matthew Dillon wrote: > Yes, you can theoretically drop any packet and still adhere to the protocol, > but at the cost of odd degredation cases occuring on the remote end (such as > the remote end taking a longer amount of time figuring out that you've > rebooted). Therefore it should only be done when absolutely necessary. > > The ICMP_BANDLIM code does precisely this: It detects a potential attack > and limits the response to it. The current ICMP_BANDLIM code is limited > to two cases: > > (1) ICMP responses > (2) TCP packets sent to bad ports > > It would take perhaps ten seconds to extend the mechanism to cover other TCP > RST cases but the above two cases usually handle the vast majority of > these sorts of attacks so if this exploit code is stopped cold by ICMP_BANDLIM, > we're done. If it isn't then we spend a few seconds extending the cases > covered by ICMP_BANDLIM and we are done. I'd certainly like to see this extended to RST. We can optimize socket searching and prevent TCP from sending RSTs (or anything!) to multicast addresses at the same time. (We probably also want to block RECEIVED TCP packets from multicast addresses, as Wes suggests.) --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.2.20000121163937.01a51dc0>