Your login page is under attack right now
Every public WordPress site gets the same traffic it never asked for: automated bots cycling username and password combinations against wp-login.php. They don't need to guess well. They need to guess often. XML-RPC and the REST API hand them two more doors into the same building.
You won't spot it in your analytics. You'll spot it in a sluggish admin, a flood of failed-login emails, or, on the bad day, an account that isn't yours posting spam. One weak password on one account is the whole game.
What most people do
Deny from rules work until you switch hosts, lose the file, or fat-finger your own IP and need FTP to climb back in.A better way: three commands, one front door
TrueCommander gives you the two things that actually stop brute-force: a rate limiter and a blocklist. Both are plain commands. Type limit login attempts and every authentication endpoint starts counting failures per IP. Type block ip and a specific address or whole range stops reaching the site. Type unblock ip to open the door again.
You can't lock yourself out. A block ip rule never touches a logged-in admin at request time, so you can always reach wp-admin to undo it. And limit login attempts only ever counts failures, never your successful logins.
What each command does
Three commands, one job: keep the wrong people off your login screen and let the right ones straight through.
| Command | What it does |
|---|---|
limit login attempts | Brute-force protection for wp-login.php, XML-RPC and REST authentication. Tracks failed attempts per IP. Once the limit is hit within the window, that IP is locked out. |
block ip | Blocks a single IP, an IPv6 address, or a CIDR range from the whole site. Self-registers as a startup command and stacks, so you can run it again to append another address. |
unblock ip | Removes one exact IP or range from the blocklist. Pass -all=true to clear every entry and delete the startup row. |
How it works
limit login attempts It counts failed logins per IP across all three auth endpoints, using fixed-window timing so counters reset on their own.block ip The block self-registers as a startup command, so it holds on every request and survives theme switches and updates.unblock ip Remove one address when a range turns legit again, or wipe the whole list with -all=true.| Detail | Value |
|---|---|
| Command names | limit login attempts, block ip, unblock ip |
| Rate-limit defaults | 5 attempts · 15-minute window · 30-minute lockout (all adjustable) |
| Block formats | IPv4, IPv6, or CIDR range. Examples: 1.2.3.4, 2001:db8::/32, 45.155.205.0/24 |
| Self-lockout guard | Admins are never blocked; -force=true overrides if you really mean it |
| Persistence | Blocklist stored as a startup command. Additive, runs on every page load |
| Can be used in |
Real example
You're back from the weekend to 240 failed-login notifications. The same handful of IPs, thousands of attempts against admin, editor, and your first name.
You run tp limit login attempts -max=5. Now any IP gets five tries every fifteen minutes, then a thirty-minute time-out, and the automated runs grind to nothing. Two addresses are clearly not human, so you run tp block ip -ip=185.220.101.42 and tp block ip -ip=45.155.205.0/24 to take out the whole noisy range.
A week later the host rotates and that range belongs to a real customer again. One tp unblock ip -ip=45.155.205.0/24 and they're back in. No plugin installed, no .htaccess touched, no settings page opened.
Goes further with TrueCommander
limit login attempts to a shortcut. One keypress drops the threshold and extends the lockout while the spike is live.tp unblock ip -all=true monthly so old blocks don't quietly pile up and shut out customers who rotated onto a flagged range.