Welcome new users!

[friendly-bits]

Probably barely anybody reads this but for those who do: Lately I've been noticing that this repository is starting to attract some (positive) attention and I see that people are downloading and using this project, which I'm happy about. You are always welcome to ask questions or to ask for additional features (or report bugs if any).

At this occasion I'll also mention that the next release should be coming soon'ish, which features support for additional shells (ksh93 and yash), more robust compatibility checks, improved reliability and some security improvements as well. Keep posted.

[OIITCONZ]

Hi @friendly-bits
Thanks for the great script. I have just tried it on an Ubuntu LTS 24.04 and it was very smooth.

Two questions : I notice ICMP is not working. I geo white listed NZ (so banning all other countries) I cannot ping the server. Is that this shell or standard server functionality? I can ssh in on a different to standard port so it handled that very well.

I am wanting to ban all traffic from all countries except NZ and then either forward a set of ports or forward everything from this server to a fixed ip address. The end result is to setup a community minecraft server - which is getting hammered by scum from other countries. Keeping it NZ only keeps the ND kids we run the server for safe. Are there any configurations that allow this?

Thanks for the great work,

[friendly-bits]

Hi there @OIITCONZ
I'll answer your first question first.
geoip-shell doesn't specifically block any ports by default. So probably ICMP not working is unrelated. You can check if geoip-shell has anything to do with it by issuing this command: geoip-shell off and checking if ping is working now. This disables geoip-shell completely. To re-enable later, use geoip-shell on.

[friendly-bits]

As to your second question, I'm not sure what you mean by "forward a set of ports or forward everything" but it sounds like you want to set up a tunnel. geoip-shell doesn't do tunnels but there is plenty of software for this. geoip-shell will not interfere with that software, unless for some reason that software needs to receive traffic from blocked countries. What geoip-shell does is it fetches a list of ip subnets which belong to certain country or countries (in your case NZ), creates an ipset (if using iptables) or nftables set (if using nftables) out of that list, and (in whitelist mode) creates iptables or nftables rules which block all inbound traffic which didn't come from ip addresses included in the set. When installed for all network interfaces rather than a specific WAN network interface, geoip-shell also creates some allow rules in order to not block DHCPv6 and other essential communication (which is non-routable, so should not affect the effectiveness of geoip blocking).

Generally, if you need things which should occasionally receive traffic from blocked countries, you would have to either add those countries to the whitelist, or come up with some sort of a workaround, for example here users came up with a workaround to allow letsencrypt to renew certificates (you will probably need to use Google automatic translation):
https://forum.netcup.de/administration-of-a-server-vserver/vserver-server-kvm-server/18634-geoblocking/

If you have any additional questions about geoip-shell, please feel free to ask.

[friendly-bits]

Also note that the available geoip data is not 100% reliable. In some cases some ip subnets may be listed under one country but actually belong to a different country. This is not frequent but this happens. This is a shortcoming of all geoip blocking, not just geoip-shell. Specifically for NZ, I don't know how many ip subnets are assigned wrong and in which way (either an address in NZ is listed under a different country or an address in a different country appears under NZ). It could be that NZ is not affected at all, or it could be that you will have issues. You will just need to try and see.

geoip blocking is very effective for reducing the attack surface despite this shortcoming, however if you need a guarantee that 100% percent of people trying to access your server from NZ are not geoblocked, this guarantee can not be given.

[friendly-bits]

geoip-shell will not interfere with that software, unless for some reason that software needs to receive traffic from blocked countries.

To clarify this point, geoip-shell creates a firewall rule which will allow the locally running software to make outbound connections to blocked countries and receive response. Only if the software is listening for inbound connection requests (without establishing an outbound connection first) then it will not be able to see it if given request comes from a blocked country.

[OIITCONZ]

Basically I am wanting to block all ips from anywhere but NZ. Then set up rules similar to this : sudo iptables -A INPUT -m set --match-set nz_ips src -j ACCEPT sudo iptables -t nat -A PREROUTING -m set --match-set nz_ips src -j DNAT --to-destination 123.456.789.1 sudo iptables -A FORWARD -d 123.456.789.1 -j ACCEPT Obviously 123.456.789.1 is not my real destination ip address. My concern is if i do rule 1 above - I cannot set to only allow NZ ips - but geoip should be doing that so I can ignore rule 1 Rule 2 - Is where this gets difficult. How do I set a prerouting so only acceptable ips from an NZ range are routed out by rule 3? Rule 3 How and where would I set this. My server is an out of the box Ubuntu LTS 24.04 . I turned off UFW and turned on IPTables. The iptables rules above are from examples for doing this using iptables and ipset sources but none of them seemed to work - leaving me unable to ping out, resolve DNS etc. Yours lets me do those things so now I am trying to add the forwarding rules as the final step. The end goal is only allow minecraft players from NZ to connect to the server. We are getting hammered by dipsticks from overseas which is chewing up bandwidth and CPU faster than it should for a small server. Ideally only ports 4000 - 40010 would be forwarded and all others dropped (SSH excluded) This box is a relay / router to stand in front of the minecraft server. I could run geoshell on the minecraft server but there are other considerations (like 11 other servers behind the same nat) and some of them need overseas to connect. I suspect the best option is put MC on its own box, and run geoip on the MC box. I would prefer to use a VPS with a wide bandwidth and other firewalls infront rather than direct to my server. Thanks for your help and answer. Shane Shane Hollis Outsourced Information Technology Limited Mob: 022 626 5084

