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!
Tell a friend.. If you sell routers to clients and/or you
configure them, include that in your default configuration.
Encourage people to filter inbound ICMP where possible..
Do whatever it takes to work with your customer/peers to
put a stop to this kind of abuse. Of all the attacks to date,
this (and the recent land.c which is a different issue together)
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.
</SoapBox>
We thank you for your support..
[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
I suggest finding the source networks (MCI has published such a tool) and
dropping their BGP sessions until they deal with the problem.
There is one national network in particular that IMHO doesn't give a damn
about this, and has turned their head the other way MULTIPLE times when we
have attempted to track this down.
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
==>* Filtering ALL ICMP is pretty silly, ICMP is there for more than just
==> pings, and some of it is important.
I believe he only said he was filtering ICMP echo replies.
==>* 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.
People have been sending spoofed floods for ages. The problem is that
with a spoofed flood, you must have the bandwidth to send it from.
"smurf" multiplies traffic--a half a T1, pointed at 2 different
co-location networks of a total of 180 hosts, can generate 67.5 Mbit/sec
of traffic!
See http://www.quadrunner.com/~chuegen/smurf.html for technical
information on the attack. Jake Khuon graciously converted my slide
presentation into a webbified form at
http://www.rsng.net/presentations/nanog11/smurf/index.html
==>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?
One side note which is cued in perfectly by this is that netflow exports
(or even "show ip cache flow") will show you all the hosts that are
sending ICMP echo replies if you're being smurfed. One provider I know of
has a script which parses the netflow output, sorts it, and then sends it
to the NOC staff which is then responsible for mailing a form letter with
smurf attack information to the InterNIC contact for that network.
/cah
[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.
Sure.. but it wont take a genius on the attackers side to figure out what
types arent being blocked, and use those..
* 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.
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
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..
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: