Hi,
Apologies if this has been asked and answered before but I cannot seem
to find anything about it via Internet searches...
I'm running Fail2Ban v0.9.2 (installed using yum) on CentOS 6.7
I run a jail to block various remote connection attempts from my
external interface to ports like telnet (23), VNC (5900) and various
other that should not be accepting connections from the public Internet,
basically hacking attempts...
Here is my jail.local entry
[remote-connections]
enabled = true
filter = remote-connections
action = iptables-allports[name=REMCON, protocol=all]
[email protected]]
logpath = /var/log/messages
maxretry = 1
findtime = 86400
bantime = 604800
The action is the standard default installed iptables-allports.conf with
no modifications, which has the following actionstop and actionunban lines
actionstop = iptables -D <chain> -p <protocol> -j f2b-<name>
iptables -F f2b-<name>
iptables -X f2b-<name>
actionunban = iptables -D f2b-<name> -s <ip> -j <blocktype>
As you can see from my jail definition above I have a strict policy that
if there is so much as 1 match then the source IP gets banned for 1 week
(bantime = 604800). My opinion is that nobody should be trying to access
the the ports I specify in my filter and if they are then it can only be
for malicious intent, therefore ban them:)
Okay, now down to the reason for emailing the this list...
While testing to get information together my f2b-REMCON chain contained
965 entries (it has been much higher than that too) so I consider it
having been working rather well...
The problem is that when I do a service fail2ban restart (or reload) it
takes 3 and a half minutes to restart which I can see,from the
fail2ban.log file, is due to the fact that fail2ban is first issuing an
"unban" for each IP in the chain.
An individual unban of a single IP is quite quick, typically under 0.5 a
second, but of course multiply that by the number of entries I get in my
f2b-REMCON chain, it's no longer a quick process...
My question being, is there a specific reason the unban per IP is done?
Could fail2ban not just use the "actionstop" as defined in the action to
flush and remove the chain, which would be very quick?
The reason I'm having an issue with this is because I regularly restart
my firewall, for various reasons, and of course you should to first stop
fail2ban, then restart the firewall (iptables or whatever) and then
start fail2ban again.
If you don't do it this way, the firewall restart would flush and remove
all the f2b chains. Restarting fail2ban after the firewall has flushed
all the f2b chains takes even longer as fail2ban logs errors per IP it
knew about as they no longer exist in the iptables chains.
I'm currently busy with a script to manage 3G failover with ADSL as the
primary link, both managed by the LINUX server and not ADSL/3G router(s).
Part of this script will bring up the 3G connection when the ADSL link
drops and then restart the firewall with the new ppp interface set so
the relevant iptables rules can allow the traffic in the relevant
external interface. As the firewall is going to be restarted, fail2ban
also needs to be restarted and if this takes upwards of 3 minutes I will
not be getting traffic in on the new ppp interface until the firewall
gets to restart.
While 3 minutes is not the end of the world it does have a negative
impact on our business as during that "down time" we are not receiving
emails and staff that work remotely via VPN are stalled too.
If I leave fail2ban out of the firewall restart process it only take 1
or 2 seconds and everything is processing again as normal.
Is there a way to get fail2ban to restart faster by not issuing the
unban for each banned IP?
--
Regards
------------------------
Rhys McWilliams
http://www.castlehillcc.co.za
[email protected]
------------------------------------------------------------------------------
_______________________________________________
Fail2ban-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
