Linux Server Hardening Checklist for Cloud VPS Deployments

Small‑business owners and DevOps engineers alike often launch a Cloud VPS with a fresh Linux distribution and assume it’s ready for production. In reality, a vanilla install leaves dozens of attack surfaces open—from default services to mis‑configured permissions. This checklist walks you through the essential hardening steps you should audit before exposing your VPS to the internet, helping you balance security, performance, and operational overhead.

1. Baseline System Assessment

Identify the current attack surface

Start by cataloguing every listening port and enabled service. A quick ss -tuln or netstat -tulnp reveals what’s exposed. Compare the list against your application requirements; any service you cannot justify should be disabled or removed.

Audit installed packages

Run dpkg -l (Debian/Ubuntu) or rpm -qa (CentOS/RHEL) and look for unnecessary packages such as mail servers, FTP daemons, or GUI components. Removing them reduces the code base an attacker can exploit.

2. Secure the Network Layer

Configure a host‑based firewall

UFW (Ubuntu) or firewalld (CentOS) provides a simple rule set. Permit only the ports required for your application (e.g., 80/443 for web, 22 for SSH) and deny everything else. Example UFW rule set:

• ufw default deny incoming
• ufw default allow outgoing
• ufw allow 22/tcp # SSH (limit to trusted IPs later)
• ufw allow 80,443/tcp

Restrict SSH access

Beyond firewall rules, harden SSH itself:

• Change the default port (e.g., 2222).
• Disable password authentication; use PubkeyAuthentication yes.
• Enable AllowUsers or AllowGroups to limit who can log in.
• Activate MaxAuthTries 3 and LoginGraceTime 30.

3. System and Kernel Hardening

Apply security‑focused kernel parameters

Use sysctl to tighten networking and memory handling. Add the following to /etc/sysctl.d/99-hardening.conf:

net.ipv4.ip_forward = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
fs.suid_dumpable = 0
kernel.randomize_va_space = 2

Run sysctl -p /etc/sysctl.d/99-hardening.conf to apply immediately.

Enable automatic security updates

On Debian/Ubuntu, install unattended-upgrades and configure /etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

This ensures critical patches are applied without manual intervention, reducing the window of exposure.

4. Service‑Specific Hardening

Web server (Nginx/Apache) security

Implement the following best practices:

• Disable directory listings (autoindex off; for Nginx).
• Enforce TLS 1.2+ and strong ciphers; use Let’s Encrypt for free certificates.
• Set Content‑Security‑Policy and X‑Frame‑Options headers.
• Run the web server under a non‑privileged user (e.g., www-data).

Database hardening (MySQL/PostgreSQL)

Only bind the database to 127.0.0.1 unless a separate application tier requires remote access. Use strong, randomly generated passwords and enable role‑based access controls. Example for MySQL:

[mysqld]
bind-address = 127.0.0.1
skip-name-resolve
sql-mode = STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION

5. Monitoring, Logging, and Incident Response

Centralize logs

Configure rsyslog or systemd-journald to forward logs to a remote syslog server or a managed logging service. Retain logs for at least 30 days to aid forensic analysis.

Deploy intrusion detection

Tools like fail2ban can automatically ban IPs that trigger repeated authentication failures. A basic jail.local entry for SSH:

[sshd]
enabled = true
port    = 2222
filter  = sshd
logpath = /var/log/auth.log
maxretry = 3

6. Backup and Recovery Considerations

Snapshot strategy

Take regular, immutable snapshots of the root volume. Retain at least three generations (daily, weekly, monthly) and test restoration procedures quarterly. For a cost‑effective approach, you can rely on Cloud VPS snapshot features, which integrate seamlessly with most Linux distributions.

Off‑site replication

In addition to provider snapshots, push database dumps to an off‑site object store (e.g., S3‑compatible storage). Encrypt the dumps with GPG before transfer.

7. Checklist Summary

• Run a full service and port inventory; remove anything unnecessary.
• Enable a host‑based firewall and restrict SSH (non‑standard port, key‑based auth).
• Apply kernel hardening via sysctl and enable automatic security updates.
• Tighten web and database configurations (TLS, least‑privilege users, bind‑address).
• Set up centralized logging, fail2ban, and regular snapshot backups.
• Test restore procedures and maintain an off‑site copy of critical data.

Conclusion

Hardening a Cloud VPS is not a one‑time task but an ongoing audit. By systematically applying the items in this checklist, you dramatically lower the risk of compromise while keeping operational overhead manageable. Remember to revisit the checklist after major OS upgrades, new application deployments, or any change to your network topology—security is a continuous process, not a set‑and‑forget configuration.