Brute Force Protection

Brute force is repeated guessing of credentials. The usual targets are SSH, wp-login, cPanel, and API endpoints. Modern attackers rarely hammer one account. They use leaked password lists and try many accounts from many IPs so they are harder to notice.

Signs on a server

On Linux, journalctl -u ssh fills with Failed password for root or random usernames. On WordPress, access logs show hundreds of requests to wp-login.php or xmlrpc.php. cPanel may record failed logins from countries you never use.

If CPU rises without a visitor increase, check whether PHP is still processing the login page. Sometimes the attack does not consume bandwidth, but it does consume workers and database connections.

What to do

Disable SSH password login when possible. Use keys, set PasswordAuthentication no and PermitRootLogin no in /etc/ssh/sshd_config, then test with a new session before closing the old one. If passwords are required, restrict the port or source IPs.

Install fail2ban to reduce automated guessing. Example /etc/fail2ban/jail.local:

[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h

After restarting, check fail2ban-client status sshd. For WordPress, use an access-log filter and a jail that reads wp-login.php, or a security plugin with its own rate limit.

Enable 2FA. Two-Factor Authentication means a leaked password is not enough. Store recovery codes somewhere that survives a lost phone.

What usually goes wrong

Behind a CDN or reverse proxy, logs contain the proxy IP. fail2ban can then block the wrong address. Configure real_ip or a module that reads X-Forwarded-For correctly.

While testing SSH rules, keep an existing logged-in session and have provider console access ready. Do not close the old session until the new one is proven to work.

A short bantime lets bots return quickly. For repeated attacks, use one hour or more. But remember that fail2ban is not DDoS protection. For traffic floods, see DDoS and WAF.

FAQ