Fail2ban 0.10: New Features. Test open
This is the announcement of the new version of fail2ban (still a test alpha branch), in which, in addition to many other improvements and goodies, albeit belatedly, the long-planned support for IPv6 has nevertheless appeared.
Time, be it not right - flies at a frantic speed.
Briefly a list of new, already included (and most likely joining soon) in fail2ban version 0.10:
- of course IPv6 support (so far only for iptables, iptables-ipset, firewallcmd, pf)
- new syntax for pseudo-conditional sections in configuration files, used for conditional substitution and interpolation of parameters for various host types, example
[Init?family=inet6](currently used only for IPv6 support)
- Significant increase in fail2ban performance compared to version 0.9.x
- performance regression prevention with increasing number of IP addresses (
- preventing a situation out of memory, when a large number
failureof many IPs (maxEntries), as well as optimization of memory usage in the manager
- (str2seconds) convenient time settings in the configuration, i.e. use
- (seekToTime) - quick start, prevents long reading of large files for the first time after starting the service
- smart caching of everything and everything (dnsToIp, ipToName, pre-interpolation of call parameters action, etc.)
- [soon] merge with my incremental version (branch
- [soon] customizable variable ban factor (new version
ban-time-incr), for example, geo-dependence of the IP address, below is a configuration example, where the IP address ten times earlier will be considered "bad" if the country is not Russia)
geo.country = RU:1 default:10
- [coming soon] auto-configurable sub-network lock
- [soon] fully rewritten client-server (the ability to execute in foreground mode, covering with tests, the new “restart” command in addition to “reload”, a variable level of detail to heavydebug at startup and other improvements)
The significant performance increase in fail2ban version 0.10 can be roughly estimated in the following figures:
|Rating / Version||0.9.4||0.10|
|Average response time (Delayed finding failure)||200 ms||15 ms|
|Average Time to Lock (Lock Delay)||150 ms||10 ms|
|Maximum response time (Delayed finding failure)||500 ms||30 ms|
|Maximum Time to Lock (Lock Delay)||1000 ms||20 ms|
|Average blocking speed||6 IP / sec||170 IP / sec|
|Block Delay Increase (Regression)||100 ms / 1000 IPs||5 ms / 1000 IPs|
The evaluation is quite strongly influenced by a lot of parameters, such as (spurious) logging activity, quality (and quantity) of regular expressions (fail2ban filter), call speed and banaction type, lookups type parameters
usedns, etc. etc. However, ceteris paribus, in a case close to ideal, approximately the following figures are obtained.
For those who have read my article “Fail2ban [incremental]: Better, faster, more reliable” or use this “incremental” version - all new 0.10 merged in this thread - https://github.com/sebres/fail2ban/tree/0.10 -full . I will not support it here yet (see PR gh-1460 )
It is also planned to automatically configure blocking of subnets (since it is especially important for IPv6 addresses). Just putting separately 2 16 (or 65.536) IPv6 addresses in the ban if the attacker has a subnet of X :: / 112 is somehow not comme il faut (let’s say nothing about higher-order subnets).
I hope that before the release of 0.10 this functionality will be finalized.
I repeat, 0.10 is still a test branch. Anyone who wants to take part in testing or modify, for example, support for others,
git clone -b 0.10 https://github.com/fail2ban/fail2ban.git