IP flooding by using broadcast address

We're seeing a pernicious sort of DOS attack lately. The
attack takes advantage of hosts IP stack implementation, and how it
deals with ICMP packets to the broadcast address. Basically, the short
and sweet of it is that most hosts will respond to an echo-request to
its broadcast address with an echo reply.

  So imagine this scenario: some disgruntled hax0r forges his
source address to be your web server (or shell server, or irc server,
or whatever) and sends some broadcast pings to a well populated remote
network. His/her ping will be amplified by the number of hosts on the
remote network.

  Here is an example to illustrate:

  In one window, I did this:

(ed) spanky:~$ ping 205.236.175.255
205.236.175.255 is alive
(ed) spanky:~$

  In another, this:

(root) spanky:~# snoop -d isptp0 proto icmp
Using device /dev/isptp (promiscuous mode)
spanky -> 205.236.175.255 ICMP Echo request
toolbox.total.net -> spanky ICMP Echo reply
falcon.total.net -> spanky ICMP Echo reply
annex-08.mtl.total.net -> spanky ICMP Echo reply
199.166.230.99 -> spanky ICMP Echo reply
     gig.net -> spanky ICMP Echo reply
205.236.53.122 -> spanky ICMP Echo reply
middletown.total.net -> spanky ICMP Echo reply
205.236.53.199 -> spanky ICMP Echo reply
server95.total.net -> spanky ICMP Echo reply
205.236.175.20 -> spanky ICMP Echo reply
freddy.total.net -> spanky ICMP Echo reply
205.205.162.10 -> spanky ICMP Echo reply
tors.accent.net -> spanky ICMP Echo reply
lightning.total.net -> spanky ICMP Echo reply
c4700-01.mtl.total.net -> spanky ICMP Echo reply
as5200-35.mtl.total.net -> spanky ICMP Echo reply
newsfeeder.total.net -> spanky ICMP Echo reply
annex-03.mtl.total.net -> spanky ICMP Echo reply
annex-02.mtl.total.net -> spanky ICMP Echo reply
as5200-31.mtl.total.net -> spanky ICMP Echo reply
as5200-30.mtl.total.net -> spanky ICMP Echo reply
phoenix.total.net -> spanky ICMP Echo reply
bretweir.total.net -> spanky ICMP Echo reply
205.236.175.10 -> spanky ICMP Echo reply
wacky.total.net -> spanky ICMP Echo reply
205.236.87.200 -> spanky ICMP Echo reply
annex-01.mtl.total.net -> spanky ICMP Echo reply
annex-10.mtl.total.net -> spanky ICMP Echo reply
as5200-06.mtl.total.net -> spanky ICMP Echo reply
as5200-33.mtl.total.net -> spanky ICMP Echo reply
as5200-13.mtl.total.net -> spanky ICMP Echo reply
as5200-34.mtl.total.net -> spanky ICMP Echo reply
annex-09.mtl.total.net -> spanky ICMP Echo reply
as5200-28.mtl.total.net -> spanky ICMP Echo reply
annex-06.mtl.total.net -> spanky ICMP Echo reply
as5200-08.mtl.total.net -> spanky ICMP Echo reply
as5200-22.mtl.total.net -> spanky ICMP Echo reply
as5200-36.mtl.total.net -> spanky ICMP Echo reply
as5200-03.mtl.total.net -> spanky ICMP Echo reply
cradlerock.total.net -> spanky ICMP Echo reply
as5200-26.mtl.total.net -> spanky ICMP Echo reply
as5200-37.mtl.total.net -> spanky ICMP Echo reply
c4700-02.mtl.total.net -> spanky ICMP Echo reply
www.greernet.com -> spanky ICMP Echo reply
199.166.230.69 -> spanky ICMP Echo reply
ns2.accent.net -> spanky ICMP Echo reply
rizzo.infobahnos.com -> spanky ICMP Echo reply
www.webquebec.com -> spanky ICMP Echo reply
annex-07.mtl.total.net -> spanky ICMP Echo reply
as5200-12.mtl.total.net -> spanky ICMP Echo reply
as5200-32.mtl.total.net -> spanky ICMP Echo reply
as5200-19.mtl.total.net -> spanky ICMP Echo reply
as5200-02.mtl.total.net -> spanky ICMP Echo reply
as5200-29.mtl.total.net -> spanky ICMP Echo reply
as5200-11.mtl.total.net -> spanky ICMP Echo reply
as5200-20.mtl.total.net -> spanky ICMP Echo reply
as5200-10.mtl.total.net -> spanky ICMP Echo reply
as5200-21.mtl.total.net -> spanky ICMP Echo reply
as5200-16.mtl.total.net -> spanky ICMP Echo reply
as5200-15.mtl.total.net -> spanky ICMP Echo reply
as5200-05.mtl.total.net -> spanky ICMP Echo reply
as5200-01.mtl.total.net -> spanky ICMP Echo reply
irc.total.net -> spanky ICMP Echo reply
as5200-25.mtl.total.net -> spanky ICMP Echo reply
as5200-04.mtl.total.net -> spanky ICMP Echo reply
squid.total.net -> spanky ICMP Echo reply
205.236.175.12 -> spanky ICMP Echo reply
as5200-14.mtl.total.net -> spanky ICMP Echo reply
pico.total.net -> spanky ICMP Echo reply
c4700-03.mtl.total.net -> spanky ICMP Echo reply
nic2.total.net -> spanky ICMP Echo reply
under.total.net -> spanky ICMP Echo reply
annex-04.mtl.total.net -> spanky ICMP Echo reply
198.168.57.42 -> spanky ICMP Echo reply
as5200-09.mtl.total.net -> spanky ICMP Echo reply
as5200-24.mtl.total.net -> spanky ICMP Echo reply
as5200-27.mtl.total.net -> spanky ICMP Echo reply
as5200-23.mtl.total.net -> spanky ICMP Echo reply
as5200-17.mtl.total.net -> spanky ICMP Echo reply
as5200-18.mtl.total.net -> spanky ICMP Echo reply
as5200-07.mtl.total.net -> spanky ICMP Echo reply

  (I've already been in contact with Total Access Inc, and they
were most cooperative in putting filters on their networks to prevent
this from happening again.)

  In the above example, you see that a single echo request