…

-- ---- All Outsourced Information Technology Limited's work, sales and correspondence is covered under our terms of service and privacy policies found at https://outsourcedit.co.nz/tandc . Our online invoicing system is found at https://books.zoho.com/portal/outsourcedinformationtechnolog and invoices, receipts and quotes can be accessed there. All goods and services sold are covered under the Sale of Goods Act and the Consumer Guarantees Act of NZ and will be liable for GST where applicable.

------ Original Message ------ From "friendly-bits" ***@***.***> To "friendly-bits/geoip-shell" ***@***.***> Cc "Secure Log On and Form System" ***@***.***>; "Mention" ***@***.***> Date 24/08/2024 8:41:32 pm Subject Re: [friendly-bits/geoip-shell] Welcome new users! (Discussion #4)

As to your second question, I'm not sure what you mean by "forward a set of ports or forward everything" but it sounds like you want to set up a tunnel. geoip-shell doesn't do tunnels but there is plenty of software for this. geoip-shell will not interfere with that software, unless for some reason that software needs to receive traffic from blocked countries. What geoip-shell does is it fetches a list of ip subnets which belong to certain country or countries (in your case NZ), creates an ipset (if using iptables) or nftables set (if using nftables) out of that list, and (in the whitelist mode) creates iptables or nftables rules which block all inbound traffic which didn't come from ip addresses included in the set. When installed for all network interfaces rather than a specific network interface, geoip-shell also creates some allow rules in order to not block DHCPv6 and other essential communication (which is non-routable, so should not affect the effectiveness of geoip blocking). Generally, if you need things which should occasionally receive traffic from blocked countries, you would have to either add those countries to the whitelist, or come up with some sort of a workaround, for example here users came up with a workaround to allow letsencrypt to renew certificates (you will probably need to use Google automatic translation): https://forum.netcup.de/administration-of-a-server-vserver/vserver-server-kvm-server/18634-geoblocking/ If you have any additional questions about geoip-shell, you are welcome to ask. — Reply to this email directly, view it on GitHub <#4 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM7P7INLNJNUTPWQ3XZQGDTZTBBLZAVCNFSM6AAAAABNBHSZRKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANBTGY3DMOA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[friendly-bits]

Hi, did you manage to achieve the config you wanted? I posted some replies below which I'm not sure you've seen.

[friendly-bits]

First off, you should probably get acquainted with netfiler hooks:
https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks

(this is from the nftables wiki but the netfilter kernel infrastructure is used by iptables as well)

geoip-shell creates rules attached to the prerouting hook. With nftables this is done via a chain which attaches directly to the hook, with iptables geoip-shell uses the PREROUTING built-in chain in table mangle (read section 2 of NOTES.md for additional details).

This means that geoip blocking is done before any routing decisions about the ingress traffic are made. In other words, traffic from geoblocked countries will not reach table nat where your second rule is located. So with geoip-shell, you don't need the match-set in that rule.

Now correct me if I'm wrong but it sounds like you actually want to geoblock only traffic arriving on some specific ports and let all the other traffic reach its destination. You can do this with geoip-shell: read NOTES.md, sections 9-11.

Last but not least please run geoip-shell status and make sure that the firewall backend is set to iptables. When nftables is present in the system, geoip-shell defaults to nftables. So if you find out that currently the firewall backend is nftables then use this command to change the firewall backend to iptables:
geoip-shell configure -w ipt

[friendly-bits]

You can also read this for more information on how packets traverse tables and chains with iptables:
https://www.baeldung.com/linux/iptables-chains-tables-traversal

[friendly-bits]

Sorry, for some reason the links to NOTES.md didn't work in the above answer, fixed now.

[friendly-bits]

I may not have answered all of your questions directly but I hope that with the above information, you can come up with the specific solution you need. If you still need more help after you have processed that information, feel free to ask.

[OIITCONZ]

Hi, Yes - I saw the replies. No - Not achieved yet. I had a client whose system went down ( gotta love electricians cutting cables) so had to put this on pause until this afternoon. I'll let you know how it goes. Thanks you. I see you are well named friendly-bits. BTW : Do you have a donate link? Buy you a coffee or two? Shane

…

Message ID: ***@***.***>

[friendly-bits]

No need really for a coffee but you can give the repo a star if you fancy.
And please do keep me posted.

[Fantanchero]

Hello.
I'm new on sysadmin.
Trying to setup geoip it gives me the following error:
" ...... Error: Could not process rule: Numerical result out of range..........."
Maybe I'm missing or outdated some dependency?
Thanks in advance.

Debian 12.

[Fantanchero]

After some investigation, the error:
Error: Could not process rule: Numerical result out of range
refers to nftables maximum length of a set name is 15 characters (read 27 on other site).
If I'm not mistaken, if the name is "UY_ipv4_2024-10-08_geoip-shell" then is 30 chars.
Is there a way to modify the naming scheme on the script?

[friendly-bits]

Indeed, turns out that nftables wiki says the set name must be 16 characters or less:
https://wiki.nftables.org/wiki-nftables/index.php/Sets

Which is weird because geoip-shell creates sets with 31 characters-long names and this works just fine on all systems I've tested with (Debian, Linux Mint, Gentoo, OpenWrt). Perhaps there is some obscure kernel compile-time option which can be set to enforce this and most distros don't set it.

Current set names format is kinda ingrained in the geoip-shell code, so quite a bit of modification will be necessary. I'll make an experimental branch which will implement shorter set names.

[friendly-bits]

The experimental branch is here:

https://github.com/friendly-bits/geoip-shell/tree/shorter-nftables-set-names

Please test with it and let me know if the issue is fixed.

[Fantanchero]

Working perfectly now
Thanks you very much.

Successfully configured geoip-shell for firewall backend: nftables.

Ip lists in the final whitelist: 'UY_ipv4 UY_ipv6'.

View geoip status with 'geoip-shell status' (may require 'sudo').

Install done.
fanta@linux:~/firewall/geoip-shell-shorter-nftables-set-names$ sudo geoip-shell status

geoip-shell status:

geoip-shell v0.5.8

Firewall backend: nftables
Geoip blocking mode: whitelist
Ip lists source: ripe
Country codes in the whitelist: UY ✔
IP families in firewall rules: ipv4 ipv6 ✔
Geoip rules applied to network interfaces: venet0

Protocols:
tcp: Geoip is applied to all ports
udp: Geoip is applied to all ports

Geoip firewall chain: enabled ✔
Whitelist blocking rule: ✔

nftables sets optimization policy: performance

Cron system service: ✔
Update cron job: ✔
Update schedule: '12 4 * * *'
Last successful update: Oct-10-2024 19:34:29
Persistence cron job: ✔
Automatic backup of ip lists: On

No problems detected.

[friendly-bits]

Thanks for reporting this and helping me identify the issue. The fix is now incorporated in v0.5.9.

[oraculix]

Hello Anton,
I just want to leave a big THANK YOU! for sharing your work here.

After some years of not having the need, I researched into Geoblocking again and – after sifting through quite some outdated stuff – luckily stumbled upon your scripts.

Within a few minutes, geoip-shell was up and running on my Debian Bookworm Instance that has an SSH Port open to the public Internet. And many unwelcome visitors trying to get in from day one on.

Keep up the good work!
Cheers, Uwe

[friendly-bits]

Hi Uwe and thank you for sharing your experience. This kind of responses makes it worthwhile to do open source development.

[orkaa]

Hey friendly-bits,

I also wanted to say a quick thank you!

I've been running a public endpoint for my homelab and wanted to restrict the access to my home country only. I looked into a custom nginx setup, then bunkerweb and while those worked, they only covered the HTTP(s) ports.

Then I found your project on reddit, that protects the whole server, including SSH and the setup is super simple! Loving it so far!

[friendly-bits]

Hi, thanks for this nice review. Glad geoip-shell is useful to you.

[QuaxEros]

Of course i read your welcome post!

So.. I'm since close to 3 weeks under heavy attack of botnet(s) and the guys are giving me no sleep. Using MANY thousands of single IPs and over a thousand IP-ranges. Don't know why they think it's worth their time so much...

Held up well for these weeks but my fail2ban block-lists became so large it started interfering with proper functioning of the server(s), f2b can hardly keep up and not all connects provoke errors to react on. Needed a different approach, geo-blocking seemed obvious but hard to find a decent option. Luckily stumbled upon your repo and decided to give it a go. Worried about interference with my other firewall related measures and (over)complicated setup, some NAT-guests behind hypervisor, some direct on WAN bridge, 2 web servers, 1 mail server, a panel, a docker host, internal virtual local nets, The Works... All for community and non-profit projects.

Started using Geoip-shell carefully today and for now not having any issues besides my lips cramping from my constant smile... Might even catch some sleep this night!
Having it in the MANGLE table seems to make it trouble-free pre-filtering before f2b and other rules (still have to test some though...)

Your coffee and beer is standing in front of me, come drink it with me my man !!

[friendly-bits]

Great to hear that this little project helped you with what sounds like a nightmare. I started working on it mainly to stop the bot scanning and never imagined that it would be used to stop a targeted botnet attack. I also have to say that depending on the resources and determination of the attackers, geoblocking may turn out to only provide a temporary relief, till the attackers figure it out and adapt.

About avoiding interference with your services: geoip-shell supports specifying trusted ip's or subnets which will be excluded from the filter. If having any trouble, you may need to figure out which ip's should be allowed and use that geoip-shell option. Depending on the situation, you might also need to exclude certain ports from geoblocking, which is supported by geoip-shell as well.

I appreciate the invitation for coffee/beer. However we are statistically unlikely to be even in the same geographical region (I live in a small country which I don't really want to publicly disclose). So I have to decline. I also currently don't accept donations. But I do appreciate the attitude.

Please do keep me posted on how it goes with the whole attack situation.

[QuaxEros]

I'll open up my own thread and explain my setup and use case so we can go into the specifics of how it could hinder (or not) my other defenses and rule chains. For now Asia and Brazil are the origin of all the zombies (not scattered all over the world). Yep, that is a bit strange, i feel it is almost a personal vendetta with the way the resources are used and the attack is coordinated, my servers are kind of insignificant also.. It's not a DDOS but a brute force on all services. Will have time for this in a few days i hope... CU Later..!

[namshubs]

Using openWRT i wanted to explore the use of the geoip-shell for routing only and not strictly for blocking.

My intention is to split the traffic from my homecountry (DE) IP set directly to the WAN
and the other Traffic i want to route through an existing openvpn tun0 dev.

I manged such a configuration with manual ip lists some years ago but needed a lot of external help
and a lot of shellscript workarounds.(I found i have much less patience ourdays :)

I wonder if it wouldnt be faster using the geoip-shell script for the ip-set maintainance and marking.

To access the ip-set names i would like to avoid to "extract the ip-set name with date" each time since the set name has now a date suffix.
Is there a flag or method to name the ip-set always the same ? (IP_DE_4) or IP_DE_6) ?

If someone has addititional recomenddations for this goal please let me know, i am quite out ouf the practise in these days.

I admire the elegance and the smooth integration of the project! Kudos!

[friendly-bits]

Hi, thank you for the compliments. If you want to use sets created by geoip-shell for your own purposes, in principle you can configure geoip-shell with arbitrary country codes and disable geoblocking:

geoip-shell configure -c <"country_codes"> -N true

You can then use the ipsets created by geoip-shell for your purposes. As to sets naming, unfortunately sets creation logic needs the date in set names. The main reason is that when updating sets, geoip-shell creates a new set first and then removes the old ones, and you can not create a set with the same name as the existing set. This needs to be implemented this way for technical reasons which are a bit too long to explain. If you want to get a name of a particular set, you could either implement your own solution or use internal functions from the geoip-shell scripts:

#!/bin/sh

interesting_country_codes="<your_country_codes>"
interesting_families="4 6"

# source required geoip-shell scripts
. /usr/lib/geoip-shell-lib-common.sh &&
. /usr/lib/geoip-shell-lib-<nft|ipt>.sh ||
    { logger -t <your_script_name> -p user.err "ERROR: Failed to source geoip-shell scripts."; exit 1; }

ipsets="$(get_ipsets)" && [ -n "$ipsets" ] ||
    { logger -t <your_script_name> -p user.err "ERROR: Failed to get geoip-shell ipsets."; exit 1; }

for family in $interesting_families; do
    for country_code in $interesting_country_codes; do
        get_matching_line "$ipsets" "" "${country_code}_${family}" "*" matching_ipset

        [ -n "$matching_ipset" ] ||
            { logger -t <your_script_name> -p user.err "ERROR: Failed to get IP set name for '${country_code}_${family}'."; continue; }

        case "$matching_ipset" in *"$_nl"*
            logger -t <your_script_name> -p user.err "ERROR: Got string containing newlines for '${country_code}_${family}'."
            continue
        esac

        # do something with the ipset $matching_ipset
    done
done

Replace <strings_encolsed_in_angle_brackets>.

Note that internal geoip-shell functions API may change in future releases (although I am not planning to change these specific functions right now but I can't guarantee they won't be changed), so this script may require adjustments at some point in the future.

I can not test this code right now so it may or may not need some minor changes.

[namshubs]

Thank you for the fast reply!
First. I understand this date suffix is part of the system.
Second, i just looked in your sample code, and i guess thats the way.
So i will sharpen my skills with your sample code!

[namshubs]

hello, let me know if i stress your patience :)

