Hi, The main reason I changed to using ipset was because of my my rather large block list that you have to wait for f2b to unban each entry when issued with a stop. This in itself is not too much an issue but I restart my firewall whenever my ADSL connection gets a new IP so that certain firewall rules know bout the new IP and waiting for f2b to unban 1500+ entries was taking way too long. I had looked at various ways of trying to get f2b to just flush/dump the chain entries but it didn't seem to work as expected and ipset was the best solution. I went from waiting about 3 minutes for a f2b stop and iptables restart down to under half a second as I only had to restart my iptables setup...
I do agree that the management of the ipset structure is a little more complicated but I'll eventually get around to writing a simple unban script that does the f2b side and the ipset side too, just haven't yet had the desperate need to unban in a hurry... Regards ------------------------ Rhys McWilliams Cell: +27 82 335-5014 Fax: 086 618-2798 http://www.castlehillcc.co.za [email protected] On 2015/11/17 10:56, Nick Howitt wrote: > There are a couple of issues with ipset. > > Firstly, although its blocking and loading is much faster, it is not > nearly so easy to spot blocks at a glance and manage them if > necessary. It is also harder to unban as, with your method you don't > have an unban rule, relying on ipset block to expire. Manually, you > need to both delete the ipset block and issue an unban command to > remove it from the f2b database. This is really a management issue. > > The other issue is again our friend, iptables. On my version (1.4.7? > on el6) iptables cannot remove an ipset rule directly using the normal > -D switch. This is fixed in later versions of iptables. Fortunately > these rules are relatively easy to find if there is one rule per set ( > so not a udp and tcp rule although this can be got round with a loop) > so they can be deleted by listing the table with line numbers, > grep'ing the jump target then picking out the line number of the rule > and deleting that. Messy. Without this, stopping f2b would leave the > iptables rule in place. > > Personally I really like the ipset approach apart from its visibility. > > Regards, > > Nick > > On 2015-11-17 08:16, Rhys McWilliams wrote: >> Hi, >> I stand to be corrected but as far as I know f2b does not have a >> "recovery mechanism" that will attempt to re-create the chains if >> they've been removed by some other means. >> Those log entries don't seem to show f2b trying to re-create the >> chains... >> The "iptables -D" is an attempt at removing a chain rule. >> The "iptables -F" is the chain flush command and >> the "iptables -X" is the deletion of chain command. >> If f2b was trying to create the chain there should be "iptables -N" >> command to create the "new" chain. >> >> It is also most definitely not a path issue or else you would be getting >> different error messages and your one log line >> "iptables v1.4.21: Couldn't load target `f2b-sshd':No such file or >> directory\n\nTry `iptables -h' or 'iptables --help' for more >> information.\niptables: No chain/target/" could only possibly return >> such an error if it had actually executed iptables... >> >> If I am incorrect about the f2b recovery mechanism then I do agree that >> it would be nice for it to work but there is nothing wrong with creating >> scripts to "work around" issues until said issues has been resolved and >> the script therefore no longer required. >> >> There is another solution to this and that is to use iptables with the >> set and mark parameter and use f2b to populate an ipset list which does >> not get flushed when iptables restarts and f2b can happily access it as >> needed. >> I've changed to this method as one of my f2b rules has built an ipset >> list that currently contains 1718 entries of IPs to block and I can >> restart my iptables as often as I like without effecting that list or >> f2b... >> >> Regards >> ------------------------ >> Rhys McWilliams >> Cell: +27 82 335-5014 >> Fax: 086 618-2798 >> http://www.castlehillcc.co.za >> [email protected] >> >> On 2015/11/17 10:00, Nick Howitt wrote: >>> With later versions of iptables (not mine!) which support the -C >>> (check) >>> switch, you can avoid the issue by changing the actionunban (and >>> actionstop?) rules to check if the rule exists first before deleting >>> it. >>> I've done an ugly bash/grep hack to my rules as I use a restricted set. >>> The overall result is a tidy log but I'm sure it takes a bit longer to >>> execute. It is me just being a purist. >>> >>> Nick >>> >>> On 2015-11-17 07:39, Y. wrote: >>>> In my opinion, your issue is not a PATH issue, but simply that the >>>> fail2ban chain does not exist anymore after the firewall has been >>>> reset. Restarting fail2ban does recreate the chain, which is why it >>>> works thereafter. I see two solutions: >>>> - either you add the creation of the fail2ban chain to your firewall >>>> rules: this would avoid the errors, but it would not restore the bans; >>>> - or you create a script as already suggested: stop f2b, tweak fw, >>>> start f2b. >>>> >>>> On Tue, 17 Nov 2015, Stein Rune Risa wrote: >>>>> Hi! >>>>> Yes, I understand this is happening because of the flushing of rules, >>>>> but it seems that fail2ban has a built-in recovery mechanism to >>>>> handle >>>>> this situation. >>>>> >>>>> The recovery mechanism is to readd the iptables rules (see log >>>>> from my >>>>> original mail). >>>>> >>>>> The issue is that the recovery mechanism is not working - because >>>>> PATH >>>>> is not set correctly for fail2ban - which was my original question. >>>>> >>>>> I don't want to create scripts to compensate for this, when I can fix >>>>> the original issue instead, which is to get the recovery mechanism to >>>>> work properly. >>>>> >>>>> So the question still remains: how can I set the PATH for the >>>>> fail2ban >>>>> process? >>>>> >>>>> Best regards >>>>> Stein Rune Risa >>>>> >>>>> On Tue, Nov 17, 2015 at 7:33 AM, Rhys McWilliams >>>>> <[email protected]> wrote: >>>>> Hi, >>>>> Those errors you are seeing are due the iptables restart, >>>>> which >>>>> would have flushed and removed all the chains, including the ones >>>>> f2b creates. >>>>> This is normal behaviour when iptables is restarted (which is >>>>> what is happening with iptables-restore). >>>>> The log entries below are from f2b trying to work on one of >>>>> the >>>>> chains it knew it had created when it started, but that chain no >>>>> longer exists due to the iptables restart. >>>>> Restarting f2b would re-create the relevant f2b chains and >>>>> therefore function as expected again. >>>>> >>>>> What I had done to overcome this was to create a script to >>>>> restart the firewall, which basically first does a fail2ban stop then >>>>> restarts iptables and then starts fail2ban again so all was as >>>>> it should be... >>>>> >>>>> ##### fwrestart.sh ##### >>>>> #!/bin/bash >>>>> >>>>> /etc/init.d/fail2ban stop >>>>> /etc/init.d/iptables restart >>>>> /etc/init.d/fail2ban start >>>>> >>>>> Regards >>>>> ------------------------ >>>>> Rhys McWilliams >>>>> Cell: +27 82 335-5014 >>>>> Fax: 086 618-2798 >>>>> http://www.castlehillcc.co.za >>>>> [email protected] >>>>> On 2015/11/16 21:03, Stein Rune Risa wrote: >>>>> Hi! >>>>> I am using fail2ban and very happy with that. But I have one use case >>>>> where behavior is not optimal. >>>>> >>>>> I store my iptables rules in a file an occasionally run >>>>> iptables-restore if I have modified the rule set. >>>>> >>>>> After I have done this, I see the following errors in fail2ban-log: >>>>> >>>>> 2015-11-16 07:58:26,043 fail2ban.action [3074]: ERROR >>>>> iptables -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd >>>>> iptables -F f2b-sshd >>>>> iptables -X f2b-sshd -- stdout: b'' >>>>> 2015-11-16 07:58:26,044 fail2ban.action [3074]: ERROR >>>>> iptables -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd >>>>> iptables -F f2b-sshd >>>>> iptables -X f2b-sshd -- stderr: b"iptables v1.4.21: Couldn't load >>>>> target `f2b-sshd':No such file or directory\n\nTry `iptables -h' >>>>> or 'iptables --help' for more information.\niptables: No >>>>> chain/target/m$ >>>>> 2015-11-16 07:58:26,044 fail2ban.action [3074]: ERROR >>>>> iptables -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd >>>>> iptables -F f2b-sshd >>>>> iptables -X f2b-sshd -- returned 1 >>>>> 2015-11-16 07:58:26,044 fail2ban.actions [3074]: ERROR >>>>> Failed >>>>> to execute ban jail 'sshd' action 'iptables-multiport' info >>>>> 'CallingMap({'ipmatches': <function >>>>> Actions.__checkBan.<locals>.<lambda$ >>>>> >>>>> I think this is because the iptables entries for fail2ban have been >>>>> flushed, and it is trying to restore them - but cannot find >>>>> the iptables executable. >>>>> >>>>> I have to do a sudo service fail2bank stop and then start to resolve >>>>> this issue. That restores iptables entries for fail2ban and >>>>> fixes the issue. >>>>> >>>>> I've examined the /etc/init.d/fail2ban script and find: >>>>> >>>>> PATH=/usr/sbin:/usr/bin:/sbin:/bin >>>>> >>>>> iptables is in /sbin, but it seems to use this PATH variable just >>>>> when >>>>> it starts up - because it manages to set iptables rules OK >>>>> on start - but not when running. >>>>> >>>>> I see that fail2ban process runs as root (from htop): >>>>> >>>>> 3580 root 20 0 282M 18196 6516 S 0.0 0.9 0:06.90 ├─ >>>>> /usr/bin/python3 /usr/bin/fail2ban-server -s >>>>> /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x >>>>> -b >>>>> >>>>> I would rather not add fail2ban entries to my iptables rule file - >>>>> but >>>>> I hope there is somehow to make fail2ban being able to >>>>> execute iptables runtime. A path variable somewhere that I can set to >>>>> include /sbin. >>>>> >>>>> Any ideas? >>>>> >>>>> Best regards, >>>>> Stein Rune Risa >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> Presto, an open source distributed SQL query engine for big data, >>>>> initially >>>>> developed by Facebook, enables you to easily query your data on >>>>> Hadoop >>>>> in a more interactive manner. Teradata is also now providing full >>>>> enterprise >>>>> support for Presto. Download a free open source copy now. >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Fail2ban-users mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> >>>> _______________________________________________ >>>> Fail2ban-users mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users >>> ------------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Fail2ban-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users >> >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Fail2ban-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/fail2ban-users ------------------------------------------------------------------------------ _______________________________________________ Fail2ban-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fail2ban-users
