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: 18.104.22.168 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 22.214.171.124 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.