AS205869, AS57166: Featured Hijacker of the Month, July, 2018

Before I get into talking about this month's honorary Hijacker of
the Month, I really must start by thanking everyone who pitched in and
helped to insure an appropriate response and outcome for the BitCanal
case, which I reported here last month. You all know who you are, and
I won't explicitly name you here, only because most of you have expressed
to me privately that you would prefer it if I didn't. But you folks
deserve the lion's share of the credit, and I, in contrast, played
only the most minor supporting role.

I must also say that I was astonished and very pleasantly surprised by
the very effective and, to-date, very nearly 100% effective response to
my call to action with respect to Bitcanal. This thief, Joao Silveira,
aka Mr. Bitcanal, and his business are still limping along, and, I'm sure,
trying desperately to get back online after everybody with half a brain
became convinced of what he has been up to for lo these past several
years. He's apparently managed to at least get his main web site
(www.bitcanal.com) back online, but now he's totally dependent on
GoDaddy hosting for that. :slight_smile: I guess that he doesn't have a whole
lot of IP space to call his own anymore, or any least not very much
of it that he can actually get anyone to route for him.

I should also offer my apologies for the rather deliberately rude way
that I got right up into the faces of Cogent, GTT, and Level3, right
here on the NANOG list, with regards to BitCanal. I see now that that
was really rather completely unfair and uncalled for. All three took
swift and appropriate action once they became fully aware of the
issue/problem, and I am grateful to all of them for their prompt action,
and also, of course, I am equally grateful also to the many other
providers and IXes who also took appropriate action in this case.

Following my posting last month about BitCanal, at least one person
rightly took me to task for the rude way I approached the problem, and
even moreso for the fact that I escalated the problem to this list
as my first response to the whole issue. With 20/20 hindsight, I can
now only agree with those criticisms. I shouldn't have done that.
I am pleased with the final result, i.e. Bitcanal being kicked from
essentially the whole Internet, but the ends do not justify the rather
hamfisted means I elected to employ. I will try to do better in future.

With that in mind, when I recently found another such operation...
another entity performing an entire set of obviously very deliberate
hijacks, evidently for the purpose of leasing the hijacked space to
snowshoe spammers... I took what I had learned from the BitCanal case
and applied it. In particular, rather than me having a very public
tantrum and getting on the cases of each and every company that bgp.he.net
said might be connected to the hijacker somehow, I instead began by running
traceroutes to all of the relevant hijacked blocks. (If I would have had
the good sense to have done this in the BitCanal case, I most probably
would have begun by just hasseling Cogent alone, and privately, off list,
since from where I sit, all of the traceroutes to all the blocks that
Bitcvanal stole had Cogent as the next-to-last hop. YMMV)

Anyway, in this new case I found that the next-to-last hop for all of
the relevant traceroutes was a set of routers belonging to Telecom Italia.
Rather than calling them out here, this time I had the good sense to
just message TelecomItalia directly about the issue. it took me a couple
of tries, but I was eventually able to find a proper contact address for
a proper sort of person to discuss this matter with @ Telecom Italia.
The two links below are (1) my message to them and (2) their very nice
and proactive response back to me:

      Me -> Telecom Italia
      https://pastebin.com/raw/Ek3mxKCR

      Telecom Italia -> Me
      https://pastebin.com/raw/mtcA4Ehy

Given that I sent my message to them well after business hours on Friday,
I consider their response, sent on Monday, to be super-fast and very
responsive. Of course, I am absolutely ecstatic also that they have
elected to stop all routing to the particular bunch of of badness that
I explicitly called out to them, at least for the time being.

As you can all see, my message to TelecomItalia describes the issue/problem
with AS205869 - Universal IP Solution Corp. in some considerable detail.
In a nutshell, these guys are criminals and they've been reselling the
IPv4 space they've hijacked, specifically but perhaps not only to snowshoe
spammers. (Specific evidence available upon request.) Of course, one can
easily imagine even vastly worse uses that may be made of stolen IP space.

By the time that I personally became aware of what these specific jerks
were up to, they had already used, abused, and tossed aside several other
IPv4 blocks -and- also a number of other previously abandoned ASNs. (They
have been absconding with -both- abandoned IPv4 address blocks -and- also
a number of previously abandoned ASNs... as well as one that was/is in
active use by its legitimate owner. And they have bee doing so without
any apparent restraint watever.) The evidence of all this is crystal
clear from a quick review of all of the relevant RIPE records. They
left their bloody fingerprints all over this mess.

Anyway, by the time I noticed them. late last week, the set of routes and
ASNs that this particular set of crooks were still fradulently using were
as follows:

