Fail2Ban Setup Guide: Protect SSH, Nginx, and WordPress from Brute Force

The Scale of Brute Force Attacks in 2026

Every server connected to the internet is under constant bombardment. The moment you provision a VPS and assign it a public IP address, automated scanners begin probing your SSH port, testing default credentials, and looking for vulnerable web applications. This is not a hypothetical threat — it is a statistical certainty.

Research from security firms consistently shows that an unprotected server receives between 30,000 and 100,000 SSH brute-force attempts daily. WordPress login pages attract thousands of credential-stuffing attempts per hour. Nginx authentication endpoints are continuously hammered by botnets. Without an automated defense mechanism, it is only a matter of time before an attacker finds a weak password or exploits a timing vulnerability.

What Is Fail2Ban and How Does It Work?

Fail2Ban is an intrusion prevention framework written in Python that monitors log files for patterns of malicious behavior and automatically updates firewall rules to block offending IP addresses. It operates on a simple but powerful principle: if someone fails to authenticate too many times within a defined period, they are banned.

The architecture consists of three core components:

Installing Fail2Ban

Fail2Ban is available in the default Ubuntu repositories and can be installed with a single command. After installation, it starts automatically and enables the SSH jail by default.

Configuring the SSH Jail

SSH protection is the most critical jail and should be your first configuration. The default settings are often too lenient for production servers. Here is a hardened SSH jail configuration:

Let us break down each parameter to understand exactly what it does:

Progressive Ban Times

Fail2Ban supports incremental ban times for repeat offenders. This is extremely effective against persistent attackers who return after their initial ban expires:

With this configuration, the first ban lasts 1 hour, the second ban lasts 2 hours, the third lasts 4 hours, and so on — doubling each time up to a maximum of 7 days (604800 seconds). This means persistent attackers face increasingly severe penalties while legitimate users who mistype their password once recover quickly.

Nginx Jails: Protecting Your Web Server

SSH is just one attack vector. Your web server faces its own set of threats: authentication brute forcing, bot crawling, script injection attempts, and more. Fail2Ban ships with several Nginx filters that you can enable immediately.

Nginx HTTP Authentication

If you use HTTP Basic Auth to protect admin areas, staging sites, or internal tools, this jail catches repeated authentication failures:

Nginx Bot Search

Bots constantly scan for vulnerable scripts, backup files, and admin panels. They request paths like /admin, /phpmyadmin, /.env, and /wp-admin even on servers that do not run those applications. The nginx-botsearch jail bans IPs that trigger too many 404 errors on suspicious paths:

Nginx No-Script

This jail targets scanners looking for executable scripts (CGI, PHP, ASP) in locations where they should not exist. It is particularly useful for static sites or sites with strictly controlled PHP locations:

WordPress Brute Force Protection

WordPress is the most targeted CMS on the internet. The wp-login.php and xmlrpc.php endpoints are continuously hammered by credential-stuffing bots. Since Fail2Ban does not ship with a WordPress filter by default, you need to create a custom one.

Writing Custom Filters

The real power of Fail2Ban lies in its extensibility. You can write custom filters for any application that writes authentication events to log files. Here is the anatomy of a filter and how to build one from scratch.

Filter Regex Syntax

Fail2Ban uses Python regular expressions with one special placeholder: <HOST>, which matches an IP address (both IPv4 and IPv6). Every failregex line must contain <HOST> to tell Fail2Ban which IP to ban.

Testing Filters with fail2ban-regex

Before deploying any custom filter, test it against actual log data. The fail2ban-regex command simulates filter matching without affecting your firewall:

Managing Bans: Essential Commands

Knowing how to check status, ban, and unban IPs is critical for day-to-day operations. Here are the commands you will use most frequently:

iptables vs nftables Backend

Modern Linux distributions (Ubuntu 22.04+) have migrated from iptables to nftables as the default firewall framework. Fail2Ban supports both, but you need to configure the correct backend to avoid conflicts.

To configure nftables globally for all jails, add these lines to the [DEFAULT] section of your jail.local:

Email Notifications

You should know when bans are triggered, especially for jails protecting critical services. Fail2Ban can send email notifications on ban and unban events using the sendmail or mail action:

The action types control how much information you receive:

Persistent Bans Across Restarts

By default, Fail2Ban loses all bans when the service restarts (which happens during package upgrades or server reboots). To make bans persistent, you need to enable the ban database:

The dbpurgeage parameter controls how long ban records are kept in the database. Setting it to 604800 seconds (7 days) means that bans are remembered across restarts for up to one week, and the incremental ban time feature can reference previous bans.

Complete Production Configuration

Here is a complete, production-ready jail.local that combines everything we have discussed into a single configuration file:

Monitoring and Troubleshooting

After deploying Fail2Ban, continuous monitoring is essential to ensure it is working correctly and not producing false positives that lock out legitimate users.

Checking Fail2Ban Logs

Common Issues and Solutions

Fail2Ban with Panelica

Best Practices Summary

• Always use jail.local for customizations, never edit jail.conf
• Test every custom filter with fail2ban-regex before deploying
• Use nftables backend on Ubuntu 22.04+ for better performance
• Enable incremental ban times for SSH to punish persistent attackers
• Add your own IP to ignoreip to prevent self-lockout
• Enable the SQLite database for persistent bans across restarts
• Monitor /var/log/fail2ban.log regularly for false positives
• Configure email notifications for critical jails (SSH, database)
• Set aggressive ban times (24h+) for SSH but moderate times (1h) for web jails
• Keep Fail2Ban updated — newer versions include better filters and performance