Why self-host Fail2ban on a VPS
Fail2ban is the simplest and most universal protection tool for an exposed server: it continuously reads your log files, applies regular expressions (the filters) to spot intrusion attempts, and bans the offending IP by adding it to iptables/nftables for a configurable duration. On a VPS, it's the first line of defense to set up before anything else, because it requires no external dependency, consumes almost nothing and immediately protects SSH against bruteforce. Beyond SSH, you can extend it to Nginx (auth attempts, URL scans), Postfix, WordPress or any service that writes logs. Everything runs locally on your machine: no data leaves, no third-party service is involved. It's the solution to favor for robust, self-contained protection that's easy to audit.
The concrete benefits of this template
- Automatic banning of IPs that bruteforce SSH, from the first suspicious attempts.
- Filters for many services: SSH, Nginx, Apache, Postfix, WordPress, and custom filters.
- Minimal footprint: it runs without trouble on the smallest of VPSes.
- Progressive banning (repeat offense): the more an IP reoffends, the longer the ban.
- Email notifications on each ban to keep an eye on attacks.
- Fully self-contained and local: no network dependency, simple to audit and version.
Requirements to host it
Fail2ban is extremely frugal: it runs on any VPS, even a 1 vCPU / 512 MB, with no perceptible impact. It installs directly on the system (no need for Docker) and requires root access, a firewall backend (iptables or nftables, present by default) and access to the logs of the services to protect (/var/log/auth.log for SSH, the access/error logs for Nginx). No additional domain or port is needed. The golden rule: always configure a whitelist (ignoreip) with your fixed IP before enabling banning, so you don't lock yourself out of your own server.
Install and configure Fail2ban on your VPS
Install Fail2ban
On Debian/Ubuntu: sudo apt update && sudo apt install fail2ban. The service starts automatically. Check with sudo systemctl status fail2ban.
Create a jail.local
Never modify jail.conf directly. Instead, copy your settings into /etc/fail2ban/jail.local: that's where you define bantime, findtime, maxretry and above all ignoreip = 127.0.0.1/8 VOTRE_IP to protect yourself from a self-ban.
Enable SSH protection
In jail.local, enable the [sshd] jail with, for example, maxretry = 3 and bantime = 1h. After 3 failures within findtime, the IP is banned for one hour at the firewall level.
Add a jail for Nginx
Enable the [nginx-http-auth] and [nginx-botsearch] jails by pointing logpath to your Nginx logs. This blocks repeated authentication attempts and malicious URL scans.
Reload and check the active jails
Apply the configuration: sudo systemctl restart fail2ban, then sudo fail2ban-client status lists the active jails and sudo fail2ban-client status sshd shows the currently banned IPs.
Test a ban and the unban
Verify correct operation with sudo fail2ban-client status sshd. To release a legitimate IP blocked by mistake: sudo fail2ban-client set sshd unbanip X.X.X.X.
Enable progressive banning to wear down repeat offenders: in jail.local, set bantime.increment = true and bantime.factor = 2. Each new reoffense doubles the ban duration, which thus goes from one hour to several days for the most persistent IPs. Pair it with a change of the default SSH port and the disabling of password authentication (SSH keys only): Fail2ban then becomes a safety net rather than your only rampart.
The official documentation
For advanced configuration, options specific to the tool, and version changes, refer to the official Fail2Ban documentation. This guide covers deployment on a ServOrbit VPS; the vendor's documentation remains the reference for fine-tuning.
