North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: SMURF amplifier block list - READ THIS
- From: Karl Denninger
- Date: Tue Apr 14 18:24:41 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: 220.127.116.11 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
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 18.104.22.168 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
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 Sprunk "Oops." Email: firstname.lastname@example.org
> Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W