How to secure a Linux server in 2026: the complete checklist

A Linux server exposed to the Internet receives its first login attempts within minutes of going live. These are not people targeting you personally: they are bots sweeping the Internet nonstop, testing passwords, looking for forgotten files and exploiting vulnerabilities as soon as they are published.

The good news: the vast majority of these attacks fail against a properly configured and monitored server. Here is the checklist we apply, ordered by priority.

1. Access: close the obvious doors

SSH access is the first target. Three settings remove most of the risk:

1. Key-based authentication only. Disable passwords (PasswordAuthentication no). A key cannot be guessed.
2. No direct root login. Log in with a named user, then elevate with sudo (PermitRootLogin no or prohibit-password).
3. Automatic banning. An IP address that fails several times in a row should be blocked automatically for a while, then longer if it comes back.

Changing the SSH port reduces log noise, but it replaces none of the three points above.

Also check:

• the keys in each account's ~/.ssh/authorized_keys: every key should have a known owner;
• accounts with a login shell and members of the sudo group;
• access left behind by former contractors or employees.

2. Network: expose only what is needed

List what is actually listening on your server:

sudo ss -tlnp

Every port open to the outside needs a reason. A database, a cache or an admin interface almost never needs to be reachable from the Internet: bind them to 127.0.0.1 and use an SSH tunnel when needed.

Then enable a firewall with a deny-by-default policy, and open only SSH, HTTP and HTTPS.

3. Updates: the rule that prevents most incidents

Most compromises exploit vulnerabilities that were already fixed at the time of the attack. The patch existed; it simply had not been installed.

• Enable automatic security updates for the system (unattended-upgrades on Debian and Ubuntu).
• Reboot when the kernel has been updated.
• Watch the number of pending security updates: if it keeps growing, something is blocking.

4. Application versions: the blind spot

Automatic system updates do not touch your applications. Your web framework and your npm, Python or PHP dependencies stay at the version installed during the last deployment.

That is where the most dangerous flaws hide. In December 2025, the React2Shell (CVE-2025-55182) vulnerability allowed remote code execution on applications using React Server Components. Servers that had not updated their framework could be exploited with a single request.

You need to regularly compare installed versions against public vulnerability databases. We detail the method in our article on CVEs and vulnerable dependencies.

5. Web: block common probes

Your web server constantly receives requests for /.env, /.git/, /wp-login.php or /phpmyadmin, even if you use none of them. Block these paths, rate-limit requests per IP address and hide the web server version.

Add the basic security headers: Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options and a suitable Content-Security-Policy.

6. Files: detect what changes

An attacker who gets in wants to stay. They add an SSH key, create an account, install a scheduled task or modify a service. Watching the integrity of a few sensitive files is enough to detect most of these persistence techniques:

• /etc/passwd, /etc/shadow, /etc/sudoers and /etc/sudoers.d/
• /etc/ssh/sshd_config and authorized_keys files
• crontabs and systemd services

7. Malware: scan regularly

On a web server, the antivirus is mostly useful to catch webshells and files dropped through an upload form or an application flaw. A daily low-priority scan of web directories, temporary folders and home directories is enough in most cases. See our article: does a Linux server need an antivirus?

8. Performance: an underrated security signal

An unknown process eating all the CPU is often a crypto miner installed by an attacker. A disk filling up suddenly can signal exfiltration or logs exploding under an attack. Monitor CPU, memory and disk, and know which processes are normal. Details in what CPU, RAM and disk reveal about an intrusion.

9. Backups: your last line of defense

• Automatic, encrypted backups, stored off the server.
• At least one copy that an attacker with root access cannot delete.
• A restore tested at least once per quarter. A backup that was never restored is only a hypothesis.

10. Monitoring: read what your server is telling you

All the measures above produce signals: blocked attempts, alerts, modified files, vulnerable versions. These signals are useless if nobody reads them.

This is the point most often missing in small companies: the logs exist, but nobody has time to analyze them. The fix is to summarize those signals and send them where the team already works, for example Slack. See how to get security alerts in Slack.

The checklist at a glance

Frequently asked questions

How long does it take to secure a Linux server?

Count half a day for an experienced administrator on a fresh server. The hard part is not the initial setup, it is monitoring over time.

Is a VPS from a hosting provider already secure?

No. The provider secures its infrastructure; the system, access and application configuration remain your responsibility.

Do I need a full-time security expert?

For a small company, rarely. What you need is a solid baseline configuration and a tool that warns you when something changes.

FondateurMode, the Linux Server AntiVirus Powered by AI, applies a large part of this checklist with one command: antivirus, automatic IP banning, vulnerable versions, file integrity, performance monitoring, and a daily AI-written report in Slack or by email. Try it free for 14 days.