Hi!
As it is shown in the fail2ban logs:
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$
This means that fail2ban is actually trying to recreate its own iptables
rules. I would rather want these built-in fail2ban mechanisms to work than
to make workarounds.
Why else should the recovery mechanisms be there if we just created
paralell workarounds?
Best regards
Stein Rune
On Tue, Nov 17, 2015 at 8:39 AM, Y. <[email protected]> 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
