cPanel Firewall Setup Guide (2026): Configure CSF + LFD in WHM Without Breaking Email or AutoSSL

A default cPanel install usually feels calm on day one. By day ten it’s noisy: login probes on 2087/2083, SMTP auth attempts, and port scans on anything that answers. You don’t need an elaborate network design to fix that. You need a cPanel firewall setup guide that fits real WHM servers: install CSF + LFD, keep WHM/cPanel reachable, and avoid changes that break mail, AutoSSL, or DNS.

This walkthrough assumes you manage a WHM server (VPS or dedicated) and want a hosting-safe baseline. Examples use AlmaLinux/Rocky with cPanel. The same sequence works on most supported distributions.

Before you touch the firewall: quick prep to avoid lockouts

Firewalls rarely “break” servers. Lockouts are the common failure mode.

Do these checks first so you can recover fast.

Have console access. On a VPS, confirm KVM/VNC or rescue access is available. On a dedicated server, check for out-of-band access if your provider offers it.
Confirm your management IP. From your workstation, run curl -s https://ifconfig.me and write down the IP. If you’re behind CGNAT or your IP changes often, allow a VPN IP or a stable office range instead.
Know your service ports. Typical cPanel hosting needs: 22 (SSH), 80/443 (web), 2087/2083 (WHM/cPanel), 25/465/587 (SMTP), 110/995 (POP3), 143/993 (IMAP), 53 (DNS if you host it), and 21 + passive FTP ports if you still support FTP.

If SSH hardening is still on your list, do it before you tighten firewall rules. HostMyCode includes rollback steps in this SSH lockdown tutorial.

Decide your baseline policy (what you will and won’t allow)

CSF (ConfigServer Security & Firewall) is common in cPanel environments because it fits hosting reality. You get simple port rules, IP allowlists, and LFD for login-failure detection.

Your goal isn’t “block everything.” Your goal is predictable access and a smaller attack surface.

Use this baseline if you host typical websites and mailboxes:

Inbound allowed: 80, 443, 22 (restricted), 2087/2083 (restricted), 25/465/587, 110/995, 143/993, 53 (only if you run authoritative DNS), 2077/2078 (webdisk if needed), 2096/2095 (webmail if you use it).
Outbound allowed: 80/443 (updates, plugins), 25/587 (mail delivery), 53 (DNS lookups), and anything else you explicitly need (backups to an S3 endpoint, monitoring, etc.).
Inbound blocked: everything else by default.

If you’re moving clients from shared hosting onto your own WHM server, expect “legacy” requirements. FTP and older mail clients still show up.

Decide what you’ll support before the migration, not after the first wave of tickets. For cutover sequencing, pair this guide with HostMyCode’s DNS cutover checklist.

Install CSF on a cPanel/WHM server

On cPanel servers, install CSF from the shell as root. After that, manage it from WHM.

Remove/disable conflicting firewalls (carefully). If you’re using Firewalld, CSF typically runs best with it disabled. Check status:
```
systemctl status firewalld
```
If it’s active and you want CSF as the primary firewall:
```
systemctl stop firewalld
systemctl disable firewalld
```
Install required Perl modules (usually already present on cPanel). Most cPanel builds already include what CSF needs.

If you see missing module errors later, install them from your OS repositories.

Download and install CSF.

cd /usr/src
rm -rf csf*
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh

Verify it loaded.
```
csf -v
csf -l
```

In WHM, search for “ConfigServer Security & Firewall.” If it doesn’t appear, refresh cPanel’s components:

/usr/local/cpanel/scripts/upcp --force

First run: test mode, then apply rules safely

CSF starts in testing mode to prevent instant lockouts. Keep it enabled until your port list and allowlists are confirmed.

Open the main config.
```
vi /etc/csf/csf.conf
```
Leave this enabled initially:
```
TESTING = "1"
```
Set your inbound/outbound ports. These are the lines you’ll revisit most often:
```
TCP_IN = "22,25,53,80,110,143,443,465,587,993,995,2083,2087,2095,2096"
TCP_OUT = "22,25,53,80,110,113,443,587"
UDP_IN = "53"
UDP_OUT = "53,113"
```
Notes:
- 113 is ident (some mail checks still touch it). It’s usually harmless outbound; inbound is typically not required.
- If you run passive FTP, you must add 21 plus a passive port range (covered later).
- If you don’t host DNS on this server, don’t open inbound 53.
Reload CSF.
```
csf -r
```

Don’t guess here. Validate reachability from outside before you disable test mode.

Allow WHM/SSH access without leaving them open to the world

WHM (2087) and SSH (22) get hammered on public IPs. If you administer from a small set of networks, IP allowlisting is safer than relying on brute-force protection alone.

