Solution: Re: Huge smurf attack
danderson at lycos.com
danderson at lycos.com
Tue Jan 12 21:35:56 UTC 1999
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
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??
"Craig A. Huegen" <chuegen at quadrunner.com> on 01/12/99 02:01:04 PM
To: Steve Gibbard <scg at wwnet.net>, Devin Anderson/Lycos
cc: nanog at 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 at lycos.com wrote:
==>> I'm not sure what the big issue here is with the smurf attacks. If you
==>> up some kind of access list that disables incoming icmp traffic, then
==>That breaks path MTU discovery (see RFC 1435 for more info on that),
access-list 101 deny icmp any any echo
access-list 101 deny icmp any any echo-reply
access-list 101 permit icmp any any
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.
More information about the NANOG