Geoblocking project which may work its way into OpenWRT

I think we should consider download lists of IP addresses/ranges and build firewall rules from them as the base functionality here. Not much extra code to go from country lists to various IP block lists. A lot of people have written scripts to do this over the years for their own systems.

The current banIP has the advantage of being further along - supports nftables and has an OpenWRT web UI for configuration and status along with various other integrations.

GeoIP blocking is not a completely different thing to arbitrary lists blocking, I agree. And it may not be much code, depending on how you code. The way I code involves extensive error checking, extensive documentation, a lot of figuring out efficiency issues, and quite a bit of thinking about making the product easy to use and accessible. Considering all that, expanding functionality to a seemingly nearby area is actually a leap. That's one thing. Second thing, I want the product of my work to be easily usable by a non-techie. For a non-techie, a simpler thing that achieves the same result as a more complex thing is better because there is less figuring out to do, plus there is less surface area for bugs and security vulnerabilities. I would even argue that this is true for almost everyone.

As to nftables, as mentioned above, I will add support for that. As to Luci interface, thinking about it is way too premature here. The purpose of this post was not to offer a ready-to-use product but to see if there is even any interest for it. So far it seems that most people like what's already implemented in OpenWRT with regards to GeoIP and don't feel like a simpler and narrower solution could be useful. I'm fine with that.

It may sound discouraging to you what the people are saying here but you should not take anything to personally.

I have no doubt that there are people out there that if they find your package they will find it useful

2 Likes

Your opening post does not mention existing solutions, which indicates you have not been aware of them, but at the same time, it states that your project is still under development and not optimized for OpenWrt, so advising you to save time and effort is logical.

There's nothing wrong if you decide to continue own development after knowing about other approaches, but what is better or worse, let the users choose for themselves depending on their personal preferences and needs.

2 Likes

I don't think you understand my motivation correctly. The actual motivation is just being a nerd who likes to tinker and gets excited when tinkering succeeds. But thank you for the kind words anyway.

All righty, I'll sum up the information collected in this experiment (as I see it). There is a more complex, less secure, less reliable and potentially less user-friendly solution for GeoIP but it's already implemented, and you want to save me the trouble of fitting a different solution, because...
This is where my understanding ends, basically. But I understand the direction in which the wind is blowing here and I don't think further discussion is useful.

This is not the best way to make friends... it fine pitching your solution by claiming it improves on these points, but maybe do that not by making alternatives appear worse?

Personally, I will likely never use any geoIP based blocking (I say likely, as I may be forced to do so, if under attack mostly from one locality, but I do not expect that), so the more complex banIP likely would be my choice as it offers the kind of rejections I might actually use. However, for anybody looking specifically for a geoIP solution that does one thing (and does it well) having yours available sounds great. In short there is probably room for multiple solutions here...

2 Likes

I agree on that point and I made my best to avoid direct critique of the alternative solutions.Moreover, I made a complement to it in one of my comments. It's not personal - it's actually just summing up the arguments and the counter-arguments that have been made here. Well, I did skip the part that deals with efficiency because I don't think we reached a decisive conclusion about that, and perhaps that conclusion can't be reached before the code is optimized for OpenWRT (for instance, just by doing some more experiments, I have already cut down the parsing time for the ARIN list by half).

As to pitching, these are my claims, as you noted, but these claims have not been disputed. Some have been even seemingly agreed to. Some are obvious.

Also, most of the replies have been "we already have BanIP". So by the nature of this argument, I have no choice but to compare my project to it. You can call it pitching if you like but I definitely do not intend to make the alternatives appear worse. I'm honestly comparing because this is what the situation calls for. And it's not at all a one-dimensional comparison. In some ways it's better and in some ways it's worse. Then in some ways it's worse rn by the virtue of the alternative already implementing something that I'm only planning to implement, and then some things that I'm not even planning to implement anytime soon (like Luci interface).

I actually briefly considered offering parts of my code to BanIP but I don't think any of it will get accepted because it follows a completely different approach and the underlying philosophy is completely different. So at this point I feel that for a moment being honest and direct is the one thing that I can actually contribute here.

To balance, I'll even say that having looked at the BanIP code, I think that the developer is objectively more knowledgeable about shell development than myself. I would have found implementing similar functionality in posix-compliant code (without the features of Bash) quite challenging. So this is one minus for my project. Adding a Bash dependency is another minus. I do believe that the thorough approach I've taken, and the extended functionality (and in some cases improved processing speed) offered by Bash compensates for that, though.

Just to respond to this specifically. The reason I started this project in the first place was to stop bot scans and attacks on my server. Not that this server has any significant importance - but it was being routinely attacked, many times an hour. Simply whitelisting my country and blocking everything else stopped this completely. So my personal experience is that it's extremely effective, for this particular purpose (and that's just one example). Adding support for blackslits was an afterthought, actually, and it's probably less effective than whitelisting because of the imprecision of geoip data which you mentioned. But it was very little effort on my part, and someone might need it, so I implemented it anyway.