Linux server hardening checklist for a new VPS

A new server with a public IP is scanned by bots almost immediately. Hardening means reducing what an attacker can reach and limiting the damage if something goes wrong. Work through these steps in order, and test each change from a second session so you do not lock yourself out.

1. Update everything

sudo apt update && sudo apt upgrade -y
sudo apt install unattended-upgrades

Turn on automatic security updates. Most real-world compromises use old, known flaws. Reboot when the kernel is updated, or use a live-patch service if you have one.

2. Users and sudo

• Create a normal user with sudo and stop working as root.
• Give each person their own account. Do not share logins.
• Remove or lock accounts you do not need.
• Use sudo with care, and grant only the commands people need where you can.

3. Secure SSH

Use keys, disable password and root login, limit users and keep a second session open while you test. The details are in the SSH hardening article of this series.

4. Firewall

Allow only what you need and deny the rest.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable

Allow SSH before enabling. Check what is listening with ss -tulpn. Databases and admin tools should listen on localhost or a private network, never on the public interface. Also use your cloud provider's firewall (security group) as a second layer.

5. Run fewer things

Every running service is attack surface.

• List services with systemctl list-units --type=service --state=running.
• Remove or disable what you do not use.
• Install only needed packages.
• Run each app as its own non-root user, with a systemd unit, as covered earlier in this series.

6. Protect files and secrets

• Set correct permissions: configuration with secrets 600 or 640, never world-writable files.
• Keep secrets in environment files readable only by the service user, not in Git or in command history.
• Check for odd setuid files and world-writable directories now and then.

7. Logs and detection

• Keep logs (journalctl, /var/log) and make sure they do not fill the disk (log rotation).
• Install fail2ban to slow repeated login attempts.
• Send important logs and alerts off the server, because an attacker may erase local ones.
• Consider file integrity or intrusion detection tools for important servers, such as AIDE or auditd rules.

8. Backups

Take regular, tested, offsite backups and keep them encrypted. Hardening lowers the chance of a problem; backups are what save you when it happens. See the backup strategy article.

9. Extra layers (as needed)

• Two-factor authentication or a VPN/bastion for administration.
• Mandatory access control such as AppArmor (default on Ubuntu) left enabled.
• Kernel and network settings (sysctl) tuned according to a trusted guide, such as the CIS benchmarks.
• A web application firewall or CDN in front of public sites, with the origin locked to accept only the CDN.

10. Make it routine

• Weekly: check updates, failed logins and disk space.
• Monthly: review users, SSH keys, open ports and backups, and test a restore.
• Write down the setup steps (or use configuration management or scripts) so a rebuilt server is as secure as the first.

Quick checklist

• Updated, automatic security updates on.
• Non-root user with sudo, root login off.
• SSH keys only.
• Firewall on, only needed ports open.
• Unused services removed.
• Secrets protected, correct permissions.
• Logs kept, fail2ban on, alerts set.
• Tested offsite backups.

Takeaway: patch quickly, shrink what is exposed, use keys and least privilege, watch the logs and keep tested backups. Do the basics well and routinely before reaching for advanced tools.

---

Linux & DevOps series, Part 2 (delivery and operations): 5 of 5. Previous: Backup strategy: the 3-2-1 rule and testing your restores.