How long does this take?

A couple of hours for someone who has done it before, and most of a day for someone who has not, largely spent on the backup and restore testing. The first four steps take under thirty minutes and remove the majority of the automated attack surface.

My host says the server is already secure. Is it?

Your host secures their platform, not your machine. Once you have root on a VPS, patching, firewall configuration, access control and backups are your responsibility, and shared-responsibility models are explicit about this. Check your provider terms; the split is usually clearer than people expect.

Hardening

How to secure a VPS you just bought

Ordered by how much risk each step removes, not by how interesting it is. If you only do the first four, you have still eliminated most of what automated attacks rely on.

By David Kabel · Updated 2026-09-01 · 3 min read

The short answer

Take root off SSH, use keys instead of passwords, move admin access onto a private network, and deny by default at the firewall. Then automate patching, add intrusion detection with file integrity monitoring, ship logs off the box, and back up somewhere that fails independently, testing a restore on a schedule. Everything else is refinement.

The eleven steps

Create a non-root user and disable root SSH loginMost automated attacks target root directly. Removing that target ends the majority of drive-by attempts before anything else you do matters.
Switch SSH to key-only authenticationPassword auth on a public IP will be brute-forced continuously. Keys end that category of attack outright rather than slowing it down.
Put SSH behind a private networkBetter than hardening the public door is not having one. A mesh VPN removes SSH from the internet entirely, which is the single largest reduction in exposure available to a small server.
Configure the firewall to deny by defaultOpen only the ports the service actually needs. Deny-by-default means a service you forget about later is not automatically exposed.
Enable unattended security updatesUnpatched packages are the most common route in. Automate it, because manual patching on a server nobody owns does not happen.
Add rebootless kernel patchingKernel vulnerabilities normally mean scheduling downtime, so they get deferred. Live patching removes the trade-off between staying patched and staying up.
Install host intrusion detection with file integrity monitoringYou want to know when a file changes that should not have. This is also a mandatory PCI DSS control if you handle cardholder data.
Collect and retain logs somewhere off the machineLogs stored only on the compromised host are the first thing an attacker clears. Retention is also a PCI DSS Requirement 10 obligation.
Set up monitoring that alerts a humanMetrics nobody looks at are decoration. The alert has to reach a person who can act, or it does not count.
Configure off-site backups in a different failure domainA second disk in the same machine survives disk failure and nothing else. Off-site means a provider or region that fails independently.
Restore one, on a scheduleA backup you have never restored is a file, not a backup. Restore-test on a cadence and document how long it took.

What people usually skip, and regret

In practice the two that get skipped are log retention and restore testing, because neither produces any visible benefit until the day you desperately need it. That is exactly why they are worth doing on day one rather than after an incident, when the logs you needed have already rotated away and the backup turns out to have been excluding a directory nobody reviewed.

Want this done and kept done?

Wardio runs all eleven as standard, then keeps them running. See what that costs.

Free server review