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

Decision 1 for server hardening. This is not a CIS document. The ticket says which notes you accepted. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.

Decision 2 for server hardening. The release is supported. The patch guide is already true. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.

Decision 3 for server hardening. Key login for a named admin is proven before passwords are refused. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.

Decision 4 for server hardening. Root SSH login is off. Administration is the named account and sudo. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.

Decision 5 for server hardening. The firewall allows the management prefix and the service ports, not the world. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.

Decision 6 for server hardening. Console or out-of-band was tested first. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.

Decision 7 for server hardening. sudoers names a job. It is not a blank cheque. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.

Decision 8 for server hardening. Auditors ran on redacted copies. Secrets are not in the ticket. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.

Decision 9 for server hardening. Logging stays on. The logging guide owns retention. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.

Decision 10 for server hardening. The canary still accepts the key after the reload. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.

Decision 11 for server hardening. A second person watched the outside-prefix test fail and the inside-prefix test succeed. Write that decision in the ticket before you change the host. The proof is the smallest command or screen that confirms it, recorded with the hostname and the time. If the host disagrees, the ticket changes. A second change does not go on top of a failed check. The rollback is the previous value you wrote down, not a reboot that hides which line mattered.

Hardening checks before the next host is touched

Check 1 in Hardening checks before the next host is touched. The OS is a supported release. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 2 in Hardening checks before the next host is touched. A named admin key session works. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 3 in Hardening checks before the next host is touched. Console or out-of-band works. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 4 in Hardening checks before the next host is touched. Root SSH login is refused. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 5 in Hardening checks before the next host is touched. Password SSH is refused only after the key worked. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 6 in Hardening checks before the next host is touched. The firewall does not allow management from every address. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 7 in Hardening checks before the next host is touched. An address outside the prefix cannot open SSH. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 8 in Hardening checks before the next host is touched. An address inside the prefix can. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 9 in Hardening checks before the next host is touched. sudoers was checked with visudo or the platform check. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 10 in Hardening checks before the next host is touched. Auditor notes are accepted or fixed in the ticket. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 11 in Hardening checks before the next host is touched. No secret from a config is in the ticket. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 12 in Hardening checks before the next host is touched. The previous sshd and firewall files are saved. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 13 in Hardening checks before the next host is touched. The canary login was retested after reload. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 14 in Hardening checks before the next host is touched. Logging is still on. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 15 in Hardening checks before the next host is touched. The hostname in the prompt matches the hostname in the ticket for server hardening. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 16 in Hardening checks before the next host is touched. The result line includes the time and the person, not only the command. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 17 in Hardening checks before the next host is touched. You can point at the rollback value without searching a chat history. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

Check 18 in Hardening checks before the next host is touched. Done is a sentence a second person can repeat: the proof for server hardening happened, and the next host is not started early. Record the device name, the result, and the time on the same line. If the result does not match this check, stop and fix the ticket before you add another change. The rollback for this check is the previous value you wrote down, not a reboot. A reboot hides whether the check was the one that mattered. When the check passes, move to the next one. When it fails, the incident is this check.

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. A published page is linked. The others are named until they are published.

The content plan also names a companion in another desk: Security: Server Hardening Guide.