From owner-freebsd-security Fri Jan 21 13:44:55 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 D3EDB1527D for ; Fri, 21 Jan 2000 13:44:52 -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 OAA24224; Fri, 21 Jan 2000 14:44:44 -0700 (MST) Message-Id: <4.2.2.20000121144222.025dad80@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 14:44:42 -0700 To: Keith Stevenson , freebsd-security@FreeBSD.ORG From: Brett Glass Subject: Re: Some observations on stream.c and streamnt.c In-Reply-To: <20000121162757.A7080@osaka.louisville.edu> References: <4.2.2.20000120194543.019a8d50@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:27 PM 1/21/2000 , Keith Stevenson wrote: >The ICMP_BANDLIM seemed to be the life saver. I got tons of >"icmp-response bandwidth limit" messages in my syslog, but the load didn't >climb and I was still able to provide network services from the target host. That's probably because one of the things the exploit does is to create an ICMP storm. Looks like it's triggered by the outgoing RST, which in turn is sent in response to the bogus ACK. >The machine which was running TCP_RESTRICT_RST in addition to ICMP_BANDLIM >behaved exactly like the one without TCP_RESTRICT_RST. You'll see a difference if you run with TCP_RESTRICT_RST and don't have ICMP_BANDLIM turned on. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message