Whitelist your admin IP(s). Add your workstation or office IP to /etc/csf/csf.allow:
```
vi /etc/csf/csf.allow
```
Add a line like:
```
203.0.113.10 # admin workstation
```
Then reload:
```
csf -r
```
Optionally restrict SSH/WHM with TCP wrappers-style rules. CSF supports country and IP restrictions.

The lowest-risk approach is simple: allowlist trusted IPs, enforce SSH keys, disable passwords, and add 2FA where it makes sense.
Confirm access from a second network. Test from a mobile hotspot or another office connection.

If something’s wrong, fix it while TESTING=1 is still acting as your safety net.

Enable LFD (Login Failure Daemon) and tune it for hosting reality

LFD turns CSF from “static rules” into active protection. That means more blocking, but also more chances for false positives.

Block repeated failures, but don’t ban legitimate users for typos or flaky mail clients.

Enable key LFD options in /etc/csf/csf.conf. Start with sensible defaults:

LF_DAEMON = "1"
LF_SSHD = "1"
LF_CPANEL = "1"
LF_SMTPAUTH = "1"
LF_POP3D = "1"
LF_IMAPD = "1"

Set ban thresholds that won’t punish normal users. A reasonable starting point for shared/reseller-style hosting:
```
LF_TRIGGER = "10"
LF_SSHD_PERM = "1"
LF_CPANEL_PERM = "1"
LF_SMTPAUTH_PERM = "0"
```
Why: SSH and WHM are admin surfaces; permanent bans are usually fine there. SMTP/IMAP/POP are customer-facing; permanent bans tend to create support churn.
Set temporary ban time. This slows attackers without turning every incident into an emergency:
```
LF_TEMPBAN = "3600"
```

Reload and watch logs.

csf -r
systemctl restart lfd

tail -f /var/log/lfd.log

If you’re chasing webmail or SMTP issues, separate “blocked by firewall” from “broken mail config.” This HostMyCode guide keeps the mail-side diagnosis clean: cPanel email troubleshooting in WHM.

Stop the most common hosting attacks: port scans, floods, and bad bots

CSF includes several settings that pull their weight on hosting servers. They matter even more when sites are not behind a CDN.

Port scan tracking (PS). Flags clients that hit many ports in a short window.
```
PS_INTERVAL = "300"
PS_LIMIT = "20"
PS_PERMANENT = "0"
```

SYN flood protection. Useful during noisy traffic spikes.

SYNFLOOD = "1"
SYNFLOOD_RATE = "75/s"
SYNFLOOD_BURST = "150"

Connection tracking for common services. Tune based on server size and real traffic.

Start conservative, then adjust:
```
CONNLIMIT = "80;20,443;40"
```
Meaning: per-IP connection limits for 80 and 443. If you host APIs, long-polling, or busy WooCommerce sites, you may need to raise these gradually.

If WordPress login brute force is your main pain point, rate limiting at the web server is often cleaner than banning an IP for every service. See this Nginx rate limiting tutorial and use it alongside CSF.

Make sure AutoSSL and Let’s Encrypt validations still work

AutoSSL failures often get blamed on the CA. In practice, firewall rules and DNS cause most repeat issues.

Checklist:

Inbound 80 and 443 must be open to your web server for HTTP-based validation.
Outbound 80/443 must be allowed so the server can reach CA endpoints.
DNS must resolve correctly for the hostname and the domain being issued.
Don’t block common CA IPs by accident (country blocks can do this).

To test from the server:

curl -I http://yourdomain.example/.well-known/acme-challenge/test
curl -I https://yourdomain.example/

If AutoSSL still fails after firewall changes, follow a focused path in this AutoSSL troubleshooting tutorial.

FTP on cPanel: configure passive ports (or turn FTP off)

FTP still shows up in reseller workflows. It’s also fragile behind NAT and strict firewalls.

If you can, prefer SFTP. If you must support FTP, configure it intentionally and keep the port range tight.

Set a passive port range in WHM. Go to WHM > Service Configuration > FTP Server Configuration. For Pure-FTPd, set a small range like 30000-31000.

Open that range in CSF. Edit /etc/csf/csf.conf:

TCP_IN = "... ,21,30000:31000"
TCP_OUT = "..."

Reload:

csf -r

Verify with a real client. Use FileZilla in passive mode and confirm directory listing and uploads work.

If you don’t need FTP, disable it in WHM and close port 21 plus the passive range. Fewer exposed services means fewer surprises later.

DNS on the same server: confirm UDP/53 and TCP/53 behavior

If your WHM server is authoritative DNS (PowerDNS or BIND), allow inbound UDP/53 and TCP/53. UDP handles most queries.

