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 <[email protected]>
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
