Originally published in 2013. Reworked on 23 October 2026; this revision replaces the previous instructions.
One defensive layer, not complete protection
Fail2ban examines log events and can act when they match configured filters. It can help with repeated attempts, but does not replace strong authentication, maintained software or appropriate service exposure.
The first version of this article dates to 2013. This revision does not present the old Debian paths and packages as a current installation procedure.
Verify the log source
Check how the service records events. Log files and the systemd journal need appropriate backend configuration. Formats can change between releases and distributions.
A filter that fails to recognise real events can remain silent. An overly broad filter can block legitimate activity.
Use local configuration files
Fail2ban provides .local files and directories for custom settings. Use them for values you need to change instead of replacing package-managed files wholesale.
maxretry, findtime and bantime describe the event threshold, observation window and ban duration. Choose them for the service and its users.
Test without losing access
Plan a recovery channel before changing access rules. Test filters against appropriate sample events and verify the resulting firewall actions. Do not generate access attempts against third-party systems.
Check false positives
A useful review covers attempts that should be stopped and legitimate access that must continue. Document decisions and review logs after release. Initial configuration starts maintenance; it does not complete it.