Setting Up CSF Firewall on a cPanel VPS (Step-by-Step)

If you've provisioned a cPanel VPS recently, you've probably noticed WHM nudges you toward installing CSF — ConfigServer Security & Firewall — instead of leaving raw iptables or UFW to manage things yourself. There's a good reason for that. CSF understands cPanel's port layout out of the box, ships with a brute-force login monitor called LFD, and gives you a WHM interface so you're not editing iptables rules blind over SSH at 2 a.m. This guide walks through installing it, configuring it safely, and the handful of settings that trip people up — including the one that locks admins out of their own server.

Why CSF instead of plain iptables or UFW

UFW is a fine general-purpose firewall for a plain Ubuntu or Debian box. But on a cPanel/WHM server, it doesn't know anything about the dozens of ports cPanel services actually use — Exim, Dovecot, FTP passive ranges, WHM itself on 2087, cPanel on 2083. You'd be hand-maintaining that list. CSF is built specifically for WHM environments: it auto-detects the standard cPanel port set, integrates with WHM's UI, and pairs with LFD (Login Failure Daemon), which watches auth logs across SSH, FTP, cPanel, and email and temporarily bans IPs that fail login too many times. It's effectively fail2ban and a firewall rolled into one, tuned for cPanel.

Installing CSF on your VPS

Log in over SSH as root and pull the installer directly from ConfigServer:

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

The installer checks for conflicting firewalls (iptables-persistent, ufw, firewalld) and will warn you if one is active. Disable those first — running two firewall managers on the same box is how you end up with rules fighting each other and nobody able to explain why a port is closed.

systemctl stop ufw
systemctl disable ufw

Once installed, you'll find CSF under WHM > Plugins > ConfigServer Security & Firewall. Everything from here can be done through that UI, though for bulk edits SSH is faster.

Step one: stay in testing mode

This is the single most important setting in the entire setup. Open /etc/csf/csf.conf (or the WHM “Firewall Configuration” screen) and confirm:

TESTING = "1"

With testing mode on, CSF automatically clears its own iptables rules every 5 minutes via a cron job. That safety net exists because a misconfigured firewall on a remote VPS with no console access is one of the fastest ways to lock yourself out permanently. Leave it on for at least a day while you confirm SSH, WHM, FTP, and mail all still work, then flip it to "0" and restart CSF.

Configuring ports correctly

CSF ships with sane defaults for a standard cPanel install, defined in TCP_IN, TCP_OUT, UDP_IN, and UDP_OUT. Check these match what you're actually running before going live:

If you changed the SSH port in /etc/ssh/sshd_config, update TCP_IN in csf.conf to match — CSF doesn't read sshd_config, so the two can drift out of sync silently. That's a common cause of "I can't SSH in anymore" tickets after a hardening pass.

Whitelisting and blocking IPs

Two files matter most day-to-day: /etc/csf/csf.allow and /etc/csf/csf.deny. You can edit them directly or use the CLI, which is faster once you're used to it:

# Permanently allow an IP (your office, a monitoring service)
csf -a 203.0.113.10 "Office static IP"

# Block an IP immediately
csf -d 198.51.100.25 "Repeated login abuse"

# Remove a block
csf -dr 198.51.100.25

# Temporarily allow an IP for 1 hour (useful while testing)
csf -ta 203.0.113.10 3600 "Temporary access"

Always whitelist your own admin IP (or your VPN exit IP) in csf.allow before you start tightening anything else. LFD doesn't care who you are — if your IP racks up enough failed logins during testing, it gets banned like anyone else's.

Tuning LFD brute-force protection

LFD's defaults are reasonable, but on a busy mail server with lots of legitimate password mistakes (think: an old phone still trying an outdated app password), the defaults can feel aggressive. The key settings live in csf.conf:

LF_TRIGGER = "0"
LF_SSHD = "5"
LF_FTPD = "10"
LF_POP3D = "10"
LF_IMAPD = "10"
LF_ALERT_TO = "you@yourdomain.com"

LF_SSHD = "5" means five failed SSH attempts within the tracking window trigger a temporary ban. Set LF_ALERT_TO to an address you actually check — not the domain you're protecting, since if that mail queue is the thing under attack, alerts about it won't reach you. After any config change, apply it with:

csf -r

The lockout scenario, and how to recover from it

Sooner or later almost everyone does this: sets TESTING = "0" too early, then a rule change blocks their own SSH session mid-edit. If that happens:

• If your VPS provider offers a browser-based console (VNC/serial console outside the network stack), use that to log in locally and run csf -f to flush all rules.
• If you have no console access, contact your hosting provider's support — at SkyServer we can flush CSF or restore SSH access from the hypervisor side without needing your locked-out session.
• Once back in, re-enable TESTING = "1" before making further changes, and test each change in a second SSH session before closing the first one.

Prevention checklist

• Keep TESTING = "1" until every service is confirmed working, then disable it.
• Whitelist your admin/VPN IP in csf.allow before touching anything else.
• Never close a working SSH session while testing a new rule — open a second one first.
• Match TCP_IN to your actual SSH port if you've changed it from 22.
• Review /var/log/lfd.log periodically to see what LFD has been blocking — it's a good early signal of scanning or credential-stuffing activity aimed at your server.
• Run csf -u occasionally to pull the latest CSF version; ConfigServer ships updates fairly often.

Frequently Asked Questions

Does CSF replace iptables, or run on top of it?

CSF is a front end that generates and manages iptables (or nftables on newer distros) rules for you. You shouldn't hand-edit iptables directly once CSF is managing the firewall — any manual rule you add outside CSF's config files gets wiped the next time CSF reloads.

Can I run CSF alongside a cloud provider's network firewall (like a security group)?

Yes, and it's a good idea. A network-level firewall from your provider blocks traffic before it reaches the VPS at all, while CSF handles OS-level rules and the LFD brute-force monitoring that a network firewall can't do. They're complementary, not redundant.

Why does LFD keep banning my own IP?

Usually a client somewhere — an old phone, a forgotten script, a cron job with stale credentials — is retrying a login with the wrong password from your network. Check /var/log/lfd.log to see which service triggered it, whitelist your IP in csf.allow, and track down the offending client separately.

I installed CSF and now my WHM login is timing out. What happened?

Almost always a port mismatch — CSF's TCP_IN list doesn't include 2087, or it does but a network-level firewall in front of the VPS is blocking it before CSF even sees the traffic. Check both layers, and confirm testing mode is on so a bad rule clears itself within five minutes.

Is CSF free, and does it need a license?

CSF itself is free and open source. ConfigServer sells commercial support and a separate product (cxs) for scanning, but the firewall and LFD components you're configuring here don't require a paid license to run.