Back to tutorials
Tutorial

cPanel Fail2Ban Setup Guide Tutorial (2026): Stop Brute-Force Logins in WHM, cPanel & Webmail

cPanel Fail2Ban setup guide tutorial (2026) to block brute-force attacks on WHM, cPanel, webmail, and SSH—step-by-step.

By Anurag Singh
Updated on Aug 26, 2026
Category: Tutorial
Share article
cPanel Fail2Ban Setup Guide Tutorial (2026): Stop Brute-Force Logins in WHM, cPanel & Webmail

Most cPanel compromises start the same way. A bot hammers WHM, cPanel, or webmail until it finds a weak password. This cPanel Fail2Ban setup guide tutorial shows you how to turn that noise into automatic blocks, without changing how your customers log in.

You’ll install Fail2Ban on a cPanel/WHM server. Then you’ll hook it into the services that actually get hit: cPHulk, Dovecot, Exim, and SSH.

The goal is simple. Fewer successful guesses, and fewer “why is this IP trying 2,000 passwords?” alerts.

What you’ll build (and what you won’t)

You’ll configure Fail2Ban to read real authentication logs on a cPanel server. Then it will apply firewall bans.

You’ll start with conservative defaults. That reduces false positives and helps legitimate users avoid lockouts after a bad streak.

  • You will: install Fail2Ban, enable jails for SSH, cPanel/WHM/webmail via cPHulk integration, and mail auth; tune ban times; whitelist trusted IPs; test bans.
  • You won’t: replace cPHulk, add a WAF, or rebuild your stack. If you need WAF rules, that’s a separate job.

Prerequisites and a safe starting checklist

Before you change anything, confirm what you’re running. Also confirm how you’ll recover if you block yourself.

cPanel deployments vary most at the firewall layer (CSF vs firewalld vs nftables).

  • Root access to the server (SSH as root or via sudo)
  • cPanel/WHM installed and licensed
  • A known-good management IP (your office/VPN) that you can whitelist
  • Console access from your hosting provider (recommended), in case you block yourself

If you’re building a new server for hosting clients, start with a VPS with predictable networking and solid console access. A HostMyCode VPS is a clean fit for cPanel pilots and production servers where you want root control without dedicated hardware overhead.

Quick diagnostics (run these first):

cat /etc/os-release
uname -r
whmapi1 version 2>/dev/null | head
ss -lntp | egrep ':(22|2083|2087|2096|2095|993|995|587|465|25)'

Decide how Fail2Ban will ban: CSF, firewalld, or nftables

Fail2Ban bans via “actions.” On cPanel servers, CSF (ConfigServer Security & Firewall) is common.

Newer OS installs may use firewalld. Some admins run direct nftables. Pick one primary enforcement path and stick with it.

  • If you use CSF, Fail2Ban should call csf -d / csf -dr.
  • If you use firewalld, Fail2Ban can use the firewallcmd action.
  • If you use nftables, use the nftables actions (less common on cPanel stacks).

Detect CSF quickly:

command -v csf && csf -v

Detect firewalld:

systemctl is-active firewalld

This tutorial shows a CSF-first setup (common in hosting), with notes for firewalld where it matters.

Step 1 — Install Fail2Ban on a cPanel server

In 2026, most cPanel servers run AlmaLinux/Rocky/CloudLinux. Start with distro packages.

They’re predictable, supported, and easy to patch.

AlmaLinux / Rocky / RHEL family:

dnf install -y epel-release
dnf install -y fail2ban fail2ban-firewalld
systemctl enable --now fail2ban
fail2ban-client status

Debian/Ubuntu (less common for cPanel, but possible):

apt update
apt install -y fail2ban
systemctl enable --now fail2ban
fail2ban-client status

Important: leave /etc/fail2ban/jail.conf alone. Put overrides in /etc/fail2ban/jail.local. Put custom filters in /etc/fail2ban/filter.d/.

Step 2 — Set global defaults (ban time, find time, retries)

Create /etc/fail2ban/jail.local with hosting-friendly defaults. You want bans long enough to slow bots down.

You also want bans short enough that a typo doesn’t turn into a support ticket.

cat > /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
# Tune for hosting: short window, moderate retries
findtime = 10m
maxretry = 5
bantime  = 1h

# Email alerts are optional; many cPanel servers already alert elsewhere
# destemail = root@localhost
# sender = fail2ban@your-hostname
# mta = sendmail

# Whitelist your management IPs (office/VPN/monitoring)
ignoreip = 127.0.0.1/8 ::1
EOF

Add your static management IPs now. Example:

perl -0777 -i -pe 's/^ignoreip = (.*)$/ignoreip = $1 203.0.113.10 198.51.100.24/mi' /etc/fail2ban/jail.local

Restart Fail2Ban:

systemctl restart fail2ban

Step 3 — Enable SSH protection (baseline jail)

Even if SSH is “admins only,” bots still sweep port 22 all day. Start with the standard sshd jail.

Verify bans work before you add cPanel-specific logic.

Add to /etc/fail2ban/jail.local:

cat >> /etc/fail2ban/jail.local <<'EOF'

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = systemd
EOF

