---
title: Brute Force Protection
description: "Repeated login attempts against SSH, wp-login, or cPanel. Limit attempts, enable 2FA, and block the source."
canonical: https://penasihathosting.com/en/hosting-wiki/brute-force
type: wiki
locale: en
updated: 2026-10-29
author: Willya Randika
---

# Brute Force Protection

## Overview

- **Summary:** Repeated login attempts against SSH, wp-login, or cPanel. Limit attempts, enable 2FA, and block the source.
- **Author:** Willya Randika ([profile](/penulis/willya-randika))

## Article

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`:

```ini
[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](/en/hosting-wiki/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](/en/hosting-wiki/ddos) and [WAF](/en/hosting-wiki/waf).

## FAQ

<Accordion>
  <AccordionItem title="Is fail2ban enough for WordPress?">
    No. It reduces password guessing, but vulnerable plugins, weak accounts, and malware still need updates, 2FA, and scanning.
  </AccordionItem>
  <AccordionItem title="Why was my IP blocked after a few wrong passwords?">
    That is the intended behavior. Use `fail2ban-client set sshd unbanip YOUR_IP` from another session, then fix the credentials.
  </AccordionItem>
  <AccordionItem title="Is changing the SSH port enough?">
    It only reduces automated noise. It is not real security. Key-based auth, 2FA, and a firewall still matter more.
  </AccordionItem>
</Accordion>