AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these schmucks?
Johann
adofou at gmail.com
Fri Aug 25 10:50:11 UTC 2017
Hello,
AS29073 seem be visible (for anyone?) on AMS-IX routeserver.
I think that can explain why many ASN peer with this network.
So, thanks for this thread. I have filtered this ASN on AMS-IX RS (99 =>98).
Johann
2017-08-17 5:51 GMT+02:00 Troy Mursch <troy at wolvtech.com>:
> 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