SMURF amplifier block list - READ THIS

Karl Denninger karl at mcs.net
Tue Apr 14 22:22:42 UTC 1998


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 at 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 at paranet.com
> Sprint Paranet        -Albert Einstein      ICBM:  33.00151N 96.82326W



More information about the NANOG mailing list