Linux Server Hardening: The Basics

A freshly installed Linux server starts in reasonable shape, but without a few settings the attack surface is needlessly large. This list focuses on what reduces real risk rather than a full compliance checklist.

1. SSH: keys instead of passwords

Password-based SSH is the first attack surface on most servers: an internet-facing port 22 receives continuous attempts.

• PasswordAuthentication no, key authentication only
• PermitRootLogin no
• Keys protected with a passphrase, and the private key never on the server

If the server faces the internet, place a jump server or VPN in front so SSH is not directly exposed.

2. Service minimisation

What does not run cannot be attacked. Check what listens (ss -tulpn) and stop what is unnecessary. Typical surplus: an old web server, a database that should only be local, duplicated monitoring agents.

3. Only the necessary ports

A local firewall on every server, not just at the network edge. Deny by default, permitting only ports actually in use, with source restrictions where possible.

A database should never listen on 0.0.0.0 if only the application server reaches it.

4. Automatic security updates

Automatic patching on servers is debated, but practice shows an unpatched system is a greater risk than the rare update failure. A compromise: automatic security updates, manual version upgrades.

5. Least privilege

• Services should not run as root but under dedicated, restricted users
• sudo rights for specific commands rather than blanket access
• sudo usage logged

6. Logging with central collection

Local logs are in the attacker's hands. System logs must be copied to a separate server or SIEM, because traces on the machine can be deleted. We covered this in detail in our logging article.

Minimum: authentication events, sudo usage, service starts, package installation.

7. Filesystem integrity

A simple integrity checker (AIDE or similar) flags when a system binary or configuration changes. Run daily, with the report sent elsewhere rather than kept on the machine.

8. Mandatory access control

SELinux or AppArmor restricts what a process can do even when compromised. Disabling it is a common reflex during troubleshooting, and nobody re-enables it afterwards. Refining the policy is the better path.

Containers

If services run in containers, a few things change:

• Containers should not run as root, preferably with a read-only root filesystem
• Host hardening remains necessary; a container is not an isolation boundary
• Image vulnerability scanning should be part of the pipeline, not a one-off
• Do not pass secrets through environment variables, as they appear in the process list

What to measure

• How many servers permit password SSH
• How many services run as root
• Time between a security patch's release and its installation
• What percentage of logs reach the central collector

Our IT security services include establishing and reviewing server baselines.