I like your thinking. As a slight lateral idea, have you investigated using ipset blocking rules instead? They are far more suitable for large numbers of blocks but I have not checked them out in f2b recently. I have a feeling on my distro there were problems with deleting ipset rules from the INPUT chain but they would be much faster as you only load one or two rules in iptables. All the rest of the IP manipulation is outside iptables.
Nick On 2015-10-06 11:55, Rhys McWilliams wrote: > 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? ------------------------------------------------------------------------------ _______________________________________________ Fail2ban-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fail2ban-users
