I was hired by the Russian ISP company to get it back to the business. Due
to impact of the financial crisis, the company was almost bankrupt, but then
found the investor and have a big wish to life again.
When I tried to announce it's networks, upstreams rejected to accept it
because of Spamhaus listings. But our employer sworn there is not and was
not any spamming from the company. The Spamhaus lists all our networks as
spamming Zombies. And it IS announced and used now!!! The announce is from
American based company Internap (AS12182). I wrote the abuse report them,
but instead of stop unauthorized announces of our networks, I was contacted
by a person named 'Michael Lindsay' - he tell me he buy our networks from
some other people and demand we get back our abuse reports. Of course, we
don't. After a short googling, I found this is well-known cyber crime
person: http://www.spamhaus.org/rokso/listing.lasso?file=818&skip=0, and he
did IP hijacking with the fake letter of authorization before: http://www.spamhaus.org/rokso/evidence.lasso?rokso_id=ROK8686 so our company
is not a first victim of him. Yes, our company "help" him with the mistake
of loosing old domain link-telecom.biz he was also squatted. This domain was
listed as contact at RIPE Database.
It is a good topic why these easy-to-forge LOAs is still in use, as
RADB/RIPE DB/other routing database with the password access is a common
thing. But this is not the main thing. The main thing is why Internap helps
to commit a crime to the well-known felony person, and completely ignores
our requests? Is there any way to push them to stop doing that immediately?
If anybody can - please help...
Right now there are:
46.96.0.0/16
83.223.224.0/19
94.250.128.0/19
94.250.160.0/19
188.164.0.0/24
As I can see in the spam block lists like Spamhaus, all our networks was
affected:
83.223.224.0/20
86.59.128.0/17
79.174.128.0/18
94.250.128.0/17
188.164.0.0/16
46.96.0.0/16
Received: from mail-qy0-f177.google.com ([209.85.216.177])
by mailman.nanog.org with esmtp (Exim 4.76 (FreeBSD))
(envelope-from <noc@link-telecom.net>) id 1QuwTJ-000AP1-FT
for nanog@nanog.org; Sat, 20 Aug 2011 20:05:05 -0500
Received: by qyk2 with SMTP id 2so1654839qyk.15
for <nanog@nanog.org>; Sat, 20 Aug 2011 18:05:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.247.15 with SMTP id ma15mr447953qcb.1.1313888704629; Sat,
20 Aug 2011 18:05:04 -0700 (PDT)
Received: by 10.229.95.15 with HTTP; Sat, 20 Aug 2011 18:05:04 -0700 (PDT)
X-Originating-IP: [192.251.226.206]
He contacted me privately and stated he always uses Tor. I explained how that
lends even less credibility than a questionable/forged transfer authority in
business discussions... He claims he will be posting from his office Monday
morning.
The good credibility: There does appear to be a Denis Spirin in ?the Ukraine?
who is a IT consultant. There is also a Denis Spirin who appears to be a
director at a Russian venture capitalist... unknown if they have any
connection.
The bad credibility: Posting thru Tor via GMail. The "link-telecom.net" domain
appears to have no services or presence other than a MX record to GMail. The
same "noc@link-telecom.net" address he controls is also the registered
contact on all the IP blocks in Spamhaus and allegedly hijacked... why not
just contact Internap directly?
Yes, they are using our ASN 31733 to originate networks. All the visible
paths are through AS12182. Internap was contacted about a week ago, but did
nothing.
No, I'm not a venture capitalist, but IT specialist.
I am too sleepy, so replied to Adrian directly while wanted to post in the
list.
RIPE NCC can't withdraw any prefixes. They can do de-registration. In this
case it will not lead to withdraw, as it is announced without any honor to
RIPE Database, like Routing Registry. So it will be changed from hijacked
company prefix to hijacked unused prefix, with the same result - mass
spamming from it.
Would YOU filter announcements from YOUR customer based solely on an
email request from noc@link-telecom.net?
The Spamhaus reports appear credible, as does the RIPE registration
issue with those prefixes. If I was InterNAP, I think I'd challenge my
customer about them. Start of business Monday morning.
Yes, they are using our ASN 31733 to originate networks. All the visible
paths are through AS12182. Internap was contacted about a week ago, but did
nothing.
Which seems to be the right decision because the whois data backed it on.
No, I'm not a venture capitalist, but IT specialist.
I am too sleepy, so replied to Adrian directly while wanted to post in the
list.
If you are claiming right over these prefixes I suggest you to contact RIPE NCC.
Back when I worked at an RIR, a prefix was "misplaced". When I contacted the (country monopoly PTT) ISP and told them the prefix had been removed from APNIC's database and should not be routed. Their response was "We have a contract with the customer for connectivity. We do not have a contract with you." and I was encouraged to get the customer to voluntarily withdraw the prefix.
If BGPSEC+RPKI were deployed, there might be something active the RIRs could do. However, this has its own implications regarding centralized control of the routing system (as discussed, ironically enough, in the RIPE region). And this is going to get much more 'interesting' as the IPv4 free pool exhausts and the market moves from black to grey or white. Fun times ahead.
I completely agree... the real issue here is the system is flawed and RIPE/ARIN/APNIC etc have zero actual authority over actual routing. Yet another reason they aren't worth the money we flush down the toilet for them to do absolutely nothing.
--Tammy
Convenient as it may be to use a LIR and their historic provided prefixes,
have you thought about starting with a clean slate ?
If the company was close to bankrupt and one can only assume that it didn't
require a couple /16's and a couple /19's ...
Didn't you get ANY questions from RIPE in that regard when you discussed the
topic with them ? The reason why those prefixes where provided isn't valid
anymore and if you are restarting the business even a /21 should be enough
...
Even in Russia a will take some time to get the customers back, especially
if they have been offline for some time. (If they where not offline, the
prefixes wouldn't have been hijacked correct ? ... )
Next to this all, none of the prefixes that I currently see under the stated
AS have a route-object in the RIPE db and the AS object AS31733 isn't
updated since 2008, as none of the listed AS's there are current / active
upstreams / peers.
From where I stand it doesn't surprise me that your upstreams don't want to
advertize it and if they would, don't be surprised if some networks filter
your prefixes regardless if you are listed on a shady list on Spamhaus.
If Portnap doesn't / won't assist in this matter, you can send an abuse
message to both Tinet and NTT and have them reject the prefixes on their
ingress port.
They will probably only do that in case you have your AS record and route
objects correctly documented and can actually provide the proof they require
to do so.