Fail2ban: Redundant setting in jail.conf for extended ban?

[electrofloat]

Hi!

I was looking into the new bantime.increment feature and now I have a couple of questions:

1. The jail.conf still contains the [recidive] part which was used to check selflog to ban previously banned ips, but the new bantime.incement is exactly for that. Isn't this redundant now?
2. the bantime.increment comments do not talk about how it relates to findtime and maxretry. If the first ban is over, then the second one will immediately be set as soon as it is detected, or it has to happen in findtime for maxretry and then it will be set with an increased time?
3. The comments talk about the default being banTime * 1, 2, 4, 8, 16, 32... which for me means that this can be continued indefinitely but #bantime.formula = ban.Time * (1<<(ban.Count if ban.Count<20 else 20)) * banFactor shows that it'll be maxed out at 2^20. Which one is true?
4. Can bantime.multipliers have indefinite number of multipliers or only 20?

[sebres]

1. it is indeed redundant, but remained for backwards compatibility (as well as for some special purposes);
2. #1460 description contains a table illustrating that (I have to add this to our wiki yet);
   shortly - the same exponential formula will be used for both (increments bantime and decrements max attempts count);
3. it is almost impossible to reach this exponential increased time by default settings, because by default bantime (1h) even with factor 1 already after 13th ban it will grow to almost 1 year, after 15th it is 4 years, after 18th - 30 years, after 19th - 60 years, and 20th ban will cause 1h * 220, which corresponds to about 120 years. Considering all bans together the intruder is banned for almost 240 years!
   Such long bans (as well as persistent bans) are ugly for several reasons, therefore it is even recommended to set bantime.maxtime to several weeks or 1 month. Longer bans would simply grow iptables / ipsets, so unnecessarily burden the network subsystem and not practicable at all.
   If a (known as bad) intruder makes 1 attempt after 1 month ban, it will be banned immediately (again for 1 month), so why one should use longer banning? Anyway I use it several years and see extremely rare some attempts after 2-3 months banning (either they got "fixed", change IP/provider, or simply removed my protected hosts from its attack targets list).
4. It is not restricted, but as already said it is not needed.

[electrofloat]

I've modified the sendmail-whois.conf to contain <bantime> and <bancount> like this:
actionban = printf %%b "Subject: [Fail2Ban] <name>: banned <ip> from <fq-hostname> for <bantime> seconds # <bancount> time(s)

and I'm getting weird results:

[Fail2Ban] ssh: banned 192.168.56.1 from localhost.localdomain for 2 seconds # 1 time(s)
[Fail2Ban] ssh: banned 192.168.56.1 from localhost.localdomain for 2 seconds # 2 time(s)
[Fail2Ban] ssh: banned 192.168.56.1 from localhost.localdomain for 8 seconds # 3 time(s)
[Fail2Ban] ssh: banned 192.168.56.1 from localhost.localdomain for 2 seconds # 4 time(s)
[Fail2Ban] ssh: banned 192.168.56.1 from localhost.localdomain for 32 seconds # 5 time(s)
[Fail2Ban] ssh: banned 192.168.56.1 from localhost.localdomain for 2 seconds # 6 time(s)

I can confirm that the ban time is increasing every time, but in the mail it does not always. Am I missing something, or is this a bug?

[sebres]

but in the mail it does not always.

Because the prolongation is made completely asynchronous (intruder should be blocked as soon as possible), the ban can occur before the bantime gets really increased.
If it is expected, another action parameter actionprolong was added for this purposes, so use that instead of actionban.