Server Hardening & Audit Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

This is a planning guide, not a benchmark

This page is not a CIS benchmark and not a vendor hardening PDF. It is the order a careful admin uses so the host is smaller and you can still log in. The auditors on this site read a file you paste: sshd_config, a Nginx or Apache config, sudoers, a crontab, or a systemd unit. They do not scan a network. You review their notes and you decide.

The order is boring. Patch onto a supported release first. Create a named admin with a key. Prove the key works. Then stop password login and direct root login. A firewall allows the management prefix and the service ports you named, and you tested that a stranger's address is not the management prefix. You do not lock the firewall and the SSH config in the same minute from a remote session you might cut off. Use a console or a second session.

sudoers is edited with visudo or the file the platform checks. The sudoers auditor reads a copy. A blanket permission for every command with no password is not the starting point. Name the command if you can. The permissions guide covers file modes. The patch guide covers the update path. A host past end of life does not become safe because sshd was tightened.

Nothing here asks you to disable logging, disable the firewall, or turn off malware controls to make a step pass. If a control blocks the change, the change is wrong or the control needs its own ticket. The security desk has the longer companion. This page stays on the host.

A lab SSH path you cannot lock yourself out of

On the lab host, from the console, confirm the named admin can log in with a key on a second session. Then set the SSH daemon so that root cannot log in with a password and, after the key session is proven, so that passwords are not accepted. The exact keys are the ones on your version's sshd_config manual. Reload the daemon only while the console and the key session are both open. If the key session dies and the console lives, you fix it from the console. If you have neither, you have skipped this paragraph.

The management prefix in the lab is 192.0.2.0/24. The firewall allows SSH from that prefix to the lab host and allows the lab web port only from loopback until the web guide says otherwise. It does not allow the world. A test from an address outside the prefix should fail, and you record that failure. A test from inside the prefix should work.

Paste a copy of sshd_config into the auditor with secrets already absent. Read the notes. You do not need a perfect score to ship the lab. You need to understand each note and either change the line or write why you will not. Do the same for sudoers if you added a rule.

A systemd unit and a crontab get the same treatment when they exist: the auditors read them, and the systemd and scheduling guides remain the place you edit. Hardening is not a second copy of those guides.

# Review before you paste. Lab order, not a full sshd_config.
# 1. Named admin key login works, console open.
# 2. Then refuse root password login.
# 3. Then refuse passwords, only if the key session still works.
# Firewall: SSH from 192.0.2.0/24 in the lab, not from every address.
# Replace the prefix. Do not permit the world to manage the host.

A change you can finish

Production uses the real admin keys and the real management prefix. One host is the canary. Console or out-of-band is tested before you reload sshd. The rest of the hosts follow after the canary's key login still works.

Rollback is the previous sshd_config and the previous firewall, from the console if you must. You kept those files. You do not roll back by opening the host to every address.

Confirm the OS is supported and patched.
Open a console and a working key session for the named admin.
Reload SSH only after that session exists.
Restrict management to the named prefix and prove an outside address fails.
Run the file auditors on copies with no secrets.
Accept or fix each note in the ticket.
Repeat on the next host only after the canary login still works.

Mistakes that outlive the command

server hardening fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Disabling passwords before the key works.
Reloading sshd from the only session, with no console.
Allowing management from every address so you would not lock yourself out.
PermitRootLogin left open because a script uses root.
A sudo rule that allows every command without a password for everyone.
Turning the firewall off to test a service.
Calling a past-end-of-life host hardened.
Pasting a live config full of secrets into a ticket because the auditor printed it.

Decisions to write down before the window

One decision for server hardening: This is not a CIS document. The ticket says which notes you accepted. The release is supported. The patch guide is already true. Key login for a named admin is proven before passwords are refused. Root SSH login is off. Administration is the named account and sudo. The firewall allows the management prefix and the service ports, not the world. Console or out-of-band was tested first. sudoers names a job. It is not a blank cheque. Auditors ran on redacted copies. Secrets are not in the ticket. Logging stays on. The logging guide owns retention. The canary still accepts the key after the reload. And a second person watched the outside-prefix test fail and the inside-prefix test succeed.

Hardening checks before the next host is touched

Confirm this before you call the change done: The OS is a supported release. A named admin key session works. Console or out-of-band works. Root SSH login is refused. Password SSH is refused only after the key worked. The firewall does not allow management from every address. An address outside the prefix cannot open SSH. An address inside the prefix can. sudoers was checked with visudo or the platform check. Auditor notes are accepted or fixed in the ticket. No secret from a config is in the ticket. The previous sshd and firewall files are saved. The canary login was retested after reload. Logging is still on. The hostname in the prompt matches the hostname in the ticket for server hardening. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for server hardening happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: Security: Server Hardening Guide.