How to Secure a cPanel Server: Complete Server Security Hardening Guide

A fresh cPanel server is not a secure server. cPanel ships with sensible software but leaves the locking-down to you, because it cannot know whether you will use FTP, whether your customers need shell access, or which IP addresses should ever reach WHM. This is the hardening sequence we apply to every server we install for customers and to our own shared and reseller machines, in the order that matters, with the settings, the commands and the reason behind each one.

Who this is for: root administrators of a WHM/cPanel VPS or dedicated server. If you are on shared or reseller hosting, your host does this layer; the account-level items (strong passwords, 2FA, keeping WordPress updated) still apply to you.

What's in this guide

• What are you actually defending a cPanel server against?
• The order to do it in
• 1. SSH hardening
• 2. Firewall: CSF/LFD after the 2025 ConfigServer shutdown
• 3. cPHulk, two-factor and WHM access control
• 4. WHM Security Advisor and the settings that matter
• 5. PHP and web server hardening
• 6. ModSecurity: a web application firewall
• 7. Account isolation with CloudLinux CageFS
• 8. Imunify360: what it adds and how it coexists with CSF
• 9. Mail: stop your server becoming a spam source
• 10. Updates and kernel patching
• 11. Backups that survive a compromise
• 12. Logs, alerts and monitoring
• Verification checklist
• FAQ

What are you actually defending a cPanel server against?

Almost every compromised cPanel server we have cleaned up fell to one of five things. Knowing which is which tells you which layer stops it.

Threat	How it looks	Layer that stops it
Brute-force logins	Thousands of SSH, WHM, cPanel, FTP and mail login attempts per day from botnets	SSH keys, CSF/LFD, cPHulk, 2FA
Web application exploits	An outdated WordPress plugin lets an attacker upload a PHP shell	ModSecurity or Imunify360, PHP hardening, malware scanning, updates inside the account
Cross-account movement	One hacked account reads another account's wp-config.php or the server's configuration	CageFS, jailed shell, PHP-FPM per user, symlink protection
Outbound spam	A compromised contact form sends 50,000 emails; the IP lands on blocklists	Hourly mail limits, "nobody" restriction, SMTP restrictions, SPF/DKIM/DMARC
Unpatched server software	A known kernel, OpenSSL, Exim or cPanel vulnerability exploited weeks after the fix shipped	Automatic cPanel and OS updates, KernelCare

Notice what is not on the list: exotic zero-day attacks. They exist, but they are not what takes down hosting servers. The boring layers below stop the boring attacks, which are nearly all of them.

The order to do it in

Do these in sequence on a fresh server, before the first customer account exists. On a server that already hosts sites, do them in the same order but take a snapshot or a full backup first, and keep a second SSH session open while you change anything that could lock you out. The cPanel server setup guide covers where in the build these steps sit.

1. SSH hardening

SSH is the most attacked service on any public server, and it is also the one where a mistake locks you out. So the order inside this step matters: add the key, prove it works, then remove the password path.

# On your laptop: generate a modern key (skip if you have one)
ssh-keygen -t ed25519 -C "you@yourbrand.com"

# On the server: install the public key
mkdir -p /root/.ssh && chmod 700 /root/.ssh
echo "ssh-ed25519 AAAA...your-public-key..." >> /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

Open a second terminal and confirm ssh root@your-server logs in without asking for a password. Only then edit /etc/ssh/sshd_config:

sed -i 's/^#\?PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#\?PermitRootLogin .*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sed -i 's/^#\?MaxAuthTries .*/MaxAuthTries 3/' /etc/ssh/sshd_config
sed -i 's/^#\?X11Forwarding .*/X11Forwarding no/' /etc/ssh/sshd_config
sshd -t && systemctl restart sshd

PermitRootLogin prohibit-password keeps key-based root login working while refusing root passwords, which is the practical setting on a cPanel server where WHM's own tools expect to run as root. If your policy requires no direct root login at all, create a user in the wheel group, confirm sudo -i works from it, and set PermitRootLogin no.

Should you change the SSH port? It does not make the server more secure against a targeted attacker, but it removes about 95% of the automated noise from your logs and from LFD's inbox. If you change it, change it in three places in this order: the CSF TCP_IN list, sshd_config (Port 2222), then restart sshd, and test from a second session before closing the first. WHM's Security Advisor will stop warning about port 22 once it sees the change.

2. Firewall: CSF/LFD after the 2025 ConfigServer shutdown

