mailing list archives
Re: SMURF amplifier block list
From: "Alex P. Rudnev" <alex () Relcom EU net>
Date: Sat, 18 Apr 1998 23:21:02 +0400 (MSD)
During an in progress attack, you probably have to take extreme measures,
Do you remember - it's not attack against you or attack by some of your
customer's networks used as amplifier, but the attack initiated from your
own network. You never note such thing withouth some permanent
It's why we saw this 100% helpless against the SMURF's.
but they shouldn't be generally applied. No one wants to lose addresses
that *might* be a broadcast address in some possible netmask. /24 is maybe
common, but is not the only netmask. And the people who don't use it won't
want you to break their customers networks.
At 2:51 PM -0400 4/18/98, Alex P. Rudnev wrote:
I am talking about boths blocking exterior smurfers from usage your
networks as amplifier, and blocking your smurfers from sending such
packets by your network. Second task allow you to cutch any smurfer in
your own network in a 5 minutes.
Just now the only thing big ISP can do in case of SMURF is to block
ECHO_REPLY packets to some attacked networks; it results from preventing
any PING tests from this networks. Why don't sacrify some addresses
(*.255, really) from be pinged at all, but save your from be the source
or amplifier of the SMURF?
And then, if you should not block by 'log' such packets you'll have the
log records about your own smurfers withouth loosing any ICMP
capabilities at all.
Plain Aviation, Inc dean () av8 com
We Make IT Fly! (617)242-3091 x246
Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)