mailing list archives
Re: SMURF amplifier block list
From: "Alex P. Rudnev" <alex () Relcom EU net>
Date: Sun, 12 Apr 1998 21:41:28 +0400 (MSD)
Sorry, you don't understand.
The worst thing in the smurf attack is not the attack itself (small IP
flood, what's it? now the hackers have not really big amlifiers at their
lists), but the fact the attacker originated source is faded usially. The
best way to found the source of such attack is to trace echo-request
packets directed to one or more smurf-amplified networks.
If some (even some) network anounce _we keep on-line list of
smurf-amplified address and control all attempts to send packets to this
networks_, do you suppose hackers would work through this network? Any
attempt to send smurf cause them to be discovered and disconnected; even
if it's only anouncement, not real control, it's enougph to prevent a lot
of hackets from the such attempts.
The only way to fight against any kind of such attacks is to be sure any
intruder should be fixed and disconnected in a few minutes. If I proclaim
(anyone who attempt to break CITYLINE.RU ISP here should be killed by the
gang of big and gloomy boys) do you think anyone in Moscow attampts to
break CITYLINE? Even if he don't believe to this anouncement - but 10%
for this to be true is enougph for hacker to be stopped.
Just this case. While we are not seing every day _XXX was catched and
disconnected due to attempt to run SMURF_ you can found any new ways to
defend yourself - no matter, they discover new ways to attack you. If
they think they can be catched - it's enougph.
Remember, this intruders use small ISP as their service providers, not
huge MCI or SPRINT.
And you even don't need the full list of such amplified addresses to open
some kind of monitoring against the smurfers.
Btw, if someone cry here _I am smurfed from XX.XX.XX.XX address, what
should you do to help him? I guess you should check (by IP accounting if
you have it; by NetFlow accounting if you have it; or close you boredom
and go home if you have not any) _are you sure the echo-request
packets to this broadcast addresses are not originated from YOUR customer_.
May be, someone will maintain such lists? First, it allow to fix smurf
source by 'log' option in the CISCO list; second, it'll prefere some
If Karl will supply us the IP address of a non-critical machine in his
network then we only need one list maintained. Anyone can then add new
networks to Karl's list simply by smurfing his non-critical machine and it
will still meet his criteria of a verified atack.
Michael Dillon - Internet & ISP Consulting
http://www.memra.com - E-mail: michael () memra com
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)
Re: SMURF amplifier block list Alex P. Rudnev (Apr 12)
Re: SMURF amplifier block list jlixfeld (Apr 13)
Re: SMURF amplifier block list Karl Denninger (Apr 12)
Fixing RFC's WAS Re: SMURF amplifier block list Forrest W. Christian (Apr 13)
Re: Fixing RFC's WAS Re: SMURF amplifier block list Michael Dillon (Apr 13)
Re: Fixing RFC's WAS Re: SMURF amplifier block list Alex P. Rudnev (Apr 13)
Re: SMURF amplifier block list Forrest W. Christian (Apr 13)
Re: SMURF amplifier block list E Pluribus Linux (Apr 13)