Home page logo
/

nanog logo nanog mailing list archives

Re: SMURF amplifier block list - READ THIS
From: Karl Denninger <karl () mcs net>
Date: Tue, 14 Apr 1998 17:22:42 -0500

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault