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)
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.
No comments yet. Be the first to comment.