Under Brute Force Attack? Lock Down Your Website Login Page

If your site’s login page is under a brute-force attack, you need a clear lock-down plan—not vague security slogans. Homeowners running a small shop site and local businesses alike often notice slow admin screens, thousands of failed logins, or locked-out staff before they realise bots are hammering wp-login.php, a custom admin URL, or XML-RPC. This guide stays strictly on hardening that login surface: the common failure modes, numbered DIY fixes you can run safely, and when to bring in specialist website support from Fixwebnode so the attack stops without breaking legitimate access.

Fixwebnode works with sites across Geelong and the wider service footprint—see all service areas—with hands-on hardening rather than marketplace hand-offs. Related build work (for example website solutions for builders or Figma to native Gutenberg blocks) only helps if the login path itself is no longer an open door.

Why locking down the login page matters right now

Brute force is simple: automated clients try password lists against your username field until something works. On WordPress and many CMS stacks the default endpoints are public, unthrottled, and logged poorly. A successful guess means full content takeover, malware injection, or customer data exposure. Even a “failed” attack burns CPU, fills auth logs, triggers false lockouts, and can push shared hosting into resource limits. Hardening is about reducing guess rate, removing weak credentials, closing alternate auth doors, and alerting you before damage spreads.

Common issues when your login is under brute force

These problems show up repeatedly on small-business sites. Each has different symptoms and a different root cause—treat them as separate checklists.

1. Default login URL flooded; auth log full of unknown IPs

Symptoms: /wp-login.php or /admin returns slowly; hosting panel shows CPU spikes; auth.log or web access logs list rapid POSTs from many countries; staff occasionally get “too many attempts” even when typing correctly.

2. XML-RPC or alternate auth endpoints bypass your “pretty” login protection

Symptoms: You installed a login-renamer or CAPTCHA plugin, but failed logins keep rising; access logs show hits on /xmlrpc.php, /wp-json/jwt-auth, or REST cookie routes; security plugins report “xmlrpc multcall” bursts.

3. Shared weak admin passwords and no second factor

Symptoms: One generic admin or owner email account; password reused from email; no application passwords policy; after a breach elsewhere, your CMS is the next stop; recovery email goes to an inbox nobody monitors.

4. No server-side ban layer—only a plugin that attackers ignore

Symptoms: Wordfence/iThemes lockouts fire, yet the same subnets return minutes later; VPS has open SSH with password auth alongside the web login; Fail2ban or equivalent is missing; Cloudflare is on DNS-only (grey cloud) so origin still sees raw attack traffic.

How to fix issue 1: throttle and relocate the public login

Goal: cut the request rate at the edge and stop advertising the default path. Prefer reversible changes and keep one emergency admin path documented offline.

Step 1 — Confirm the flood in logs

On a typical Linux VPS or cloud VM:

sudo tail -n 200 /var/log/auth.log
sudo grep -E 'wp-login|xmlrpc' /var/log/nginx/access.log | tail -n 100
# Apache variant:
sudo grep -E 'wp-login|xmlrpc' /var/log/apache2/access.log | tail -n 100

You should see repeated POSTs and 401/302 patterns from rotating IPs. Note peak rates before changing anything.

Step 2 — Enable edge rate limiting (Cloudflare example)

If the zone is proxied (orange cloud), create a WAF rate-limit rule: path contains wp-login.php or your admin path; method POST; threshold e.g. 5 requests per 10 seconds per IP; action managed challenge or block. Verify with a controlled login from your office IP.

Step 3 — Nginx limit_req on the login location

