comez.dev
en
~/article/hardening-a-linux-web-serverAll articles

article2 min read25 views

Hardening a Linux web server: a practical baseline

The short list of controls I apply to every new server before anything else is installed.

On this page (7)
  1. 1. Patch first, then automate
  2. 2. Lock down SSH
  3. 3. Default-deny firewall
  4. 4. Reduce the attack surface
  5. 5. Slow down brute force
  6. 6. Isolate sites from each other
  7. 7. Monitor, back up, and test the restore

A fresh server is probed within minutes of getting a public IP address. Most of the compromises I have cleaned up were not clever: weak credentials, outdated software, or services that never needed to be reachable from the internet. This is the baseline I apply before anything else goes on the machine.

1. Patch first, then automate

Update everything once by hand, then let the system apply security updates on its own.

apt update && apt full-upgrade -y
apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

2. Lock down SSH

Key-only authentication, no direct root login, and a short allow-list of users.

# /etc/ssh/sshd_config.d/10-hardening.conf
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
AllowUsers deploy

Always run sshd -t before reloading, and keep your current session open until a second session proves you can still log in.

3. Default-deny firewall

Only what you can name should be reachable.

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

4. Reduce the attack surface

List what is listening and remove whatever you cannot justify.

ss -tulpn
systemctl list-unit-files --state=enabled

Databases and caches (MySQL, Redis, Memcached) should listen on 127.0.0.1 or a private network, never on a public interface.

5. Slow down brute force

fail2ban with the sshd jail covers the common case. Keep the ban time long enough to matter and whitelist your own address.

6. Isolate sites from each other

Give every site its own system user and PHP-FPM pool, so a compromise of one application does not become a compromise of all of them. Disable functions that web applications rarely need, such as exec, shell_exec and proc_open.

7. Monitor, back up, and test the restore

Hardening reduces the chance of an incident; monitoring and verified backups decide how bad the incident is. Alert on failed services and on disk and memory pressure, and make sure at least one backup copy lives outside the server.

General

Comments0

No comments yet. Be the first to comment.

Leave a comment

Related

Working on something similar?
Happy to review an architecture or help with delivery.

contact