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