Reload and check status:

systemctl restart fail2ban
fail2ban-client status sshd

If you want a least-privilege admin model (recommended on reseller servers), pair this with a controlled sudo workflow. HostMyCode’s guide to SSH access control on a hosting VPS is a good reference.

Step 4 — Choose the cPanel angle: use cPHulk + Fail2Ban, not competing logic

cPanel ships with cPHulk for brute-force protection. Don’t build a fragile setup that scrapes UI logs.

If cPHulk already provides a reliable “this IP is abusive” signal, use it.

The practical pattern in 2026 is simple:

  • Let cPHulk detect abusive login behavior for WHM/cPanel/webmail.
  • Let Fail2Ban apply consistent firewall bans (and give you unified visibility).

First, confirm cPHulk is enabled in WHM:

  1. WHM → Security Center → cPHulk Brute Force Protection
  2. Enable it and set reasonable thresholds (don’t allow unlimited retries).

Also enable stronger admin logins. If you haven’t set it up yet, follow cPanel Two-Factor Authentication for WHM and client access.

Step 5 — Integrate Fail2Ban with CSF (recommended on cPanel stacks)

If you’re running CSF, let Fail2Ban ban through CSF. That keeps enforcement consistent.

It also makes troubleshooting simpler later.

Create an action file:

cat > /etc/fail2ban/action.d/csf.conf <<'EOF'
[Definition]
actionstart =
actionstop =
actioncheck =

actionban = csf -d <ip> "fail2ban-<name>"
actionunban = csf -dr <ip>
EOF

Now set the default banaction in /etc/fail2ban/jail.local:

perl -0777 -i -pe 's/^\[DEFAULT\]/[DEFAULT]\nbanaction = csf/mi' /etc/fail2ban/jail.local

Restart Fail2Ban and verify it loads cleanly:

systemctl restart fail2ban
fail2ban-client ping

If you use firewalld instead: keep banaction as default and ensure fail2ban-firewalld is installed. Then set jails to use banaction = firewallcmd-ipset for better performance under high ban counts.

Step 6 — Add mail authentication jails (Dovecot + Postfix/Exim)

Webmail gets the attention. Many real compromises start with IMAP/SMTP credential stuffing.

Blocking repeated mail auth failures reduces account takeovers and the spam bursts that follow.

On most cPanel servers:

  • IMAP/POP auth: Dovecot logs (often via systemd journal or /var/log/maillog)
  • SMTP: Exim on cPanel, sometimes Postfix on non-cPanel stacks

Add Dovecot jail (works well on systemd-based distros):

cat >> /etc/fail2ban/jail.local <<'EOF'

[dovecot]
enabled = true
port = pop3,pop3s,imap,imaps,submission,465,smtp
backend = systemd
EOF

Add Exim auth jail (logpath varies; cPanel typically logs to /var/log/exim_mainlog):

cat >> /etc/fail2ban/jail.local <<'EOF'

[exim]
enabled = true
port = smtp,submission,465
logpath = /var/log/exim_mainlog
EOF

Restart and inspect:

systemctl restart fail2ban
fail2ban-client status dovecot
fail2ban-client status exim

If your server is struggling with outbound email reputation, don’t rely on hunches. Start with logs and SMTP responses.

Two practical references: email bounce troubleshooting and mail queue troubleshooting.

Step 7 — Protect WHM/cPanel/webmail by watching cPHulk blocks

This is the maintainable approach. Let cPHulk decide what crosses the line. Then let Fail2Ban enforce bans at the firewall.

This avoids chasing log format changes after cPanel updates.

cPHulk log locations can vary by cPanel build. Even so, you can still work from cPanel’s login logs in a predictable way.

A simple option is to watch auth failures in the cPanel login log. Then you ban repeat offenders.

Find your cPanel login log files:

ls -lah /usr/local/cpanel/logs/

Common files include login_log and access_log. We’ll target login_log for failed attempts.

Create a custom filter that matches the obvious failure markers.

Create /etc/fail2ban/filter.d/cpanel-login.conf:

cat > /etc/fail2ban/filter.d/cpanel-login.conf <<'EOF'
[Definition]
# Match common cPanel/WHM/webmail failed login markers in /usr/local/cpanel/logs/login_log
# This is intentionally conservative to avoid false positives.
failregex = ^<HOST>\s+.*\sFAILED\sLOGIN\s.*$
            ^<HOST>\s+.*\sInvalid\slogin\s.*$
ignoreregex =
EOF

Now add the jail:

cat >> /etc/fail2ban/jail.local <<'EOF'

[cpanel-login]
enabled = true
filter = cpanel-login
logpath = /usr/local/cpanel/logs/login_log
port = 2082,2083,2086,2087,2095,2096
maxretry = 5
findtime = 10m
bantime = 2h
EOF

Reality check: the exact strings in login_log can differ. Test the filter before you depend on it:

fail2ban-regex /usr/local/cpanel/logs/login_log /etc/fail2ban/filter.d/cpanel-login.conf

If the regex matches nothing but you know failed logins exist, inspect the latest entries. Then adjust the patterns.

