From: Stein R. R. <st...@gm...> - 2015-11-17 08:27:12
|
Good point! I did not read the iptables commands carefully enough - and I see that you are correct. I assumed they tried to recreate the chains - but I see now that you are correct. I was mislead by some additional comments in the log file that I did not include the first time: 2015-11-16 08:08:26,841 fail2ban.action [3074]: ERROR iptables -n -L INPUT | grep -q 'f2b-sshd[ \t]' -- stdout: b'' 2015-11-16 08:08:26,842 fail2ban.action [3074]: ERROR iptables -n -L INPUT | grep -q 'f2b-sshd[ \t]' -- stderr: b'' 2015-11-16 08:08:26,842 fail2ban.action [3074]: ERROR iptables -n -L INPUT | grep -q 'f2b-sshd[ \t]' -- returned 1 2015-11-16 08:08:26,842 fail2ban.CommandAction [3074]: ERROR Invariant check failed. Trying to restore a sane environment 2015-11-16 08:08:26,949 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 08:08:26,949 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 --hel$ 2015-11-16 08:08:26,949 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 08:08:26,949 fail2ban.actions [3074]: ERROR Failed to execute unban jail 'sshd' action 'iptables-multiport' info '{'ip': '43.229.$ As you can see it first does listing of iptables and greps for f2b-sshd and then outputs: "ERROR Invariant check failed. Trying to restore a sane environment" I was mislead to think that the "restoring of the sane environment" meant recreating the chains - but it does at least noe output this in the logs as you say. I think I will fix this by adding iptables rules fail2ban to my ruleset. Thank you. Best regards, Stein Rune Risa On Tue, Nov 17, 2015 at 9:16 AM, Rhys McWilliams <rh...@ca...> 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 > rh...@ca... > > 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 > >>> <rh...@ca...> 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 > >>> rh...@ca... > >>> 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 > >>> Fai...@li... > >>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users > >>> > >>> > >>> > >>> > >>> > >> > ------------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Fail2ban-users mailing list > >> Fai...@li... > >> https://lists.sourceforge.net/lists/listinfo/fail2ban-users > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Fail2ban-users mailing list > > Fai...@li... > > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Fail2ban-users mailing list > Fai...@li... > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > |