COMMAND
ICMP
SYSTEMS AFFECTED
Most systems
PROBLEM
Following text is in great part Edward Henigin's baby (credit
goes to him). It is about a pernicious sort of DOS attack used
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
[Total Access Inc were already contacted, and they have put
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.
SOLUTION
What you need to do is put filters on your routers to prevent
broadcast packets from entering your network.
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, and makes
it harder for people to launch attacks like this one.
If your network is composed *only* of /24 allocations (ie you're
not supernetting or subnetting anywhere on class C's, or all your
class A/B networks are subnetted as /24's), then you can do all
the filtering with one filter on your *inbound* Internet
interfaces (note that you should filter both the all ones and the
all zeros addresses, as they are both recognized by some IP
stacks).
! filter broadcast packets from the outside world into our network
access-list 109 deny ip any 0.0.0.255 255.255.255.0
access-list 109 deny ip any 0.0.0.0 255.255.255.0
access-list 109 permit ip any any
!
in se 0
ip access-group 109 in
!
Another way to do it is to only filter to the broadcast addresses
*outgoing* on your directly connected interfaces. For example,
if your router has an ethernet interface with half a dozen
as5200's or Max 4004's on it, and your ethernet interface had
address 192.168.3.1/24, then you'd do this:
! filter broadcast packets from anywhere into my directly attached
! terminal server network
access-list 110 deny ip any host 192.168.3.255
access-list 110 deny ip any host 192.168.3.0
access-list 110 permit ip any any
!
in e 0
ip access-group 110 out
!
There is also one command for ciscos, 'ip directed-broadcast'.
Specifically, the 'no' form of the command will no convert
broadcast packets into broadcast ethernet packets, on the final,
directly connected interface. From cisco's online documentation:
To enable the translation of directed broadcast to physical
broadcasts, use the ip directed-broadcast interface
configuration command. To disable this function, use the no
form of this command.
The real purpose of the `ip directed-broadcast' command is to
allow the filtering of server visibility and reachability (for
example, allowing departmentally-maintained BOOTP servers).
And a final note: there are very few applications which depend on
the routing of broadcast packets. You may know of one such
application; if it's a popular one that you think lots of people
are using, speak up. So you should feel safe in blocking
broadcast traffic in your network. Popular applications which
depend on *non*-routed broadcast traffic include RIP and netbios
(Microsoft's networking protocol). Putting filter access-lists
on your interfaces should not interfere with non-routed broadcast
traffic. BOOTP and DHCP are obvious applications that reply on
directed broadcast forwarding.