Hello List,
as promised, I had a look at Tim's blacklisting code and talked on the phone with Michael and Peter how to handle all this "ipset load and destroy stuff" in a good way.
So we talked about, how to deal with all the different scripts and places where ipset sets are involved. We agreed that it would be the best to handle them at a central place (script) and decided the easiest way would be the perl-based firewall script which is used to generate and create the firewall rules. (rules.pl)
We also talked about how the IP blocklist feature become a core component of IPFire and to integrate it into this. I'll give more details about this in the related discussion on this list.
While discussing about this we came across that the dynamic approach of loading and destroying sets which Tim is using in his code is very lovely and so decided to adopt it in a very similar way.
This results in two first patches which have been sent to the development mailing list.
The first one will allow the firewall engine to dynamically destroy (unload) ipset sets if they are not longer required.
https://patchwork.ipfire.org/project/ipfire/patch/20220227134903.1828-1-stef...
The second patch is a fist step of moving all "ipset" related rules into the same script.
https://patchwork.ipfire.org/project/ipfire/patch/20220227134903.1828-2-stef...
Best regards,
-Stefan
Hello Michael, Hello Tim,
thanks for your feedback and discussion.
Hello Tim,
On 15 Feb 2022, at 19:28, Tim FitzGeorge ipfr@tfitzgeorge.me.uk wrote:
Hello,
I'm concerned about this as well. Depending on when it does the ipset destroy it may be OK (for example as part of shutting down the system or prior to rebuilding the firewall from scratch, as in these cases it either won't matter or the OP blocklist ipsets will be reloaded), but in general I would consider it a bad idea to delete all the ipsets whether or not you 'own' them - each 'package' should only touch it's own 'property', while this just deletes all the ipsets regardless.
This is quite hard to implement though. We could in theory iterate over all possible country codes and try to delete all sets, but that seems to be a very slow and not elegant solution to the problem.
Having said that, I think it will probably be alright as according to the documentation ipset destroy won't delete lists which have references to them, and the IP blocklist ipsets should always have references.
This is good for us though. If we can consider the “destroy” command to be more of a cleanup and it is safe to call it, then we should not run into any trouble here.
@Stefan: Can you confirm that any sets that are still referenced elsewhere won’t be destroyed and that there is no ugly output that could alarm anyone?
I did not have a look at Tim's code at the moment, nor some testing of his feature so I'm unable to say yes or no, for both of your questions.
I'll dig into this at the weekend and phone back what I got.
-Stefan
-Michael
Tim
On 15/02/2022 12:41, Michael Tremer wrote:
Hello,
Looking at the other patchset that implements IP blocklists, could this interfere with this in any way?
-Michael
On 14 Feb 2022, at 18:42, Stefan Schantl < stefan.schantl@ipfire.org> wrote:
Signed-off-by: Stefan Schantl stefan.schantl@ipfire.org
config/firewall/rules.pl | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/config/firewall/rules.pl b/config/firewall/rules.pl index f685d08a7..da01b8775 100644 --- a/config/firewall/rules.pl +++ b/config/firewall/rules.pl @@ -31,6 +31,7 @@ require "${General::swroot}/location- functions.pl"; my $DEBUG = 0;
my $IPTABLES = "iptables --wait"; +my $IPSET = "ipset";
# iptables chains my $CHAIN_INPUT = "INPUTFW"; @@ -114,6 +115,9 @@ sub main { # Flush all chains. &flush();
+ # Destroy all existing ipsets. + run("$IPSET destroy");
# Prepare firewall rules. if (! -z "${General::swroot}/firewall/input"){ &buildrules(%configinputfw); -- 2.30.2