To make this understood in a more clear context there are Linux users that have done exactly that and use ATM switches to lauch attacks from since they are hard to trace from IP based networks and I see it constantly in my traceroutes and some exceeed the 30 hop limit on the web pages offering traceroutes from the major players on the backbone... Henry R. Linneweh Adrian Chadd wrote:

On Fri, 5 Dec 1997, Wayne Bouchard wrote:

[snip]

...

threaten the most disruption of internet services. With ISDN and DSL, users have the bandwidth necessary to generate even more dangerous levels of traffic. If you don't think this issue affects you, it does. If you're not a target, your probably being used as a source.

I agree totally. A couple of problems:

* Filtering ALL ICMP is pretty silly, ICMP is there for more than just pings, and some of it is important. * If people start doing this, someone with a smidgen of time on their hands will write a ping flooder that uses random TCP or UDP packets with spoofed from addresses.

I'm curious however - can anyone out there running netflow or something similar give me a breakdown on what kind of ICMP traffic they're seeing?

Adrian

-- ™
¢4i1å

Adrian Chadd writes...

A couple of problems:

* Filtering ALL ICMP is pretty silly, ICMP is there for more than just pings, and some of it is important.

Such as MTU Discovery. If your customers try to go down a path where the MTU is smaller than what they are sending, and if their packets prohibit fragmentation, ICMP is the only way to inform their stack to reduce the size of the MTU. Otherwise they may failures ranging from intermittent to totality. Intermittent ones would often be seen when just a small amount of data sometimes gets through. For example, an HTTP request could be sent in a small packet, but posting a large form would not. How many tech support people would know that the ability to get a page and the inability to post a form could be caused by the customer's own ISP blocking ICMP network unreachable? So you need to leave "network unreachable" coming in. Ref: "TCP/IP Illustrated, Volume 1, The Protocols", by W. Richard Stevens See: page 340.

* If people start doing this, someone with a smidgen of time on their hands will write a ping flooder that uses random TCP or UDP packets with spoofed from addresses.

Already been done. I've had one of those for 4 years. The ultimate solution to network security was published a few months ago in the Dilbert series. -- Phil Howard | suck5it2@spammer8.edu end7it92@s0p0a2m0.com suck1it8@no6place.net phil | end3it30@no3where.edu stop7it1@dumb6ads.net ads6suck@no8where.com at | end6it68@noplace0.net die6spam@anywhere.org no1spam0@spam9mer.com milepost | no1way40@spammer0.org end2ads9@spammer2.com blow8me2@no3place.com dot | suck3it7@no62ads4.net no7spam7@noplace0.edu no7spam8@noplace1.net com | blow2me9@spammer0.com stop1659@anyplace.com crash345@lame2ads.com

On Mon, Dec 08, 1997 at 11:39:45AM -0700, Wayne Bouchard wrote:

Since so far 6 people misunderstood this, I *meant* those networks that don't need to permit it, should consider filtering inbound ICMP echo request packets. (And, hence, blocking the spoofed packet from causing an ICMP echo reply flood.)

I personally don't see why this would be preferable to just putting no ip directed-broadcast on all relavent interfaces. Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - ahp@hilander.com | Erols Internet, INC. | |Network Engineer | Springfield, VA. | +------------------------------------+--------------------------------------+

Mike Hedlund wrote:

[snip]

Well.. the main problem with smurf is that as far as i know, it uses the reply from a broadcast. that will rule out tcp unless they send a direct flow from the attackers box to the destination/victims box. For UDP, you would have to send it to a broadcast, and also hope there is a udp service listening (ie.. a test program i wrote sent 1 udp broadcast to 198.32.136.255:7 and received a whole bunch of replies.. turn off small services on routers would be helpfull.. :)). You could also do that to any network, the point being.. its easier to disable simple udp services then to setup filters on border routers..

-mike

I guess that depends upon how many border routers you have :) It would also help to filter outgoing traffic from your network to ensure you do not become the unwitting source of a smurf attack.. -- Leigh Porter

At 11:48 AM -0500 12/8/97, Karl Denninger wrote:

On Fri, Dec 05, 1997 at 10:05:13PM -0700, Wayne Bouchard wrote:

...

Okay, so I'm now blocking 45 megs of icmp echo-reply packets at my borders.. At one point, this was 80,000 packets/sec. (No, I'm not exagerating.)

<SoapBox>

For anyone who has not, PLEASE DISABLE DIRECTED BROADCASTS!

Yes. Disable directed broadcasts to your own internal networks. I suspect these are most often sent by mis-configured snmp management systems. You probably don't want them trying the manage/monitor your devices anyway. Just don't break SNMP and ICMP for remote networks. For example, we use SNMP (HP Open View) to manage and monitor our clients networks remotely. HP Open View uses pings every 5 to 15 minutes to detect if a machine is still up. It uses directed broadcasts and mask requests to detect new machines and map the remote network. When something 'host down' event happens, we automatically detect whether it's an ISP event or a customer event, and take the appropriate action. We expect intermediary ISP's to pass ICMP from our network to their network. So directed broadcasts to the customer network should be controlled by the customer's policy, even when the CPE router is managed by the ISP. (I don't know of any ISP/NSP that doesn't or won't do this).

...

Tell a friend.. If you sell routers to clients and/or you configure them, include that in your default configuration.

Yes, do that. we need more work of the simple, but expensive kind. ;-)

...

Encourage people to filter inbound ICMP where possible..

Umm. No. Don't do that. ICMP is necessary for flow control and congestion management. Not to mention traceroute and ping use echo reply, and are handy. If you have 80,000 users each doing a ping once per second, then you probably need to provision more than a t3. But only 30 t1 users need to ping -f to load up a t3. So you need to figure out who the 30 or so are, and shut them down quickly. What might be more useful is a way to detect ping floods from a specific source, and automatically send them back source quenches. That is, tell them to shut their hole, uh, pipe. Umm, program to do this? me? maybe. I'll post when/if I do it. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++