10-07-2026, 05:53 PM
Hardening a VPS is an ongoing process: reduce exposed services, protect administrator access, keep software supported and make recovery verifiable. This checklist gives you evidence to collect, not just settings to copy.
Scope: Examples target systemd-based Ubuntu/Debian. Adapt package, service and firewall commands for other distributions. On a hosting-panel server, follow vendor-supported procedures so panel updates do not undo your changes.
Safety first: Test the provider console, save configuration backups and keep your current SSH session open. Make one access-control change at a time and confirm a second login works. Never use your only production server to experiment with an unreviewed hardening script.
1. Protect the account that owns the VPS
Enable MFA on the provider, registrar, DNS and backup accounts. Store recovery codes securely and use unique passwords. Review API tokens, team access and billing/contact recovery paths. A hardened guest cannot prevent an attacker with provider-console access from replacing its disks.
Verify: Remove obsolete users/tokens, test your recovery procedure and confirm security notifications go to a monitored address.
2. Inventory users, services and public listeners
Review human users, service accounts and privileged groups. Do not delete unfamiliar system accounts without understanding their purpose. Bind database/cache services to loopback or the required private interface. Remove obsolete software after checking dependencies.
Verify: From an external machine you control, test only your server's intended ports. Check IPv4 and IPv6; a local listener list alone does not prove what the Internet can reach.
3. Use named admins and tested SSH keys
Each administrator should have their own account/key so access can be revoked individually. Protect private keys with a passphrase and keep them off the server. Confirm key login and sudo in a new session before disabling any existing method.
For a standalone server where keyboard-interactive MFA is not used, the intended SSH policy may include:
Back up the configuration and edit the effective file/snippet with sudoedit. Inspect Include order, provider snippets and Match blocks. Validate and review before reloading:
If syntax is valid, use the appropriate reload mechanism; commonly sudo systemctl reload ssh on Ubuntu/Debian. Then test a fresh login. For conditional Match blocks, inspect the actual user/client context with sshd -T -C. Do not disable keyboard-interactive if your intended MFA depends on it.
Verify: Your named admin can log in and use sudo; root/password access behaves as intended. Keep the console available until all checks pass.
4. Restrict management access at both firewall layers
Use the provider firewall and a supported guest firewall. Permit your actual SSH port before enabling restrictions. Prefer a VPN or trusted source addresses for SSH and panel interfaces; account for a changing home IP and recovery access. Expose web ports only for services that need them. Do not expose database, Redis or Docker management endpoints publicly.
For an existing UFW deployment, inspect without changing policy:
Do not layer UFW over a panel-managed firewall without checking compatibility. Review IPv6 and Docker forwarding/published-port behavior separately.
Verify: Fresh management connections succeed from approved paths and unintended public ports are unreachable. A hidden panel URL or custom SSH port is not an authentication control.
5. Patch every software layer
Track the OS, kernel, panel, plugins, PHP/runtime versions, web apps and dependencies. Remove end-of-life versions or plan a supported migration. Review updates and backups before applying them:
Use automatic security updates where supported, but confirm allowed repositories, logs, failure alerts and reboot policy. Third-party software may require a separate update process. Schedule and verify reboots when needed; installing a kernel update does not mean the running kernel changed.
Verify: Update jobs finish successfully, notifications arrive and the application still works after maintenance.
6. Protect hosting panels and applications
Use a valid TLS certificate, unique admin credentials and supported MFA. Restrict panel access and disable unused plugins/API access. Give applications separate database users with only needed privileges. Keep secrets outside public web roots and avoid storing them in repositories or world-readable files.
Do not solve ownership errors with recursive chmod 777. Do not disable SELinux/AppArmor to make an application start; examine the denial and adjust the intended policy. Validate application-specific permissions and test uploads, scheduled jobs and updates afterward.
Verify: The panel is reachable only through intended paths; TLS validates without bypassing warnings; application accounts cannot access unrelated databases/files.
7. Treat brute-force protection as an extra layer
Fail2ban or an equivalent tool can help with services that still need public login endpoints. Verify the selected filter reads the actual log/journal and the ban action uses your active firewall. Account for reverse proxies so legitimate visitors are not all attributed to the proxy's IP. Use supported real-client-IP configuration and trusted proxy ranges.
Verify: Inspect service status, configuration checks and jail counters using the installed tool's documentation. Keep a console and recovery path for accidental bans. Rate limiting does not replace keys, MFA or timely patching.
8. Make detection useful
Monitor unexpected successful logins, privileged changes, new listeners, failed update/backup jobs and resource exhaustion. Retain logs long enough to investigate and consider a protected off-server copy. Basic inspection:
Service/log names vary; also inspect application and panel audit logs. Failed SSH attempts are common on public hosts. An unfamiliar successful login or a changed authorized_keys file deserves investigation.
Verify: Trigger a harmless test alert and confirm someone receives it. Redact IPs, usernames and personal data before sharing logs publicly.
9. Keep independent, tested backups
Use encrypted off-site backups, retention and credentials with limited scope. Include application-consistent database backups, files, configuration and rebuild instructions. Protect at least one copy from deletion by a compromised production server where feasible. A snapshot under the same provider account is useful, but shares that account's failure risk.
Verify: Restore into an isolated environment and test the application. Record how much data/time recovery would lose. Monitor backup age and restore failures.
10. Prepare for compromise before it happens
Keep a private inventory, contacts and rebuild plan. If compromise is suspected, use the provider console/trusted workstation, preserve relevant evidence and isolate the affected system as appropriate. Do not assume deleting one suspicious file makes the host trustworthy. Plan to rebuild from a known-good image and rotate exposed credentials from a clean device after containment. Check adjacent provider, DNS, backup and application accounts too.
Monthly review: Are all administrators still authorized? Are OS/apps supported? Are only necessary ports exposed? Do alerts arrive? Has a restore been tested? Repeat after major deployments or staff changes.
Further reading
Share your OS, panel and intended public services if you need help tailoring the checklist. Keep credentials and private keys private.
Scope: Examples target systemd-based Ubuntu/Debian. Adapt package, service and firewall commands for other distributions. On a hosting-panel server, follow vendor-supported procedures so panel updates do not undo your changes.
Safety first: Test the provider console, save configuration backups and keep your current SSH session open. Make one access-control change at a time and confirm a second login works. Never use your only production server to experiment with an unreviewed hardening script.
1. Protect the account that owns the VPS
Enable MFA on the provider, registrar, DNS and backup accounts. Store recovery codes securely and use unique passwords. Review API tokens, team access and billing/contact recovery paths. A hardened guest cannot prevent an attacker with provider-console access from replacing its disks.
Verify: Remove obsolete users/tokens, test your recovery procedure and confirm security notifications go to a monitored address.
2. Inventory users, services and public listeners
Code:
cat /etc/os-release
getent passwd
getent group sudo
sudo ss -lntup
systemctl --failed
systemctl list-unit-files --state=enabledVerify: From an external machine you control, test only your server's intended ports. Check IPv4 and IPv6; a local listener list alone does not prove what the Internet can reach.
3. Use named admins and tested SSH keys
Each administrator should have their own account/key so access can be revoked individually. Protect private keys with a passphrase and keep them off the server. Confirm key login and sudo in a new session before disabling any existing method.
For a standalone server where keyboard-interactive MFA is not used, the intended SSH policy may include:
Code:
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication noCode:
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep -E '^(permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication) 'Verify: Your named admin can log in and use sudo; root/password access behaves as intended. Keep the console available until all checks pass.
4. Restrict management access at both firewall layers
Use the provider firewall and a supported guest firewall. Permit your actual SSH port before enabling restrictions. Prefer a VPN or trusted source addresses for SSH and panel interfaces; account for a changing home IP and recovery access. Expose web ports only for services that need them. Do not expose database, Redis or Docker management endpoints publicly.
For an existing UFW deployment, inspect without changing policy:
Code:
sudo ufw status verbose
sudo ufw status numberedVerify: Fresh management connections succeed from approved paths and unintended public ports are unreachable. A hidden panel URL or custom SSH port is not an authentication control.
5. Patch every software layer
Track the OS, kernel, panel, plugins, PHP/runtime versions, web apps and dependencies. Remove end-of-life versions or plan a supported migration. Review updates and backups before applying them:
Code:
sudo apt update
apt list --upgradableVerify: Update jobs finish successfully, notifications arrive and the application still works after maintenance.
6. Protect hosting panels and applications
Use a valid TLS certificate, unique admin credentials and supported MFA. Restrict panel access and disable unused plugins/API access. Give applications separate database users with only needed privileges. Keep secrets outside public web roots and avoid storing them in repositories or world-readable files.
Do not solve ownership errors with recursive chmod 777. Do not disable SELinux/AppArmor to make an application start; examine the denial and adjust the intended policy. Validate application-specific permissions and test uploads, scheduled jobs and updates afterward.
Verify: The panel is reachable only through intended paths; TLS validates without bypassing warnings; application accounts cannot access unrelated databases/files.
7. Treat brute-force protection as an extra layer
Fail2ban or an equivalent tool can help with services that still need public login endpoints. Verify the selected filter reads the actual log/journal and the ban action uses your active firewall. Account for reverse proxies so legitimate visitors are not all attributed to the proxy's IP. Use supported real-client-IP configuration and trusted proxy ranges.
Verify: Inspect service status, configuration checks and jail counters using the installed tool's documentation. Keep a console and recovery path for accidental bans. Rate limiting does not replace keys, MFA or timely patching.
8. Make detection useful
Monitor unexpected successful logins, privileged changes, new listeners, failed update/backup jobs and resource exhaustion. Retain logs long enough to investigate and consider a protected off-server copy. Basic inspection:
Code:
sudo journalctl -u ssh --since "24 hours ago" --no-pager
sudo journalctl -p warning -b --no-pager
last -n 20
systemctl --failedVerify: Trigger a harmless test alert and confirm someone receives it. Redact IPs, usernames and personal data before sharing logs publicly.
9. Keep independent, tested backups
Use encrypted off-site backups, retention and credentials with limited scope. Include application-consistent database backups, files, configuration and rebuild instructions. Protect at least one copy from deletion by a compromised production server where feasible. A snapshot under the same provider account is useful, but shares that account's failure risk.
Verify: Restore into an isolated environment and test the application. Record how much data/time recovery would lose. Monitor backup age and restore failures.
10. Prepare for compromise before it happens
Keep a private inventory, contacts and rebuild plan. If compromise is suspected, use the provider console/trusted workstation, preserve relevant evidence and isolate the affected system as appropriate. Do not assume deleting one suspicious file makes the host trustworthy. Plan to rebuild from a known-good image and rotate exposed credentials from a clean device after containment. Check adjacent provider, DNS, backup and application accounts too.
Monthly review: Are all administrators still authorized? Are OS/apps supported? Are only necessary ports exposed? Do alerts arrive? Has a restore been tested? Repeat after major deployments or staff changes.
Further reading
- Ubuntu OpenSSH guidance
- Ubuntu firewall documentation
- Ubuntu automatic updates
- OpenSSH configuration reference
- 15 Things to Do After Buying a New VPS
Share your OS, panel and intended public services if you need help tailoring the checklist. Keep credentials and private keys private.