CSF is still the standard firewall for cPanel servers in 2026, but where you get it from has changed. ConfigServer (Way to the Web Ltd), which wrote and sold support for CSF for 20 years, closed on 31 August 2025 and released version 15 under the GPLv3. The old download server went dark, which is why servers still pointing at it started logging update errors. cPanel then published and now maintains a public fork on GitHub (github.com/cpanel/cpanel-csf), packaged for cPanel & WHM systems, focused on security and stability fixes rather than new features, and existing installs with auto-updates enabled were moved to cPanel's update mirrors in early 2026.

What this means in practice: install CSF from cPanel's maintained package, not from a tarball someone kept from 2024, and check that an existing server's update source no longer points at download.configserver.com. If csf -v reports it cannot check for updates, the server is on the dead source and needs to be repointed; cPanel's announcement documents the one-line fix for cPanel servers.

Once installed, the whole firewall lives in /etc/csf/csf.conf. These are the settings we change on every server:

Setting	Value	Why
TESTING	0	With 1, the rules flush every 5 minutes and the firewall is decorative
TCP_IN	22 (or your port),25,53,80,110,143,443,465,587,993,995,2082,2083,2086,2087,2095,2096	Everything a cPanel server needs and nothing else; drop 21 unless you run FTP, drop 110/143 if only IMAPS/POP3S
TCP_OUT	20,21,22,25,53,80,110,113,443,465,587,993,995,2087	Outbound control stops a hacked account from opening reverse shells on random ports
UDP_IN / UDP_OUT	53 in; 20,21,53,113,123 out	DNS and NTP only
LF_SSHD / LF_CPANEL / LF_FTPD / LF_SMTPAUTH / LF_POP3D / LF_IMAPD	5 failures, permanent block	LFD reads the logs and blocks the source IP at the firewall
LF_TRIGGER_PERM	1 (or 3600 for a 1-hour block)	Temporary blocks are kinder to customers on shared office IPs
CT_LIMIT	150 to 300	Blocks IPs with an abnormal number of open connections (small floods)
SYNFLOOD	1, rate 100/s, burst 150	Cheap protection against SYN floods; real DDoS needs your provider
PORTFLOOD	22;tcp;5;300,80;tcp;60;5,443;tcp;60;5	Rate-limits new connections per port per IP
RESTRICT_SYSLOG	3	Stops users from spoofing log lines that LFD acts on
LF_ALERT_TO / LF_ALERT_FROM	A mailbox not on this server	Alerts about the server must not depend on the server

Before you enable it, add your own IP so a typo cannot lock you out, then restart and check the state:

csf -a YOUR.HOME.OR.OFFICE.IP "admin"
csf -r
csf -l | head -40
tail -f /var/log/lfd.log

Useful day-to-day CSF commands (block, unblock, search a blocked IP) are in our Linux commands for cPanel servers list.

3. cPHulk, two-factor authentication and WHM access control

LFD blocks at the network layer; cPHulk (WHM, Security Center, cPHulk Brute Force Protection) blocks at the application layer and understands cPanel's own login formats across WHM, cPanel, webmail, FTP, SSH and mail. Enable it, add your IP to the whitelist, and set the thresholds so a customer mistyping a password 3 times is not locked out for a day: 10 failures per IP in 15 minutes for a 1-hour block is a practical starting point; tighten it on servers with no customers.

Two-factor authentication (Security Center, Two-Factor Authentication) should be mandatory for root and every reseller. A stolen root password with 2FA on is an inconvenience; without it, it is the end of the server.

Host Access Control (Security Center) restricts which IPs can reach WHM (whostmgrd), cPanel (cpaneld) and SSH at the daemon level. If your team works from fixed IPs, allow those and deny the rest for WHM and SSH; leave cPanel and webmail open because customers connect from everywhere. It is a second lock behind CSF, and it protects you on the day someone accidentally opens the firewall.

4. WHM Security Advisor and the settings that matter

Security Advisor (Security Center) is cPanel's own audit of the server, and the fastest way to see what is still wrong. Work through every red and yellow item. On a fresh install the list usually contains:

• Compiler access (Security Center, Compiler Access): disable for unprivileged users. Exploit kits compile helpers on the target; take away the compiler.
• Apache symlink protection: enable the EasyApache 4 symlink race-condition protection, or rely on CloudLinux's kernel-level version if installed. This stops one account reading another's files through symlinks.
• Shell Fork Bomb Protection (Security Center): on. Limits resources per shell user.
• Password Strength Configuration (Security Center): minimum 65 for all services. Weak customer passwords become your problem.
• Jailed shell (Manage Shell Access): jailed by default for any account that needs shell; most need none.
• Cookie IP validation (Tweak Settings): strict. A stolen session cookie cannot be replayed from another IP.
• Referrer safety check and Require SSL for cPanel/WHM/Webmail (Tweak Settings): on. Plaintext logins on 2082 and 2086 should not exist.
• Service Manager (Service Configuration): disable everything you do not use. Typical candidates: Mailman, cpdavd (WebDisk), ProFTPD if no one uses FTP, cups, rpcbind.
• Update Preferences: RELEASE tier, automatic, daily. Security fixes should not wait for a human.

Then run /scripts/upcp --force once so the server is current before you go further, and re-check Security Advisor. The goal is an empty list, or one where every remaining item is a deliberate decision you can explain.

5. PHP and web server hardening

PHP is how attackers get in; the web server is what they use once they are in. Both have settings that reduce what a compromised site can do.

Run PHP-FPM per account (MultiPHP Manager). Each account's PHP runs as that account's user in its own pool, so a shell uploaded through one site runs with that user's permissions only. It is also faster than suPHP. Do not run mod_php (DSO) on a multi-tenant server; every site's PHP then runs as the Apache user with access to every other site's files.

Disable dangerous functions (MultiPHP INI Editor, per PHP version). The list we use on hosting servers:

disable_functions = exec,passthru,shell_exec,system,proc_open,popen,show_source,pcntl_exec,dl

This breaks a small number of legitimate scripts (some backup plugins, some image tools). When a customer needs one function back, add it for their account's own php.ini rather than reopening it server-wide.

Also in the INI editor: expose_php = Off (do not advertise the version), allow_url_include = Off, display_errors = Off on production, and a memory_limit and max_execution_time that stop one script from eating the box. The performance side of these settings is in the cPanel optimization guide.

Web server: in EasyApache 4 keep only the modules you need, set ServerTokens Prod and ServerSignature Off in the Apache pre-main include, disable directory indexing by default, and enable HTTP/2. On LiteSpeed the equivalents live in the WebAdmin console; LiteSpeed reads .htaccess rules, so per-site hardening rules written for Apache keep working.

TLS everywhere: AutoSSL (SSL/TLS, Manage AutoSSL) issues and renews free certificates for every domain and for the hostname; leave the hostname on the cPanel provider so WHM never shows a certificate warning again. Force HTTPS redirects per domain (Domains, Force HTTPS Redirect), and in the Apache or LiteSpeed configuration add Strict-Transport-Security so browsers refuse to downgrade.

6. ModSecurity: a web application firewall in front of PHP

A WAF inspects each request before it reaches the application and blocks the patterns that exploits use: SQL injection, file inclusion, PHP code in upload fields, known bad user agents. On cPanel it is ModSecurity (Security Center, ModSecurity Configuration and Vendors). Install the OWASP Core Rule Set vendor from WHM, enable it, and watch /usr/local/apache/logs/modsec_audit.log for a week. Some rules will trip on legitimate WordPress admin actions; disable those specific rule IDs per domain (Security Center, ModSecurity Tools) rather than turning the engine off. Imunify360 ships its own, better-maintained rule set and replaces this step when installed; see section 8.

7. Account isolation with CloudLinux CageFS

On a server that hosts other people's sites, isolation is the layer that turns "one site got hacked" into a Tuesday instead of a rebuild. Standard cPanel gives you separate Linux users, jailed shells and PHP-FPM pools, which is decent. CloudLinux adds two things standard Linux cannot:

• CageFS gives each account a virtualised filesystem in which it can see only its own files, its own processes and a curated set of system binaries. A PHP shell inside a caged account cannot list /home, cannot read /etc/passwd usefully, and cannot see which other sites are on the server. Enable it for all users in WHM's CageFS screen and re-run it whenever you add software users need.
• LVE limits cap CPU, memory, IO, IOPS, entry processes and process count per account. A runaway or malicious script in one account hits its ceiling instead of the server's. This is a security control as much as a performance one, because most "the whole server is down" incidents start as one account being abused.

Add the PHP Selector so customers run a hardened PHP version you control, and HardenedPHP if you must keep an old PHP version alive for a legacy application. On a single-tenant server where you own every site, CloudLinux is optional; on a reseller server it is the difference between a hosting business and a liability.

8. Imunify360: what it adds and how it coexists with CSF

