VPS Security Checklist: 15 Steps to Lock Down Your VPS

Before you use the checklist

This page is the operational companion to the deeper VPS hardening guide. Work through it on a new Linux VPS, after a material application change, and during scheduled security reviews. For every control, record the owner, the change made, the evidence collected, and the rollback or recovery path.

Treat the VPS as production infrastructure: patch the operating system, protect credentials, restrict administrative access, review installation scripts, and test recovery procedures.

Virtarix supplies self-managed VPS and VDS infrastructure. The customer installs, configures, secures, updates, and operates the operating system and software. That includes credentials and access control, firewall and network configuration, operating-system and application updates, installed software and integrations, data handling, independent copies, and recovery planning.

Do not treat any single item as proof that a server is secure. The checklist reduces known exposure only when the controls are configured for the actual workload, verified after change, monitored, and revisited as the system changes.

The 15-step VPS security checklist

1. Patch the operating system and exposed services

Inventory the operating system, package sources, web server, database, runtime, control panel, agents, and every internet-facing service. Apply supported security fixes in a maintenance window, then confirm that required services restarted and the workload still passes its health checks. Do not call the task complete because the package command returned successfully.

Record the versions before and after, failed packages, restart or reboot status, application checks, and rollback point. Use the VPS patch-management process when the server needs a repeatable approval and recovery workflow.

2. Create a non-root administrator and prove recovery access

Create a named administrator with only the required sudo permissions. Open a second session and prove that the account can authenticate, elevate for an approved command, and read the logs needed for troubleshooting. Keep the existing root session open until that test succeeds.

Before restricting root access, document how an operator will recover from a broken SSH configuration, lost key, failed firewall rule, or unavailable identity provider. Use only recovery methods that the server provider actually documents; do not assume a browser console or rescue workflow exists.

3. Use SSH keys and restrict password and root login safely

Give each administrator an individual key rather than sharing one credential. Protect private keys, remove keys that no longer have an owner, and review every entry in user and root authorized_keys files. The SSH key setup guide covers key creation and connection testing.

Disable password authentication and direct root SSH only after a separate tested session proves the replacement path works. Validate the SSH configuration before reloading it, keep the current session open during the test, and define the exact rollback command.

4. Configure the host firewall and any documented network firewall

Start with a written listener inventory: protocol, port, source range, owning process, business reason, and expiry date for temporary access. Permit only required traffic. Configure the Linux host firewall in every case; add a provider-side network firewall only when the provider explicitly offers and documents one.

Apply SSH rules before enabling a default-deny policy, test from a fresh session, and confirm that the application remains reachable only on its intended ports. The safe UFW SSH setup demonstrates the lockout-resistant sequence.

5. Remove unused services and listeners

Compare listening sockets and running services with the approved workload inventory. Stop and disable packages, daemons, development servers, sample applications, and remote-administration services that have no current owner or purpose. Uninstall them when the dependency and rollback review permits it.

Recheck listeners after a reboot, because a disabled process can return through another service unit, container restart policy, or application supervisor. Keep exceptions explicit instead of accepting every open port as necessary.

6. Restrict databases, dashboards, and administration panels

Do not expose a database, orchestrator API, metrics endpoint, debug interface, or administration panel to the public internet merely because it has a login screen. Bind it to loopback or a private interface where the architecture allows, restrict source networks, require strong authentication, and terminate encrypted transport appropriately.

Confirm the service is unreachable from an unapproved network and still usable through the intended administrative path. Use the public admin-panel exposure guide for a deeper exposure and ownership review.

7. Create independent copies and complete a restore test

Define what must be recoverable: application data, databases, configuration, secrets references, user uploads, and the instructions needed to rebuild the service. Store customer-owned copies across a failure boundary that matches the risk, protect access to them, set retention deliberately, and monitor backup jobs.

Every Virtarix VPS and VDS includes one backup and one snapshot. Those included recovery points do not replace customer-owned copies or an independent recovery plan. Follow the VPS backup strategy guide and prove the process with the restore-test checklist.

