A freshly installed server is at its most exposed in the first hours of its life. It has a public IP address, default settings and often a root password sent by email. Automated scanners find new addresses quickly, and they do not care that you have not finished setting things up yet.
Hardening is the work of closing the doors you do not need and locking the ones you do. Nothing on this list is exotic. What makes it effective is doing all of it, in a sensible order, before the server takes on real sites. Here is the checklist we begin with on a new Linux server.
Patch Everything First
Before anything else, bring the operating system fully up to date. Installation images are often weeks or months old.
# Debian and Ubuntu
apt update && apt full-upgrade
# AlmaLinux and Rocky Linux
dnf upgrade --refreshReboot if the kernel was updated. Then turn on automatic security updates so the server keeps receiving fixes between maintenance work, using unattended-upgrades on Debian based systems or dnf-automatic on Red Hat based ones. Decide whether automatic updates should cover security fixes only or all packages, depending on how much change the server can tolerate.
Lock Down Remote Access
SSH is the front door of a Linux server, so it gets attention early.
- Create a named administrator account and give it
sudorights, rather than working as root. - Set up SSH key authentication for that account and test that it works in a second session before changing anything else.
- In
/etc/ssh/sshd_config, setPasswordAuthentication noandPermitRootLogin no, orprohibit-passwordif a control panel needs root key access. - Limit who can log in with
AllowUsersorAllowGroups. - Restart SSH with
systemctl restart sshd, orsshon Debian and Ubuntu, keeping your existing session open in case of mistakes.
Moving SSH to a non-standard port cuts down log noise from bots but is not a security control on its own. Keys and firewall rules do the real work.
Firewall With A Default Deny
Start from the position that nothing is allowed in, then open only what the server needs. For a typical web server that is SSH, HTTP and HTTPS, plus mail and control panel ports if they are used.
Use the firewall that suits the system: ufw on Ubuntu, firewalld on AlmaLinux and Rocky, or CSF on servers running cPanel or DirectAdmin. If you have a fixed office or VPN address, restrict SSH and control panel ports to it. Add brute force protection as well, through Fail2ban, CSF’s login failure daemon or the control panel’s own tools.
Remove What You Do Not Need
Every running service is something that could have a vulnerability. List what is listening on the network:
ss -tulpnAnything you do not recognise or need should be stopped and disabled with systemctl disable --now servicename, or removed altogether. Common candidates include mail services on servers that do not handle mail, old FTP servers, and database ports listening on public addresses.
The same thinking applies to web tools. Database admin pages such as phpMyAdmin, old installer scripts and forgotten test files in web roots are all things attackers look for. If a tool is needed, put it behind a login and an IP restriction. If it is not needed, remove it. A smaller server is an easier server to defend.
Separate Sites And Users
If one site on a server is compromised, the damage should stop at that site.
- Run each site or application as its own system user.
- Use PHP-FPM pools per site, each running as that site’s user.
- Keep file permissions tight: typically
644for files and755for folders, with configuration files holding passwords readable only by their owner where possible. - Never use
777permissions to make something work. It almost always hides a different problem. - Leave SELinux or AppArmor enabled rather than switching them off at the first error.
Harden The Application Layer
Web Server And TLS
Serve sites over HTTPS with automatically renewing certificates, disable old protocols such as TLS 1.0 and 1.1, and stop the web server advertising its exact version in headers. Consider a web application firewall such as ModSecurity with a well maintained rule set.
PHP
Set expose_php = Off and display_errors = Off on production servers, keep each PHP version on a supported release, and set realistic limits for memory and execution time.
Databases
Bind MySQL, MariaDB or PostgreSQL to 127.0.0.1 unless remote access is genuinely required, remove anonymous users and test databases, and give each application a separate database user with only the privileges it needs.
Plan For The Day Something Goes Wrong
Hardening reduces risk but cannot remove it entirely. The last part of the checklist is about recovering when something does slip through.
- Backups: automated, stored off the server, with more than one copy kept. Test a restore every few months so you know it works.
- Logs: keep authentication, web server and system logs for long enough to investigate problems, and consider sending them to a separate system an attacker cannot easily wipe.
- Time: make sure time synchronisation through
chronyorsystemd-timesyncdis working, so log timestamps line up. - Monitoring: alerts for unusual load, disk space, failed services and unexpected logins.
- Two-factor authentication: on control panels, hosting provider accounts and anywhere else that offers it.
- Documentation: a record of what was changed and why, so the next person can understand the server.
Our server security page covers the ongoing work that keeps a hardened server that way.
How Server Defenders Can Help
Whether you have a brand new server or an older one that has never been reviewed, our server setup and hardening service works through this checklist and adapts it to the sites you run. Get in touch to tell us about your server.
