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