8. Centralise useful logs, monitoring, and alerts

Collect authentication, privilege, firewall, service, application, and backup events with timestamps that can be correlated. Alert on conditions an operator can act on, such as repeated authentication failures, an unexpected listener, a stopped critical service, storage exhaustion, or a failed backup. Assign a responder and escalation path to each alert.

Test delivery by generating a safe known event, then confirm the record includes enough context to investigate it. The VPS log-review routine covers the review habit; the Zabbix monitoring guide covers a customer-managed monitoring option.

9. Rotate credentials and control secrets

Inventory administrator keys, service-account tokens, database credentials, deployment keys, API keys, certificates, and recovery codes. Record an owner, permitted use, storage location, rotation trigger, and revocation method for each secret. Remove credentials belonging to former staff, abandoned automation, and retired integrations.

Keep secrets out of source repositories, shell history, images, and general-purpose configuration exports. Prefer narrowly scoped credentials and prove that rotation does not leave an old credential active.

10. Add brute-force and abuse controls to exposed authentication

Rate-limit or temporarily block repeated failed authentication where the service supports it. Configure the control for the actual log source and authentication path; installing a package alone does not protect SSH, a control panel, and a web application automatically.

Use a known test source to confirm a failure is detected, the intended action occurs, legitimate administrators have a recovery path, and the event reaches monitoring. The Fail2Ban guide explains jail-specific detection and external alerting.

11. Define an automatic security-update policy

Decide which security updates may install automatically, which require staging or maintenance approval, how services are restarted, and who handles failures. Automatic updates can reduce exposure time, but unattended changes without health checks and rollback can create a different operational risk.

Test the policy on the supported distribution, monitor its result, and review held or failed packages. Keep kernel, runtime, database, container image, and application dependency updates in scope even when they use different update mechanisms.

12. Review file ownership, permissions, and privilege boundaries

Check sensitive configuration, private keys, environment files, web roots, upload directories, sockets, scheduled tasks, and service units. The owner and mode should match the process that needs access—no broader. Review sudo rules, setuid/setgid files, capabilities, and privileged groups for unexplained escalation paths.

Apply corrections to exact paths, then test the affected service. Avoid recursive permission changes across an application tree unless its ownership contract explicitly requires them; broad changes can expose secrets or break execution.

13. Harden the application and runtime

Apply the security controls of the actual web server, database, language runtime, container engine, control panel, and application. Disable debug mode and unused modules, validate installation scripts before running them, keep dependencies supported, isolate services, and avoid running the workload as root when a narrower identity works.

For containers, review image provenance, mounted secrets, published ports, Linux capabilities, privileged mode, host mounts, and update/redeploy procedures. Treat isolation as one boundary in the design, not as a replacement for host patching, firewalling, or recovery.

14. Prepare incident access and a recovery runbook

Write down how an operator will recognise a suspected compromise, preserve useful evidence, isolate the workload, revoke credentials, restore or rebuild from a trusted point, validate service integrity, and communicate ownership. Store the runbook somewhere reachable when the VPS or normal identity system is unavailable.

Exercise the access path and the first recovery actions without causing an outage. Record dependencies on provider features exactly as documented, name the decision-maker for destructive containment, and define when to rebuild instead of attempting an in-place repair.

15. Optionally change the SSH port to reduce scan noise

Moving SSH away from port 22 can reduce routine bot noise in logs, but it does not replace keys, restricted source access, patching, rate limits, monitoring, or recovery. An attacker can still discover an open SSH listener.

If the operational benefit is worth the added configuration, update the SSH service and every relevant firewall rule before reloading, validate the configuration, test a second session on the new port, and keep rollback access. Follow the SSH port-change guide for the safe sequence.

Sign-off record

Use this table as the minimum evidence record. A control remains open when the evidence or recovery path is missing.

Re-run the checklist after architecture changes, new public services, administrator turnover, a security incident, or a failed recovery test. Security work is complete only for the current reviewed state; the next change creates a new state to verify.