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
Devin Anderson
Network Engineer
Lycos, Inc.
Brandon Ross <bross@mindspring.net> on 01/12/99 02:05:02 AM
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
That breaks path MTU discovery (see RFC 1435 for more info on that), among
other things.
-Steve
==>
==>> 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