VPS security checklist

Secure a new VPS before deploying public applications: patch the operating system, create named administrative access, verify key-based recovery, allow only required network services and establish backups and monitoring. Make one access-control change at a time and keep a tested console session available so a firewall or SSH mistake does not lock out every administrator.

Scope and limitations

This is a baseline for an internet-facing Linux VPS, not a complete hardening standard. Commands, package names and defaults vary by distribution and image. Windows VPS, containers, control panels, databases, mail servers, regulated workloads and high-availability systems need separate vendor- and application-specific procedures.

No checklist can guarantee that a server is secure. Threat modelling, vulnerability management, incident response and periodic review remain ongoing work.

Phased VPS security checklist

1. Establish controlled access

Record the provider console and recovery method before changing SSH or firewall rules.
Create named administrator accounts and avoid routine direct root login.
Install and test SSH public keys from a second session before disabling weaker access methods.
Restrict administrator permissions to what is needed and protect private keys outside the server.
Synchronise time and document the server owner, purpose, operating system and support window.

2. Patch and reduce exposure

Apply supported operating-system and package updates, then reboot when required.
Configure automatic security updates with a maintenance and restart policy appropriate to the workload.
List listening ports and running services; disable or remove what the application does not need.
Set a default-deny inbound firewall policy and explicitly allow required management and application ports.
Bind databases and internal services to private or local interfaces unless public access is explicitly required.

3. Protect applications and data

Terminate public web traffic with current TLS and redirect intended HTTP traffic to HTTPS.
Store secrets outside public directories and avoid placing credentials in repositories or shell history.
Run services as dedicated, unprivileged users and apply restrictive file permissions.
Create off-server backups for configuration and application data and test a restoration.
Document dependencies, certificates, DNS, scheduled tasks and the order needed to rebuild the service.

4. Monitor and maintain

Collect authentication, firewall, system and application logs with appropriate retention and access controls.
Monitor availability, disk space, memory pressure, certificate expiry, backup completion and unusual login activity.
Review user accounts, keys, firewall rules, packages and exposed ports on a schedule.
Prepare an incident contact path and a method to isolate the server without destroying evidence.
Re-run the checklist after major application, network or administrator changes.

VPS security FAQ

Should SSH always be moved to a non-standard port?

A different port may reduce routine scanner noise, but it does not replace keys, patching, access controls, firewall rules or monitoring. Treat it as an optional operational choice, not a primary defence.

Should password login be disabled immediately?

Only after key-based access and a provider console or other recovery method have been tested. Otherwise a typing or firewall mistake can lock out every administrator.

Is a snapshot a complete backup?

Not by itself. Snapshots can be useful, but recovery also depends on retention, independence from the failed system, application consistency and a tested restore process.