# inside http {}
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# inside server {}
location = /wp-login.php {
 limit_req zone=login burst=3 nodelay;
 include fastcgi_params;
 fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Reload and test:

sudo nginx -t && sudo systemctl reload nginx
curl -I https://your-domain.example/wp-login.php

Step 4 — Optional: change the login slug carefully

Use a maintained plugin (e.g. WPS Hide Login) or equivalent for your CMS. Immediately bookmark the new URL, update your password manager, and confirm XML-RPC is handled separately (next section). Never rely on obscurity alone.

When to call Fixwebnode: if reload breaks admin AJAX, if you are on managed WordPress without shell, or if lockouts trap the owner account—book Geelong website support before you lock yourself out overnight.

How to fix issue 2: close XML-RPC and leftover auth doors

Renaming wp-login.php does nothing if xmlrpc.php still accepts system.multicall password guesses.

Step 1 — Measure XML-RPC abuse

sudo grep xmlrpc /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head
curl -I https://your-domain.example/xmlrpc.php

Step 2 — Disable or tightly restrict XML-RPC

If you do not need Jetpack remote publish or classic mobile apps, block it at the web server:

location = /xmlrpc.php {
 deny all;
 return 403;
}

Or in WordPress (theme/plugin free functions file only if you maintain it):

add_filter('xmlrpc_enabled', '__return_false');

Step 3 — Review REST and custom JWT routes

List plugins that register auth endpoints. Disable unused JWT/OAuth plugins. For headless setups, require application passwords over HTTPS only and rotate tokens after the incident.

Step 4 — Verify

curl -X POST https://your-domain.example/xmlrpc.php -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'
# Expect 403 or empty/disabled behaviour, not a method list

When to call a pro: mobile apps, print workflows, or ERP bridges still depend on XML-RPC—Fixwebnode can whitelist by IP or replace the integration without a hard cutover.

How to fix issue 3: credentials, roles, and MFA

Rate limits fail if the correct password is short or reused. Fix identity next.

Step 1 — Inventory admin users

In wp-admin → Users, or via WP-CLI on the server:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Remove unknown admins; demote contractors to Editor; ensure every remaining admin is a named person.

Step 2 — Force strong unique passwords

Reset each admin password to a 16+ character random value stored only in a password manager. Invalidate sessions:

wp user session destroy <user-id> --all

Step 3 — Turn on two-factor authentication

Install a maintained TOTP plugin (or host-level SSO). Enrol every administrator on a hardware key or authenticator app. Save recovery codes offline—not in the same inbox attackers target.

Step 4 — Kill the classic “admin” username pattern

Create a new administrator with a non-guessable login, log in as that user, then delete or demote admin. Update deployment scripts and local wp-cli configs that still reference the old name.

When to call Fixwebnode: multiple staff share one login, or you need SSO against Microsoft 365/Google Workspace for a Geelong office—identity design is easy to get wrong under pressure.

How to fix issue 4: Fail2ban and origin protection

Plugins alone will not stop determined botnets. Add a ban layer on the host and make sure the CDN actually proxies traffic.

Step 1 — Confirm Cloudflare (or similar) is proxying

DNS A/AAAA records must be proxied. Compare public IP to origin:

dig +short your-domain.example A
curl -s ifconfig.me

If dig returns your bare VPS IP, attackers skip the WAF. Fix DNS first.

Step 2 — Install and enable Fail2ban (Debian/Ubuntu)

sudo apt-get update
sudo apt-get install -y fail2ban
sudo systemctl enable --now fail2ban

Step 3 — Jail for repeated login POSTs (Nginx example)

sudo tee /etc/fail2ban/filter.d/wordpress-login.conf >/dev/null <<'EOF'
[Definition]
failregex = ^<HOST> .* "POST /wp-login\.php
ignoreregex =
EOF

sudo tee /etc/fail2ban/jail.d/wordpress-login.local >/dev/null <<'EOF'
[wordpress-login]
enabled = true
port = http,https
filter = wordpress-login
logpath = /var/log/nginx/access.log
maxretry = 5
findtime = 600
bantime = 3600
EOF

sudo fail2ban-client reload
sudo fail2ban-client status wordpress-login

Adjust logpath for Apache (/var/log/apache2/access.log). Watch bans during the next wave.

Step 4 — Harden SSH so the same campaign cannot pivot

sudo grep -E '^(PasswordAuthentication|PermitRootLogin|PubkeyAuthentication)' /etc/ssh/sshd_config
# Aim for: PasswordAuthentication no, PermitRootLogin no, PubkeyAuthentication yes
sudo systemctl reload sshd

Only after your key login is verified.

When to call a pro: you lack SSH, use cPanel-only hosting, or Fail2ban bans your office NAT—Fixwebnode can tune jails and WAF rules without extended downtime.

When DIY is enough vs when to book Fixwebnode

DIY is enough when you have panel or SSH access, a recent backup you have restored before, one or two admin users, and the attack is mostly noisy failed POSTs with no file changes. Work the four issues in order: prove the flood, close alternate endpoints, fix credentials/MFA, then add Fail2ban/CDN.

Book Fixwebnode when any of these appear: unknown admin users or scheduled tasks; modified wp-config.php, theme files, or new PHP droppers; email deliverability failing after the incident; checkout or membership plugins breaking under rate limits; multisite or custom login flows; or you simply cannot risk locking owners out during business hours. Specialist website support is the right move for production lock-down, clean malware review, and a hardening baseline that survives the next wordlist campaign—not a one-off plugin toggle.

Geography is straightforward: Fixwebnode supports sites for clients in Geelong and across listed regions on the service areas page. Construction and design rebuilds stay separate product lines; the priority here remains stopping the brute-force path first.

Lock the login, then talk through the rest

Brute force against a public login is noisy, predictable, and fixable when you treat symptoms as distinct systems problems: open default URLs, XML-RPC side doors, weak shared admins, and missing host bans. Run the numbered steps above, verify with log greps and controlled login tests, and keep a documented break-glass admin path.

If you want a specialist to harden the stack with you—or the attack already looks like a breach—start a conversation with Fixwebnode via website support in Geelong. Bring your hosting type, CMS version, and a sample of the failed-login log lines so the lock-down plan matches your live site, not a generic checklist.