Hi Bill, Thanks for the info, I've basically implemented this now for all my jails so that I can stop/start my firewall any time without having to also restart fail2ban. I'm now down to 0.24 of a second for the firewall to restart when needed so this is working well for me now. Interestingly, it still takes about 12 seconds to run the "service fail2ban restart" but at least my scripts no longer need to do that...
Regards ------------------------ Rhys McWilliams Cell: +27 82 335-5014 Fax: 086 618-2798 http://www.castlehillcc.co.za [email protected] On 2015/10/07 21:27, Bill Shirley wrote: > My approach is to not use the unban but use an ipset with a timeout value. > This > let's the kernel/ipset keep track of when to unban. > #--------------------- my_ipset_ipport: > [INCLUDES] > > before = iptables-blocktype.conf > > > [Definition] > actioncheck = > actionstart = > actionstop = > actionban = ipset -exist add fail2ban-<name> <ip> timeout <bantime> > #actionunban = ipset -exist del fail2ban-<name> <ip> > actionunban = > > [Init] > name = Ip > port = ssh > protocol = tcp > bantime = 3600 > > #--------------------- jail: > [apache-noscript] > #enabled = false > enabled = true > filter = apache-noscript > #action = my_ipset_ip > action = my_ipset_ipport[port=http, bantime="%(bantime)s"] > my_ipset_ipport2[port=https, bantime="%(bantime)s"] > logpath = /var/log/httpd/error_log > maxretry = 2 > bantime = 86400 > > Note: my_ipset_ipport2 is just a symlink to my_ipset_ipport. Also > I don't use an actionstart or actionstop since I add the ipset with Shorewall. > > Use the ipset command to manually unban. > > Bill > > > > On 10/6/2015 11:06 AM, Rhys McWilliams wrote: >> Hi Nick, >> Great suggestion to look at ipset as it should definitely be faster for >> iptables to process than standard rules... >> >> I've given it a test with my list of "attackers" IPs which is currently >> at 1023 entries... >> The results are definitely better with 1 minute 50 seconds to stop with >> ipset as compared to 3 minutes 49 seconds for the standard rules. >> fail2ban still goes through the motion of issuing an unban for each IP >> so I'd guess that the time difference is down to the fact that it's >> quicker to run the "ipset del" command that it is to run "iptables -D". >> >> On the plus side, it is quite an improvement in time so I'm grateful for >> the suggestion... >> >> I'm sure if I set the actionunban to be the same as the actionstop if >> would do just that, but then you loose the ability to unban a single IP, >> among other things, so that's not really a solution... >> >> Regards >> ------------------------ >> Rhys McWilliams >> Cell: +27 82 335-5014 >> Fax: 086 618-2798 >> http://www.castlehillcc.co.za >> [email protected] >> >> On 2015/10/06 15:03, Nick Howitt wrote: >>> 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 >> > ------------------------------------------------------------------------------ > Full-scale, agent-less Infrastructure Monitoring from a single dashboard > Integrate with 40+ ManageEngine ITSM Solutions for complete visibility > Physical-Virtual-Cloud Infrastructure monitoring from one console > Real user monitoring with APM Insights and performance trend reports > Learn More http://pubads.g.doubleclick.net/gampad/clk?id=247754911&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
