Bug 12421 - add overrides for networks with faked location
Summary: add overrides for networks with faked location
Status: CLOSED FIXED
Alias: None
Product: Location Database
Classification: Unclassified
Component: Database (show other bugs)
Version: unspecified
Hardware: all All
: - Unknown - Minor Usability
Assignee: Peter Müller
QA Contact: Michael Tremer
URL:
Keywords: 5MinuteJob, Umbrella
Depends on:
Blocks:
 
Reported: 2020-05-31 13:51 UTC by Peter Müller
Modified: 2022-02-19 11:25 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Müller 2020-05-31 13:51:55 UTC
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?)
Comment 2 Horace Michael (aka H&M) 2020-11-20 08:30:46 UTC
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
Comment 3 Peter Müller 2020-11-20 11:03:30 UTC
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.
Comment 4 Horace Michael (aka H&M) 2020-11-22 13:29:21 UTC
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
Comment 5 Peter Müller 2020-11-22 21:22:58 UTC
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
Comment 6 Horace Michael (aka H&M) 2021-01-20 20:42:15 UTC
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!
Comment 7 Peter Müller 2021-01-26 15:44:59 UTC
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
Comment 8 Charles Brown 2021-03-15 16:55:34 UTC
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
.
Comment 9 Charles Brown 2021-03-20 19:54:20 UTC
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
...
Comment 10 Peter Müller 2021-03-20 20:21:45 UTC
> 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.
Comment 11 Charles Brown 2021-03-24 13:09:49 UTC
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
...
Comment 12 Charles Brown 2021-03-24 23:33:51 UTC
"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
...
Comment 13 Charles Brown 2021-03-24 23:38:56 UTC
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
...
Comment 14 Charles Brown 2021-03-25 10:19:26 UTC
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'
Comment 15 Peter Müller 2021-04-05 12:04:39 UTC
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. :-)
Comment 16 Peter Müller 2022-02-19 11:25:32 UTC
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.