AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these schmucks?
Troy Mursch
troy at wolvtech.com
Thu Aug 17 03:51:56 UTC 2017
This discussion is not pertaining to a customer of a network service
provider. Ecatel / Quasi Networks (AS29073) has an established track
record of ignoring abuse requests for years. So much so they are now in
legal trouble, per court documents published on August 14:
https://uitspraken.rechtspraak.nl/inziendocument?id=ECLI:NL:RBDHA:2017:9026
(Use Google Translate if you can’t read Dutch)
Setting aside the child porn, phishing sites, route hijacking, copyright
infringement, and large-scale outbound hacking activities - why would
anyone peer with another AS who deliberately ignores abuse requests?
Yesterday I spoke with BREIN, the organization leading case against
AS29073, they advised, "Our effort is aimed at outing the actual people
behind it so they can be held responsible."
If anyone has information regarding AS29073 and would like to share it with
BREIN you can submit it via this web form:
https://stichtingbrein.nl/contact.php
__
*Troy Mursch*
Bad Packets Report <https://badpackets.net/>
(702) 509-1248
On Mon, Aug 14, 2017 at 1:17 PM, Siegel, David <Dave.Siegel at level3.com>
wrote:
> If you believe that a customer of a network service provider is in
> violation of that service providers AUP, you should email
> abuse at serviceprovider.net. Most large networks have a security team that
> monitors that email address regularly and will cooperate with you to
> address the problem.
>
> Dave
>
>
>
>
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ronald F.
> Guilmette
> Sent: Monday, August 14, 2017 1:50 PM
> To: nanog at nanog.org
> Subject: AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these
> schmucks?
>
>
> Sorry for the re-post, but it has been brought to my attention that my
> inclusion, in my prior posting, of various unsavory FQDNs resolving to
> various IPv4 addresses on AS29073 has triggered some people's spam
> filters. (Can't imagine why. :-) So I am re-posting this message now,
> with just a link to where those shady FQDNs and their current forward
> resolutions may be found. (I also took the opportunity to clean up some
> minor typos.)
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> I think that this is primarily Level3's problem to fix. But you be the
> judge. Please, read on.
>
> +_+_+_+_+_+_+_+_
>
> Over the weekend, I stumbled upon an interesting blog calld "Bad Packets",
> where a fellow named Troy has written about various unsavory goings on
> involving various newtorks. One network that he called out in particular
> was AS29073, formerly called "Ecatel". on his blog, this fellow Troy has
> noted at length some break-in attempts originating from AS29073 and his
> inability to get anyone, in particular RIPE NCC, to give a damn.
>
> https://badpackets.net/the-master-needler-80-82-65-66/
> https://badpackets.net/a-conversation-with-ripe-ncc-regardin
> g-quasi-networks-ltd/
> https://badpackets.net/quasi-networks-responds-as-we-witness
> -the-death-of-the-master-needler-80-82-65-66-for-now/
>
> The fact that RIPE NCC declined to accept the role of The Internet Police
> didn't surprise me at all... they never have and probably never will.
> But I decided to have a quick look at what this newtork was routing, at
> present, which can be easily see here:
>
> http://bgp.he.net/AS29073#_prefixes
>
> So I was looking through the announced routes for AS29073, and it all
> looked pretty normal... a /24 block, check, a /24 block, check, a /21 block
> check... another /24 block, and then ... WAIT A SECOND! HOLY MOTHER OF
> GOD! WHAT'S THIS??? 196.16.0.0/14 !!!
>
> So how does a little two-bit network with a rather dubious reputation and
> a grand total of only about a /19 to its name suddenly come to be routing
> an entire /14 block??
>
> And of course, its a legacy (abandoned) Afrinic block.
>
> And of course, there's no reverse DNS for any of it, because there is no
> valid delegation for the reverse DNS for any of it... usually a good sign
> that whoever is routing the block right now -does not- have legit rights to
> do so. (If they did, then they would have presented their LOAs or whatever
> to Afrinic and thus gotten the reverse DNS properly delegated to their own
> name servers.)
>
> I've seen this movie before. You all have. This gives every indication
> of being just another sad chapter in the ongoing mass pillaging of unused
> Afrinic legacy IPv4 space, by various actors with evil intent.
> I've already documented this hightly unfortunate fad right here on
> multiple occasions:
>
> https://mailman.nanog.org/pipermail/nanog/2016-November/089232.html
> https://mailman.nanog.org/pipermail/nanog/2017-August/091821.html
>
> This incident is a bit different from the others however, in that it -does
> not- appear that the 196.16.0.0/14 block has been filed to the brim with
> snowshoe spammers. Well, not yet anyway.
>
> But if in fact the stories are correct, and if AS29073 does indeed have a
> history of hosting outbound hacking activities, then the mind reels when
> thinking about how much mischief such bad actors could get into if given an
> entire /14 to play with. (And by the way, this is a new world's record I
> think, for largest single-route deliberate hijack.
> I've seen plenty of /16s go walkabout before, and even a whole /15.
> But an entire /14?!?! That is uniquely brazen.)
>
> In addition to the above, and the points raised within the Bad Packets
> blog (see links above) I found, via passive DNS, a number of other causes
> for concern about AS29073, to wit:
>
> Shady FQDNs (incl possible child porn ones) on AS29073 moved here:
> https://pastebin.com/raw/f4M09UKL
>
> (In addition to the above, I've also found plenty more domain names
> associated with AS29073 which incorporate the names "Apple" "AirBnB",
> "Facebook", and "Groupon", as well as dozens of other legitimate companies
> and organizations.)
>
> I confess that I have not had the time to look at any of the web sites
> that may or may not be associated with any of the above FQDNs, but the
> domain names themselves are certainly strongly suggestive of (a) the
> possible hosting of child porn and also and separately (b) the possible
> hosting of phishing sites.
>
> So, given the history of this network (as is well documented on the Bad
> Packets blog) and given all of the above, and given what would appear to be
> the unauthorized "liberation" of the entire 196.16.0.0/14 block by
> AS29073, one cannot help but wonder: Why does anybody still even peer with
> these jerks?
>
> The always helpful and informative web site bgp.he.net indicates that
> very nearly 50% of the connectivity currently enjoyed by AS29073 is being
> provided to them by Level3. I would thus like to ask Level3 to reconsider
> that peering arrangement in light of the above facts, and especially in
> light of what would appear to be the unauthorized routing of the
> 196.16.0.0/14 block by AS29073.
>
> Surprisingly, given its history, AS29073 apparently has a total of 99
> different peers, at present, and I would likewise ask all of them to
> reconsider their current peering arrangements with this network. I am
> listing all 99 peers below.
>
> Before I get to that however, I'd like to also note that there currently
> exists, within the RIPE Routing Registry, the following route object:
>
> route: 196.16.0.0/14
> origin: AS29073
> mnt-by: QUASINETWORKS-MNT
> mnt-by: EC42500-MNT
> mnt-routes: EC42500-MNT
> mnt-routes: M247-EU-MNT
> created: 2017-03-28T21:47:03Z
> last-modified: 2017-08-11T19:58:39Z
> source: RIPE
>
> I confess that I am not 100% sure of the exact semantics of the
> "mnt-routes"
> tag, but it would appear from the above that the UK's M247 network
> (AS9009)...
> which itself is not even peering with AS29073... appears to have, in
> effect countersigned the above RIPE route object, vouching for its
> correctness and authenticity as they did so. Why they would have done
> that, especially given that they themselves are not even peering with
> AS29073, is, I confess, beyond me. But I would love to have them explain
> it, or even try to explain it.
> It's enigmatic, to say the least.
>
> Anyway, the "created" date in the above record seems to be consistant with
> that actual start of the announcement of 196.16.0.0/14 by AS29073, which
> the RIPE Routing History tool says occured sometime in March of this year.
>
> One additional (and rather bizzare) footnote to this whole story about the
> 196.16.0.0/14 block has to do with the entity that allegedly -is- the
> current rightful owner of the block (as far as Afrinic is concerned).
> That entity is designated by the Afrinic handle ORG-IA41-AFRINIC and that
> in turn has an admin-c and tech-c of NAIT1-AFRINIC. The record for that
> handle is as follows:
>
> -------------------------------------------------------
> person: Network and Information Technology Administrator
> address: Unit 117, Orion Mall, Palm Street
> address: Victoria, Mahe
> address: Seychelles (SC)
> phone: +972-54-2203545
> e-mail: info at networkandinformationtechnology.com
> nic-hdl: NAIT1-AFRINIC
> mnt-by: MNT-NETWORKANDINFORMATIONTECHNOLOGY
> changed: info at networkandinformationtechnology.com 20150725
> source: AFRINIC
> -------------------------------------------------------
>
> Upon fetching the current WHOIS record for networkandinformationtechnolog
> y.com
> I found it more than passing strange that all of the contact details
> therein are associated *not* with anything in Africa, nor even anything in
> the home country of AS29073 (Netherlands) but rather, the address and phone
> numbers therein all appear to be ones associated with a relatively well
> known Internet attorney in Santa Monica, Califiornia by the name of Bennet
> Kelly.
>
> As it happens, in the distant past (about 10 years ago) I personally
> crossed swords with this particular fellow. He may be a lot of things, but
> it never seemed to me that stupid was one of them. And indeed the domain
> name networkandinformationtechnology.com and all of its connections to
> the 196.16.0.0/14 block appear to date from 2015...
> long before AS29073 started routing this block (which only started in
> March of this year).
>
> So, my best guess about this whole confusing mess is that the -original-
> legitimate owners of the 196.16.0.0/14 block most probably sold it on, in
> a legitimate transaction, to some other party in 2015, where that other
> party was/is represented by Mr. Bennet Kelly, Esq. And my guess is that
> neither he nor the new owners, who he represents, even know that their
> expensive /14 has gone walkabout, as of March of this year.
> I will be trying to make contact with Mr. Kelley today to discuss this
> with him and will post a follow-up if any new and interesting information
> arises from that conversation.
>
>
> Regards,
> rfg
>
>
> Peers of AS29073:
> ============================================================
> ====================
> 1 Level 3 Communications, Inc.
> United States
> AS3356
> 2 REBA Communications BV
> Netherlands
> AS56611
> 3 Hurricane Electric, Inc.
> United States
> AS6939
> 4 Core-Backbone GmbH
> Germany
> AS33891
> 5 Init7 (Switzerland) Ltd.
> Switzerland
> AS13030
> 6 RETN Limited
> Ukraine
> AS9002
> 7 COLT Technology Services Group Limited
> United Kingdom
> AS8220
> 8 State Institute of Information Technologies and Telecommunications
> (SIIT&T "Informika")
> Russian Federation
> AS3267
> 9 GlobeNet Cabos Submarinos Colombia, S.A.S.
> Colombia
> AS52320
> 10 Digital Telecommunication Services S.r.l.
> Italy
> AS49605
> 11 IT.Gate S.p.A.
> Italy
> AS12779
> 12 green.ch AG
> Switzerland
> AS1836
> 13 UNIDATA S.p.A.
> Italy
> AS5394
> 14 GEANT Limited
> European Union
> AS20965
> 15 IP-Max SA
> Switzerland
> AS25091
> 16 Lost Oasis SARL
> France
> AS29075
> 17 nexellent ag
> Switzerland
> AS31424
> 18 SEACOM Limited
> Mauritius
> AS37100
> 19 Angola Cables
> Angola
> AS37468
> 20 ENTANET International Limited
> United Kingdom
> AS8468
> 21 Blix Solutions AS
> Norway
> AS50304
> 22 POST Luxembourg
> Luxembourg
> AS6661
> 23 Zayo France SAS
> France
> AS8218
> 24 Wind Telecomunicazioni SpA
> Italy
> AS1267
> 25 Swisscom (Switzerland) Ltd
> Switzerland
> AS3303
> 26 Pacnet Global Ltd
> Hong Kong
> AS10026
> 27 SURFnet bv
> Netherlands
> AS1103
> 28 SEEWEB s.r.l.
> Italy
> AS12637
> 29 BIT BV
> Netherlands
> AS12859
> 30 euNetworks Managed Services GmbH
> Germany
> AS13237
> 31 CAIW Diensten B.V.
> Netherlands
> AS15435
> 32 netplus.ch SA
> Switzerland
> AS15547
> 33 DOKOM Gesellschaft fuer Telekommunikation mbH
> Germany
> AS15763
> 34 ADISTA SAS
> France
> AS16347
> 35 Viewqwest Pte Ltd
> Singapore
> AS18106
> 36 Digital Ocean, Inc.
> European Union
> AS200130
> 37 Digital Ocean, Inc.
> Netherlands
> AS202018
> 38 Open Peering B.V.
> Netherlands
> AS20562
> 39 Services Industriels de Geneve
> Switzerland
> AS20932
> 40 Cemig Telecomunicaes SA
> Brazil
> AS23106
> 41 SG.GS
> Singapore
> AS24482
> 42 Vorboss Limited
> United Kingdom
> AS25160
> 43 equada network GmbH
> Germany
> AS25220
> 44 Avantel, Close Joint Stock Company
> Russian Federation
> AS25227
> 45 Gyron Internet Ltd
> United Kingdom
> AS29017
> 46 IPROUTE SRL
> Italy
> AS49289
> 47 LLC "TRC FIORD"
> Russian Federation
> AS28917
> 48 Hostserver GmbH
> Germany
> AS29140
> 49 Telekommunikation Mittleres Ruhrgebiet GmbH
> Germany
> AS12329
> 50 Internet Systems Consortium, Inc.
> United States
> AS30132
> 51 Liquid Telecommunications Ltd
> United Kingdom
> AS30844
> 52 Paulus M. Hoogsteder trading as Meanie
> Netherlands
> AS31019
> 53 Digiweb ltd
> Ireland
> AS31122
> 54 Fiberax Networking&Cloud Ltd.
> United Kingdom
> AS3252
> 55 Hivane
> France
> AS34019
> 56 CELESTE SAS
> France
> AS34177
> 57 Kantonsschule Zug
> Switzerland
> AS34288
> 58 Citycable
> Switzerland
> AS34781
> 59 SoftLayer Technologies Inc.
> United States
> AS36351
> 60 Network Platforms (PTY) LTD
> South Africa
> AS37497
> 61 Micron21 Datacentre Pty Ltd
> Australia
> AS38880
> 62 Convergenze S.p.A.
> Italy
> AS39120
> 63 Fiberby ApS
> Denmark
> AS42541
> 64 IP ServerOne Solutions Sdn Bhd,
> Malaysia
> AS45352
> 65 Easynet Global Services
> European Union
> AS4589
> 66 IP-Only Networks AB
> Sweden
> AS12552
> 67 Tango S.A.
> Luxembourg
> AS48526
> 68 Les Nouveaux Constructeurs SA
> France
> AS49463
> 69 CustodianDC Limited
> United Kingdom
> AS50300
> 70 MCKAYCOM LTD
> United Kingdom
> AS50763
> 71 Daisy Communications Ltd
> United Kingdom
> AS5413
> 72 MC-IX Matrix Internet Exchange RS-1
> Indonesia
> AS55818
> 73 NetIX Communications Ltd.
> Bulgaria
> AS57463
> 74 Anycast Global Backbone
> Australia
> AS58511
> 75 LUXNETWORK S.A.
> Luxembourg
> AS29467
> 76 oja.at GmbH
> Austria
> AS39912
> 77 Elisa Oyj
> Finland
> AS6667
> 78 A1 Telekom Austria AG
> Austria
> AS8447
> 79 Fusix Networks B.V.
> Netherlands
> AS57866
> 80 ClaraNET LTD
> United Kingdom
> AS8426
> 81 "OBIT" Ltd.
> Russian Federation
> AS8492
> 82 Console Network Solutions Ltd
> United Kingdom
> AS43531
> 83 NetCologne GmbH
> Germany
> AS8422
> 84 Tesonet Ltd
> Lithuania
> AS201341
> 85 Linx Telecommunications B.V.
> Estonia
> AS3327
> 86 Strato AG
> Germany
> AS6724
> 87 CJSC RASCOM
> Russian Federation
> AS20764
> 88 Sunrise Communications AG
> Switzerland
> AS6730
> 89 KPN B.V.
> Netherlands
> AS1136
> 90 MTN SA
> South Africa
> AS16637
> 91 Portlane AB
> Sweden
> AS42708
> 92 TM Net, Internet Service Provider
> Malaysia
> AS4788
> 93 Network Dedicated SAS
> Switzerland
> AS62355
> 94 Next Layer Telekommunikationsdienstleistungs- und Beratungs GmbH
> Austria
> AS1764
> 95 Telkom SA Ltd.
> South Africa
> AS5713
> 96 ShockSRV Internet Services Private Limited
> Netherlands
> AS60115
> 97 JUPITER 25 LIMITED
> Netherlands
> AS64484
> 98 M-net Telekommunikations GmbH
> Germany
> AS8767
> 99 Neterra Ltd.
> Bulgaria
> AS34224
>
More information about the NANOG
mailing list