From route@onyx.infonexus.com Sun Sep 15 13:32:15 1996 Received: from onyx.infonexus.com (plugHead@onyx.infonexus.com [204.162.164.220]) by suburbia.net (8.7.4/Proff-950810) with SMTP id NAA02793 for ; Sun, 15 Sep 1996 13:31:35 +1000 From: route@onyx.infonexus.com Received: (qmail-queue invoked by uid 501); 15 Sep 1996 03:34:27 -0000 Message-ID: <19960915033427.29601.qmail@onyx.infonexus.com> Subject: Re: BoS: ping flood To: lucas@wasteland.org (Synthesizer Punk) Date: Sat, 14 Sep 1996 20:34:26 -0700 (PDT) Cc: best-of-security@suburbia.net In-Reply-To: from "Synthesizer Punk" at Sep 15, 96 11:03:38 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Synthesizer Punk's thoughts were: | Ping floods are often a barrage of ICMP Echo packets, requesting the Ping floods are *always* barrages of ICMP_ECHO packets. | machine recieving them to respond, making the target host participate in | killing itself off. Now once they make it into your LAN, they're basically It's not just the fact that an ICMP_ECHO packet elicits an ICMP_ECHOREPLY packet, but the fact that the incoming datagram must be demultiplexed up the TCP/IP stack. This takes time and resources. So, even if yur kernel (or packet filter) was modified to ignore ICMP_ECHO traffic, the attack would still have a pronounced effect on the target. | I've seen people excessively pingflood networks, they just called their | connection provider (UU, Sprintlink, et et) and said "Hey, filter these ICMP | packets from this class C" or so. If the ping flood is done right, the source address will be spoofed, and random enough that blocking a single class C would be ineffectual. The only choice here is to drop all ICMP_ECHO traffic at the NAP. -- [ route@infonexus.com ] Editor, Phrack Magazine / Member, Guild Corporation the greatest trick the devil ever pulled was convincing the world he didn't exist