Hi guys, i had to modify my "/etc/init.d/fail2ban" file to have fail2ban be restarted when iptables is restarted. The original file contains "after iptables" and "/etc/init.d/iptables restart" does the following : # /etc/init.d/iptables restart * Stopping firewall ... [ ok ] * Loading iptables state and starting firewall ... [ ok ] after that, there is no any rule named "fail2ban-ssh" (if i had configured fail2ban to use the ssh rule) in `iptables-save` . When i put "need iptables" in the depend() function, this happens : * Caching service dependencies ... [ ok ] * Stopping fail2ban ... [ ok ] * Stopping firewall ... [ ok ] * Loading iptables state and starting firewall ... [ ok ] * Starting fail2ban ... [ ok ] Which seems to be the correct behaviour, since the rule named "fail2ban-ssh" is restored after iptables is restarded. Is there any reason to have "after" and not "need" in the depend() function ? Am i doing stg wrong ? If not, i suggest to replace "after iptables" by "need iptables" in the init.d script.
Hi, Fail2ban can work with tcp wrapper, shorewall or anything else too. Netfilter (iptables) was the first implemented and seems to be the most popular. Iptables is not mandatory but is the default solution in order to ban aggressive hosts. Moreover, Fail2ban should handle a firewall restart quite well. It should check that the chain fail2ban-ssh is present and if it is not the case, Fail2ban should recreate it on the next failure. Thus, I suggest to leave "after iptables".
shouldn't it be restarted after shorewall restart too ?
(In reply to comment #2) > shouldn't it be restarted after shorewall restart too ? > When using the "iptables" action, Fail2ban will check before banning a new host that some requirements are met such as the existence of a given chain. If this check fails, Fail2ban will recreate the chain and thus restore a proper environnement. So it shouldn't be a big problem.
Fail2ban restores the fail2ban-ssh chain when it needs to add a new rule
