From owner-freebsd-security Wed Jun 21 14:47:50 2000 Delivered-To: freebsd-security@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with SMTP id A8FE137C098 for ; Wed, 21 Jun 2000 14:47:46 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 61510 invoked by uid 1000); 21 Jun 2000 21:47:45 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Jun 2000 21:47:45 -0000 Date: Wed, 21 Jun 2000 16:47:45 -0500 (CDT) From: Mike Silbersack To: Brett Glass Cc: Maksimov Maksim , freebsd-security@FreeBSD.ORG Subject: Re: How defend from stream2.c attack? In-Reply-To: <4.3.2.7.2.20000621125756.048b6d80@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 21 Jun 2000, Brett Glass wrote: > At 10:15 AM 6/21/2000, Mike Silbersack wrote: > > >Is ICMP_BANDLIM enabled? If so, crank net.inet.icmp.icmplim down to 20 or > >so, and you should be just as protected as if enabling the restrict RST > >option. > > If it's an ACK flood, limiting RSTs is important because the response to > an unexpected ACK is normally supposed to be a RST, not an ICMP packet. ICMP_BANDLIM isn't a totally correct name, actually. It currently causes ICMP unreachables _and_ RST packets to be rate limited. > The various "stream.c" exploits cause ICMP floods as well, but this is > a secondary effect. > > The ICMP packets are triggered when RSTs from the attacked host(s) hit the > upstream router and the spoofed addresses are detected. If there are fewer > (or no) RSTs, there will not be an ICMP flood. > > It's a good idea to turn on ICMP bandwitdh limiting, RST restriction, and > SYN+FIN dropping in your kernel configuration and rc.conf. Given that ICMP_BANDLIM rate limits RST, it's probably better to turn on ICMP_BANDLIM and set the threshold to something in the sub-50 range. I guess if you're not using T/TCP (which I doubt anyone is anyway), turning on syn+fin dropping isn't a bad idea either. However, I'm still puzzled by the original poster's problem; from the results matt/others posted when the other stream related fixes were applied, I was under the impression that you'd still be more than OK with the default setting of 200. I don't think a freeze should result. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message