On Thu, 16 Apr 1998, Alex P. Rudnev wrote:
We are seing long SMURF attack against the address 193.124.51.206. I ask everyone who read this list and can check traffic over his network to check if he see ICMP packets FROM 193.124.51.206 (SRC address) TO 129.72/16, 129.74/16 etc...
Don't let those North Americans bully a poor Russian network operator, Really, we are not poor operator (this crazy hacker could not waist a valuable part of our E3 bandwidth); but I am tired to see this useless attempts once a week, and I think any crime should be punished sometimes.
Alex. You too can use the whois database at whois.arin.net to find out who owns 129.72 and 129.74 so you can email them and ask for them to turn of directed broadcast. It's not just a database for North Americans, you know. Yes, I know it very well. Just as those fact that more than 90% of NANOG's readers can't trace frauded packets in their own networks (due to technical issuesm, usially, a luck of cpu power or so on)... But anyway it's a small chance that someone read this message, then look at his IP accounting or Netflow file, and cry _that's it; I see a lot of packets originated from my ISDN_x.y.z customer with the frauded SRC address destined to this broadcast addresses_. Yes, I know it's very small chance, but why don't try.
Really; the broadcast addresses of this SMURF amplified networks are well known. All the ISP who are to be unhappy to serve SMURF intruder are to do is to add filter for this network, with some log-input option, and watch at this log sometimes... If I do not want to allow my customers SMURF another customers, I'll do it (yes, you are right - I dod not installed this filters yet through this work is listed in my TODO records). Through I have checked my network a few times for this echo-request packets - no one was found. I hope this smurfers live out of our network.
P.S. in case you don't understand the English above, it was mostly sarcasm directed at those other guys, not at you. And you might want to send this URL to the network operators where the smurf flood is originating http://www.quadrunner.com/~chuegen/smurf.cgi
-- 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)