resulted in 81 echo replies, an 81x amplification of Internet traffic.
A 28.8Kbps Internet connection becomes 2332.8Kbps, about a T1 and a
half, worth of bandwidth, when amplified 81 times. You well know that
this much traffic is more than enough to peg a small ISP. If one of
these fiends either a) enlists the help of a few friends, all on 28.8
connections, or b) does this sort of thing from an open box on a higher
speed university connection, well, they can take down even larger
ISP's.

  What you need to do is put filters on your routers to prevent
broadcast packets from entering your network.

  I believe that some networks, like Total Access Inc's, are
among a list of "known" networks that can be used as part of a
"portfolio", if you will, of networks that can be used to attack other
networks.

  Everyone needs to be doing the following:

  1) Keep measured traffic stats, and look at them, using
     something like MRTG.

  2) Filter all broadcast traffic from coming into your network.
     I believe that it's QUITE rare to have an application that
     is both *routed* and uses the broadcast address. This is
     made harder when you VLSM, but I belive the majority of
     networks are provisioned on an 8 bit boundary, so you can
     filter 90% of the traffic by filtering to the .255 address.

  3) Re-iterating what people have said before, filter outbound
     traffic to allow only *your* host traffic from getting out.
     This makes you a responsible Internet citizen, by preventing
     people from using your network to launch attacks such as
     this against others.

  I think it would be very wise of cisco to have a global flag
(or at least, a per-interface flag) which would prevent the forwarding
of a packet to an all-ones address. If cisco won't add this feature,
maybe Ascend will in their GRF, and maybe a few more GRF's will be sold
because of it.

  Thank you for your time.

  Edward Henigin
  Engineering Director, Texas Networking, Inc.
  ed@texas.net
  (512) 427-1655

  Alternate POC's for Texas.Net:
  Michael Douglass Senior Systems Engineer mikedoug@texas.net
  Bill Bradford Systems Administrator mrbill@texas.net
  Jonah Yokubaitis President barron@texas.net

before my mailbox gets spammed by all of y'all, I'd like to
publicly apologize for my "cisco bashing." cisco makes a fine product
that I recommend in most situations.

  I'd still like to know that cisco listens to little guys like
me, tho.

  Also, I need to point out that my recommendations of filtering
the broadcast address are targeted towards leaf networks, rather than
transit networks.

  Ed