Back to tutorials
Tutorial

cPanel CSF Firewall Setup Tutorial (2026): Configure WHM Security Without Locking Yourself Out

cPanel CSF firewall setup tutorial for 2026: install, whitelist, tune rules, and protect WHM/cPanel without outages.

By Anurag Singh
Updated on Jul 14, 2026
Category: Tutorial
Share article
cPanel CSF Firewall Setup Tutorial (2026): Configure WHM Security Without Locking Yourself Out

Your cPanel server probably already has a firewall running. It might be firewalld, raw iptables/nftables rules, or whatever your distro enabled by default. The usual problem isn’t “no firewall.” It’s consistency.

On a hosting server, you need predictable rules, readable logs, and a fast way back in when a change goes sideways. This cPanel CSF firewall setup tutorial shows how to install, configure, and validate CSF/LFD on a WHM server in 2026 without locking yourself out.

CSF (ConfigServer Security & Firewall) still fits cPanel well. It understands common hosting ports and pairs cleanly with LFD (login failure detection). It also keeps key settings in plain config files.

The goal is a baseline you can maintain. You should not have to second-guess every reload.

What you’ll build (and what you should back up first)

Goal: a CSF configuration that:

  • Allows WHM/cPanel/Webmail and DNS without surprises
  • Protects SSH and mail ports with sensible rate controls
  • Logs blocks you can act on (not noise)
  • Supports safe testing and a rollback path

If this is a production box, take a snapshot or confirmed restore point before you touch firewall rules.

If you don’t have that, fix it first.

HostMyCode customers typically do this on a managed VPS hosting plan. You can request a pre-change snapshot or schedule a change window.

For a practical restore workflow, keep this handy: VPS backup restore tutorial.

Prerequisites (don’t skip these on cPanel)

  • Root SSH access (or sudo with full root shell)
  • WHM/cPanel installed and working
  • Static IP or at least one stable admin IP/CIDR you control
  • Console access or out-of-band access (recommended) for recovery

Tip: If admins work from different networks, define a “break glass” path now.

Use a jump host, a VPN egress IP, or a dedicated office CIDR.

Lockouts often happen because the only trusted IP was someone’s home connection.

Then it changed.

If you want a clean ops setup, put a controlled entry point in place first: SSH jump host setup guide.

Step 1: Confirm your current firewall state and cPanel ports

Before you install CSF, confirm what already manages firewall rules:

# AlmaLinux/Rocky/RHEL-family
systemctl is-active firewalld || true

# Ubuntu/Debian
systemctl is-active ufw || true

# General: see if nftables is being used
command -v nft && nft list ruleset | head

# Check listening ports (cPanel/WHM/DNS/mail)
ss -lntup | awk 'NR==1 || /:22 |:53 |:80 |:443 |:2083 |:2087 |:2096 |:110 |:143 |:465 |:587 |:993 |:995 /'

Common cPanel-related ports you’ll care about:

  • SSH: 22 (or your custom port)
  • HTTP/HTTPS: 80/443
  • WHM: 2087 (TLS)
  • cPanel: 2083 (TLS)
  • Webmail: 2096 (TLS)
  • DNS: 53 TCP/UDP
  • Mail: 25, 465, 587, 110, 143, 993, 995 (depending on your stack)
  • FTP (if you still use it): 21 + passive range

Write down what you actually use. Don’t open ports “just in case.”

On hosting boxes, that invites constant scanning and avoidable abuse.

Step 2: Install CSF/LFD on a cPanel server

On cPanel servers, CSF is usually installed from the vendor tarball. Run:

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

Then verify required Perl modules (CSF includes a check script):

perl /usr/local/csf/bin/csftest.pl

If it reports missing modules, install them via your OS package manager. Then rerun the test.

On modern cPanel builds, most dependencies are already present.

Finally, confirm the service scripts exist:

csf -v
which csf && which lfd

Step 3: Disable conflicting firewall managers (carefully)

CSF manages iptables/nft under the hood. If another firewall tool is also active, you’ll eventually see “random” drops and hard-to-explain behavior.

What you disable depends on the OS:

  • RHEL-family: If firewalld is active and you’re standardizing on CSF, disable firewalld after CSF is installed (but keep CSF in testing mode).
  • Ubuntu: If UFW is active, disable it before enabling CSF (again, while CSF is still in testing mode).
# Example: disable firewalld (RHEL-family)
systemctl disable --now firewalld

# Example: disable UFW (Ubuntu)
ufw disable

Don’t reload CSF yet.

First, enable testing mode and whitelist your admin IP.

Step 4: Set CSF to testing mode and whitelist your IP

CSF’s config lives at:

  • /etc/csf/csf.conf
  • /etc/csf/csf.allow (whitelist)
  • /etc/csf/csf.deny (manual blocks)

