What is server hardening?
Server hardening means shrinking everything an attacker can use on a machine: shutting off services you don't need, closing ports, removing passwords from remote access, patching on time and no longer advertising versions. A hardened server isn't invulnerable, but it makes an attacker work much harder and leaves a trail when they try.
It applies the same to a VPS, an EC2 instance or a physical box. The cloud doesn't change the rule: under the AWS Shared Responsibility Model, your instances' guest operating system and its firewall are your job, not the provider's.
You don't have to invent the list. The CIS Benchmarks are consensus-built configuration recommendations with versions for each distribution, such as Ubuntu 24.04 LTS and 22.04 LTS, free to download as PDF for non-commercial use from the CIS Ubuntu Linux page. NIST SP 800-123 dates from 2008, but its principles still hold: plan, install the minimum, configure carefully and maintain.
What goes into a Linux server hardening checklist?
Nine items, from the most urgent to the most often forgotten. Work through them in this order.
1. Only the services you need
Every service listening on the network is a door. List what's open with «ss -tulpn» and turn off what you don't use with «systemctl disable --now service-name». The usual leftovers: a mail server nobody configured, a database listening on every interface when only the local machine uses it, forgotten admin panels.
2. A default-deny firewall
The baseline is to deny all inbound traffic and open only what's needed, usually 80 and 443. On Ubuntu, «ufw default deny incoming» and then «ufw allow» one port at a time. On AWS, security groups play that role: no admin port should be open to 0.0.0.0/0.
3. SSH with keys, no root, and not open to the whole internet
In OpenSSH, per its documentation, «PermitRootLogin» defaults to «prohibit-password» and «PasswordAuthentication» defaults to «yes»: password logins are allowed unless you change it. Turn it off, log in with keys and with an unprivileged user that uses sudo.
PermitRootLogin no PasswordAuthentication no KbdInteractiveAuthentication no PubkeyAuthentication yes AllowUsers deploy
A key isn't enough if port 22 is still open to everyone: it gets hammered all day and any future SSH flaw reaches you. Restrict it to your IPs, a VPN or a bastion host. We cover the layers in is port 22 still open? (Spanish).
4. Automatic patches and service restarts
On Ubuntu, unattended-upgrades comes installed and applies security updates once a day. Confirm it's still enabled in «/etc/apt/apt.conf.d/20auto-upgrades» and check its history in «/var/log/unattended-upgrades». Careful: an updated package doesn't protect you until the process using it restarts. That was the case with PHP2Shell: without restarting PHP-FPM, the patch doesn't apply. And if your branch no longer gets patches, plan the upgrade to PHP 8.4.
5. PHP and the web server without version banners
By default, PHP ships with «expose_php» on and adds an «X-Powered-By» header with its exact version. nginx publishes its version in the «Server» header and on error pages with «server_tokens on», and Apache defaults to «ServerTokens Full». That hands an attacker the list of flaws to try.
; php.ini expose_php = Off # nginx, http block server_tokens off; # Apache ServerTokens Prod ServerSignature Off
6. Current TLS and HTTPS everywhere
Redirect all HTTP to HTTPS, renew certificates automatically and turn off old protocols. As a reference, NIST SP 800-52 Rev. 2 requires TLS 1.2 for US government systems and calls for TLS 1.3 support. Add security headers such as «Strict-Transport-Security».
7. Logs shipped off the server
If someone gets root, local logs are the first thing they wipe. Ship access, SSH and application logs somewhere else with a defined retention, and make sure someone reviews the alerts. A log nobody reads is only good for the post-mortem.
8. Backups you can actually restore
Off the server, encrypted, with a copy the server itself can't delete and a tested restore. On AWS, an AWS security audit also checks the immutable vault and the copy in another Region.
9. Least privilege
The application runs as its own user, never as root. The web server user can't write to the code. Secrets such as the «.env» file live outside the public directory. Everyone logs in with their own account, not a shared one.
How do you harden without taking production down?
- Take a snapshot or backup before touching anything.
- Make one change at a time and validate the config before reloading: «sshd -t», «nginx -t» or «apachectl configtest».
- When changing SSH, keep a second session open until you've confirmed you can log back in.
- Write down how to roll back each change before you apply it.
- Measure before and after with the same review, to prove the change closed what it was meant to close.
How does Security OS review your servers?
The Security OS server scanner checks from the outside what anyone on the internet can see of your server, across nine areas: exposed files, TLS and HTTPS, SSH access, firewall and network, updates, services and environments, logs, backups and security headers. Each finding arrives prioritized, and the remediator prepares the fix with its rollback. Nothing is applied without your approval, and the same engine confirms it was closed.
Security OS isn't a 24/7 SOC and doesn't do penetration testing: it audits, fixes with your OK and proves it with before-and-after evidence. To keep up with flaws that hit servers, check this week's alerts, or see Security OS in full.
Passive check: it only reads your homepage's public response, like a browser. Use it only on domains you own or manage.
Check my PHP for freeFrequently asked questions
What is server hardening?
It's shrinking a server's attack surface: fewer services, a default-deny firewall, key-only SSH without root, current patches, no version banners and tested backups.
Which hardening guide should I follow?
The CIS Benchmark for your distribution is the most widely used standard and is free to download for non-commercial use. NIST SP 800-123 covers the general principles of server security.
Are SSH keys enough?
No. Keys stop password theft, but port 22 open to the whole internet still draws attacks. Limit it to your IPs, a VPN or a bastion, and disable root login.
Does hiding my PHP version protect me?
Only from the most automated scans. A vulnerable PHP is still vulnerable even if it doesn't advertise its version. Update and restart PHP-FPM first, then hide the version.
Are automatic updates safe in production?
For security patches, generally yes: on Ubuntu, unattended-upgrades only uses the official security sources by default. Check its logs and restart the affected services.
Do I still need to harden servers on AWS?
Yes. On EC2, the operating system and its firewall are your responsibility under the Shared Responsibility Model. AWS secures the infrastructure, not your server.
Sources
- CIS Benchmarks
- CIS Ubuntu Linux Benchmarks
- NIST SP 800-123: Guide to General Server Security (July 2008)
- NIST SP 800-52 Rev. 2: Guidelines for TLS Implementations (August 2019)
- OpenSSH: sshd_config(5)
- Ubuntu Server: Automatic updates
- PHP: php.ini core directives (expose_php)
- nginx: server_tokens
- Apache HTTP Server 2.4: ServerTokens and ServerSignature
- AWS: Shared Responsibility Model
Written by Samuel Hinojosa and the wITS security team · Updated Oct 25, 2026 · Markdown
