cPGuard Brute Force Protection — Block Login Attacks on Your Hosting

Brute force attacks are the simplest yet most relentless threat to any hosting account. Every day, millions of bots scan the internet looking for unprotected servers, trying default passwords and common username combinations thousands of times per minute. cPGuard Brute Force Protection automatically blocks these attacks at every entry point — SSH, DirectAdmin control panel, FTP, email, and WordPress login — so attackers never get close to your account.

Unlike manual defense, cPGuard works 24/7 without any action on your part. The moment an attacker tries too many failed logins, they're instantly banned at the firewall level. Even better, cPGuard uses off-server CAPTCHA filtering that stops bots before they ever consume your server's CPU — a technique that significantly reduces load and improves response times for legitimate users.

What threats does cPGuard actually stop?

Brute force is far more common than most hosting users realize. Security researchers report that, on average, a public-facing server experiences a brute force login attempt every 30 seconds. Over a week, that's 20,000+ attempts. Without protection, a weak password can be cracked in hours. With cPGuard active, attackers give up within minutes when they hit the ban wall.

Service	Protection method	Outcome
SSH (Port 22)	Fail2Ban + auto-ban via nftables	Block IPs that fail N times in X seconds
DirectAdmin login	Rate limiting + IP ban	Prevent panel login attacks
FTP (Port 21)	Fail2Ban integration	Block FTP credential stuffing
Email (SMTP/IMAP/POP3)	Rate limiting + ban	Prevent email account takeover
WordPress wp-login.php	DNS-based CAPTCHA + rate limit	Filter bots before they reach server
WordPress XML-RPC	Block / CAPTCHA	Close hidden brute-force channel
Custom login URLs	User-defined	Protect custom app admin pages

How DNS-based CAPTCHA works — and why it's faster

Traditional CAPTCHA solutions display the challenge directly on your server. This sounds fine on paper, but in practice it means your server is still doing work: rendering the CAPTCHA, validating responses, tracking sessions. If a bot is sending 1,000 requests per second, your server processes 1,000 CAPTCHA renders before it can reject them. That burns CPU.

cPGuard uses a smarter approach: DNS-based CAPTCHA redirection. When a login attempt occurs, cPGuard doesn't spend your server's resources. Instead, it redirects the request to OPSShield's dedicated CAPTCHA server. The bot cannot solve a CAPTCHA (bots are designed to spam, not to understand image puzzles). The bot is filtered out right there, never reaching your server. A real user who passes the CAPTCHA is redirected back to your login page on your server.

The result is dramatic: 99% of bot traffic never consumes a single millisecond of your server's CPU. Your hosting feels faster, your bandwidth usage drops, and your server stays responsive even under heavy attack. This is why enterprise hosting providers swear by offloaded CAPTCHA — it's not just about security, it's about performance.

Rate limiting and automatic IP banning — configurable thresholds

For services where CAPTCHA is too strict — like SSH and FTP, where legitimate scripts might make multiple rapid calls — cPGuard uses rate limiting combined with Fail2Ban and nftables firewall rules. This is equally effective but gives legitimate traffic more tolerance.

Here's how it works:

• Configure a threshold: e.g., "Allow 5 failed login attempts in 60 seconds"
• Monitor in real-time: cPGuard counts failed attempts from each IP
• Trigger auto-ban instantly: When IP exceeds the threshold, Fail2Ban creates an nftables firewall rule that blocks that IP completely
• Set ban duration: Temporary bans (e.g., 1 hour) automatically expire; permanent bans stay until manually removed
• Zero CPU cost: Once banned, packets from that IP are dropped at the kernel layer — your application never even sees them

The power of firewall-layer blocking is that it's incredibly efficient. Your web server doesn't waste resources rejecting the banned IP — the operating system kernel handles it first. This is why large attacks that used to take down unprotected servers are trivial to handle with cPGuard active.

WordPress-specific brute force protection — wp-login.php and XML-RPC

WordPress is by far the most targeted platform for brute force attacks. Every WordPress install has the same login URL (`/wp-login.php`), and bots know this. Studies show that 50–80% of all hosting brute force attacks target WordPress credentials.

cPGuard has two dedicated defenses for WordPress:

wp-login.php — the main dashboard attack vector