to load the ip list into nftables i had at least "whitlist" the country, whithout no sets make it into nft.

e.g.

geoip-shell configure -c "DE" -N true -m whitelist

with a little filtering i could identify then the table names
nft list sets | awk '$1=="set" && $2 ~ /^RU_[0-9]+_[0-9]{4}-[0-9]{2}-[0-9]{2}$/ { print $2 }

lists now the setnames and i can run them in my own script.
DE_4_2025-07-30
DE_6_2025-07-30

i now try to use this in the further routing script / preparation
txs meanwhile!d

[friendly-bits]

Hi, the command nft list sets will print sets name and sets contents, which you then need to filter. This is unnecessarily slow. Instead, you could use the command nft -t list sets. The -t option prevents sets contents from being printed.

In general, this approach has the downside of printing all sets in all tables, and if another set in another table will match the regex used in the awk command (BTW this particular regex will only match sets for Russia because of RU) then you get set names you did not expect. Instead you could use the command:

nft -t list table inet geoip-shell | awk '$1 == "set" && $2 ~ /^[A-Z][A-Z]_[46]_[0-9]{4}-[0-9]{2}-[0-9]{2}$/ {print $2}'

Which will print the names of all geoip-shell sets for countries.

[namshubs]

To give you a little background
The routing solution shall be for my former coworkers and friends in Sankt Petersburg.
Most of the foreign "western" internet is meanwhile blocked there (meta, youtube, linkedin, nearly all media outlets bbc, spiegel, welt.de etc.). Most western VPN are also not working anymore, yet a view are under the radar.

