Keeping your VPS secure: hardening, Lynis and a maintenance routine
With Securing your VPS: the first five minutes you lay the foundation: updates, logging in with a key, a firewall and fail2ban. But a server is never finished. Software ages, certificates expire and disks fill up. Here you'll read how to lock down your server further step by step after that (hardening), how to check it with Lynis, and which maintenance rhythm helps.
Four principles
- A small attack surface. What isn't there can't leak. Remove services and packages you don't use, and only keep the ports open to the outside that are really needed. See Which services are listening on your VPS, and what can be reached from outside?
- Least privilege. No daily work as root, services under their own user, never
chmod 777. See Reading and setting file permissions correctly on your VPS. - Defence in depth. Assume that one measure will fail. A database that only listens on
127.0.0.1, sits behind a firewall and has a strong password stays safe if one of those three fails. - Seeing what happens. Logs, monitoring and backups. Without those three, you only notice a problem when it's too late.
The CIS Benchmarks in brief
The Center for Internet Security (CIS) creates the CIS Benchmarks: lists of recommended settings per product, including for Debian and Ubuntu. They're divided into Level 1 (basic measures without many downsides, the goal for most servers) and Level 2 (stricter, may cost functionality or speed). Use them as a reference: understand a recommendation before you apply it, change one thing at a time and write down why you deliberately don't do something. Be careful with ready-made scripts that apply "all of CIS" in one go: they make it easy to lock yourself out.
Checking with Lynis
Lynis is a free open-source program that inspects your server from the inside. It doesn't change anything itself, it only reports.
sudo apt install lynis sudo lynis audit system
On AlmaLinux and Rocky Linux you install it from EPEL with sudo dnf install lynis. Here's how to read the results:
- Warnings are something you really should look at, for example packages with known vulnerabilities (meaning there are pending updates).
- Suggestions are advice. Many are useful, some don't fit your server. A suggestion to disable
AllowTcpForwarding, for example, breaks your SSH tunnels. Don't follow them blindly. - Every finding has a code in brackets, such as
[SSH-7408]. Use it to look up in/var/log/lynis.logexactly what was tested. - The hardening index (a number up to 100) is a pointer in the right direction, not a score to chase.
Make a snapshot before you change anything based on Lynis, see Snapshots and backups of your VPS, and know how to open the console in case you do lock yourself out.
A maintenance rhythm
An example for a small server. Adapt it to your own situation and put the moments in your calendar.
| When | What |
|---|---|
| Every week | Go through alerts from your monitoring; systemctl --failed; reboot if /var/run/reboot-required exists |
| Every month | apt list --upgradable (is anything stuck?); update containers; disk space; errors in the log with journalctl -p err --since "1 month ago" |
| Every quarter | Do a test restore of a backup; review users and authorized_keys; run Lynis again |
| Every year | Check the end-of-life date of your version and plan an upgrade; update security.txt if you have one; update your server file |
Help with the individual parts: Updates and automatic updates, Monitoring from outside and inside, Backups with restic to another location, Revoking SSH access to your VPS for a former employee or a lost laptop and Upgrading your VPS to a new version of Debian or Ubuntu.
A server file
Write a short document for each server and store it outside the server, for example in your password manager:
- name, IP addresses, operating system and the end-of-life date of that version;
- what's running (services, containers, websites) and which ports are open for them;
- where the backups are stored, how you restore them and when you last tested that;
- which secrets are stored on the server (not the secrets themselves, but which ones and where you replace them);
- who has access, and what you deliberately did differently from the default.
That file helps during an outage, during an upgrade and when someone else takes over management.
timedatectl that the clock is synchronised: with the wrong time, logs are useless and certificates may be considered invalid.Your VPS is fully self-managed: you take care of hardening and maintenance inside the server yourself. We help with the WebOké part, such as the VPS screen, the network, snapshots and the daily backups.
Want to learn more? Take the free course VPS and Linux server management, lesson 10.1 Hardening and CIS principles or lesson 10.4 Final check: putting your server to the test.