I should have been more careful when stating 'filtering icmp' in my previous messages. I use something similar to this:
access-list 101 deny icmp any any echo access-list 101 deny icmp any any echo-reply access-list 101 permit icmp any any
Only I'm allowing the echo-reply so I can ping/traceroute out for my troubleshooting needs. However, I don't buy the 'it breaks testing methods' because there are other ways to test that using icmp for incoming stuff. Plus, if you use named access lists (in new code releases), you can throw in a permit statement then delete it without taking out the whole list. (That is done with the 'ip access-list extended <name>' subset- very nice, check it out) Of course this doesn't do anything for your upstream links, but what can you do about that anyway? Get on your tier 1 provider for that! Plus, you STILL have directed broadcasts turned off in my scenario so the access list is almost futile. And if you are worried about excess CPU utilization, so what? Look into stuff like the netflow switching commands rather than the optimal setting. That can make a tremendous difference. Or you can always buy better gear! How important is your service?? later- devin "Craig A. Huegen" <chuegen@quadrunner.com> on 01/12/99 02:01:04 PM To: Steve Gibbard <scg@wwnet.net>, Devin Anderson/Lycos cc: nanog@merit.edu Subject: Re: Solution: Re: Huge smurf attack 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
On Tue, 12 Jan 1999 danderson@lycos.com wrote:
Only I'm allowing the echo-reply so I can ping/traceroute out for my troubleshooting needs. However, I don't buy the 'it breaks testing methods' because there are other ways to test that using icmp for incoming stuff.
Yes, but, do you have any idea how many tech support calls would be generated by our customers complaining that they can't ping or be pinged? Our service is advertised as unrestricted Internet access. Our customers rightfully expect to be able to ping out as well as be pinged. If we blocked all echo throughout our network, we would be completed flooded with technical support calls. Doing something like this, similar to the serveral suggestions to filter all .0 and .255 addresses, is an attempt to fix the symptom instead of the real problem.
Plus, you STILL have directed broadcasts turned off in my scenario so the access list is almost futile.
Of course. 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.
:: Brandon Ross writes ::
Doing something like this, similar to the serveral suggestions to filter all .0 and .255 addresses, is an attempt to fix the symptom instead of the real problem.
So is forcing vendors to make the equivalent of "no ip directed-broadcast" the default. The problem is that dolts configure routers. The symptom is "ip directed-broadcast" is configured (or not unconfigured) where is shouldn't be. (For the record, I agree with you on blocking ICMPs and blocking .0/.255 ... both are bad ideas. But so is forcing vendors to violate the router requirements RFC. If we (the internet community) want directed broadcasts to be dropped by default, we should get off our collective duffs and change the RFC.) - Brett (brettf@netcom.com) ------------------------------------------------------------------------------ ... Coming soon to a | Brett Frankenberger .sig near you ... a Humorous Quote ... | brettf@netcom.com
Brett Frankenberger wrote:
:: Brandon Ross writes ::
Doing something like this, similar to the serveral suggestions to filter all .0 and .255 addresses, is an attempt to fix the symptom instead of the real problem.
So is forcing vendors to make the equivalent of "no ip directed-broadcast" the default. The problem is that dolts configure routers. The symptom is "ip directed-broadcast" is configured (or not unconfigured) where is shouldn't be.
Actually, several vendors came to the conclusion they should change the default on their own... But, as customers of the router and networking equipment vendors, the choice IS ultimately yours. If you have specific needs, then ask for them. If you feel that routers which can filter RFC1918 addresses at your peering points, at wire speed without croaking is important to you and your neighbor ISPs, then ask for it. Such things CAN be built, if someone expresses a desire to buy.
(For the record, I agree with you on blocking ICMPs and blocking .0/.255 ... both are bad ideas. But so is forcing vendors to violate the router requirements RFC. If we (the internet community) want directed broadcasts to be dropped by default, we should get off our collective duffs and change the RFC.)
On the subject of changing the RFC, I had been thinking about submitting a draft on this subject for a while, and did submit one yesterday. See <draft-senie-directed-broadcast-00.txt> on your favorite document mirror site. I guess that qualifies as getting off my duff. Please read the document and send me comments. Dan -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
participants (4)
-
Brandon Ross -
Brett Frankenberger -
danderson＠lycos.com -
Daniel Senie