VPS Security Checklist: The Complete Guide

Why a checklist, not a single fix

No single control secures a VPS on its own, because attackers only need one weak layer to get in while defenders need every layer to hold. A hardened firewall does nothing if SSH still accepts weak passwords, and hardened SSH does nothing if the web application behind it has an unpatched vulnerability. Server security works as a set of layers that each remove a specific attack path, and this checklist is organized around those layers in the order most VPS operators should tackle them.

This matters more for small and mid-sized businesses than the marketing around "enterprise security" suggests. Most attacks against internet-facing servers are not targeted at a specific company; they are automated scans running continuously against the entire internet, looking for whichever server responds to a known weakness. A small VPS running a client's website is exactly as visible to those scans as a large enterprise server, and according to the 2025 Verizon Data Breach Investigations Report, stolen or misused credentials were involved in roughly 32% of breaches overall, which is why the checklist below starts with access control rather than more exotic defenses.

SSH access hardening

SSH hardening means replacing password logins with cryptographic keys, disabling root login, and restricting sshd's configuration so that automated brute-force attempts cannot succeed even after running for years. This is the first thing to fix on any new server, because SSH is almost always the first service an attacker's scanner will probe.

At minimum, generate an Ed25519 key pair, disable PasswordAuthentication, set PermitRootLogin no, and restrict connecting accounts with AllowUsers. We cover the full set of sshd_config directives, recommended cipher suites, and the reasoning behind each setting in our dedicated SSH hardening: best practices to stop brute-force attacks guide.

Firewall configuration

A firewall enforces a default-deny policy at the network level, so that only the specific ports your applications actually need, such as SSH, HTTP, and HTTPS, are reachable at all. Everything else should be rejected before it ever reaches a running service.

On Ubuntu and Debian, ufw is the simplest way to manage this and translates into either iptables or nftables rules depending on your system. For more complex rule sets, multiple servers, or finer control, nftables is the modern, actively developed successor to iptables. Both approaches can enforce the same default-deny posture; the right choice depends on how much granularity you need. We compare the three options directly, including migration notes from iptables, in the Linux firewall guide: iptables vs nftables vs ufw.

Intrusion prevention with fail2ban

Fail2ban watches log files for repeated failed login attempts and automatically bans the offending IP address for a configurable period, which stops distributed brute-force attacks from grinding away indefinitely against SSH, web login forms, or mail services. It is a second layer that works alongside key-based authentication and a firewall, not a replacement for either.

A reasonable starting configuration bans an IP for one hour after three failed SSH attempts within a ten-minute window, with escalating ban times for repeat offenders. Fail2ban can also protect nginx, WordPress login pages, and mail servers using the same jail model. Full jail configuration, whitelisting your own IPs, and integrating fail2ban with your firewall are covered in the Fail2ban setup guide: automated intrusion prevention.

Patch management

Patch management means applying operating system and software security updates promptly and consistently, ideally through automation rather than a manual schedule someone has to remember. Unpatched software is one of the most common root causes of breaches: research from the Ponemon Institute, conducted for ServiceNow, found that 60% of breach victims reported being breached through a known vulnerability for which a patch existed but had not been applied.

For most Linux distributions, enabling unattended security updates closes this gap with almost no ongoing effort. On Debian and Ubuntu, the unattended-upgrades package handles this; on RHEL-based systems, dnf-automatic serves the same role. The harder part is patching applications and dependencies that live outside the OS package manager, and knowing when a patch requires a restart or a maintenance window. We go through both sides of this in the Server patch management guide: why unpatched servers get hacked.

Web server hardening

Web server hardening means configuring nginx (or another web server) to hide unnecessary version information, enforce modern TLS settings, set protective response headers, and avoid serving files or directories it shouldn't. Most of the actual data attackers want lives behind the web server, not behind SSH, which makes this layer just as important as the operating system controls above it.

