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