Open /etc/csf/csf.conf and set:

TESTING = "1"

Now whitelist your current admin IP (replace with your public IP):

echo "203.0.113.10 # admin workstation" >> /etc/csf/csf.allow

If you have a jump host, whitelist its IP or CIDR instead of a laptop IP.

For teams, a small office CIDR or VPN egress IP keeps the allowlist from drifting every week.

Load CSF rules:

csf -r

In testing mode, CSF typically flushes itself after a short window (commonly 5 minutes). This is designed to prevent lockouts.

Use that window to validate access from a second SSH session.

Step 5: Configure allowed inbound/outbound ports for hosting

In /etc/csf/csf.conf, the settings that drive most behavior are:

  • TCP_IN / UDP_IN (what the world can reach)
  • TCP_OUT / UDP_OUT (what your server can initiate)

A reasonable baseline for a typical cPanel web + mail server might include:

TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995,2083,2087,2096"
UDP_IN = "53"

TCP_OUT = "20,21,22,25,53,80,110,113,443,587,993,995"
UDP_OUT = "53,123"

Notes:

  • Port 113 is IDENT. Some mail systems still probe it; allowing outbound can reduce mail delays.
  • NTP 123/UDP keeps time sane (TLS and auth depend on it).
  • If you use passive FTP, set a passive port range in WHM and add it to TCP_IN.

After edits, reload:

csf -r

Step 6: Turn on LFD with sane thresholds (stop brute-force noise)

LFD is where CSF moves from “ports and rules” into something operational. It tails logs and blocks IPs that behave like attackers.

The main tradeoff is false positives.

This matters on hosting servers, especially with customers behind shared NAT.

Open /etc/csf/csf.conf and review these practical settings:

  • LF_TRIGGER: how many login failures before a temp block
  • LF_SSHD, LF_CPANEL, LF_WEBMIN (if applicable): enable log monitoring per service
  • LF_TEMPBLOCK: temp block duration
  • LF_PERMBLOCK: permanent block toggle

Example values for a hosting server with many legitimate logins:

LF_TRIGGER = "10"
LF_TEMPBLOCK = "3600"
LF_PERMBLOCK = "0"
LF_SSHD = "1"
LF_CPANEL = "1"

This catches obvious brute-force attempts without turning every bad-password day into a permanent ban.

On reseller-heavy servers, permanent blocks often become support tickets.

Restart LFD after changes:

systemctl restart lfd || service lfd restart

Step 7: Lock down WHM/cPanel access without breaking customers

CSF can restrict access to specific ports by IP. This works well for admin panels.

It can also break customer access if you overdo it.

Two approaches that hold up in real operations:

  • Admin-only restriction: Restrict WHM (2087) to admin IPs, leave cPanel (2083) open to customers.
  • Geo/IP allowlisting: Allow cPanel only from countries or networks you serve (works best for internal business hosting, not public hosting).

If you want a structured approach with verification steps, use this related tutorial as a reference: cPanel IP whitelisting tutorial.

At minimum, treat WHM as an admin-only surface. A practical pattern is:

  • Keep port 2087 in TCP_IN.
  • Use CSF’s csf.allow to allow your admin IPs.
  • Use csf.deny to block broad ranges if needed.

You can also route WHM through SSH port forwarding instead of leaving it exposed.

It’s straightforward and reduces scanning noise.

See: SSH port forwarding tutorial.

Step 8: Enable connection tracking limits to reduce resource abuse

On shared hosting and reseller servers, abuse patterns are common. One IP might open hundreds of connections.

Bots probe endpoints. Broken scripts hammer PHP.

CSF provides basic connection tracking. In /etc/csf/csf.conf:

  • CT_LIMIT: max connections per IP
  • CT_PORTS: which ports to track

Example baseline (tune for your traffic):

CT_LIMIT = "200"
CT_PORTS = "80,443"

If you host APIs or high-traffic sites behind Cloudflare or another proxy, plan for shared egress IPs.

Add proxy IPs to /etc/csf/csf.ignore so you don’t block your own edge.

Step 9: Make email safer without blocking legitimate sending

Hosting servers get punished quickly for outbound spam. A firewall won’t fix compromised accounts.

But CSF/LFD can slow the blast radius and surface problems sooner in logs.

Three practical steps:

  1. Keep SMTP ports explicit: Only open what you use (25/465/587). If you route outbound mail via a smart host, you can often restrict outbound to 587 only.
  2. Watch for mail queue spikes: Pair CSF with alerting so you notice backlogs before reputation drops.
  3. Have a cleanup playbook: If you get flagged, you need to trace the sender fast.

Use these as your operational references:

Step 10: Turn off testing mode (only after a controlled verification)