tail -n 50 /usr/local/cpanel/logs/login_log

Restart Fail2Ban and check:

systemctl restart fail2ban
fail2ban-client status cpanel-login

Step 8 — Tune bans so you don’t create support tickets

Most self-inflicted pain comes from two places. One is forgetting ignoreip. The other is choosing ban times that are too aggressive.

  • Admins: whitelist office/VPN IPs. If you don’t have static IPs, use a bastion/jump box and whitelist that single IP.
  • Clients: keep bantime moderate (1–2 hours) for UI logins. For SSH, longer bans are fine.
  • Resellers: expect occasional lockouts from misconfigured mail clients. Use Dovecot bans, but keep retries slightly higher if your user base needs it.

If you need safer SSH patterns, use a dedicated jump host. It reduces exposed admin surface without changing client-facing ports.

See this jump box tutorial.

Step 9 — Test bans safely (without actually getting locked out)

Testing by intentionally failing real logins gets messy fast. Start with Fail2Ban’s client commands.

Then confirm the firewall reflects the block.

Manually ban a test IP (use a non-critical IP):

fail2ban-client set sshd banip 203.0.113.200
fail2ban-client get sshd banip

Verify in CSF:

csf -g 203.0.113.200

Unban it:

fail2ban-client set sshd unbanip 203.0.113.200

If you’re using firewalld, list ipsets instead:

firewall-cmd --get-active-zones
firewall-cmd --info-ipset=f2b-sshd 2>/dev/null || true

Step 10 — Add basic operational visibility (so bans don’t become a mystery)

You don’t want bans to stay invisible until a client opens a ticket. Two habits help:

  1. Review Fail2Ban status as part of your daily server checks.
  2. Watch ban counts and repeat offenders. Then tune thresholds based on reality.

Useful commands:

fail2ban-client status
fail2ban-client status sshd
fail2ban-client status cpanel-login
journalctl -u fail2ban --since "24 hours ago" | tail -n 80

If you want broader signals (uptime + resource spikes + log patterns), build a minimal monitoring baseline. This pairs well with server monitoring for hosting VPS.

Common pitfalls on cPanel servers (and quick fixes)

  • Fail2Ban bans, but traffic still reaches the service: you’re banning in the wrong firewall layer. Confirm you actually use CSF or firewalld, and align banaction.
  • Regex matches too much (false positives): tighten the filter. Favor exact “FAILED LOGIN” style markers, not broad “authentication failure.”
  • cPanel updates change log format: rerun fail2ban-regex after major cPanel updates. Keep your custom filter conservative.
  • Client mail app triggers bans: increase maxretry slightly for Dovecot, but keep findtime short. Also encourage app passwords or stronger credentials.
  • You lock out your own admin IP: whitelist first, and keep provider console access available.

Hardening checklist you can apply in under 30 minutes

  • Enable cPHulk with reasonable thresholds
  • Enable 2FA for WHM administrators
  • Install Fail2Ban and confirm it runs on boot
  • Set ignoreip for admin IPs (office/VPN/jump host)
  • Enable jails: sshd, dovecot, exim, and cpanel-login
  • Test manual ban/unban and confirm firewall state
  • Document how to unban an IP (support runbook)

Summary: a practical defense that fits hosting reality

Every cPanel server lives under constant credential pressure. Fail2Ban won’t fix weak passwords.

Fail2Ban does one thing well: it turns repeated failures into quick, automatic blocks. Pair it with cPHulk and 2FA. You’ll reduce successful brute-force logins without disrupting normal client workflows.

If you’re running multiple sites or reseller accounts, you’ll want predictable performance and root-level security controls. Run cPanel on a VPS sized for your workload. Or bring in managed help once the server becomes business-critical. HostMyCode offers managed VPS hosting for production hosting servers, and you can also start with a self-managed HostMyCode VPS to keep full control of your security stack.

If you’re building a cPanel server for clients, stable compute and predictable networking make security work easier. Start with a right-sized HostMyCode VPS, or choose managed VPS hosting if you want help keeping updates, firewall rules, and security controls consistent.

FAQ

Will Fail2Ban replace cPHulk on cPanel?

No. Use cPHulk as the cPanel-aware detector, and use Fail2Ban as the enforcement layer that applies consistent firewall bans and keeps ban activity easy to review.

Should I ban on the cPanel ports (2083/2087) or just SSH?

Do both. SSH scans never stop, but cPanel/webmail attacks are the direct path to account compromise and outbound spam. Use separate jails so you can set different thresholds and ban times.

What’s a safe ban time for shared hosting customers?

For cPanel/webmail, 1–2 hours is usually enough to slow bots down without creating long client lockouts. For SSH, longer bans (4–24 hours) are fine.

How do I unban a client IP quickly?

Use Fail2Ban so you’re not digging through firewall tables: fail2ban-client set cpanel-login unbanip 198.51.100.50. If you use CSF directly, you can also remove it with csf -dr 198.51.100.50.

Can I do this on a dedicated server instead of a VPS?

Yes. The steps are the same. Dedicated servers make sense when you need consistent CPU under high mail/web load or you host many accounts. Fail2Ban is lightweight either way.