Key items include disabling server_tokens so nginx does not advertise its exact version, enforcing TLS 1.2 and above with modern cipher suites, setting headers like X-Content-Type-Options and Content-Security-Policy, and applying rate limiting to login and API endpoints to blunt credential-stuffing attempts. The full configuration walkthrough is in Nginx security best practices.

DDoS protection

DDoS protection means having a plan for absorbing or filtering a flood of malicious traffic before it exhausts your server's bandwidth, connections, or application resources. For most small and mid-sized businesses, this does not require a dedicated scrubbing appliance; it requires the right combination of a content delivery network or reverse proxy in front of the origin server, rate limiting at the application and web server layer, and a hosting provider with basic network-level filtering.

The right level of DDoS protection depends heavily on what you are running and how much downtime actually costs your business. We break down the practical, cost-appropriate options for SMB websites, including free and low-cost tiers, in DDoS protection for small business websites.

Monitoring and log analysis

Server monitoring means continuously watching system logs, authentication logs, resource usage, and network activity so that unusual behavior is caught early instead of discovered weeks later. A hardened server that nobody is watching can still be compromised quietly, especially through a slow-moving attack that stays under any single alert threshold.

At a minimum, centralize your authentication logs, web server logs, and system logs somewhere they can't be deleted by an attacker who gains access to the server itself, and set alerts for anomalies like a spike in failed logins, unexpected outbound connections, or new user accounts. We cover log sources, retention, and practical alerting setups in Server monitoring and log analysis.

Incident response

Incident response is the plan you follow when, despite the layers above, you find evidence that a server has been compromised: how to confirm the breach, contain it, preserve evidence, and restore clean service. Having this plan written down before an incident happens is what separates a contained, hours-long disruption from a prolonged, costly one.

Warning signs worth investigating immediately include unfamiliar cron jobs, unexpected outbound network connections, new SSH keys you didn't add, and unexplained spikes in CPU or bandwidth. The step-by-step process for confirming and containing a breach, including what evidence to preserve, is in How to detect and respond to a server breach.

Managed security vs DIY

The honest tradeoff between managed security and doing it yourself is not about whether the controls in this checklist work; it's about whether your team has the time and consistency to keep applying them every week, especially patching and 24/7 monitoring, which degrade quickly without continuous attention. A one-time hardening pass is valuable, but attackers do not stop finding new techniques after you finish it.

Some businesses have the in-house capacity to own this checklist indefinitely. Others find that an external team auditing, configuring, and continuously monitoring the same controls is more reliable than relying on whoever last had time to check the server. We lay out the real tradeoffs, including where DIY genuinely works fine, in Managed security vs DIY: what SMBs need to know.

The full checklist, in one place

Here is every item from this guide condensed into a single reference list. Work through it in order for a new server, or use it to audit an existing one.

• SSH: key-based authentication only, root login disabled, sshd_config hardened, modern ciphers enforced.
• Firewall: default-deny inbound policy, only required ports open, rules reviewed after every new service.
• Fail2ban or equivalent: SSH jail enabled, sensible bantime and maxretry, extended to web login forms.
• Patching: unattended security updates enabled for the OS, a process for patching applications outside the package manager.
• Web server: version disclosure disabled, modern TLS enforced, security headers set, rate limiting on sensitive endpoints.
• DDoS protection: a CDN or reverse proxy in front of the origin, rate limiting, a provider with basic network filtering.
• Monitoring: centralized, tamper-resistant logs, alerts on authentication anomalies and unexpected outbound traffic.
• Incident response: a written plan for confirming, containing, and recovering from a breach, reviewed before you need it.
• Backups: regular, tested, and stored somewhere a compromised server cannot delete them.
• Least privilege: no shared root accounts, sudo scoped to what each account actually needs.

Go deeper on each item: ransomware protection, backup strategy and the 3-2-1 rule, exposed databases, Docker host security, SSH two-factor authentication, exposed .env and .git files, and users, sudo and least privilege.

In the news: Yandex data center attacks and what they mean for resilience, a case study for the backup, DDoS and failover items above.