What Is a Brute-Force Attack and How to Stop It
How brute-force and credential-stuffing attacks work against websites and servers, how to recognise them in your logs, and the layered defences that stop them.
Table of Contents
A brute-force attack is an automated attempt to log in by trying many passwords against a login page or service, such as a WordPress admin, a control panel, SSH or email. Credential stuffing is a variant that tries username and password pairs leaked from other breaches. Both are stopped by the same layers: unique strong passwords, two-factor authentication, rate limiting and lockouts, and blocking abusive sources, plus removing logins that do not need to be public.
Even when attacks fail, they can slow your site and fill your logs, so defences help performance as well as security.
Types of password attacks
| Attack | What happens |
|---|---|
| Simple brute force | Trying many passwords for one account |
| Dictionary attack | Trying common passwords and word lists |
| Password spraying | Trying a few common passwords across many accounts, to avoid lockouts |
| Credential stuffing | Trying leaked username/password pairs from other sites |
Common targets
- CMS logins such as
wp-login.phpandxmlrpc.phpon WordPress. - Hosting control panels and webmail.
- SSH on servers.
- Email accounts (IMAP, SMTP).
- Customer account logins on your own site.
How to recognise an attack
- Many failed logins in a short time, often from many IP addresses.
- Repeated requests to login URLs in access logs.
- Security plugin or host alerts.
- Higher server load or resource-limit errors at odd times; see common hosting errors.
Layered defences
1. Strong, unique passwords
Make guessing hopeless and leaked passwords useless; see strong passwords and password managers.
2. Two-factor authentication
A correct password alone is not enough to log in; see two-factor authentication explained.
3. Rate limiting and lockouts
Slow down or temporarily block repeated failures, per account and per IP address. Use progressive delays rather than permanent lockouts, which attackers can abuse to lock real users out.
4. Block abusive sources
- Fail2ban on servers watches logs and bans IP addresses with repeated failures (SSH, mail and web logins).
- Web application firewalls block known attack patterns and abusive clients at the edge; see what is a web application firewall.
- CAPTCHAs on public login and registration forms slow automated attempts, at some cost to usability.
5. Reduce exposure
- SSH: use key-only authentication and disable password login; brute force then cannot succeed. See SSH security best practices.
- WordPress XML-RPC: block it if nothing uses it.
- Admin areas: restrict by IP address or VPN where practical.
- Unused accounts: delete them.
6. Check for breached passwords
When users set passwords on your site, reject ones that appear in known breach lists.
7. Monitor and alert
Alert on spikes in failed logins and on successful logins from unusual locations.
Example: reading the signs in an access log
A WordPress site becomes slow every night. The access log shows lines like:
198.51.100.23 - - [04/Oct/2026:02:11:07 +0600] "POST /wp-login.php HTTP/1.1" 200 4321
198.51.100.23 - - [04/Oct/2026:02:11:08 +0600] "POST /wp-login.php HTTP/1.1" 200 4321
203.0.113.77 - - [04/Oct/2026:02:11:08 +0600] "POST /xmlrpc.php HTTP/1.1" 200 412
Thousands of POST requests to wp-login.php and xmlrpc.php from a handful of addresses, each returning 200 (the login form re-displayed after a failure), is a classic brute-force pattern. Counting requests per IP for those URLs confirms it:
grep -E 'POST /(wp-login|xmlrpc)\.php' access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
The response: block xmlrpc.php if unused, enable login rate limiting, confirm every administrator uses 2FA, and add the worst addresses to a temporary block list (or let Fail2ban or the WAF do it automatically).
Protecting your own users' accounts
If customers log in to your site or app:
- rate-limit by account and by IP, so attackers cannot try one password across many accounts quickly or many passwords on one account;
- respond with the same message whether the username or the password was wrong, so attackers cannot discover which accounts exist;
- notify users of logins from new devices where practical;
- offer 2FA, and require it for staff accounts.
What not to rely on alone
- Renaming the login URL reduces noise but does not stop targeted attacks.
- Hiding usernames helps a little; strong passwords and 2FA matter far more.
- Blocking whole countries can stop some traffic but also blocks legitimate users and is easily bypassed with proxies.
If an account was compromised
Change the password, revoke active sessions, enable 2FA, review recent activity, and check for changes the attacker made. For websites, see website malware: signs and what to do.
Frequently Asked Questions
Can a brute-force attack crash my website?
High volumes of login attempts can exhaust resources on shared hosting or small servers, which is why rate limiting and edge blocking also protect performance.
Is a strong password enough?
It defeats guessing, but not stolen or phished passwords. Add 2FA.
Should I block IPs permanently?
Temporary bans work well; attackers rotate IPs, and permanent lists grow stale and can block legitimate users who later receive the same address.
Related reading
These defences are part of website security basics. If you see an attack on a ServerNeed shared hosting account, contact support with the times and addresses from your logs.
Sources
Last updated 7 October 2026
