Stop WordPress Login Attacks Before They Reach Your Site

Every WordPress site has a login page at the same address, /wp-login.php, and bots know it. On our own production server, a single IP address tried to log in 1,420 times in two months. Two others tried 860 and 742 times, and more than 40 different addresses joined in. None of them got in, but every attempt cost the server work, and one weak password would have been enough. fail2ban is a small tool that watches for this and shuts the door on an attacker after a handful of tries.

Why login attacks matter even when they fail

A brute-force attack is a bot guessing usernames and passwords, one after another, until something works. Most of these bots are not aimed at you. They work through lists of millions of sites and try the same common passwords on each one. That has three costs for a small business site:

• Risk. One reused or simple password on any account with editing rights is enough for a takeover: spam pages, a redirect to a scam site, or malware served to your visitors. For a business that means lost orders, a browser or Google warning on your own site, and days of cleanup while customers see a broken page.
• Speed. Each login attempt runs PHP and queries the database, just like a real visit. Thousands of them slow the site down for your actual customers.
• Noise. Security plugins that block at the WordPress level still let every request reach WordPress first, so the server does the work before the plugin says no.

What fail2ban does

fail2ban runs on the server, outside WordPress. It reads the web server’s access log, the list of every request the site receives. When one address fails to log in too many times within a short window, fail2ban adds a firewall rule that blocks that address. After the ban time runs out, the rule is removed again.

Because the block happens at the firewall, a banned bot never reaches WordPress at all. There is no plugin to update, nothing in the WordPress dashboard, and nothing that slows down normal visitors. The bans are temporary on purpose: attackers change addresses anyway, and a short ban means a real person who mistyped their password a few times is only locked out for minutes, not forever.

What to do as a site owner

1. Use strong, unique passwords for every account that can edit the site, and remove old accounts nobody uses. fail2ban slows guessing down; it does not make a weak password safe.
2. Ask your host what protects the login page. A good answer names something that blocks at the server or firewall level, not only a plugin. A host that cannot answer is a warning sign. Three questions worth sending: Do you limit failed logins at the server? How long is a ban, and can my own team get locked out? Do I get told when an attack is blocked?
3. Switch on two-factor login. Even a stolen password then gets an attacker nowhere. It is the strongest single step after a unique password, and it takes ten minutes to set up.
4. If you run your own server, turn it on. fail2ban is free and common on Linux servers. On Trellis, the server setup we use, it takes one setting and one command, shown below.

How we set it up on our own servers

Imagewize runs on a Trellis server on Hetzner. Trellis installs fail2ban and protects SSH out of the box, but its WordPress login jail ships switched off. We turned it on with a ban after six failed logins within ten minutes, lasting fifteen minutes. The first attacker was caught within seven hours.

One thing caught us out. Jasper works from changing locations and VPN exits, and the filter we started with sometimes banned him while he was simply using the site. The cause was a pattern that matched wp-login.php anywhere in a log line, including the address of the page someone came from. Tightening it to look only at the requested page itself fixed the false bans. We still exempt a VPN range, because one ban did land during a two-factor reset, so treat an exemption list as a safety valve, not a substitute for a correct filter.

# group_vars/all/security.yml
fail2ban_bantime: 900        # 15 minutes
fail2ban_maxretry: 3         # global default, used by the sshd jail

fail2ban_services_custom:
  - name: wordpress_wp_login
    filter: wordpress-wp-login
    enabled: "true"
    port: http,https
    logpath: "{{ www_root }}/**/logs/access.log"
    maxretry: 6                # more forgiving for real users

trellis provision --tags fail2ban production

ssh -t admin@example.com "sudo fail2ban-client status wordpress_wp_login"

# filter.d/wordpress-wp-login.conf
[Definition]
failregex = ^<HOST> .* "POST [^"]*wp-login\.php[^"]*" 200

sudo fail2ban-regex /srv/www/example.com/logs/access.log \
  /etc/fail2ban/filter.d/wordpress-wp-login.conf

sudo fail2ban-client set wordpress_wp_login unbanip 203.0.113.7

Login attacks are not the only bots that hammer a WordPress site. Our post on rate limiting contact form spam with Nginx covers the other common one, and hardening PHP-FPM pools on Trellis covers what happens when too many requests get through at once. fail2ban needs control of the server, so it is not an option on shared hosting. If you would rather not run any of this yourself, that is what managed WordPress hosting is for.

Frequently asked questions

• Do I still need a security plugin if I use fail2ban? fail2ban covers login guessing at the server level, which is where it is cheapest to stop. A plugin can still be useful for things like two-factor login. They do different jobs.
• Can fail2ban lock out my own team? Only after several wrong passwords in a short time, and only for the ban period, fifteen minutes in our setup. Office or fixed IP addresses can be put on an exemption list.
• Does fail2ban slow down my website? No. It reads the log in the background, and blocked addresses are refused by the firewall before they reach the web server, so it takes load off the site rather than adding it.
• Does hiding or renaming wp-login.php stop brute force attacks? It cuts the noise from simple bots, but it is not a real defense. Attackers find the new address, and the login still accepts unlimited guesses. Limiting failed logins and using two-factor login are what actually stop the attack.
• Can I use fail2ban on shared hosting? No. It needs control of the server’s firewall. On shared hosting, ask your host what they run instead.