Based on research and analysis of network data, I believe the following networks have a wrong country code assigned - on purpose or by chance -, which requires manual correction (country overrides). This issue is a reminder for myself. 95.181.152.0/21 (US -> RU) 2a02:e00:ffe7::/48 (DE -> LT) 185.244.29.0/24 (KP -> SG / NL?)
https://patchwork.ipfire.org/project/location/list/?series=1328
91.245.232.0/24 (BZ -> RO) inetnum: 91.245.232.0 - 91.245.232.255 netname: SODEXO-PASS-ROMANIA-SRL descr: SODEXO PASS ROMANIA SRL descr: Str. Fabrica de Glucoza, nr. 5 Novopark Cladirea G descr: Municipiul Bucuresti 2 20331 country: ro
Gee, thank you for participating and reporting this one. :-) The root cause for this is #12458, which is already fixed upstream and currently scheduled for upcoming Core Update 153. Therefore, no override for this is required AFAIK, and you will be have a more accurate (or less inaccurate, if you like to put it that way :-) ) database shortly.
Hi Peter, Don't get this too harsh, but location-filter database is simply not reliable! Context: my IPFIRE is hammered these days with a bunch of attacks and Location filter is not doing its job! I see OpenVPN connection (failed) from a bunch of countries I've put in GeoIP block: like RU, Ukraine, Belarus, and my Chinese friends 27% of my failed attempts are from this IP - which literally hammers my OpenVPN: location lookup 92.63.197.97 92.63.197.97: Network : 92.63.197.0/24 Country : Netherlands Autonomous System : AS204655 - Novogara LTD In reality that is in Ukraine whois 92.63.197.97 |less inetnum: 92.63.197.0 - 92.63.197.255 netname: ORG-IKNV1-RIPE country: UA And 22% are from this IP: location lookup 87.251.74.30 87.251.74.30: Network : 87.251.74.0/24 Country : Russian Federation Autonomous System : AS204490 - Kontel LLC Which in reality is in NL inetnum: 87.251.74.0 - 87.251.74.255 netname: ds-poul country: NL RU, UA, and NL are in GeoIP Block chain... but FW does not block access to OpenVPN service! And I started to check the buggest attackers (as number of OpenVPN failed connections) and discovered above location-filter database discrepancies... Thanks for all the help! H&M
Hi, > Don't get this too harsh, but location-filter database is simply not reliable! > Context: my IPFIRE is hammered these days with a bunch of attacks and Location > filter is not doing its job! no harm feelings. :-) To clarify things a bit here, the sole purpose of the location filter is to reduce noise in your systems logs. One might argue it also protects services exposed from the firewall itself (IPsec and OpenVPN in most cases), which is sort of true, as those services should not be vulnerable to any attack at all, no matter where the attack comes from. Location-based firewall rules, on the other hand, are more vulnerable to an inaccurate location database indeed, d'accord. :-) > 27% of my failed attempts are from this IP - which literally hammers my > OpenVPN: > > location lookup 92.63.197.97 > 92.63.197.97: > Network : 92.63.197.0/24 > Country : Netherlands > Autonomous System : AS204655 - Novogara LTD Ah, my old friends over at Ecatel / Quasi Networks / Novogara / IP Volume / ... > In reality that is in Ukraine > > whois 92.63.197.97 |less > inetnum: 92.63.197.0 - 92.63.197.255 > netname: ORG-IKNV1-RIPE > country: UA This one is a special case as we have created an override for any network announced by AS204655 (as well as some others belonging to this Dutch bulletproof ISP), since they seem to tamper with RIR data sometimes, and I know for a fact that all of the IP networks announced by them are located in a datacenter located 30 km away from Amsterdam. In case you experience attacks from these Autonomous Systems, there is one threat actor behind it (including, but not limited to) - it is safe to drop any traffic from and to these: - AS204655 (Novogara Ltd.) - AS202425 (IP Volume Inc.) - AS57717 (FiberXpress BV) - AS56611 (REBA Communications BV) - AS62068 (SpectraIP BV) - AS64425 (SKB Enterprise BV) - AS62355 (Network Dedicated SAS) If you are interested, further information regarding this ISP is available, for example, here: https://www.nytimes.com/interactive/2019/12/22/us/child-sex-abuse-websites-shut-down.html > And 22% are from this IP: > > location lookup 87.251.74.30 > 87.251.74.30: > Network : 87.251.74.0/24 > Country : Russian Federation > Autonomous System : AS204490 - Kontel LLC > > Which in reality is in NL > > inetnum: 87.251.74.0 - 87.251.74.255 > netname: ds-poul > country: NL I am pretty sure it is not located in NL at all, and they just put that country into the RIR data for this network to avoid filters blocking traffic from Russia: 1. [REDACTED] 2. [REDACTED] 3. AS9002 ae11-11.RT.M9.MSK.RU.retn.net (87.245.233.244) <---- Moscow, Russia 4. AS9002 GW-TeamHost.retn.net (87.245.229.225) <---- Gateway from RETN to TeamHost 5. AS202984 40G-peer.highspeednetwork.ru (92.63.203.85) <---- some internal network infrastructure, likely fake ISP to gain connectivity from carriers easier 6. AS204490 185.186.140.109 (185.186.140.109) <---- ... and here we go into the malicious network located at the same place in greater Moscow area 7. AS204490 87.251.74.30 (87.251.74.30) <---- BOOM! While we did not create an override for this network, yet, it definitely seems to be a candidate for it. Thanks for letting us know. :-) > RU, UA, and NL are in GeoIP Block chain... but FW does not block access to > OpenVPN service! In case your machine is connected to the internet by PPPoE (e.g. a DSL connection), you most possibly suffer from bug #12519, which will be fixed in upcoming Core Update 153. Thanks, and best regards, Peter Müller
Hi Peter, inetnum: 213.108.130.0 - 213.108.134.255 country: MD Has no country in location database: location lookup 213.108.134.0 213.108.134.0: Network : 213.108.134.0/24 Autonomous System : AS44477 - IP Oleinichenko Denis Owner of this inetum is Rusia.. Hope it helps!
Hi, thanks for noticing. Meanwhile, we have an override for that AS, as some RIR data for other prefixes announced by it contain garbage (as well?), so location now shows up a country: > [root@maverick ~]# location lookup 213.108.134.0 > 213.108.134.0: > Network : 213.108.134.0/24 > Country : Russian Federation > Autonomous System : AS44477 - IP Oleinichenko Denis However, it is rather unsatisfying why this did not work in the first place. I will have a look at it... Thanks, and best regards, Peter Müller
Yet another location showing as unknown where WhoIs shows country ... [root@ipfire ~]# location lookup 140.135.36.163 140.135.36.163: Network : 140.128.0.0/13 Autonomous System : AS1659 ... WHOIS results from whois.apnic.net ... inetnum: 140.117.0.0 - 140.138.255.255 netname: TANET-BNETA descr: imported inetnum object for MOEC country: TW .
Here's another where "location lookup" shows no country but WHOIS has a country. Do you want to see these reported here? location lookup 79.137.220.70 79.137.220.70: Network : 79.137.216.0/21 Autonomous System : AS12695 - LLC Digital Network ----------------------------------------------------------- WHOIS results from whois.ripe.net ... inetnum: 79.137.213.0 - 79.137.223.255 netname: DINETHOSTING-NEXT descr: Hosting and Colocation Services country: RU ...
> Do you want to see these reported here? Yes, absolutely, keep them coming. :-) While I have a theory on why we do not show a country code for 140.128.0.0/13, the missing country information for 79.137.216.0/21 surprises me. Will look deeper into it and report back.
Is this as expected? [root@ipfire ~]# location lookup 85.25.198.85 85.25.198.85: Network : 85.25.192.0/20 Autonomous System : AS8972 - Host Europe GmbH ------------------------------------------------------------ WHOIS results from whois.ripe.net ... inetnum: 85.25.176.0 - 85.25.211.255 netname: DE-GODADDY-20050301 country: DE ...
"AU" vs Asia/Pacific ? [root@ipfire ~]# location lookup 212.115.127.229 212.115.127.229: Network : 212.115.124.0/22 Country : Asia/Pacific Autonomous System : AS18013 - ASLINE LIMITED ---------------------------------------- WHOIS results from whois.apnic.net ... country: AU admin-c: IANA1-AP tech-c: IANA1-AP mnt-by: MAINT-APNIC-AP mnt-lower: MAINT-APNIC-AP status: ALLOCATED PORTABLE last-modified: 2008-09-04T06:51:29Z source: APNIC ...
And ... [root@ipfire ~]# location lookup 85.25.198.85 85.25.198.85: Network : 85.25.192.0/20 Autonomous System : AS8972 - Host Europe GmbH [root@ipfire ~]# ---------------------------------------- WHOIS results from whois.ripe.net ... inetnum: 85.25.176.0 - 85.25.211.255 netname: DE-GODADDY-20050301 country: DE ...
And a few more ... 62.60.177.241 '62.0.0.0 - 62.255.255.255' 103.215.230.84 '103.215.228.0 - 103.215.231.255' 193.135.144.228 '193.135.144.224 - 193.135.144.231'
First, thank you all for reporting these networks. A decent amount of these was misclassified due to #12595, which is now fixed. You should observe this in the output of the "location lookup" command: [root@maverick ~]# location version Mon, 05 Apr 2021 05:02:51 GMT [root@maverick ~]# location lookup 140.135.36.163 140.135.36.163: Network : 140.128.0.0/13 Country : Taiwan Autonomous System : AS1659 [root@maverick ~]# location lookup 79.137.220.70 79.137.220.70: Network : 79.137.216.0/21 Country : Russian Federation Autonomous System : AS12695 - LLC Digital Network [root@maverick ~]# location lookup 85.25.198.85 85.25.198.85: Network : 85.25.192.0/20 Country : Germany Autonomous System : AS8972 - Host Europe GmbH [root@maverick ~]# location lookup 85.25.198.85 85.25.198.85: Network : 85.25.192.0/20 Country : Germany Autonomous System : AS8972 - Host Europe GmbH [root@maverick ~]# location lookup 193.135.144.228 193.135.144.228: Network : 193.135.144.0/23 Country : Switzerland Autonomous System : AS3303 - Swisscom (Schweiz) AG The rest of the IP addresses reported belong to a group of Autonomous Systems hijacking large stolen AfriNIC IPv4 networks (https://mybroadband.co.za/news/internet/330379-how-internet-resources-worth-r800-million-were-stolen-and-sold-on-the-black-market.html). These operate out of some place in the Asia/Pacific area, probably a data center in Hong Kong, but I have no evidence for that. However, the operators of these ASNs tamper heavily with RIR data, so we cannot trust information provided by them. Therefore, all of the IP networks announced by them will be flagged as being located in the Asia/Pacific area, unless we have qualified information which location they precisely trace back to. If you encounter any more mistakes or oddities, please let me know here. :-)
Closing this ticket, since there is no necessity for it anymore. Users tend to open new tickets for distinct problem, which is the better way of dealing with inaccurate data, and I will continue the never-ending hunt for inaccuracies or deliberately faked data on a daily basis.