Server Hardening 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 plan, not a benchmark paste

This guide is not a CIS benchmark and not the system desk's host runbook. Those exist. This page is the security order: a supported system, a named admin, a second factor where you have it, and a firewall that allows the management prefix and the service you meant. The endpoint checklist generator and the firewall rule generator draft lists. A draft that allows every address is a draft you delete.

You keep a way in. Console or out-of-band is tested before you reload a remote login or a firewall. The system hardening guide has the host detail. This page refuses the two failures that lock you out or open the world.

Patch comes before a new control. A host past its vendor's end of life does not become safe because a header changed. The vulnerability guide is the queue.

Logging stays on. A control that works by deleting evidence is not a control. The detection guide consumes those logs later.

A lab host with a narrow management rule

On the lab host, confirm the admin key or the admin factor works, and confirm the console works. Then allow management only from the lab prefix. 192.0.2.0/24 is the documentation prefix. An address outside it must fail. An address inside it must work. Write both results.

If the firewall generator emits a wide allow, delete that line before you apply anything. The service port, if the lab has a service, is opened to the clients you named, not to every address, and only after the service answers on loopback.

The checklist generator's items are questions. Answer the ones this host needs. An unanswered item is honest. A ticked item without a command or a screen is not.

Leave the CIS benchmark text to the CIS overview. Do not paste a benchmark into a shell.

# Lab order. Review before you paste.
# 1. Admin login and console both work.
# 2. Management from the named prefix only. Never every address.
# 3. A generated allow-the-world rule is deleted.
# Documentation prefix: 192.0.2.0/24. Replace it outside the lab.
# prompt-for-this is not a password to keep.

A change you can finish

The canary is one production host after the lab results. The rest follow. You do not push a firewall to a fleet from an untested draft.

Rollback is the previous firewall and the previous remote-login settings, from the console if you must.

Confirm the OS is supported and patched.
Prove the admin path and the console.
Restrict management to the named prefix.
Prove an outside address fails and an inside address works.
Delete any generated rule that allows the world.
Answer the checklist items you can evidence.
Keep logging on.

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.

Allowing every address so you would not lock yourself out.
Reloading the firewall from the only session.
Pasting a benchmark into a shell.
Turning logging off to make the host quieter.
Hardening an end-of-life system and calling it done.
A checklist with no evidence.
Opening a service port before the service is ready.
A password from the generator left as prompt-for-this.

Decisions to write down before the window

One decision for server hardening: The host is supported. Patching is already true or this window stops. Console access was tested first. Management is the named prefix, not the world. Both the allow and the refuse were tested. Wide generator rules were deleted. Logging stays on. CIS text is not pasted. The overview guide owns that checklist habit. The system hardening guide owns the host commands. Rollback files are saved. And one host is the canary.

The hour you stop

Write the hostname or the system name, the owner, and the clock time before you change anything for server hardening. If the system is serving people and you do not have a spare, this hour is a plan, not a change. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab or a copy. The log line you test with is one you created, or one you are already allowed to hold. You do not point a tool at a network, a mailbox, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a draft, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.

One change. A firewall, a detection, a DNS record, and a policy do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous value, written down while the system still works.

A second person reads the scope aloud: which host, which domain, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

Documentation addresses stay in the lab. 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 are not your production network. example.com is not your domain. Replace them before a real record or a real rule is published.

Do not allow every address because a test failed. A rule, a header, or a detection that matches the world is a draft you delete. Management stays on the prefix you named. A service port opens when the service is ready, for the clients you named.

Keep the previous file. A generator draft is not the previous file. The previous file is what you reload if the new one is wrong. You practised the reload on the lab, with a console or a second session open when the change can lock you out.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a system nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next system waits until someone else can repeat the proof from the notes. server hardening is done for this window when the proof is written, not when the tool printed a file.

This page is a planning guide. It is not legal advice, not an audit opinion, not a vendor manual, and not the text of a standard. If a lawyer, an auditor, or a regulator must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this system alone until that guide has its own window.

Hardening checks before the next host

Confirm this before you call the change done: The OS is supported. Admin login works. Console or out-of-band works. An outside address cannot manage the host. An inside address can. No rule allows every address. Logging is still on. Checklist ticks have evidence. No benchmark was pasted into a shell. The previous firewall is saved. prompt-for-this is not the live password. A second person saw both tests. The canary is the only production host in this window. 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: System: Server Hardening & Audit Guide.