TCP is required for larger responses and zone transfers (if enabled).

Update ports:

TCP_IN = "...,53"
UDP_IN = "53"

Quick external test from a workstation:

dig @YOUR_SERVER_IP example.com A +short
dig @YOUR_SERVER_IP example.com TXT +short

If you use separate DNS (often the better choice for resilience), keep DNS inbound closed here and point domains to your DNS service. Don’t improvise DNS design during a migration window.

Disable test mode and lock it in

After you’ve verified SSH, WHM, web, and mail flows, turn off testing and restart services. This is when CSF becomes “real.”

Disable testing mode.

sed -i 's/^TESTING = "1"/TESTING = "0"/' /etc/csf/csf.conf

Reload CSF and LFD.
```
csf -r
systemctl restart lfd
```
Confirm it survives reboot.
```
reboot
```
After reboot, verify:
```
csf -l
systemctl status lfd
```

Operational workflow: how to handle false positives without weakening security

On hosting servers, you need a repeatable way to handle “mail won’t connect” or “WHM login fails.” Don’t bounce between random settings.

Use the same short loop every time.

Check if the IP is blocked.
```
csf -g 203.0.113.50
```
If it’s blocked, confirm why. Start with:
```
tail -n 80 /var/log/lfd.log
```

Unblock the IP (if justified).

csf -dr 203.0.113.50
csf -tr 203.0.113.50

Prevent repeats. If the customer is legitimate but their device keeps failing, temporarily allow their IP via csf.allow.

Add an expiry reminder in your ticket notes so it doesn’t become permanent by accident.

Also consider enabling 2FA in cPanel/WHM for admins and resellers. It reduces “valid password guessed” incidents that a firewall can’t stop. For the exact clicks and checks, use this cPanel 2FA setup guide.

Practical hardening checklist for a hosting-ready CSF/LFD configuration

Use this as your last pass before you call the server production-ready.

Access: Your admin IP is in /etc/csf/csf.allow; a second admin path exists (console or alternate IP).
Ports: Only required ports are open; FTP passive range is configured if FTP is enabled.
Mail: SMTP submission (587) works for clients; IMAP/POP works externally; outbound delivery isn’t blocked.
AutoSSL: HTTP/HTTPS reachable from the internet; outbound 80/443 allowed.
LFD: Enabled for SSH/cPanel/mail; permanent bans used only for admin surfaces.
Logging: You can explain a block by reading /var/log/lfd.log, not by guessing.

Where this fits commercially: VPS vs dedicated vs managed

On a small VPS, CSF/LFD gives you strong protection with little overhead. As you add accounts and mailboxes, predictability matters more.

That predictability improves both performance and support time.

For full root control (recommended for WHM), start with a HostMyCode VPS. If you’d rather not handle security updates, firewall tuning, and service restarts yourself, managed VPS hosting can be the simpler business decision.

If you’re building a WHM server for clients or internal projects, run it on infrastructure sized for hosting workloads. HostMyCode offers predictable performance on HostMyCode VPS, and you can hand off the day-to-day admin work with managed VPS hosting if you want a tighter security baseline from day one.

FAQ

Will CSF break cPanel AutoSSL or Let’s Encrypt renewals?

Not if you keep inbound 80/443 open and allow outbound 80/443. Most “firewall-related” failures come from closing port 80 or blocking outbound HTTPS.

Should I open port 2083/2087 to the world?

Only if you have to. A safer pattern is to allowlist your admin IPs in /etc/csf/csf.allow and keep the ports open but practically unreachable to everyone else.

Do I need to open DNS (53) on my WHM server?

Only if the server is authoritative DNS for your domains. If you use external DNS, keep inbound 53 closed and allow outbound 53 for resolver lookups.

What’s the quickest way to check whether CSF blocked a customer?

Run csf -g <IP> and then inspect /var/log/lfd.log to see the trigger (SMTP auth failures, IMAP logins, cPanel attempts, and so on).

Is CSF enough, or do I still need application-level protections?

Use both. CSF reduces attack surface at the network layer. For WordPress logins, add web-server rate limits and strong credentials. For admin access, enforce SSH keys and 2FA.

Summary: a hosting-safe firewall you can operate day to day

CSF + LFD works well in cPanel environments because it matches typical hosting traffic. Expect lots of mail logins, lots of HTTP requests, and a few critical admin services you can restrict by IP.

Install it, keep testing mode on while you validate ports, then switch it off. Use logs to explain blocks instead of guessing.

If you’re rolling this out for customers and expect real traffic, run WHM on a dedicated server or a properly sized HostMyCode VPS. Securing a server is simpler when it isn’t pinned at the edge of CPU and memory.