From owner-freebsd-security Wed Jun 21 12: 3:44 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.org (lariat.org [12.23.109.2]) by hub.freebsd.org (Postfix) with ESMTP id 4657037B6CA for ; Wed, 21 Jun 2000 12:03:38 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.org [12.23.109.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id NAA23733; Wed, 21 Jun 2000 13:03:18 -0600 (MDT) Message-Id: <4.3.2.7.2.20000621125756.048b6d80@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Jun 2000 13:03:07 -0600 To: Mike Silbersack , Maksimov Maksim From: Brett Glass Subject: Re: How defend from stream2.c attack? Cc: freebsd-security@FreeBSD.ORG In-Reply-To: References: <000401bfdb64$3eae8320$0c3214d4@dragonland.tts.tomsk.su> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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. 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. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message