[22618] in North American Network Operators' Group
Re: Solution: Re: Huge smurf attack
daemon@ATHENA.MIT.EDU (danderson@lycos.com)
Tue Jan 12 17:43:28 1999
From: danderson@lycos.com
Old-To: "Craig A. Huegen" <chuegen@quadrunner.com>
cc: Steve Gibbard <scg@wwnet.net>, nanog@merit.edu
Date: Tue, 12 Jan 1999 16:35:56 -0500
To: boblevy@ix.netcom.com
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
