Is it possible to see a list of countries that are making connections into the server?

[roadhazard]

Recently discovered this project and I think it's amazing!

One question.... would it be possible to add some functionality that will record a list of countries that made (OR ATTEMPTED TO MAKE) a connection into my server?

Previously, I was using Untangle firewall. One of the things I would do with it is check the log files from time to time and look for foreign countries that made attempts to connect to my Plex server and then added those countries to the block list.

If geoip-shell kept a list of countries where connections were coming from, I think that would be a nice add. As admins, we could check this log file and see where traffic is coming from.

But if there's 507 connections from the US, don't add 507 lines, maybe do something like this:

US, 507 (Put it on a single line to indicate 507 connections from US based IP addresses. This will help keep the file small and easily read). It could be a rolling txt file and maybe keep 2 days worth of info?

[friendly-bits]

Hi, thanks for the kind words. I'll look into implementing this functionality. Probably will take some time, because I am currently implementing support for outbound geoblocking (in addition to the existing inbound geoblocking functionality). It's a rather big change which will probably take a while to finalize and debug. Once that's done, I'll be open to implementing additional features.

[roadhazard]

Ok, thanks for the reply and no hurry on implementing this. Have a great day!

[friendly-bits]

Looking into this, I can think of 3 possible ways to implement this sort of functionality:

1. Real-time logging of dropped ip addresses which should be relatively computationally and memory-consumption-wise inexpensive. Then you could use another app to process the logs and map the logged ip addresses to countries.
2. Real-time logging of dropped ip address + origin country - this would require to load a (relatively) large map of all ip ranges in all countries (consuming much more memory) and then each dropped ip address would be looked up in that map in real time (computationally expensive operation). I'm not sure if this is doable with iptables but there is a way to implement this with nftables.
3. Real-time logging of dropped ip addresses only (as in first option), and then implementing log processing and ip-address-to-country mapping functionality in geoip-shell, which would run periodically (say once a day). This would still require to temporarily load all known ip ranges into memory and may require quite a bit of system memory at that time (not sure how much before testing) and then map all logged ip's to these ranges, which may or may not be a computationally expensive task, depending on the volume of the ip addresses and the CPU. The benefit of this approach vs the 2nd option is that your firewall is much less likely to get overwhelmed by processing a large number of dropped requests in real time (a.k.a denial of service).

Which sort of logging do you think would be most useful?

[roadhazard]

So sorry for the delayed reply but yes, I think option 3 would be fine. At the end of the day, I just need to know which countries are sniffing around at a few ports I have open then I can bring the ban hammer down on them. :)

[QuaxEros]

The OP didn´t answer yet but i have the impression that your optional script check-ip-in-source.sh might have the potential to be reworked for option 3 (my favorite). Cron'ing it to the admin's discretion or even manual launch when it is quiet might be just what we need.

More opinions anyone ??

[roadhazard]

Just replied to the author. I agree, I think option 3 would be good.

[friendly-bits]

Thank you both for the input. I'll start off by implementing blocked ip addresses logging and then get to the second part which is mapping those addresses to countries.

As to check-ip-in-source.sh, it relies on grepcidr utility as a way to check specific ip addresses or ranges vs a list of ip ranges for a specific country. Technically it would be possible to use this method in a loop to check an arbitrary list of addresses vs an arbitrary list of countries. This might be an acceptable solution if using geoip-shell in blacklist mode with a limited number of countries assigned to the blacklist, but I believe that most people use it in whitelist mode, which means that a solution based on grepcidr would require sequentially checking logged addresses vs ip ranges belonging to every country except the one or few countries in the whitelist. I think this would be very inefficient. I'll revisit grepcidr options to check if it offers a way to do this in a more reasonable way. Currently my idea is to temporarily load all ranges for every country into ipsets or nft sets and then utilize the excellent performance of the netfilter kernel component to efficiently map each logged ip address to one of these sets. Maybe it's a misuse of the kernel infrastructure. Not really sure what's the best way forward on that front yet.

[QuaxEros]

Man, you work hard on this. And although i didn't dive into your code yet (sysadmin, not a coder. But hey, it's shell script so i will surely) i feel this is a very useful, robust and simple to deploy product. I use it in Blacklist mode (public mail server, just filtering out the bad guys). I'll let you do your magic, you do it well.. Goin' to install on more of my servers, i'll let you know how it goes and my findings in a week or so 'cause i do have some questions for certain use cases but too busy fighting of the attacks for now to do some research. I'll open my own thread.. Thanx for now, have a wonderful day!!

[friendly-bits]

I did spend a lot of time with this project and basically learned coding at the same time. Hence the code went through multiple rewrites as my coding skills were improving. Unfortunately, I am still not satisfied with the code, mainly because my initial design goals turned out to be a tad too ambitious for a shell code project. In particular, implementing a good command-line interface and associated parsing and validating of arguments turned out quite tricky, and as the variety of supported options grew, it only became trickier. The other ambitious goal was universality, i.e. support for almost any Linux system. This basically meant giving up on using extensions of higher-level shells like Bash and limiting it to the primitive features of the POSIX standard. The main disadvantage is the lack of support for local variables, which makes large scripts quite prone to bugs related to namespace collisions. Finally, I wanted to support OpenWrt, which basically means making the code as compact as possible. As the project grew, this became more difficult. So I came up with methods to reduce the size, however that significantly impacted code readability. So yeah, it may not be an easy task to make sense of some parts of the code, especially the -manage script which mostly consists of complex arguments- and options-parsing logic. But you are most welcome to take a look.

P.s. yet another of my design goals was reliability, so much of the code is error checking and handling, which, I believe, eventually gives this feeling of robustness. This part I am actually quite happy about.

[QuaxEros]

I'll look to understand, not to improve :-) I love the fact that you want to support OWrt. I've got 2 of 'em, cannot use behind my fiber (integrated ONT).
As defense against the "attack" geoip-shell does a fairly good job. There is only ~5-10% left of the nasty guys, much easier to handle though i still have to be looking at my screen. But at least i have time to eat and sleep now and they are a lot less effective. Great Job!!