In the fifth lesson of the Fail2ban Mastery series, we dive into the three core parameters that define how Fail2ban protects your server: maxretry, findtime, and bantime. Understanding and tuning these values is crucial for balancing security against false positives.
The Three Numbers
At the heart of Fail2ban's logic are three numeric settings:
- maxretry: The number of failed attempts allowed before a ban.
- findtime: The time window (in seconds) during which
maxretryfailures must occur. - bantime: The duration (in seconds) for which an offending IP is blocked.
Together, they form a simple rule: if an IP exceeds maxretry failed attempts within findtime seconds, it gets banned for bantime seconds.
maxretry Deep Dive
maxretry is your first line of defense. Set it too low (e.g., 1) and you risk banning legitimate users who mistype a password. Set it too high (e.g., 10) and you give attackers many chances. A common default is 5. For SSH, many administrators use 3, while for web applications, 5–10 may be appropriate to accommodate human error.
findtime Explained
findtime defines how far back Fail2ban looks when counting failures. A shorter findtime (e.g., 60 seconds) is aggressive, catching rapid brute force attempts. A longer findtime (e.g., 600 seconds) catches slower, distributed attacks. The key is to match findtime to the expected failure pattern of your service.
bantime Strategy
bantime determines how long an IP is blocked. Short bans (minutes) are mild deterrents; longer bans (hours or days) are more punishing but can lock out legitimate users who triggered the rule. A strategy many adopt is a default bantime of 600 seconds (10 minutes) for minor offenses, with longer bans for repeat offenders.
bantime.increment
Fail2ban supports bantime.increment, which multiplies the ban duration automatically for repeat violators. This is a powerful tool: the first ban may be 10 minutes, the second an hour, the third a day. Enable it by adding bantime.increment = true in your jail configuration.
Per-Service Tuning
Different services have different risk profiles. SSH typically needs stricter settings (low maxretry, moderate bantime), while web services like Nginx or Apache may tolerate higher thresholds to avoid blocking legitimate users. Always test your settings with real traffic before deploying to production.
By mastering these three parameters, you can tailor Fail2ban to your environment, reducing false positives while keeping attackers at bay.