Most of the russian websites for the dayly use (banking apps, services, railticket etc) meanwhile detect western ips (if you switched to vpn) and geoblock them (!) . So for a normal person interested to have a global information input, is in a permanent hassel to switch vpn on and off.
My idea is to give them a proper routing configuration with routing split via vpn tunnel or wan. That would give the people the option at least at home to have the unblocked internet freedom back. It could work also in other restricted internet realms.

*actually thinking about it "is also right the opposite of what geoip-blocking is meant for... :)"
i hope you dont mind my intention.

Regarding this nft list sets thing...

I choosed this approach since i could not get any results using the
ipsets="$(get_ipsets)" from your demo script. It was always empty but the nft list sets showed the table and sets

The nft list tables method was then my workaround to get the names of the tables.
so thank you for the -t and proper filter.

If i get it done i will definetly publish an howto documentation as first project in GitHub, so i guess it will take a while :)
Thanks!

[friendly-bits]

Thanks for the explanation. I can see how implementing your idea could be useful. If it works out, perhaps I could consider adding a mode of operation where only sets are created and maintained without any firewall rules.

I definitely do not mind your intention. geoip-shell was created to provide a convenient open-source solution to a particular problem. If geoip-shell can accidentally help solve another problem, I'm all for it.

i could not get any results using the
ipsets="$(get_ipsets)" from your demo script

Then there is a bug in that sample code. As I mentioned, I could not test it when writing it. This should be easy to troubleshoot and solve but the nft | awk one-liner is simpler, better and does not rely on internal API, so IMO there is no need to use the sample code.

If i get it done i will definetly publish an howto documentation as first project in GitHub

Please do let me know if/when this happens. BTW I would be happy to help you with this project, either midway or after its first public release. You can contact me privately on the OpenWrt forum.

[namshubs]

Sorry for the late reply. Short status...
I spend the weeks free time on the task.
2 times it suddenly worked. But each time after reboot not (all traffic then again was routed with the "Catch All Rule" via vpn), the marked ips or the look up failed. Still iterate myself around the hows and whys.
Will try again after a weekend in the Nature and get back! I definetly need to learn more about tables chains and rules...

[friendly-bits]

each time after reboot not

Note that geoip-shell sleeps for 30s after reboot, and then fetching, parsing and loading ipsets takes some more time. geoip-shell will refuse to change the config until it's done with the previous task. BTW you can always use logread to see what's going on during boot.