Imunify360 is a licensed security suite that combines a firewall fed by a shared threat-intelligence network, a WAF with its own rule set, a malware scanner with automatic cleanup, and proactive defence that stops known malicious PHP behaviour at runtime. It is the component that catches the uploaded web shell CSF cannot see, because CSF looks at connections while Imunify360 looks at files and PHP execution.

Do you still need CSF with Imunify360? Running both is supported; CloudLinux's own documentation says to use either the Imunify360 firewall alone or Imunify360 together with CSF. When Imunify360 detects CSF on the server it disables its own overlapping features (blocked-ports management, DoS protection and the SMTP traffic manager) so the two do not double-handle the same traffic, it will not block IPs that are on CSF's allow or ignore lists, and if you enable the integration setting it can use LFD as an event source and manage the resulting blocks itself. We keep CSF on multi-tenant servers for its port control and per-service login limits, and let Imunify360 handle malware, WAF and reputation blocking. On a small single-purpose VPS, CSF plus ModSecurity plus a weekly ClamAV or maldet scan is an honest, free alternative.

Whichever you choose, schedule a full malware scan weekly, enable automatic cleanup for known signatures, and send Imunify360's reports to the same off-server mailbox as your LFD alerts.

9. Mail: stop your server becoming a spam source

Outbound spam from a compromised account is the most common way a hosting server ends up on blocklists, and once the IP is listed every customer's legitimate mail bounces. These settings contain the damage:

• Max hourly emails per domain (Tweak Settings, Mail): 200 to 500. A hacked form can send a few hundred messages, not fifty thousand.
• Prevent "nobody" from sending mail (Tweak Settings): on. PHP mail then goes out as the account user, so you can trace it.
• SMTP Restrictions (Security Center): on. Only Exim, root and mailman may connect outward on port 25, which kills PHP scripts that talk to remote SMTP servers directly.
• Exim configuration (Service Configuration, Exim Configuration Manager): enable "Scan outgoing messages for spam and reject based on the SpamAssassin score", require RDNS for incoming, and reject mail from domains with invalid SPF where your customers can tolerate it.
• SPF, DKIM and DMARC on every domain (Email Deliverability for the first two; a DMARC TXT record in DNS for the third). Receivers use these to separate your customers' real mail from forged mail using their domains.
• Reverse DNS for the server IP must match the hostname, and the hostname must have an A record. Without this pair, Gmail treats the server as suspicious regardless of everything above.

Check the queue daily until you trust the server: exim -bpc should be a small number. A queue of thousands means an account is compromised; exim -bp | exiqsumm tells you which sender.

10. Updates and kernel patching

Most compromises exploit a vulnerability that already had a patch available. The defence is boring: let updates run automatically and do not let the kernel age.

• cPanel: Update Preferences on the RELEASE tier with automatic updates. /scripts/upcp runs nightly.
• Operating system: dnf-automatic on AlmaLinux, Rocky and CloudLinux with apply_updates = yes; unattended-upgrades on Ubuntu. Security updates apply themselves; you read the log rather than run the command.
• Kernel: a new kernel needs a reboot to take effect, and hosting servers hate reboots. KernelCare patches the running kernel in memory without a restart, which is why it is standard on shared servers. Without it, schedule a monthly reboot window and honour it.
• Third-party software: LiteSpeed, CloudLinux, Imunify360, Softaculous and JetBackup each have their own auto-update switch. Turn every one of them on.

11. Backups that survive a compromise

A backup is a security control, not just an operational one. Ransomware, a malicious ex-employee, and your own mistaken rm -rf are all solved by the same thing: a copy of the data that the server itself cannot reach and destroy.

• 3-2-1: at least 3 copies, on 2 kinds of storage, 1 of them off the server. The built-in cPanel backup (Backup Configuration) to a remote SFTP, S3-compatible or Backblaze B2 destination satisfies this. A local-only backup fails the moment the disk or the server does.
• Retention: daily for 7 to 14 days, weekly for a month, monthly for a quarter. A compromise is often discovered weeks after it happened; you need a copy from before it.
• Restore drill: restore one account from the remote copy to a test account every month. A backup you have never restored is a hope, not a plan.
• JetBackup if customers should restore their own files, databases and mailboxes without opening tickets, and for incremental backups that do not hammer the disk every night.

12. Logs, alerts and monitoring

Everything above is prevention. Detection is knowing, within minutes, when prevention failed. On a cPanel server the signals are:

