Private routes advertised

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

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

this will be a real problem as they do not have a noc.

why not ask on com-priv, nanog, arin-members, new.users.questions, the usual
places where network management is done?

randy

Hello,

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

Thanks,

Sam Critchley

I went in and stopped this announcement happening (it was actually coming
from behind 701). I've informed our NOC (UUNET) and they should clear up
afterwards.

Apologies about this happening.

Many thanks,

Sam

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.

Don't let those North Americans bully a poor Russian network operator,
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.

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

> 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)

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

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>

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>
==>
==>

After you trace them down on, just send those "dark and gloomy boys"
after 'em :slight_smile: