Location May 2021

location@lists.ipfire.org

5 participants
14 discussions

[PATCH] regular batch of various overrides
by Peter Müller 16 May '21

16 May '21

Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org> --- overrides/override-a1.txt | 5 ++++ overrides/override-a2.txt | 45 ++++++++++++++++++++++++++++++++++++ overrides/override-other.txt | 25 ++++++++++++++++---- 3 files changed, 70 insertions(+), 5 deletions(-) diff --git a/overrides/override-a1.txt b/overrides/override-a1.txt index fc97098..3a65232 100644 --- a/overrides/override-a1.txt +++ b/overrides/override-a1.txt @@ -703,6 +703,11 @@ descr: Privax LTD remarks: VPN provider is-anonymous-proxy: yes +net: 92.50.201.0/24 +descr: "InsatCom-V, ISP: Leased lines, VPN (city Volgograd)" +remarks: VPN provider (or something similar) +is-anonymous-proxy: yes + net: 92.118.39.0/24 descr: CloudMine NET remarks: VPN provider [high confidence, but not proofed] diff --git a/overrides/override-a2.txt b/overrides/override-a2.txt index f53053b..b8b3b08 100644 --- a/overrides/override-a2.txt +++ b/overrides/override-a2.txt @@ -197,6 +197,16 @@ descr: Shaw Satellite Services, Inc. remarks: Satellite Internet provider [high confidence, but not proofed] is-satellite-provider: yes +aut-num: AS35410 +descr: LVS Transnational Corporation (tm) OOO Nord-telecom +remarks: Satellite Internet provider [high confidence, but not proofed] +is-satellite-provider: yes + +aut-num: AS37019 +descr: Intersat Africa Ltd +remarks: Satellite Internet provider +is-satellite-provider: yes + aut-num: AS37296 descr: Afcom Satellite Networks Nigeria Limited remarks: Satellite Internet provider @@ -247,6 +257,11 @@ descr: AXESS Networks Solutions Germany GmbH / CeTEL GmbH / GeoLink remarks: Satellite Internet provider is-satellite-provider: yes +aut-num: AS39668 +descr: Intersat SRL +remarks: Satellite Internet provider +is-satellite-provider: yes + aut-num: AS40305 descr: ViaSat, Inc. remarks: Satellite Internet provider @@ -288,6 +303,11 @@ descr: Telenor Satellite AS remarks: Satellite Internet provider is-satellite-provider: yes +aut-num: AS44064 +descr: ChronoSat GmbH +remarks: Satellite Internet provider +is-satellite-provider: yes + aut-num: AS44720 descr: SatTel Corporation, Ltd. remarks: Satellite Internet provider @@ -423,16 +443,36 @@ descr: YahClick / Star Satellite Communications Company - PJSC remarks: Satellite Internet provider is-satellite-provider: yes +aut-num: AS207102 +descr: Intersat Telekomunikacije d.o.o. +remarks: Satellite Internet provider +is-satellite-provider: yes + +aut-num: AS208484 +descr: EuroSkyPark GmbH +remarks: Satellite Internet provider +is-satellite-provider: yes + aut-num: AS208756 descr: ALCON TELECOM LTD remarks: Satellite Internet provider is-satellite-provider: yes +aut-num: AS265676 +descr: INTERSAT S.A. +remarks: Satellite Internet provider +is-satellite-provider: yes + aut-num: AS265705 descr: HUGHES DE COLOMBIA S.A.S. remarks: Satellite Internet provider is-satellite-provider: yes +aut-num: AS327780 +descr: Intersat Africa Ltd. +remarks: Satellite Internet provider +is-satellite-provider: yes + aut-num: AS327870 descr: Global Broadband Solution remarks: Satellite Internet provider [high confidence, but not proofed] @@ -2053,3 +2093,8 @@ descr: CoreLink Communications remarks: Chinese satellite Internet provider [high confidence, but not proofed] is-satellite-provider: yes country: AP + +net: 2c0f:fad8::/32 +descr: Intersat Africa Ltd. +remarks: Satellite Internet provider +is-satellite-provider: yes diff --git a/overrides/override-other.txt b/overrides/override-other.txt index 4446279..0b521d1 100644 --- a/overrides/override-other.txt +++ b/overrides/override-other.txt @@ -248,16 +248,21 @@ descr: Inter Connects Inc. / Jing Yun remarks: part of a dirty ISP conglomerate operating most likely out of SE, hijacking AfriNIC networks country: SE -aut-num: AS62355 -descr: Network Dedicated SAS -remarks: bulletproof ISP and IP hijacker, claims to be located in CH, but traces to NL -country: NL - aut-num: AS61977 descr: Vivo Trade L.P. remarks: another shady customer of "DDoS Guard Ltd." country: RU +aut-num: AS62068 +descr: SpectraIP B.V. +remarks: bulletproof ISP (linked to AS202425 et al.) located in NL +country: NL + +aut-num: AS62355 +descr: Network Dedicated SAS +remarks: bulletproof ISP and IP hijacker, claims to be located in CH, but traces to NL +country: NL + aut-num: AS62468 descr: VpsQuan L.L.C. remarks: claims to be located in US, but traces to HK @@ -268,6 +273,11 @@ descr: Inter Connects Inc. remarks: part of a dirty ISP conglomerate, traces back to US this time country: US +aut-num: AS64425 +descr: SKB Enterprise B.V. +remarks: bulletproof ISP (linked to AS202425 et al.) located in NL +country: NL + aut-num: AS64437 descr: NForce Entertainment BV remarks: currently hijacks a single stolen /20 AfriNIC IPv4 net, hosted in NL @@ -443,6 +453,11 @@ descr: Kakharov Orinbassar Maratuly remarks: ISP located in RU, but RIR data for announced prefixes contain garbage country: RU +aut-num: AS212231 +descr: Harry Dowd +remarks: ISP located in GB, but RIR data for announced prefixes contain garbage +country: GB + aut-num: AS213035 descr: Serverion BV remarks: ISP located in NL, but RIR data for most announced prefixes contain garbage -- 2.26.2

