From owner-freebsd-security Fri Jan 21 15:44:37 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 1CEE115820 for ; Fri, 21 Jan 2000 15:44:32 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id QAA25777; Fri, 21 Jan 2000 16:44:08 -0700 (MST) Message-Id: <4.2.2.20000121163937.01a51dc0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 16:44:06 -0700 To: Matthew Dillon , Warner Losh From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Darren Reed , security@FreeBSD.ORG In-Reply-To: <200001212321.PAA64674@apollo.backplane.com> References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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