Securing a Linux server: a practical checklist

Most successful break-ins into a server do not use a novel vulnerability. They use what has been forgotten: password-based SSH, an unpatched package, open ports that should be closed and a user account whose owner left the company two years ago.

The good news is that a large part of this can be checked yourself. The list below covers the settings we most often find missing in practice when we take over a Linux server someone else configured.

1. SSH — the single most important setting

Access to the server goes through SSH, and that is also what gets attacked most. Every server on the public internet receives password-cracking attempts every day, no matter how obscure it is.

Check:

• Password-based login is disabled and only keys are in use. That single change stops the overwhelming majority of attempts.
• Nobody logs in directly as root — use a normal account and sudo.
• Blocking of failed attempts is switched on (fail2ban or equivalent).
• Who has access at all — go through every account and authorised key. Remove the ones no longer needed.

2. Firewall — everything closed except what is needed

By default everything should be denied and only what is genuinely needed opened: web traffic, SSH and the services you deliberately provide.

Databases need particular attention. A database should almost never be reachable from the public internet — that is one of the most common and most serious findings. Check which ports are open from outside and ask about each open port why it is that way.

3. Updates and patches

Check whether there are uninstalled security updates and find out how old the running system is. A separate question: does the distribution version in use still receive security updates at all? End of support means no new patches will arrive, however many times you run the update command.

The same applies to the software running on the server — PHP, the database, the web server. An outdated PHP version is as big a risk as an outdated operating system.

4. Certificates and HTTPS

Check that the certificate is valid, renews automatically and covers every subdomain in use. Also check that HTTP always redirects to HTTPS and that old, weak protocol versions are disabled. An expired certificate is one of the few technical faults every visitor notices immediately.

5. Backups — and a restore test

Three questions that need a concrete answer:

1. How old is the most recent copy?
2. Where is it — outside the server? A copy on the same machine does not help when the machine disappears.
3. When did you last try restoring from it?

If there is no answer to the third question, the backups do not really exist — there is only hope. Do one restore test into a test environment and mark in the calendar when to repeat it.

6. Logs and monitoring

Review whether anyone is watching disk usage, memory use and whether services are alive. A full disk is one of the most common causes of downtime and practically always preventable — it does not fill up overnight.

In the logs it is worth watching repeated login attempts, unusual requests and error messages that have suddenly become more frequent. A change in the pattern is usually the first sign.

7. Who and what is running on the server

Go through which services are running on the server. Over the years things accumulate that nobody uses any more: an old test environment, a long-forgotten helper tool, someone's temporary solution. Every running service is attack surface — delete what is not needed.

8. Documentation

Write down where the server is, what runs on it, who has access and what to do when something fails. This is the part whose value becomes clear on the day the previous administrator is unreachable — and that day always comes sooner or later.

What to do if the list raised more questions than answers

That is exactly the point of the list. If you could not answer several points, the server is probably in a state worth reviewing.

We will review your Linux server, tell you specifically what is in order and what is not, and propose what to fix — including when the conclusion is that no major work is needed. We wrote at greater length about what ongoing management covers in the article Linux server maintenance: what the contract covers.