Technical notes / Linux · Infrastructure · Security · Ubuntu · cPanel
Ubuntu Server Hardening: A Practical Step-by-Step VPS Security Guide
A practical Ubuntu Server 24.04 hardening roadmap covering sudo users, SSH keys, CSF/LFD, Auditd, WHM protections, and safe website migration.
Updated
Hardening means reducing unnecessary exposure, limiting privileges, and making failures easier to detect and recover from. It is an ongoing administration process: applications change, accounts accumulate, and a configuration that worked last month may no longer reflect the services you operate.
This series is a general laboratory based on Ubuntu Server 24.04 LTS. Some tutorials apply to a plain Ubuntu VPS; others explicitly require a supported cPanel/WHM installation. All accounts and endpoints are fictional. 192.0.2.10 is reserved for documentation, and example.com represents a placeholder domain. The series does not describe a real security incident.
Prerequisites and scope
Use an isolated VPS or a representative lab clone, a trusted Linux workstation, administrative access, and the provider’s console or rescue workflow. Back up configuration and application data before changes. Check supported OS, panel, and security-tool versions against current vendor documentation.
You should already have a supported base installation. This series does not install cPanel or promise that every tool is compatible with every VPS image, kernel, or architecture. For cPanel hosts, check Ubuntu system requirements first.
Before any access restriction, keep an existing session open, verify a new administrative connection, and make sure console recovery works. Apply one layer at a time so that a failure has a small, identifiable cause.
Defense in depth: give each layer a clear job
A single tool cannot cover every failure mode. A firewall can restrict reachable services while a vulnerable allowed web application remains exposed. SSH keys can resist password guessing while a stolen private key still permits access. Local audit logs can explain changes while privileged control can threaten their integrity.
| Layer | Purpose | Example in this series |
|---|---|---|
| Identity and privilege | Limit routine authority and attribute administration | Named users and sudo |
| Authentication | Reduce reusable-secret exposure | ED25519 SSH keys and WHM MFA |
| Network exposure | Permit required traffic and review denied access | CSF with a service inventory |
| Authentication monitoring | Detect repeated login failures | LFD and cPHulk |
| Change visibility | Record selected sensitive operations | Linux Audit Framework |
| Workload separation | Reduce sharing between independent applications | Separate cPanel accounts and PHP-FPM identities |
| File review and recovery | Support controlled restoration and investigation | ImunifyAV and verified backups |
Backups and independent logs should remain available even when the VPS is unavailable. Protect the provider account and recovery material with the same care as production credentials.
Understand the main risks of an Internet-facing VPS
Common risks include exposed administrative panels, password guessing, stale packages, vulnerable plugins, overly permissive files, shared credentials, and forgotten services. A website process with unnecessary privileges can expand the impact of an application bug. IPv6 can expose a service that was only reviewed over IPv4.
Operational risks also matter: a firewall mistake can interrupt mail, an SSH snippet can lock out administrators, and logs can fill a disk. Each tutorial pairs a change with a verification and a recovery route.
Start with a private baseline record:
cat /etc/os-release
uname -r
sudo ss -lntup
sudo systemctl --failed
sudo df -hThese identify the OS and kernel, listeners, failed units, and disk capacity. Keep actual output private because it can reveal service details. Do not interpret an empty failed-unit list as proof of security.
Recommended implementation order
1. Prepare recovery and update planning
Test provider-console access and an application restore before changing authentication. Inventory services, maintenance dependencies, and backup destinations. Review pending Ubuntu and cPanel-managed updates using the appropriate vendor workflows. Schedule reboots when needed and verify services afterward.
Patch management, TLS lifecycle, and application dependency updates remain ongoing work beyond the specific controls taught here. Do not replace panel-managed software with arbitrary distribution packages.
2. Create a named administrator
How to Create an Administrator User on Ubuntu Server and Stop Using Root covers adduser, supplementary groups, effective sudo policy, and fresh-session testing. This establishes a safer maintenance identity before direct root SSH access is restricted.
3. Protect SSH with keys
How to Secure SSH on Ubuntu Server with ED25519 Keys covers workstation key generation, passphrases, public-key installation, file permissions, configuration precedence, and safe reloads. Disable password and direct root authentication only after the key-only connection and sudo work.
4. Match the firewall to real services
How to Install and Configure CSF and LFD on Ubuntu with cPanel/WHM verifies package availability, backs up rules, uses temporary testing mode, and checks new SSH and WHM connections before permanent enforcement. It also addresses IPv6, outbound dependencies, and conflicting managers.
A plain Ubuntu VPS needs an appropriate supported firewall workflow of its own; cpanel-csf is not assumed available outside cPanel repositories. Keep provider filtering and host filtering aligned.
5. Record critical changes
How to Monitor Critical Linux Changes with Auditd adds a small persistent policy for identities, sudo, SSH, scheduled tasks, and systemd. It includes a harmless file test and checks event loss and log rotation. You can establish this layer earlier if you want audit visibility during the other changes.
6. Harden the hosting control plane
How to Harden cPanel and WHM with MFA and Account Isolation covers MFA enrollment, cPHulk, tested notifications, account separation, shell access, and PHP-FPM identity checks. SSH policy and panel authentication must both be reviewed.
7. Review applications before migration
How to Use ImunifyAV and Prepare Safe Website Migrations explains scoped scanning, signature updates, detection review, original backups, and staging restores. A scan without detections does not establish the absence of threats.
Verify behavior after every layer
Use fresh connections rather than relying on sessions established before the change. Verify allowed administration and required website, DNS, mail, and backup behavior. Test both IP families where enabled. Keep a private record of the configuration changed, intended effect, actual result, and rollback procedure.
The commands and expected outcomes in this series are instructional examples. They have not been executed against your VPS. Use the installed command help and version-matched documentation when a package, menu, or option differs.
Common problems and safe responses
- Remote access fails: use the known-good session or provider console. Inspect SSH, local filtering, provider filtering, and authentication blocks separately.
- A package has no candidate: stop and verify supported versions and repository origin. Do not substitute an unverified installer.
- A service stops after tightening rules: compare the failed request with the service inventory, including outbound and IPv6 requirements.
- Logs or alerts are missing: verify collection and delivery end to end, then inspect storage, queues, and exclusions.
- A setting does not persist: identify the generating tool, such as cloud-init or cPanel, and use its supported configuration mechanism.
Final security checklist
- Provider account MFA and console/rescue access are tested.
- Original configuration and application backups exist off-host; restoration has been tested.
- Named administrative accounts have verified sudo access and clear owners.
- Fresh SSH key authentication works; private keys are encrypted and recoverable.
- Effective SSH policy rejects unwanted password and direct root logins.
- Required services and outbound dependencies are documented.
- One coordinated host-firewall policy covers IPv4 and IPv6 where used.
- CSF is out of testing mode and LFD is healthy on the applicable cPanel lab.
- WHM MFA, cPHulk, and external notification delivery are verified.
- Website accounts have appropriate shell access and no unintended sudo.
- PHP execution and writable paths match the intended account boundaries.
- Audit rules are loaded; event loss, rotation, disk capacity, and off-host retention are reviewed.
- Supported OS, panel, PHP, and application updates have an owner and schedule.
- Scans have a recorded scope and completion result; suspicious files are reviewed before modification.
- Every access-changing control has a documented, tested recovery procedure.
Conclusion
A useful hardening baseline is understandable and recoverable. Work through the tutorials in small changes, verify the resulting behavior, and revisit the checklist after upgrades or service changes. Security improves through maintained controls and tested recovery, rather than a one-time configuration dump.
Official references
- Ubuntu Server security documentation.
- cPanel and WHM documentation.
- OpenSSH manuals.
- Linux Audit userspace project.
- Imunify documentation.
Each tutorial links to the specific official documentation used for its procedures.