ASN Route

I'd greatly appreciate it if readers of this post would help me to to confirm
that the non-routing of the above block is both universal and complete...
as it is, at least, from where I am sitting... but at this point I have
nothing and nobody to rail against. (Or so I thought! But while writing
this post I found some new and apparently associated curiosities relating
to a different ASN, AS57166. Read on!)

All prefixes still visible here (Oslo, Norway), through HE. Here's your
original table augmented with the AS paths I see on our border routers:

ASN Route AS path

Dead for me via:
HE
NTT
COX

Dead for me via:
HE
NTT
COX

Likewise here, via a bunch of other transits. I saw them from HE this morning but they appear to have been withdrawn now.

Dead for me via:
HE
NTT
COX

Likewise here, via a bunch of other transits. I saw them from HE this morning but they appear to have been withdrawn now.

Also gone from HE from my vantage point in Oslo, Norway.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

In message <20180724.090316.47077931.sthaug@nethelp.no>,
sthaug@nethelp.no wrote:

All prefixes still visible here (Oslo, Norway), through HE. Here's your
original table augmented with the AS paths I see on our border routers:

ASN Route AS path
-----------------------------------------------
10510 216.238.64.0/18 6939 205869 32226 10510
10737 207.183.96.0/20 6939 205869 7827 10737
10800 192.110.32.0/19 6939 205869 11717 10800
19529 104.143.112.0/20 6939 205869 11324 19529
19529 198.14.0.0/20 6939 205869 7827 19529
19529 198.32.208.0/20 6939 205869 7827 19529
19529 206.41.128.0/20 6939 205869 11324 19529
30237 192.73.128.0/20 6939 205869 11717 30237
30237 192.73.144.0/20 6939 205869 11717 30237
30237 192.73.160.0/20 6939 205869 11717 30237
30237 192.73.176.0/20 6939 205869 11717 30237

Thanks for checking this. I gather from the other posts in this thread
that this has already been rectified, and that the above CIDRs are no
longer reachable via HE.NET, correct?

Even if that's the case, I'm still left scratching my head. There's a
bit of a mystery here, or at least something that I don't quite understand.
(NOTE: I've never laid claim to being anything like an "expert" when it
comes to all this routing stuff. I just muddle along and try to do the
best I can with the limited knowledge and understanding that I have.)

So, here's what's perplexing me. You reported that all eleven of the
routes in the table above had AS paths that directly connected
Universal IP Solution Corp. (AS205869) to Hurricane Electric (AS6939).
And yet, when I looked at the following page, both yesterday and today,
I see no reported connection between those two ASNs:

     https://bgp.he.net/AS205869#_peers

I already knew before now that each of the alleged peerings reported on
similar pages on the bgp.he.net web site had to be taken with a grain of
salt, mostly or entirely because of the kinds of hanky panky and path
forgery being undertaken by various bad guys. In at least some cases,
these screwy games appear to have caused bgp.he.net to list peerings that
didn't actually exist.

But this is a rather entirely different case. In this case, it seems
that one very notable peering that -did- in fact exist, between AS205869
and AS6939, was not reported at all on the bgp.he.net page linked to above.

To be clear, I most definitely am *not* suggeting any sort of deliberate
obfsucation here, on anybody's part. Rather, I just suspect that some
of the algorithms that are used to produce the peers lists on bgp.he.net
could use some... ah... fine tuning. It certainly seems to be true that
in this case, one very important peering was utterly missed by the algorithms
that power bgp.he.net.

Regards,
rfg

radar.qrator.net serves as a complementary view to bgp.he.net and AS205869
does show as peered with AS6939 there.

Jason

But this is a rather entirely different case. In this case, it seems that one very notable peering that -did- in fact exist, between AS205869 and AS6939, was not reported at all on the bgp.he.net page linked to above.

HE usually learn these hijacked routes from IX peering and route servers. bgp.he.net tends not to report on IX peering. To their credit, HE have an extremely open peering policy. To their detriment, this means their customers see the large majority of hijacked routes due to poor filtering on many IX route servers.

Hi Ronald,

From your initial list, I can still see some prefixes with the NLnog ring :

http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=206.41.128.0
http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=52.128.192.0
http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv4?q=206.222.128.0

Also http://lg.ring.nlnog.net/prefix_bgpmap/lg01/ipv4?q=94.130.90.152

Best regards,

If I have to guess, those probably are ghost or stale routes. Wouldn't
worry about them.

I've noticed that quite a bunch of networks that use "BGP optimisers"
end up reporting having certain routes to the NLNOG LG while in reality
those were withdrawn globally.

Kind regards,

Job