Advanced Fail2ban: protecting Nginx, WordPress and mail

If you followed securing SSH, Fail2ban already protects your SSH access. But on a web server, bots mostly go after everything else: login forms, admin pages, forgotten configuration files. This guide extends Fail2ban to Nginx, WordPress and mail, and adds a long ban for those who keep coming back.

1. How Fail2ban decides

Fail2ban combines three elements in a jail:

• a filter, a regular expression that recognises a malicious attempt in a log;
• thresholds: maxretry attempts within a findtime window trigger a ban lasting bantime;
• an action, usually a firewall rule that blocks the address.

Fail2ban ships dozens of ready-made filters in /etc/fail2ban/filter.d/. Never edit the provided .conf files: put your settings in .local files, which are not overwritten by updates.

2. A clean base with an allow-list

Start with /etc/fail2ban/jail.local:

[DEFAULT]
bantime   = 1h
findtime  = 10m
maxretry  = 5
banaction = ufw
ignoreip  = 127.0.0.1/8 ::1 YOUR_STATIC_IP

ignoreip is essential: add your office address or your monitoring server to it. Without it, a burst of legitimate connections, such as a deployment script reconnecting several times, can ban you from your own server.

3. The backend trap

Fail2ban reads either log files or the systemd journal. SSH writes to the systemd journal, especially on Debian 12, whereas Nginx writes to files. If you set backend = systemd in the [DEFAULT] section, the Nginx jails ignore their logpath and never see anything, without any error message. So set the backend per jail: systemd for SSH, auto for services that write to files, as in the examples below.

4. Protect Nginx

Add to jail.local:

[sshd]
enabled = true
backend = systemd
maxretry = 3
bantime  = 24h
[nginx-http-auth]
enabled = true
backend = auto
port    = http,https
logpath = /var/log/nginx/error.log
[nginx-botsearch]
enabled  = true
backend  = auto
port     = http,https
logpath  = /var/log/nginx/access.log
maxretry = 2
[nginx-limit-req]
enabled = true
backend = auto
port    = http,https
logpath = /var/log/nginx/error.log
maxretry = 10

• nginx-http-auth bans repeated failures on areas protected by an Nginx password.
• nginx-botsearch spots bots probing your site for admin pages and well-known scripts.
• nginx-limit-req bans addresses that regularly exceed Nginx's request limit. It only works if you have configured a limit_req directive, described in limiting the impact of a DDoS attack.

5. Protect the WordPress login form

No WordPress filter is provided. Create /etc/fail2ban/filter.d/wordpress.conf:

[Definition]
failregex = ^<HOST> .* "POST /wp-login\.php
            ^<HOST> .* "POST /xmlrpc\.php
ignoreregex =

Then the matching jail:

[wordpress]
enabled  = true
backend  = auto
port     = http,https
filter   = wordpress
logpath  = /var/log/nginx/access.log
maxretry = 5
findtime = 10m
bantime  = 6h

A legitimate user submits the form once or twice; a bot, dozens of times. If you host several sites with separate logs, list them all on several lines in logpath. For configuring WordPress itself, see installing WordPress on a VPS.

6. Protect mail

If the server receives mail or authenticates users over SMTP:

[postfix]
enabled = true
backend = systemd
mode    = aggressive
[postfix-sasl]
enabled = true
backend = systemd
maxretry = 3

The aggressive mode also catches relay attempts and non-existent addresses. A server that only sends notifications does not need these jails: see configuring Postfix.

7. Punish repeat offenders

Many bots come back as soon as their ban ends. The recidive jail reads Fail2ban's own log and bans for a week any address banned several times in one day:

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 3

8. Test a filter before enabling it

A filter that matches nothing protects nothing; a filter that is too broad bans your visitors. Test it on the real log:

fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wordpress.conf

The command shows how many lines match. Then apply the configuration:

fail2ban-client -t && systemctl restart fail2ban
fail2ban-client status

The first command checks the syntax of the whole configuration; the last lists the active jails.

9. Manage bans

fail2ban-client status wordpress                  # addresses banned by one jail
fail2ban-client set wordpress unbanip 203.0.113.10 # unban an address
fail2ban-client get sshd ignoreip                 # show the allow-list
fail2ban-client banned                            # every banned address

If you banned yourself, connect from another connection, for example your phone's hotspot, or through the rescue console, then unban your address and add it to ignoreip.

Frequently asked questions