1 0

How should location-importer.in deal with RIR objects having multiple distinct "country" fields?
by Peter Müller 14 May '21

14 May '21

Hello Michael, hello location folks (CC'ed), unfortunately, another problem surfaces when processing inetnum and inet6num feeds from RIRs which provide that kind of more precise data: A decent amount of network objects have multiple distinct "country" fields. Here is an example: > inetnum: 178.79.192.0 - 178.79.255.255 > netname: EU-LLNW-20100512 > country: EU > country: SE > country: DE > country: NL > country: GB > country: ES > country: FR > country: IT > org: ORG-LNI1-RIPE > admin-c: GU2143-RIPE > tech-c: GU2143-RIPE > status: ALLOCATED PA > remarks: ****************** ABUSE COMPLAINTS TO: abuse(a)limelightnetworks.com > mnt-by: RIPE-NCC-HM-MNT > mnt-by: LLNW-MNT > mnt-domains: LLNW-MNT > mnt-routes: LLNW-MNT > created: 2010-05-12T16:20:38Z > last-modified: 2017-09-01T17:39:08Z > source: RIPE # Filtered Currently, the last country item is made persistent via the SQL INSERT statement. Since these do not appear to be sorted in any way, this makes things completely nondeterministic. The network above would be, however, recoverable: If we do not interpret "EU" as the European Union, but rather as the European country, all other country codes given here would be covered by it. Alas, this is not helping in cases such as these two: > Country of network [IPv4Network('77.74.172.0/23')] already set to 'CH', omitting 'FI' (multiple country lines in RIR data?) > Country of network [IPv4Network('185.253.140.0/24')] already set to 'GB', omitting 'NL' (multiple country lines in RIR data?) > Country of network [IPv4Network('185.253.140.0/24')] already set to 'GB', omitting 'US' (multiple country lines in RIR data?) > Country of network [IPv4Network('213.230.255.0/24')] already set to 'GB', omitting 'US' (multiple country lines in RIR data?) > Country of network [IPv4Network('213.230.255.0/24')] already set to 'GB', omitting 'JP' (multiple country lines in RIR data?) > Country of network [IPv4Network('213.230.255.0/24')] already set to 'GB', omitting 'SG' (multiple country lines in RIR data?) > Country of network [IPv4Network('213.230.255.0/24')] already set to 'GB', omitting 'AU' (multiple country lines in RIR data?) > Country of network [IPv4Network('213.230.255.0/24')] already set to 'GB', omitting 'NL' (multiple country lines in RIR data?) > Country of network [IPv4Network('213.230.255.0/24')] already set to 'GB', omitting 'FR' (multiple country lines in RIR data?) > Country of network [IPv4Network('213.230.255.0/24')] already set to 'GB', omitting 'DE' (multiple country lines in RIR data?) > Country of network [IPv4Network('193.109.168.0/22')] already set to 'GB', omitting 'US' (multiple country lines in RIR data?) There are _plenty_ of such networks, I believe RIPE IPv4 only fills several screen pages. Nothing in life is ever easy, and parsing RIR data definitely isn't... :-/ Delegating the task of handling such situations to the application using libloc does not make sense to me, as people are _expecting_ precise answers from it - if we can use the term of preciseness here at all -, otherwise, they could simply parse RIR data on their own. Therefore, we have to somehow make do with this. Possible options would be as follows: (a) We do not process such networks entirely. If a network operator wants to have his/her network covered by libloc, he/she/it should kindly fix it's RIR data. That would not prevent us from obtaining announcements for such networks, but we would not label them with any country anymore. (b) We try to automatically determine meaningful codes in each case. This is tricky and not very deterministic. What about a network having "CY" and "TR" set? Would that be covered by "EU"? 213.230.255.0/24 seems to be used worldwide, but in my point of view, this is not sufficient to classify it as an anycast network. Worse, we have or should assign a country code to anycast networks as well. (c) We try to determine the jurisdiction of a networks' organisation handle. Frankly, I have no idea what problems would arise in this case. If an organisation fails to provide accurate and meaningful RIR data, what will their organisation handle possibly look like? Trying to keep things deterministic, (a) is my current favorite - it is the most brutal, though. Do you see a better way of dealing with such networks? @All: Thoughts? Comments? Opinions? Thanks, and best regards, Peter Müller

2 4

[PATCH] override-{a{1,3},other}: weekly batch of various overrides
by Peter Müller 14 May '21

14 May '21

AS58110 is especially interesting... Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org> --- overrides/override-a1.txt | 12 +++++++++++- overrides/override-a3.txt | 15 +++++++++++++++ overrides/override-other.txt | 37 +++++++++++++++++++++++++++++++++++- 3 files changed, 62 insertions(+), 2 deletions(-) diff --git a/overrides/override-a1.txt b/overrides/override-a1.txt index 06d2d20..fc97098 100644 --- a/overrides/override-a1.txt +++ b/overrides/override-a1.txt @@ -46,7 +46,7 @@ is-anonymous-proxy: yes aut-num: AS34962 descr: Epik Network -remarks: VPN provider +remarks: Shady ISP and registrar, many prefixes announced refer to "anonymize" infrastructure is-anonymous-proxy: yes aut-num: AS35029 @@ -110,6 +110,11 @@ remarks: Autonomous System registered to offshore company, abuse contact is a is-anonymous-proxy: yes country: AP +aut-num: AS58110 +descr: IP Volume Ltd. / Epik +remarks: Shady Autonomous System registered to letterbox company, possibly copycat operation of Epik registrar, many prefixes announced refer to "anonymize" infrastructure +is-anonymous-proxy: yes + aut-num: AS58546 descr: Astrill VPN remarks: VPN provider @@ -1045,6 +1050,11 @@ descr: Access Now remarks: Tor relay provider is-anonymous-proxy: yes +net: 176.119.142.0/24 +descr: Artykova Alina Biktimerovna / BroVPN +remarks: VPN provider +is-anonymous-proxy: yes + net: 178.170.136.0/22 descr: GZ Systems Limited / PureVPN remarks: VPN provider diff --git a/overrides/override-a3.txt b/overrides/override-a3.txt index 36e03a3..ec246c1 100644 --- a/overrides/override-a3.txt +++ b/overrides/override-a3.txt @@ -190,6 +190,16 @@ descr: Hybula B.V. remarks: Generic anycast network is-anycast: yes +net: 5.182.48.0/24 +descr: FluxCDN +remarks: Generic anycast network +is-anycast: yes + +net: 5.182.49.0/24 +descr: FluxCDN +remarks: Generic anycast network +is-anycast: yes + net: 5.254.74.0/24 descr: VOXILITY LLC remarks: Generic anycast network @@ -535,6 +545,11 @@ descr: Thomas Steen Rasmussen / UncensoredDNS / censurfridns.dk remarks: Public anycast DNS resolver is-anycast: yes +net: 92.118.229.0/24 +descr: Epik +remarks: Generic anycast network +is-anycast: yes + net: 92.223.95.0/24 descr: G-Core Labs S.A. remarks: Generic anycast network diff --git a/overrides/override-other.txt b/overrides/override-other.txt index e56a208..4446279 100644 --- a/overrides/override-other.txt +++ b/overrides/override-other.txt @@ -93,6 +93,11 @@ descr: Neterra Ltd. remarks: ISP located in BG, but some RIR data for announced prefixes contain garbage country: BG +aut-num: AS35624 +descr: Neterra Ltd. +remarks: ISP located in RU, but some RIR data for announced prefixes contain garbage +country: RU + aut-num: AS39287 descr: ab stract / Peter Kolmisoppi remarks: tampers with RIR data, traces back to SE @@ -378,6 +383,11 @@ descr: Genius Guard / Genius Security Ltd. remarks: another shady customer of "DDoS Guard Ltd.", probably located in RU country: RU +aut-num: AS206898 +descr: Server Hosting Pty Ltd +remarks: ISP located in NL, but some RIR data for announced prefixes contain garbage +country: NL + aut-num: AS207046 descr: Xtudio Networks S.L.U. remarks: ISP located in ES, but some RIR data for announced prefixes contain garbage @@ -423,6 +433,11 @@ descr: Gudaev Maxim Amrakhovich remarks: announcements scatter across various places in EU (DE/CZ/??), but RIR data contain garbage country: EU +aut-num: AS210119 +descr: VPSSC Networks LTD +remarks: ISP located in UA, but RIR data for announced prefixes contain garbage +country: UA + aut-num: AS211849 descr: Kakharov Orinbassar Maratuly remarks: ISP located in RU, but RIR data for announced prefixes contain garbage @@ -508,6 +523,11 @@ descr: FlokiNET Ltd. remarks: fake offshore location (SC), traces back to RO country: RO +net: 45.89.97.0/24 +descr: IP Volume Ltd. / Epik +remarks: fake location (CH), traces back to GB +country: GB + net: 45.93.16.0/22 descr: IPv4 Superhub Limited remarks: network owned by an HK company, traces back to HK as well - but is assigned to DE. Nice try... @@ -515,7 +535,7 @@ country: HK net: 45.134.12.0/24 descr: MS Network LTD -remarks: fake offshore location (SC), traces back to NLm +remarks: fake offshore location (SC), traces back to NL country: NL net: 45.134.144.0/22 @@ -548,6 +568,21 @@ descr: Golden Internet LLC remarks: fake location (KP), WHOIS contact points to RU country: RU +net: 91.149.194.0/24 +descr: IP Volume Ltd. / Epik +remarks: fake location (CH), traces back to SE +country: SE + +net: 91.149.195.0/24 +descr: IP Volume Ltd. / Epik +remarks: fake location (CH), traces back to SE +country: SE + +net: 91.149.224.0/24 +descr: IP Volume Ltd. / Epik +remarks: fake location (CH), traces back to NO +country: NO + net: 91.243.32.0/19 descr: Petersburg Internet Network Ltd. remarks: RIR data for suballocations contain garbage, they are all located in RU -- 2.26.2

1 0

[PATCH] location-importer.in: emit warnings due to unknown country code for valid networks only
by Peter Müller 03 May '21

03 May '21

This reduces log spam in case of processing RIR database, checking for networks with unknown country codes assigned. If we would not have written into the database, there is no need to warn about them. Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org> --- src/python/location-importer.in | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/src/python/location-importer.in b/src/python/location-importer.in index 1e08458..e5f55af 100644 --- a/src/python/location-importer.in +++ b/src/python/location-importer.in @@ -623,16 +623,19 @@ class CLI(object): if not inetnum or not "country" in inetnum: return - # Skip objects with unknown country codes - if validcountries and inetnum.get("country") not in validcountries: - log.warning("Skipping network with bogus country '%s': %s" % \ - (inetnum.get("country"), inetnum.get("inet6num") or inetnum.get("inetnum"))) - return - # Iterate through all networks enumerated from above, check them for plausibility and insert # them into the database, if _check_parsed_network() succeeded for single_network in inetnum.get("inet6num") or inetnum.get("inetnum"): if self._check_parsed_network(single_network): + + # Skip objects with unknown country codes - to avoid log spam for invalid or too small + # networks, this check is - kinda ugly - done at this point + if validcountries and inetnum.get("country") not in validcountries: + log.warning("Skipping network with bogus country '%s': %s" % \ + (inetnum.get("country"), inetnum.get("inet6num") or inetnum.get("inetnum"))) + break + + # Everything is fine here, run INSERT statement... self.db.execute("INSERT INTO _rirdata(network, country) \ VALUES(%s, %s) ON CONFLICT (network) DO UPDATE SET country = excluded.country", "%s" % single_network, inetnum.get("country"), -- 2.26.2

1 0

2024

2023

2022

2021

2020

2019

2018

2017

Location May 2021