Do this in a careful order:

  1. Open a second SSH session and keep it idle.
  2. Confirm you can reach WHM (2087) and cPanel (2083) from expected networks.
  3. Confirm DNS resolves externally and your sites load over 80/443.
  4. Confirm outbound connectivity: curl to a known HTTPS URL and dig to public resolvers.
# quick checks
curl -I https://example.com

dig +short A www.google.com @1.1.1.1

echo | openssl s_client -connect 127.0.0.1:2087 -servername $(hostname -f) 2>/dev/null | head

Now set:

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

Wait a few minutes and re-check connectivity from a network that is not whitelisted.

This is the quickest way to catch restrictions that would affect customers.

Step 11: Read CSF/LFD logs like an operator

Two files tell you most of what you need day-to-day:

  • /var/log/lfd.log (why an IP was blocked)
  • /var/log/messages or /var/log/syslog (system-level firewall events)
# show recent blocks and reasons
tail -n 80 /var/log/lfd.log

# list currently blocked IPs
csf -l

# unblock a specific IP
csf -dr 203.0.113.55

Repeated SSH blocks are usually background noise.

Customers getting blocked on cPanel is different.

If that happens, raise thresholds, ignore known networks, or both.

Step 12: A safe change checklist for future firewall edits

  • Keep two SSH sessions open before csf -r.
  • Whitelist a stable admin IP (or jump host) in csf.allow.
  • Make one change at a time (ports, then LFD, then connection tracking).
  • Reload and test: web, DNS, WHM, mail ports, outbound DNS/HTTPS.
  • Document why a port is open. If you can’t justify it, close it.

Troubleshooting quick hits (the real problems you’ll hit)

You reloaded CSF and SSH dropped

  • Use console/out-of-band access and set TESTING = "1" temporarily.
  • Confirm your SSH port is in TCP_IN.
  • Add your IP to /etc/csf/csf.allow, then csf -r.

DNS stopped resolving after enabling CSF

  • Confirm 53 is in TCP_IN and UDP_IN.
  • Confirm outbound UDP_OUT includes 53.
  • Check if CSF blocked your resolver IPs: csf -l.

WHM works from your office but not from home

  • Your home IP changed. Add the new IP to csf.allow or standardize on a jump host/VPN.
  • If you’re using SSH port forwarding, keep WHM closed to the public Internet and stop fighting IP churn.

Customers complain about intermittent “connection reset”

  • Connection tracking limits may be too low for real user traffic.
  • If you’re behind a CDN/WAF, add their IP ranges to csf.ignore.
  • Check LFD for false positives: grep -i "Temporary Block" /var/log/lfd.log | tail

Operational notes for VPS vs dedicated servers

On a VPS, you typically control the guest firewall only.

On a dedicated server, you control the whole stack and get cleaner isolation.

Either way, CSF fits cPanel well because it’s predictable and easy to audit later.

If you’re building a reseller platform or hosting multiple customer sites, don’t starve the box.

Spiky traffic plus LFD processing can punish under-provisioned VMs.

A HostMyCode VPS with enough RAM for cPanel + mail + caching reduces the “why is it slow” cycle.

Summary: a CSF baseline you can maintain

CSF works best when you treat it as ongoing configuration, not a one-time install.

Keep ports tight. Whitelist stable admin paths. Tune LFD for hosting reality.

Most firewall “mysteries” come from wrong assumptions about where admins and customers connect from.

If you’d rather run cPanel without babysitting firewall rules, HostMyCode’s managed VPS hosting is built for exactly this: secure defaults, help with controlled changes, and enough headroom for real hosting workloads.

If you’re setting up cPanel on a new server, start with a VPS that won’t choke once WHM, mail, and security tooling are all running. HostMyCode offers HostMyCode VPS plans that fit cPanel well, plus managed VPS hosting when you want hands-on help hardening and maintaining the stack.

FAQ

Does CSF replace UFW or firewalld on a cPanel server?

Yes, in practice you typically pick one. CSF manages iptables/nft rules for you. Running CSF alongside UFW or firewalld often causes conflicting rules and unpredictable blocks.

What’s the safest way to avoid locking yourself out?

Enable CSF in testing mode first, keep two SSH sessions open, and add a stable admin IP (or jump host IP) to /etc/csf/csf.allow before you reload rules.

Should I permanently block IPs with LFD?

On shared hosting, permanent blocks can become support pain because many users share NAT IPs. Start with temporary blocks, then move repeat offenders to permanent blocks only after you confirm they’re not legitimate customers.

Do I need to open every mail port?

No. Open only what your server actually uses. Most cPanel mail setups need 25, 465, 587, 110/995, and 143/993, plus DNS. If you relay outbound mail through a smart host, you may restrict outbound SMTP further.

Where do I see why an IP got blocked?

Check /var/log/lfd.log for the reason and triggering service, then use csf -l to confirm it’s currently blocked.