Signal	Where	What to do with it
Login failures and blocks	/var/log/lfd.log, /var/log/secure, cPHulk history in WHM	LFD emails you per block; a spike means a campaign is running against you
Successful root and WHM logins	/usr/local/cpanel/logs/access_log, /var/log/secure; LFD's LF_SSH_EMAIL_ALERT	Every root login should be one you recognise; alert on all of them
Web attacks	modsec_audit.log, Imunify360 incidents, per-domain access logs	Repeated hits on one site usually mean an outdated plugin there
Mail queue size	exim -bpc; LFD's LF_QUEUE_ALERT	Over a few hundred queued messages, find the sending account now
Process and file changes	LFD process tracking (PT_*), Imunify360 scans, WHM's Process Manager	Unknown processes under a customer user are a compromise until proven otherwise
Uptime and load	External uptime monitor; WHM Server Status; LFD's LF_*LOAD alerts	Downtime and sudden load are how many attacks first show themselves

Send every alert to a mailbox and a phone that do not live on this server. What to monitor beyond security, and how to turn these signals into a weekly routine, is the subject of the cPanel server management and monitoring guide.

Verification checklist

Run this after the initial hardening and after every change window. Every check is from outside the server or from a second session, so you are testing what an attacker sees, not what WHM believes.

• nmap -Pn YOUR.IP from your laptop shows exactly the CSF TCP_IN list.
• ssh root@YOUR.IP with the key removed is refused; with the key, it works. sshd -T | grep -Ei 'passwordauth|permitroot' confirms both settings.
• 6 wrong SSH passwords from a spare IP produce an LFD block and an email.
• WHM over http on port 2086 redirects to https; the hostname certificate is valid.
• Security Advisor shows nothing red that you have not consciously accepted.
• A phpinfo page on a test account shows Server API FPM/FastCGI, disable_functions populated, expose_php Off.
• A request like https://testsite.com/?id=1%27%20OR%201=1 returns a 403 from ModSecurity or Imunify360.
• On CloudLinux: cagefsctl --list-enabled includes every account; lveinfo shows limits applied.
• A test message to Gmail passes SPF, DKIM and DMARC (open the message headers) and lands in the inbox.
• dnf history or /var/log/dnf.log shows automatic updates ran in the last 24 hours; uname -r matches the newest installed kernel, or KernelCare reports patched.
• The most recent remote backup exists and one account restores from it.

This is the checklist we hand over with every $50 cPanel server installation, completed, so the customer can re-run it whenever they change something.

FAQ

Is CSF still safe to use now that ConfigServer has closed?

Yes, provided it comes from a maintained source. cPanel publishes and maintains a fork for cPanel servers and delivers updates through its own mirrors. What is unsafe is a CSF install that still points at the old ConfigServer download server: it will never receive another fix. Check with csf -v and repoint or reinstall from cPanel's package.

Do I need Imunify360 if I already have CSF?

They protect different layers. CSF controls connections and reacts to login failures; Imunify360 finds and removes malware in files, blocks web attacks with a maintained rule set, and shares reputation data across thousands of servers. On a server hosting other people's sites, Imunify360 pays for itself the first time it cleans a web shell before the customer notices. On a single personal VPS, CSF plus ModSecurity plus updates is acceptable.

Should I change the SSH port?

It is optional. It stops almost all automated noise but not a targeted attacker, who will find the port in seconds. Keys, no password login and LFD are what actually protect SSH. If you do change it, update CSF first, then sshd, and test from a second session before closing the first.

How do I know if my cPanel server has already been hacked?

Look for root or WHM logins you do not recognise in /var/log/secure and cPanel's access log, unknown processes in WHM's Process Manager, a mail queue in the thousands, new cron jobs or files in /tmp and /dev/shm, and outbound connections in ss -tnp to IPs you cannot explain. Run a full Imunify360 or maldet scan. If root was compromised, rebuild the server from a clean install and restore accounts from a backup taken before the intrusion; you cannot trust a rooted system.

Can I do all of this on shared or reseller hosting?

No, and you should not need to; the server-level items are the host's responsibility. What you control is your account: strong unique passwords, two-factor authentication on cPanel, keeping applications and plugins updated, removing unused installs, and not storing backups inside public_html. If your host cannot tell you which of the items above they have done, that is your answer about the host.

How often should I re-audit a cPanel server?

Security Advisor after every cPanel major version (roughly every 2 to 3 months), the verification checklist above after any change to the firewall, SSH or PHP configuration, and a full pass, including a restore drill, quarterly. Monitoring covers the gaps in between; that is the point of it.