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... I don't think it's impossible to localise the intruder if he hold this crazy program for so long (more than 6 hours). All it's nessesary to trace is the frauded packets with the SRC address 193.124.51.206/32 and DST addresses from the black list described here a few days ago. What does we seen now is: Apr 16 20:31:49 MSK: %SEC-6-IPACCESSLOGDP: list 108 denied icmp 130.34.195.1 -> 193.124.51.206 (0/0), 1 packet Apr 16 20:31:50 MSK: %SEC-6-IPACCESSLOGDP: list 108 denied icmp 129.115.201.88 -> 193.124.51.206 (0/0), 1 packet Apr 16 20:31:51 MSK: %SEC-6-IPACCESSLOGDP: list 108 denied icmp 129.74.90.51 -> 193.124.51.206 (0/0), 1 packet Apr 16 20:31:52 MSK: %SEC-6-IPACCESSLOGDP: list 108 denied icmp 129.72.4.38 -> 193.124.51.206 (0/0), 1 packet Apr 16 20:31:53 MSK: %SEC-6-IPACCESSLOGDP: list 108 denied icmp 134.57.7.220 -> 193.124.51.206 (0/0), 1 packet Apr 16 20:31:54 MSK: %SEC-6-IPACCESSLOGDP: list 108 denied icmp 128.139.221.1 -> 193.124.51.206 (0/0), 1 packet Apr 16 20:31:55 MSK: %SEC-6-IPACCESSLOGDP: list 108 denied icmp 148.81.230.253 -> 193. etc etc... This is echo-reply packets, and this means there exists ECHO-REQUEST packets sended by intruder. On Thu, 16 Apr 1998, Sam Critchley wrote:

Date: Thu, 16 Apr 1998 17:06:25 +0100 (BST) From: Sam Critchley <samc@uk.uu.net> To: administrator@lamere.net Cc: nanog@merit.edu Subject: Re: Private routes advertised

Hello,

I've forwarded this to the UUNET NOC. You can call them on 1-800-900-0241 as well.

Thanks,

Sam Critchley

On Thu, 16 Apr 1998 administrator@lamere.net wrote:

...

Hello, alter.net is advertising private routes 192.168.nnn.nnn. who do I contact to get that shutdown?

Here is the traceroute on it.

[C:\]tracerte 192.168.2.5 0 lamere-r1.lamere.net (206.249.60.1) 8 ms 8 ms 0 ms 1 lamere-r1.lamere.net (206.249.60.1) 0 ms 0 ms 0 ms 2 206.249.57.241 (206.249.57.241) 8 ms 0 ms 0 ms 3 loki.wordwrap.net (206.249.56.1) 0 ms 7 ms 0 ms 4 bbr2-s401-wordwrap.ctel.net (208.221.76.165) 8 ms 203 ms 180 ms 5 905.Hssi2-0.GW1.BOS1.ALTER.NET (157.130.4.25) 31 ms 156 ms 234 ms 6 123.ATM2-0-0.XR2.BOS1.ALTER.NET (146.188.176.238) 8 ms 24 ms 15 ms 7 190.ATM10-0-0.XR2.EWR1.ALTER.NET (146.188.176.153) 32 ms 85 ms 32 ms 8 100.ATM10-0-0.TR2.EWR1.ALTER.NET (146.188.176.90) 39 ms 31 ms 23 ms 9 105.ATM6-0.TR2.DCA1.ALTER.NET (146.188.136.189) 24 ms 23 ms 24 ms 10 198.ATM8-0-0.XR2.TCO1.ALTER.NET (146.188.161.185) 32 ms 23 ms 24 ms 11 192.ATM1-0-0.GW2.TCO1.ALTER.NET (146.188.160.53) 31 ms 32 ms 23 ms 12 quantum-gw.customer.alter.net (157.130.34.170) 31 ms 31 ms 39 ms 13 192.168.4.1 (192.168.4.1) 86 ms * 93 ms 14 192.168.10.2 (192.168.10.2) 94 ms 94 ms 93 ms 15 192.168.11.23 (192.168.11.23) 94 ms 86 ms 125 ms 16 192.168.2.5 (192.168.2.5) 93 ms *

Curtis

-- ----------------------------------------------------------- Curtis Maurand System Administrator lamere.net Business Center We'll get you Wired. administrator@lamere.net -----------------------------------------------------------

**************************************** Sam Critchley International Systems Engineer UUNET samc@UU.net Tel: (+44) 1223 250444 ****************************************

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)

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)

On Thu, 16 Apr 1998, Gus Huber wrote: Check out a program called 'fraggle' or consult my document at http://www.quadrunner.com/~chuegen/smurf.txt ==>While reading threads on the list I'm cc'ing this message to, I thought of ==>a similar attack to smurf, that could be a problem based on SMURF attacks. ==>ICMP isn't the only services that can be potentialy exploited via his bug, ==>UDP could be a huge player too. For example those of you familiar with ==>SMB might be able to deduce what I am getting at. Just a little test I ==>did today. ==>dialin:> nmblookup -B broadcast.mydomain.com \* <hidden to protect the ==>innocent> ==> ==>Well then I went to my packet loging facilities. ==> ==>Since the class c that I send the broadcast was primarily windows machines ==>I got approximately 200 replys to this one udp packet. It seems to me ==>that this could be allmost as big of a player as smurf if executed ==>tactfuly. Some common UDP services can be fooled into sending back many ==>more packets than you send in, especialy on windows machines. I sent this ==>to this list in hopes it would be dealt with before widespread exploit of ==>it could take place. ==> ==> Gus Huber <gus@pbx.org> ==> ==>