Uh, folks, blocking the broadcast address will NOT help you in the case of a smurf POUNDING ON YOU. It will ONLY prevent your customers launching a smurf against someone ELSE. A FAR more effective means of doing THAT is to prohibit source address forgery on your connections. What a smurf does is this: 1) The SMURFER sends a FORGED packet to the amplifier. It is: source destination type victim-addr amplifier-broadcast ICMP ECHO Example: 192.160.127.97 xxx.yyy.zzz.255 ICMP ECHO The amplifier NETWORK ENTRANCE ROUTER, IF it accepts directed broadcasts, will route this to the broadcast address of the shared media network (ie: CSMA/CD FastEthernet). ALL the devices on that network respond to the victim's address. The reason this works is because (1) you don't need to be able to get replies back from the real source (since the source is forged anyway) and (2) the ICMP echo will be replied to (its a ping, silly). Now, what you do is use a LARGE packet size - say, 1Kb. So I send one packet over my ISDN line, and the amplifier sends 200 copies of it to the victim. I can effectively multiply the bandwidth of my 128kbps circuit 200-fold, which is TWENTY FIVE MEGABITS of bandwidth (!) Now, since I am smart, I use an ICMP ECHO with a payload of all zeros. STAC compresses this 1024-byte packet about 10:1, since its all one byte. I can now source ~90Mbps from an ISDN connection! This makes even a modem dial connection quite dangerous in that with compression and careful selection of the payload you can source ~10-20Mbps of smurf from a MODEM. A T1 connected person launching a smurf can burn down an OC-12 if they can find amplifiers with enough outbound capacity. Now, what are the problems for the person trying to prevent this from melting their network and/or their customers? 1. If you can't actually accept and process the inbound traffic, you're dead. Period. This means that a small ISP, say one connected by a couple of T1s, can't defend against a Smurf. They MUST go to their upstream provider and have THEM defend against it. 2. If you CAN accept the traffic, then you have several defenses. But some of them won't work. The ones which don't work include: a) Blocking traffic from broadcast addresses - none of the smurf traffic will be from a broadcast address. b) Blocking OUTBOUND traffic - the problem isn't outbound, 3. The only EFFECTIVE defense is to block ALL addresses within any netblock which is identified as being a smurf amplifier to ANY inbound traffic. You want to place this filter on your INBOUND links from other providers and exchanges. That is, if you peer with someone over a HSSI line, or buy transit over a HSSI line, you want the filter to be: inter h 1/0 ip access-group xxx in where the "access-group xxx" list contains things like: access-group 2 deny 128.0.0.0 0.0.255.255 ..... access-group 2 permit all DO NOT use extended access lists. They are wasteful in that they force more comparisons that are needed, and may cause you to degenerate into process switching at your borders (which will murder your CPU utilization). 4. By doing (3), you do not prevent the traffic from touching you; you will absorb it instead. To keep the traffic off you entirely, you need to have your *UPSTREAM* providers place the same filter on the OUTBOUND side of the interface that points towards your network. Good luck getting a *PEER* to do this - you might be able to get a *TRANSIT* provider to do it if you bitch loudly enough. 5. However, providing that you have the bandwidth on your interconnects and/or transit connections to absorb the smurfs without knocking you out, (3) is effective. It keeps your machines up, and it keeps your T1 and slower connected customers from being smurfed off the network. The *ONLY* long-term fix for smurfing is to prohibit directed broadcasts, so that amplification of the attack cannot be done. The only means available for prohibiting anything on the Internet is "shunning", much as it is with spammers. Therefore, the only way to force people to correctly configure their routers so smurfs won't work is to snub them and implement (3), either in your network or at your upstream connection's network. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost On Tue, Apr 14, 1998 at 04:37:20PM -0500, Stephen Sprunk wrote:
Aaron Beck wrote:
Im kind of under the impression that we're (ok, just me, but anyone else is welcome to jump on this bandwagon) trying to point out that class based thinking.. or even "well, most of the net is this" thinking is probably a bad idea.
The fact is that a /24 is far more dangerous as a smurf amplifier than a /30. Simple math tells you that there's 127 times as many possible hosts hitting you.
Kludges n' hacks may work most of the time, but kludges and hacks are just that.. kludgey and hackish. Hard coded defines, precompiled bins, etc have proven to be a less elegant method in other areas of the computing world... why should we repeat the same kind of mistake in the networking field?
Who suggested putting a x.x.x.255 filter into IOS itself? An access-list in a config is hardly hard-coding.
A smurf attack is just that, a smurf attack. Wouldnt the overall goal include removing the attack possibility in its entirety, not just a temporary solution that may solve some of the problems, but definetly not all of them?
If you have a suggestion for "removing the attack possibility in its entirety," please tell us. So far, nobody's come up with one.
In the meantime, I'd rather solve 99% of the problem and deal with the remaining 1% than sit around arguing about "class based thinking" and "stereotypical ideologies" in between smurf attacks.
Assuming that most of the net is based on /24s, and that smaller subnets are generally internal to those /24's may be a safe assumption, but once again its probably not the best way to think about this problem (not that I have any hints on what the best way should be, but im fairly certain that applying a stereotypical ideology to this is "not a good thing").
Look at the list of IP addresses used in any smurf attack, and they will almost always be class C or class B broadcast addresses, usually the address of a NAP or well-connected ISP. There's no sense targeting a solution for a problem which doesn't exist. Solve the general case and buy time for the more specialized ones.
just my two bits and a lot of run on sentences.
Stephen
-- Stephen Sprunk "Oops." Email: sprunk@paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W