Ransomware Protection for a Small VPS: Entry Points, Blast Radius and Recovery

How ransomware reaches a VPS

CISA's #StopRansomware Guide organises prevention under six headings: internet-facing vulnerabilities and misconfigurations, compromised credentials, phishing, precursor malware infection, advanced social engineering, and third parties and managed service providers. For a VPS run by one or two people, the first two do most of the damage. In the guide's own words, "threat actors often gain initial access to a network through exposed and poorly secured remote services."

The same pattern shows up in the data. Verizon's 2026 report, again as covered by Help Net Security, found that exploitation of vulnerabilities accounted for 31% of breaches and had overtaken stolen credentials as the most common initial access vector. Sophos's State of Ransomware 2026 page puts the share of attacks that succeeded in encrypting data at 56%. In other words, the attacker usually does not need anything clever: a reachable service, a password or key that works, or a published flaw you have not patched yet.

Close the entry points first

Work through the three doors in order of how often they are used.

• Exposed services. Every port that answers the internet is a door. Run a default deny firewall (see the Linux firewall guide), keep databases off public interfaces (exposed databases guide), and never publish the Docker API (Docker host security).
• Credentials. Use key-based authentication only and disable root login as covered in the SSH hardening guide, then add a second factor with SSH two-factor authentication. Let fail2ban absorb the constant guessing.
• Unpatched software. Automate security updates and keep an expedited path for anything on CISA's catalog. Our patch management guide covers the process, and NGINX Rift is a recent example of how long a flaw can sit in widely used software before it is found.

If you only have an hour, spend it here. Everything after this section limits the damage from an intrusion; this section is what prevents the intrusion.

Limit the blast radius

Assume one day something gets in, and decide now how much it can reach. The principle is least privilege: each account and process gets only what it needs. In practice that means the web application runs as its own unprivileged user, so a compromised app cannot rewrite system files or another application's data. Admin work happens through named accounts with scoped sudo rights (see users, sudo and least privilege), not through a shared root login.

The most important separation is between production and backups. CISA warns that "many ransomware variants attempt to find and subsequently delete or encrypt accessible backups to make restoration impossible unless the ransom is paid." A server that can reach its own backups with delete rights hands that capability to whoever takes it over. Give the backup job credentials that can add data but not remove it, or have a separate backup system pull data from the VPS instead of the VPS pushing to it.

Backups that survive an attacker

CISA's recommendation is direct: "maintain offline, encrypted backups of critical data" and "regularly test the availability and integrity of backups in a disaster recovery scenario." It also advises enabling "delete protection or object lock on storage resources often targeted in ransomware attacks." Our VPS backup strategy guide turns that into a working setup: the 3-2-1 rule, immutable copies, pull-based backups and restore tests.

Keep several generations, not just the latest. The CISA guide cautions that "care must be taken to identify such dropper malware before rebuilding from backups to prevent continuing compromises." If the intrusion began three weeks ago, last night's backup may already contain the attacker's foothold, and you need an older clean copy to fall back on.

Detect it early

Ransomware is rarely the first thing an attacker does. There is usually a period of reconnaissance and persistence first, and that is where you can catch it. Watch for new accounts, new cron or systemd entries, unexpected outbound connections, unexplained CPU or disk activity, and failed or missing backup jobs. The server monitoring guide lists what to track, and file integrity monitoring will flag changes to files that should never change.

A cheap extra signal is a few canary files in directories that nothing legitimate touches. If they are suddenly modified or renamed, something is rewriting files in bulk and you want to know in minutes, not at the next login. Alert on backup failures too: an attacker who deletes or breaks backups before encrypting often shows up first as a backup job that silently stopped.

The first hour if you are hit

Isolate first, preserve evidence second, restore third. Cut the host off from the network through the provider's firewall or console so it cannot spread or keep exfiltrating, but do not wipe it yet. This is the containment step from the breach response guide, which covers detection through recovery in full.

Then identify which backups predate the intrusion, rotate every credential that lived on the host (SSH keys, database passwords, API tokens, cloud keys), and rebuild from a known-clean image rather than cleaning in place. Remember that backups restore availability but do not undo theft: if sensitive data was on the server, treat it as potentially disclosed and check what notification duties apply to you. Whether to pay is a business and legal decision, not a technical one, and 69% of victims in Verizon's 2026 data did not.