A freshly installed cPanel server is not a secure server. Default configurations prioritize compatibility over security: the SSH port is wide open, firewall rules are permissive, plain-text panel ports are listening, and the WAF is either off or running a minimal ruleset. On one server that’s a manageable afternoon of cleanup. On a fleet of 20, 50, or 200 — where new servers are provisioned constantly and configurations drift — staying hardened stops being a task and becomes an operational discipline.
We wrote a free guide that turns that discipline into a checklist: 18 concrete steps, ordered by impact, from OS-level SSH configuration through firewall, WAF, panel hardening, email authentication, backups, and auditing. Every step is actionable, tested in production, and designed not to break client sites.
Download the guide — PDF, 29 pages, no signup →
Who the guide is for
It’s written for the people who actually run cPanel in production:
- Hosting providers signing off new servers and keeping a fleet hardened as it grows.
- Sysadmins and MSPs who inherited a box (or fifty) and need a defensible baseline, fast.
- Anyone who has ever locked themselves out of root trying to “just tighten SSH” and wants the order of operations done right.
If your job is to hand a client a server you can stand behind, this is for you.
What’s inside
The guide is a tour of every layer that needs attention before a cPanel box is production-ready:
- Keep cPanel updated — the STABLE tier and automatic updates, so the platform patches itself instead of drifting.
- SSH the right way — generate and test keys before restricting root, one key per operator, and the move that matters most: reducing or eliminating port 22 exposure entirely.
- Firewall and WAF — install and configure PXF, block known-bad networks, and replace a minimal ModSecurity setup with a real web application firewall.
- cPanel and WHM specifics — restrict WHM by IP, enforce 2FA, disable unused services, force HTTPS everywhere, and tune cPHulk brute-force protection.
- Email, backups, and auditing — enforce SPF, DKIM, and DMARC, set per-account sending limits, configure remote backups, and audit SSH access and critical changes on a schedule.
At the end you’ll find a copy-paste checklist to run against any server before signing it off, plus an appendix of real-world incidents — a compromised mailbox burning your IP reputation, a site throwing a 500, an exposure audit that finds an unauthenticated Redis open to the internet.
The opinion that shapes the guide
One idea runs through the whole thing: the most effective thing you can do for SSH isn’t to harden it — it’s to stop exposing it.
Closing port 22 to the public internet entirely removes a whole category of attack instead of mitigating it. Brute-force attempts, credential-stuffing, the daily noise of the internet scanning every box you own — all of it stops mattering when there’s nothing listening to reach. The guide keeps coming back to that: keys instead of passwords, a bastion instead of an open port, an audited entry point instead of thirty.
Where CentralHost fits
The hardening in this guide is identical whether you run CentralHost or not — it’s standard, vendor-neutral cPanel security. But several steps raise the same question: how do I do this across 200 servers? That’s where the platform shows up — fleet-wide visibility into which boxes are still exposed, an SSH access map, a browser terminal that works with port 22 closed, and an AI assistant that investigates an incident across logs, metrics, and processes and proposes a fix behind an approval gate. Read those sections as the “at scale” answer; everything else stands on its own.
Get the guide
It’s a free PDF — 29 pages, no email wall, no signup. Read it end to end or jump to the step that matches the server in front of you today.
Download “How to Harden Your cPanel Server” (PDF) →
When you’re ready to keep a whole fleet hardened — not just one box — start with CentralHost, one console for every server you run.