Re: Solution: Re: Huge smurf attack
I'm not sure what the big issue here is with the smurf attacks. If you set up some kind of access list that disables incoming icmp traffic, then turn directed broadcasts off on the interfaces, that's it. In most cases, you can't even get a packet into my AS unless its bound for dns machines or our website frontends. For those of you using Cisco gear, a simple 'no ip directed broadcast' in the interface subset will turn them off. In my mind, this takes care of all but two scenarios: 1. Your smurf attack is coming from someone within your organization, doing a broadcast while directly connected to the network. In this case, you should be able to get their ip address just by a snoop (at least on a sun box) and then you may processed to visit the offender with the clue-by-four. I once had someone who though that was a good way to inventory the machines on a network. 2. You are using some vendor who doesn't support any way of turning off directed broadcasts. From a statistics point of view, since Cisco has 87.5% of the market, most people won't find this to be a problem. I understand that only certain code revisions carry this ability on Bay gear (I want to say 11 or higher, but I could be wrong and I can't remember the code train). If you've got Torrent or something else, I don't' know but its a safe bet that if the feature isn't supported at all (doesn't matter if it is a default or not) this isn't equipment you want in your AS. Speaking from my standpoint, I sure wouldn't use it. Devin Anderson Network Engineer Lycos, Inc. Brandon Ross <bross@mindspring.net> on 01/12/99 02:05:02 AM To: nanog@merit.edu cc: (bcc: Devin Anderson/Lycos) Subject: Re: Solution: Re: Huge smurf attack On Mon, 11 Jan 1999, Daniel Senie wrote:
The proper answer to this is to disable directed broadcasts on the routers themselves. It'd be helpful if routers came out of the box with this feature disabled by default. Perhaps folks should talk with their router vendors of choice and ask for this change. I have submitted a draft into the IETF process to require this change, updating RFC 1812 (router requirements). I'm happy to say that progress is being made in this area. When a vendor comes to us for the first time, one of things I tell them is that we will not buy their hardware until they ship with directed broadcast disabled by default. We've had a lot of success in this area, we'd have even more if others would do the same. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
On Tue, Jan 12, 1999 at 11:39:17AM -0500, danderson@lycos.com put this into my mailbox:
I'm not sure what the big issue here is with the smurf attacks. If you set up some kind of access list that disables incoming icmp traffic, then turn directed broadcasts off on the interfaces, that's it. In most cases, you can't even get a packet into my AS unless its bound for dns machines or our website frontends. For those of you using Cisco gear, a simple 'no ip directed broadcast' in the interface subset will turn them off. In my mind, this takes care of all but two scenarios:
Unfortunately, things aren't quite that easy. You can't filter on your side unless you have ATM links up the wazoo; the smurf still occupies your incoming link. And many ISPs (uplinks) don't want to add filters on their side, because of load on the router or something similar. Even if that were the case, smurf attacks are getting so powerful that even a large ISP is getting to be affected. A 200Mb+ smurf can take out, or at least seriously hamper activity at the POPs of even large ISPs. I agree that something like Cisco's CAR and blocking ICMP would help. But when smurfer-wankerboy finds that he can't take out your network with a small 15Mb smurf, he'll just find 10 of his skriptkiddie friends and get them to join him, and take out your uplink with a 150-200Mb smurf. Filtering on the victim side is unfortunately not the answer. Fixing the broadcast addresses, unfortunately, is. -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) "Hanging is too good for a man who makes Founder, the DALnet IRC Network puns; he should be drawn and quoted." e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/
On Tue, 12 Jan 1999 danderson@lycos.com wrote:
I'm not sure what the big issue here is with the smurf attacks. If you set up some kind of access list that disables incoming icmp traffic, then turn
That breaks path MTU discovery (see RFC 1435 for more info on that), among other things. -Steve -- Steve Gibbard WWNet System Administration +1 734 513-7707 x 2009 http://www.wwnet.net
On Tue, Jan 12, 1999 at 01:11:09PM -0500, Steve Gibbard wrote: ==>On Tue, 12 Jan 1999 danderson@lycos.com wrote: ==> ==>> I'm not sure what the big issue here is with the smurf attacks. If you set ==>> up some kind of access list that disables incoming icmp traffic, then turn ==> ==>That breaks path MTU discovery (see RFC 1435 for more info on that), among ==>other things. Two choices: access-list 101 deny icmp any any echo access-list 101 deny icmp any any echo-reply access-list 101 permit icmp any any -or- access-list 101 permit icmp any any packet-too-big access-list 101 deny icmp any any Neither of these is a particularly elegant solution because they block troubleshooting tools such as ping and traceroute. CAR works well to provide these troubleshooting services during normal operations and to help suppress attacks. /cah
participants (4)
-
Craig A. Huegen
-
Dalvenjah FoxFire
-
danderson@lycos.com
-
Steve Gibbard