Published: 15.10.2026
A brute-force attack tries many passwords against a login page until one works. Attackers use automated tools that run day and night, and they often target the standard login addresses of popular systems. This article explains how to recognise an attack, which defences work in practice and how to apply them to WordPress and other sites.
Recognising an attack
- Many failed login attempts in the logs, from a small number of addresses or from many addresses at once.
- Slow pages or high resource use at unusual hours.
- Locked-out users who report that their correct password is rejected.
- Repeated requests for the login page from addresses that never visit any other page.
On a VPS with log access, the grep command with the phrase Failed password, applied to the file /var/log/auth.log, shows failed SSH attempts on Debian and Ubuntu. Web server and application logs show the same pattern for web logins.
Strong passwords and unique accounts
Passwords that appear in leaked lists are tried first by attackers. Use long, random passwords generated and stored in a password manager, with a unique password for each service. Remove old administrator accounts, and give each person a personal account instead of sharing one login. Avoid default usernames such as admin for the administration area.
Rate limits and lockouts
A rate limit caps how many login attempts can be made within a time window. Many content management systems and security plugins offer login limits that block an address or delay responses after several failures. On a server where you have administrator rights, a tool such as fail2ban reads the logs and bans addresses after repeated failures. Start with moderate limits, because very strict settings can lock out your own users.
Two-factor authentication
Two-factor authentication asks for a second proof, usually a code from an app, in addition to the password. A correct password alone is then not enough for an attacker. Enable it for administrators first, and then for every account that can change the site. Store the backup codes safely, because losing the device without them can lock you out.
WordPress examples
- Use a login protection feature from a trusted plugin or from your platform to limit attempts.
- Require two-factor authentication for every administrator account.
- Disable XML-RPC if you do not use it, because it can carry many password guesses in a single request.
- Change the default administrator username and use unique passwords. Moving the login address only reduces noise in the logs, so treat it as an extra step rather than protection.
- Keep WordPress, plugins and themes updated, because outdated components are a common entry point.
Other places attackers try
Brute-force attempts also target FTP and SSH accounts. Use key-based SSH login and disable password login once your keys work. Limit FTP access to the accounts you actually need, and use an encrypted connection option when your connection details offer one.
Check the defence
Test the protection by entering a wrong password a few times from your own computer, and check that the login locks or slows down as planned. Review the logs weekly and watch for unusual spikes. Keep a record of the settings you changed, so that you can relax a limit that blocks your own team.
Frequently asked questions
Will a strong password alone stop attacks? It stops most automated guessing, but a leaked password is still a risk. Rate limits and two-factor authentication add protection for that case.
Can a plugin block brute force completely? A plugin reduces the risk, and it works well together with updates, unique passwords and two-factor authentication.
Is it worth changing the login address? It can reduce noise in the logs, but it is not real protection. Use it only as an extra step.
