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 -- On Sat, Jul 19, 1997 at 05:07:48PM -0500, Edward Henigin said:
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.
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.
This is a _very_ bad assumption, with a nasty effect on perfectly valid traffic. Now that bridging (ala switching) is popular again, there are enormous numbers of supernetted class C networks out there. I can think of 10 sites right now, without thinking hard. I'm sure I could find another 100 without too much work. And that's just the sites I know of personally!! This simply doesn't work as a mechanism. There are only two solutions: 1. Disable ping reply to your hosts (annoys some people, but prevents this attacks..) 2. Disable packets to broadcast addresses on the SOURCE networks. This is the only reliable solution, since only the local admin knows what the nets are. ( Unfortunately, cisco router filters are perfectly blind to this sort of attack. You need two or three filters for each one ...)
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,
Yes! -- Joe Rhett Systems Engineer JRhett@ISite.Net ISite Services PGP keys and contact information: http://www.navigist.com/Staff/JRhett
On Sat, Jul 19, 1997 at 09:11:28PM -0700, Joe Rhett said:
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,
Yes!
I was just told that the interface command "no ip direct-broadcast" may be what I was asking for.. Ed
Edward Henigin wrote:
On Sat, Jul 19, 1997 at 09:11:28PM -0700, Joe Rhett said:
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,
Yes!
I was just told that the interface command "no ip direct-broadcast" may be what I was asking for..
At least on our (OpenROUTE Networks/Proteon) routers and those based on our code, you can control whether the router will forward packets which are directed broadcasts. For example, do you allow a packet addressed to 192.168.123.255 to travel to your network from a distance, and then be broadcast on a LAN medium that is used for the 192.168.123.0 subnet? Directed broadcasts can be useful within a company's internal network, but is not a good thing to allow on a border router. The original question, though, was about the source address. This could be addressed with filters, or with the addition of extra options. In our routers, filters could be constructed for this relatively easily. (I can't tell you about cisco product, though. I suspect they have many similar features).
Ed
-- ------------------------------------------------------- Daniel Senie dts@openroute.com OpenROUTE Networks, Inc. http://www.openroute.com/ 508-898-2800
participants (3)
-
Daniel Senie -
Edward Henigin -
Joe Rhett