[22585] in North American Network Operators' Group
Re: Solution: Re: Huge smurf attack
daemon@ATHENA.MIT.EDU (Craig A. Huegen)
Tue Jan 12 15:00:06 1999
Date: Tue, 12 Jan 1999 11:01:04 -0800
From: "Craig A. Huegen" <chuegen@quadrunner.com>
To: Steve Gibbard <scg@wwnet.net>, danderson@lycos.com
Cc: nanog@merit.edu
In-Reply-To: <Pine.LNX.3.93.990112130648.31220O-100000@rootbeer.wwnet.net>; from Steve Gibbard on Tue, Jan 12, 1999 at 01:11:09PM -0500
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