cPGuard adds a DNS-based CAPTCHA checkpoint directly before your WordPress login page. The moment an attacker reaches `/wp-login.php`, they're forced to solve a CAPTCHA. Most bots cannot do this. Meanwhile, your legitimate users — the same ones who successfully navigate your entire website — are asked to solve a simple image puzzle, which takes less than 10 seconds. This tiny friction is worth the 99.9% reduction in attack traffic.

You can also configure strict rate limits specific to wp-login.php — for example, "max 3 attempts per IP per 5 minutes" — since legitimate users don't need to try logging in more than once or twice.

XML-RPC (xmlrpc.php) — the backdoor brute-force channel

XML-RPC is a WordPress API endpoint that was designed for remote publishing. It's also a favorite of attackers because a single XML-RPC request can test hundreds of passwords in one go. Many hosting admins don't even know XML-RPC exists until they check their logs and see thousands of requests from unknown IPs trying to brute-force the `blogger.getUsersBlogs` method with random credentials.

cPGuard can block XML-RPC entirely (if you don't use remote apps), or it can add rate limiting and CAPTCHA to it. For most modern WordPress setups that use the REST API instead of XML-RPC, complete blocking is safest.

SSH brute force protection — the most aggressive attack vector

SSH (Secure Shell, port 22) is how server administrators connect to their hosting. It's also the #1 target for automated bots. If your server has SSH exposed to the internet (which all shared hosting does by default), it's under constant bombardment — literally thousands of attempts per day from botnets trying default usernames and passwords.

Without cPGuard, an attacker trying to break a 12-character password might take days. With cPGuard active and configured correctly (e.g., ban after 3 failed attempts within 60 seconds), attackers give up after seconds. The ban is enforced at the firewall level, so the attacker can't even establish a TCP connection — they're blocked before SSH even runs.

Many hosting providers recommend disabling SSH entirely for users who don't need it, or changing the default port. cPGuard is better: it keeps SSH on the standard port (so your scripts and deploys work normally) but makes it impenetrable to brute force attacks.

FTP and email account protection

While SSH gets the most attention, FTP and email are also heavily attacked. Bots try to compromise FTP credentials to upload malware and spam scripts. They target email inboxes to harvest contact lists for phishing campaigns.

FTP protection: cPGuard integrates with Fail2Ban to monitor FTP login attempts. After N failed attempts, the IP is banned. Your legitimate FTP client won't trigger this unless you're typing your password wrong over and over — but if a bot is credential-stuffing, it's banned within seconds.

Email protection: Email servers (SMTP/IMAP/POP3) are defended similarly. If an attacker tries 50 passwords in 2 minutes, cPGuard bans them. Your real users can safely attempt to log in a few times if they misremember a password.

IP whitelist — lock admins out of their own lockout

One risk of aggressive auto-banning is locking yourself out. Imagine your home Internet gets a new IP, or your office uses a shared corporate proxy. You try to log in to your DirectAdmin panel a few times (maybe password typo), and suddenly you're banned. Now you can't access your own hosting.

cPGuard solves this with IP whitelisting. You can whitelist trusted IPs (your office, your home, your VPN, your CI/CD server) that never trigger bans no matter how many times they attempt login. These IPs are treated as trusted and are never rate-limited or banned.

To manage whitelists, log into your AsiaGB App Portal and add your IP. You can update this list anytime — if you travel and switch to mobile internet, you can temporarily add your new IP, then remove the old one.

How cPGuard integrates with DirectAdmin and hosting control panels

cPGuard is built into DirectAdmin and automatically protects every login point on DirectAdmin. You don't install plugins or make code changes — it's built-in security that activates the moment you need it.

From the DirectAdmin admin interface, you can:

• Enable/disable protection per service (SSH, DirectAdmin, FTP, Email, etc.)
• Adjust thresholds (e.g., "ban after 5 failed attempts" instead of the default 3)
• Set ban durations (temporary: 30 min, 1 hour, 24 hours; or permanent)
• View active bans and manually unban IPs
• Whitelist trusted IP ranges
• Configure custom login URLs to protect (e.g., protect `/admin-portal` with CAPTCHA)

For users who don't access DirectAdmin, AsiaGB support can adjust settings on your behalf. Most users never need to touch settings — the defaults are well-tuned for typical hosting workloads.

Logs and monitoring — see attacks as they happen

cPGuard maintains detailed logs of all login attempts, bans, and CAPTCHA interactions. You can view these logs via DirectAdmin or request them from AsiaGB support. Logs are useful for:

• Diagnosing lockouts: "Why can't I log in?" → Check logs, see you were banned, unban yourself
• Spotting compromises: "My email was hacked" → Check logs, see that someone's password was correct (internal breach) vs. many failed attempts (external attack)
• Security audits: Track which IPs attacked, when, and how many attempts

When to use CAPTCHA vs. rate limiting — cPGuard's strategy

cPGuard automatically chooses the right defense for each service:

• CAPTCHA (DNS-based): WordPress, Joomla, custom web applications. These are attacked by bots that can send thousands of requests instantly. CAPTCHA stops them before your server is hit.
• Rate limiting + ban: SSH, FTP, email, DirectAdmin panel. These are used by legitimate scripts that might need multiple connections (e.g., a backup script). Rate limiting allows a few attempts, then bans; CAPTCHA would break legitimate scripts.

The end result is the same — attackers can't get in — but the method matches each service's needs.

Compatibility with other security tools

cPGuard plays well with other hosting security tools. It integrates with Fail2Ban (covered above), but also works alongside:

• Imunify360: Another security suite that monitors malware. Both work together without conflicts.
• ModSecurity / WAF rules: cPGuard handles login brute force; ModSecurity handles SQL injection and web attacks. Complementary, not competing.
• SSL/TLS certificates: cPGuard doesn't interfere with encryption.
• Backup and restore: Whitelists and ban lists are preserved during backup/restore.

Performance impact — is cPGuard slow?

No. cPGuard is designed to be invisible under normal conditions. If you're not under attack:

• DNS-based CAPTCHA: Adds ~200ms for WordPress login (the redirect to OPSShield and back) only to new IPs or after rate-limit reset. Users on whitelisted IPs, or users from the same IP who logged in recently, skip CAPTCHA.
• Firewall bans: Zero overhead. The kernel handles bans before your application code even runs.
• Logging: Negligible — a few kilobytes per day of disk I/O.

Real performance gains appear when you're under attack. Without cPGuard, a heavy brute force attack can spike CPU to 100% and make your site slow. With cPGuard, the attack is filtered at the firewall — your CPU stays low, your site stays fast.

Frequently Asked Questions

What is a brute force attack?

An automated attack that tries thousands or millions of username/password combinations until it gains access. Bots constantly scan servers across the internet 24/7 looking for weak credentials and standard login URLs. A single unprotected server can receive tens of thousands of attack attempts per hour. Most attempts use stolen password lists (leaked from major breaches over the past decade) or common default passwords.

What is DNS-based CAPTCHA and how does it work?

Instead of serving a CAPTCHA directly on your server, cPGuard redirects the user to OPSShield's CAPTCHA server first. Once passed, the user returns to your site. This filters bots before they ever reach your server, reducing load significantly. It's more efficient than server-side CAPTCHA since the offload happens at the DNS/request level. OPSShield's servers are specialized for handling millions of CAPTCHA requests per day, so they can absorb attack traffic without breaking a sweat.

Does cPGuard protect WordPress login?

Yes — cPGuard protects wp-login.php and XML-RPC with CAPTCHA, rate limiting and IP banning when failed login attempts exceed a configured threshold. It also blocks known vulnerable endpoints like wp-admin.php bruteforce paths and can be configured to protect custom admin URLs.

How does auto-ban work?

When an IP fails login attempts beyond a set limit, cPGuard automatically bans it via Fail2Ban and nftables firewall rules. Ban duration and attempt thresholds are configurable. Banned IPs cannot reach your server at all — the firewall drops packets before they consume CPU. Temporary bans automatically expire (e.g., after 1 hour); permanent bans require manual removal.

What if my own IP gets banned?

Connect from a different IP or mobile data and whitelist your normal IP through the App Portal, or contact hosting support to unban it. IPs can be temporarily banned (e.g., 1 hour, 24 hours) or permanently, so check the ban duration first. You can request a list of your current bans via AsiaGB support.

Can cPGuard be customized for my needs?

Yes — cPGuard offers fine-grained configuration: adjust failed attempt thresholds, ban durations, enable/disable protection per service, whitelist trusted IPs, and define custom login URLs. AsiaGB support can assist with custom setups if you need to balance security with specific legitimate use cases.