Jason Lixfeld said once upon a time:
Seriously.. what do you recommend? I'm totally open. I'm using deny icmp
to protect myself. I'm up to an alternative.
:> You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on
There apparently is a bit of misunderstanding when it comes to how a smurf
attack works. To understand a smurf attack you need to understand a
standard ping request.
Say we have a remote ping destination, named "target" and a originator of
the ping request named "source". In the first step of a ping request,
"source" sends an ICMP request of "echo" to "target":
"source" --- ICMP echo ---> "target"
When "target" receives the ICMP echo, it sends back an ICMP echo-reply to
"source" <--- ICMP echo-reply --- "target"
Upon reception of the "echo-reply" "source" realizes a good ping and coughs
you back the statistics on how long the whole interaction was.
With a smurf attack you have a perpetrator forging the "source" address,
which in this case could also be known as victim. The perp takes advantage
of open directed-broadcast networks to get lots of addresses responding
back to the "source" (victim) with "echo-reply". Thus the original request
looks like this:
perp (forged "source") --- ICMP echo ---> "target" (directed-broadcast)
and the reply looks like this:
"source" (victim) <==== ICMP echo-reply x "target" addresses listening to
the broadcast request for
You can easily see how the broadcast size of "target" and whether it is
open to "directed-broadcast" is the fundamental exploit in the smurf
attack. The larger the subnet, the better. However, it is also easy to
see that by blocking just "echo-reply" to certain addresses (IRC servers,
Quake servers, etc), you can at least minimize the effects of the attack.
The sad part is, the en masse echo-replies will still travel over your pipe
to get to your filter and will still consume a significant portion of your
Note, my understanding of the function of "directed-broadcast" is limited
by the fact that I've never used it in a useful function.