Geo-IP Rules

[jaggzh]

Hello! Beautiful project. Visit my facebook.
Kidding.

Okay, so this isn't a bug, but an idea. I thought it might be valuable to be able to set rules where the connection was allowed/denied based on a GeoIP lookup of the IP. In this manner we could, for instance, restrict a connection to be only within ones own country. It would of course only be as reliable as the geoip library used (ex. libgeoip), and it could be built with other options (if there are other geoip libs).

[impredicative]

What this is effectively asking for is an IP lists-based firewall, with auto-updated lists. Are there any other preexisting Linux tools for it?

[gustavo-iniguez-goya]

Visit my facebook.

🤣

No idea @impredicative . There're scripts [0] to add lists [1] of IPs using ipset [2]

I think that blocking IPs by geolocation shouldn't part of the core. It could be added as a plugin (we don't support plugins at the moment..) or by adding a new type of "lists rules": lists.ips (both IPs and network ranges)

opensnitch/daemon/rule/operator.go

Line 51 in 041cf45

OpDomainsLists = Operand("lists.domains")

It would be straight forward. The only thing is that there're no support yet for automatic updates of lists of domains (or IPs). You'd have to update them with a script for now, and you could use any type of list: grouped by geolocation, spam, etc.

0. https://github.com/trick77/ipset-blacklist
1. https://iplists.firehol.org/
2. https://ipset.netfilter.org/

[ashvinlobo]

Hi...i reccomend using CSF Firewall with ipset option enabled and using ipsets using Maxmind geolite2 database.

[Ph0rk0z]

As long as it doesn't pull in a geoclue dependency or something. I generally remove geoIP packages from my os as there is very little control over them.

[jaggzh]

Maybe it has to wait until plugins are available, where such features can be a separate optional packages with their own dependencies. opensnitch-mod-geoip-maxwhatever opensnitch-mod-white-n-blacklist-sqlite etc.

…

On Thu, Sep 16, 2021, 8:38 AM Forkoz ***@***.***> wrote: As long as it doesn't pull in a geoclue dependency or something. I generally remove geoIP packages from my os as there is very little control over them. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#485 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE3AV7J6RVYZ3TMDO3KFABLUCIFOVANCNFSM5DAWBC5Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[gustavo-iniguez-goya]

For now there won't be any third-party dependencies. There will be 3 new options to load from a directory lists of IPs, net ranges and domains with regular expressions, but you'll have to download and update them.

[jaggzh]

Okay. Unfortunately this doesn't address the issue I brought up at all, but it's a good feature itself. The actual use case for geo ip was when I was using tor. Tor establishes its initial connection but picks some entry node somewhere -- random or load distributed I guess. Once opensnitch was running I found it uses nodes throughout the world. I'd prefer my entry node to be in my home country, so I'd want to set, just for those connections, a restriction where it would be "geo-fenced" to IPs that look up to my country. Anyway, just an idea and capability that seems like it could have real practical purposes.

…

On Thu, Sep 16, 2021, 2:11 PM Gustavo Iñiguez Goia ***@***.***> wrote: For now there won't be any third-party dependencies. There will be 3 new options to load from a directory lists of IPs, net ranges and domains with regular expressions, but you'll have to download and update them. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#485 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE3AV7MMO2NAUDGQ4KT2IS3UCJMRRANCNFSM5DAWBC5Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[gustavo-iniguez-goya]

hmm, I see. Well, maybe you could have two rules:

• 000-allow-tor:
  [x] precedence, [x] From this executable: /usr/bin/tor, [x] To this IP/Network: 1.2.3.4/16

Where 1.2.3.4 is the network range of the IPs you want to allow .

• 999-deny-tor
  [x] From this executable: /usr/bin/tor , [x] Action: Deny

I don't know how Tor will respond to these restrictions, but I guess that it'll keep trying until it finds an IP that can connect to.

[jaggzh]

What about a generalized system, which doesn't have any specific dependencies, but can hand off the connection to an external binary/script specified by the user, with some spec for how that app communicates the result information? Then a tor-opensnitch-eval.sh script could be used.

(Again, blacklists aren't going to work here -- the user doesn't maintain a list of IPs/nets -- it gives an IP to geoiplookup/libgeoip and gets a city/state/country back (or whatever)). Allowing an arbitrary external script does mean the user would have to maintain the criteria within their own script, though, but the method would work.

Consequently, this is effectively a plugin-type of system, except with this method it will tend to offload configuration into the external scripts, instead of actually "plugging in". For example, an external script probably doesn't have a way of adding config options to opensnitch['s ui] for the user to choose from, nor a way to hook events itself, or access anything other than what it's provided by opensnitch outright.

[gustavo-iniguez-goya]

For future reference this could be achived by using (for example) maxmind GeoIP DB. Available on Debian Sid. I haven't checked out t if it's available on other distros though, and I'm also not aware of other similar DBs.

It could be added as a plugin (calling external scripts or not), or as a new type of lists. The user could define a new rule where they could select which countries to allow or deny, globally or per application.