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 ( failureand ban)
• preventing a situation out of memory, when a large number failureof many IPs (maxEntries), as well as optimization of memory usage in the managerFailManager
• (str2seconds) convenient time settings in the configuration, i.e. use 1hinstead 3600or 1dinstead 86400, etc.
• (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 ban-time-incr)
• [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:

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 ¹⁶ (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, actionis welcome.

Download:
https://github.com/fail2ban/fail2ban/archive/0.10.zip

Geet:
git clone -b 0.10 https://github.com/fail2ban/fail2ban.git