I just want to discuss if it’s necessary to have the Location Block filter right in front of the firewall input fixed. I think this limits its usage a little bit.
E.g. if an IPFire instance is installed right in front of a server and the server is handling mail, it’s important, that the server can get connections from all over the world. So Location Block must be turned off.
If another service on this server needs the location block, locations groups need to be created to get a similar function within a firewall rule.
If the Location Block is enabled and allows only incoming connections from, say Germany, even if a forwarding rule has an “any” source, it’s still limited to Germany in the moment.
IMHO it would be more flexible if the Location Block page/module configures a filter part of the firewall and sits not strictly in front of it.
The Location Block filter might be selected as part of the source/dest Location option of a firewall rule, where I can select single countries or location groups.
I think it a bit difficult to do a Location Block filter selective on application.
If you trust only german servers, this should be true for or mail server also.
if you understood your question right, you can do so today by turning the location filter off and limit the acceptable source(s) for e. g. port-forwarding rules to certain countries. The sole purpose of the location filter is to reduce noise in the logs, it’s security importance is rather low in my personal view.
Well, selecting single countries or creating country groups is supported today as well.
Your question sounds more like we need to clarify what the location filter is designed for and what it does in detail, but this seems to be a more general issue…
thank you for your comments.
You are right, the function of the Location Block should be clarified in the Wiki.
One can see it as incoming “noise filter”, not more not less.
But if the secured server has at least one service (SMTP, RTP etc.), which has to accept connections from all over the world, the Location Block MUST not be activated, even if a firewall rule has an “any” source set.
To use the comfort of the Location Block page in the above case anyway, I just suggested to make it a part of a firewall rule.
You can define ‘Location groups’ for firewall rules.
With this you define a REJECT rule for the locations you want to block. Rules for your exeptions can be placed before this rule.
You are right, the function of the Location Block should be clarified in the Wiki.
One can see it as incoming “noise filter”, not more not less.
yes, we should definitely do this. I will try to bring this up at the next monthly telephone conference…
Also yes, this is certainly a limitation at the time of writing. From my point of view, if bug #12025 is resolved, we could drop the location filter altogether and convert its settings into “normal” firewall rules.
You can define ‘Location groups’ for firewall rules
I know and done that, but creating groups by adding locations out of a combo box is painfully. Therefore I wish the comfort of the Location Block page.
It would be also nice to have information in the Wiki, how the global Location Block affects IPsec and OpenVPN tunnels as well as the Tor service.
Are these services bypassed?
The exact processing scheme is illustrated here, where “GEOIP_BLOCK” (we need to update this diagram as well ) comes before “IPSECINPUT”, “OPENVPNINPUT” and “TOR_INPUT”. Those services are therefore not bypassed, this is what bug #12025 is about.
For Tor, there is a patch available making this more independent, but it has never made it into the repository. As mentioned above, I will bring this up at the next telco and we will then decide what to do about this here…
Thanks for your patience, and best regards,
Peter Müller
thanks a lot for bringing this issue to attention. Maybe I should start a new thread about this, but I continue here.
IMHO, the FW INPUT chain design is really not flexible and too strict regarding the input security of services like OVPN, IPsec or TOR.
To run TOR or VoIP (RTP), I nearly have to disable the global location block, while I want to expose the IPsec input only to my own country.
In core 152 the concerning part of the INPUT chain looks like:
Problem starts when you want to secure IPsec input, OVPN input and TOR in different ways.
In the moment there’s no way to configure/limit these inputs.
I would wish and recommend that IPSECINPUT, WIRELESS INPUT, OVPNINPUT, TOR_INPUT simply become rules of INPUTFW.
That way, using the GUI, you can configure different location blocks, source IP ranges etc. for every service.
If you add a new service, simply add the according rules to the INPUTFW.
I would further remove the LOCATIONBLOCK (old GEOIPBLOCK) completely and let it be part of the INPUTFW, for example as first rule by default.
The Location Groups setup could be much more easy, if combined with the Location Block page like this:
And last, while checking the chains, I saw that a rule with a location based source (here “DE”) has (of course) ppp0 as input, so a red background color would be cleaner:
Hi Peter,
I am the one who created that diagram…5 years (or so) ago.
If the chain order changed in the meanwhile, or new chains appear, please let me know and I will update it.
Best,
H&M
@pmueller, what was the result of the phone conf concerning this topic? Are there any plans for changing this global geoblock setup in near furture?
Reason I’m asking is that I just want to limit the OVPN service to German locations but nothing else. The global geo filter is not suitable.
But as I know, FW rules are applied after the OVPNINPUT chain, is this correct?
