Hosting server security checklist: 40 checks

A hosting server security checklist covers six areas: the operating system and its updates, SSH access, the network firewall, the control panel, isolation between hosting accounts, and the web layer with its backups. The 40 checks below are written for an Ubuntu or Debian VPS that hosts websites for you or your customers. If you only have an hour, do checks 3, 7 to 9, 14, 16, 20 and 39 first: they close the most common ways in.

A bare VPS hardening guide, like our 10 steps for the first hour on Ubuntu, covers the base system; a hosting server also has a panel, customer accounts that must not reach each other, PHP you did not write, and mail that can get your IP blocklisted.

For each check, the last column says whether ZoPanel already does it for you, based on our security documentation and install guide. "Yes" means done automatically at install or by default. "One click" means Security Center offers a Fix button. "Checked" means Security Center reports it but you act. "You" means you have to do it yourself, on ZoPanel or any other panel.

The 40-point hosting server security checklist

Where to start if you only have an hour

The order that removes the most risk fastest:

1. Updates (2, 3). Automatic security updates on Ubuntu and Debian are handled by unattended-upgrades; Ubuntu's documentation explains how to check and tune it.
2. SSH keys, then no passwords (7 to 9). Add a key, test it in a second terminal, then disable password logins. Our guide to SSH brute force protection has the exact steps and the usual lockout traps.
3. Firewall and panel port (14 to 16). Default deny, then restrict the panel to your office or VPN IP. Several of the worst panel incidents of recent years involved admin ports open to the whole internet, as we documented in hosting panel security incidents 2024 to 2026.
4. 2FA (20). Turn it on for yourself, then require it for every admin and reseller.
5. Off-server backups (39). They decide how bad a bad day gets.

Checks people get wrong

The Docker and UFW trap (17). Docker writes its own iptables rules, so a port published with -p 8080:8080 can be reachable from the internet even when UFW says it is blocked. Docker's own packet filtering documentation warns about this. Publish containers on 127.0.0.1 only and put them behind the web server with SSL.

Quotas that are only measured (29). Many setups show disk usage per account but never enforce it. Check that the kernel actually enforces quotas, for example with repquota -a or your panel's quota status.

A WAF in blocking mode on day one (38). Blocking from day one on a shared server breaks page builders and imports. Start in log-only mode; we explain the tuning in ModSecurity and OWASP CRS without false positives.

Backups that live on the same server (39). A local backup protects against a bad plugin update, not against ransomware or a lost disk. Our 3-2-1 website backup strategy explains how to keep copies an attacker on the server cannot delete.

How to verify the checklist on a running server

A few commands answer most of the list on any Ubuntu or Debian server:

# 3: automatic updates
systemctl status unattended-upgrades --no-pager
# 4: reboot needed?
ls /var/run/reboot-required 2>/dev/null && echo "reboot needed"
# 8-10: effective SSH settings
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|maxauthtries'
# 13: extra root accounts
awk -F: '$3 == 0 {print $1}' /etc/passwd
# 14-15: firewall and listening services
sudo ufw status verbose
sudo ss -tlnp | grep -v '127.0.0.1\|::1'
# 30: process hiding
grep ' /proc ' /proc/mounts
# 29: quotas enforced
sudo repquota -a | head

On ZoPanel, the Security Center at the top of the Security page runs most of these checks for you, scores the server and offers a one-click Fix where it is safe. SSH fixes refuse to run until an SSH key is set up, so they cannot lock you out. For a deeper standard, the CIS Benchmarks for Ubuntu and Debian go much further than any 40-point list.

Where ZoPanel leaves work to you

To be clear about the column above: ZoPanel does not decide your SSH policy for you, does not restrict the panel port until you list your IPs, does not turn on the WAF by itself (and cannot on Ubuntu 22.04, which has no ModSecurity module for nginx), and does not send backups off the server until you configure S3, which needs a Pro license. Other panels have similar gaps; the checklist is there to close them whichever panel you run. You can compare how panels handle these areas on our comparison page.

Conclusion

A hosting server security checklist is never finished: you go through it at install, then again after every big change such as a new panel version, a new reseller or a new app. The 40 checks above cover the system, SSH, network, panel, account isolation, web layer and recovery. If you do only the first-hour items, you are already ahead of most servers on the internet.

If you want most of the "Yes" column handled for you, try the ZoPanel Free plan: 3 hosting accounts, 10 websites and 10 databases, no time limit, installed with curl -fsSL https://get.zopanel.net | sudo bash. Then open Security Center and work through what is left.

Frequently asked questions

What is the most important security step for a new hosting server?

Turn on automatic security updates and switch SSH to key-only login. Many compromises use known vulnerabilities or guessed passwords, and these two steps address both. Restricting the control panel port to your own IPs comes a close third.

How often should I review a server security checklist?

At install, after every major change (new panel version, new services, new resellers) and at least once a quarter. Automated checks run continuously, but a manual review also catches things no tool knows about, such as former staff accounts.

Do I need a web application firewall on a hosting server?

It is a useful layer, especially on shared servers with many WordPress sites, but it comes after updates, isolation and backups. Roll it out in log-only mode first so it does not block legitimate requests from page builders or imports.

Does a control panel make a server less secure?

It adds attack surface, because it is a web application with root-level power over the server. A panel that keeps its web interface unprivileged, restricts its port and requires 2FA reduces that risk; one that runs as root and is open to the internet increases it.