OS Installation and Hardening

Back to Server Setup · Operating System and Stack · Security Settings · Service Offerings

The first step of installation and configuration: a clean install with unnecessary services disabled, security baselines applied, and the attack surface kept to what's actually needed. The principle underneath it is short. Every service you do not run is one you never have to patch, never have to monitor, and never have to explain to an auditor.

1. Start Minimal, Add Deliberately

It is far easier to add a package than to work out whether something installed by default is safe to remove. So we install the smallest base the platform offers and add only what the application needs.

• Minimal or server base image — no desktop environment, no office software, no printing, no sound. A graphical environment on a server is a large body of code that exists to be exploited.
• One purpose per machine where it is affordable. Combining roles means a compromise of the weakest one reaches the others, and it makes patching windows collide.
• Disable, then remove. A stopped service can be started; an uninstalled package cannot. Where removal is safe, remove.
• Nothing listening that does not need to be. Enumerate what is bound to a network interface and justify each one. Services that only need local access should be bound to localhost rather than to every interface — this is separate from the firewall, and it is the layer that still protects you when a firewall rule is wrong.

2. Apply a Recognised Baseline, Then Adjust

There is no reason to invent a hardening standard. Published benchmarks and vendor security guides cover the same ground far more thoroughly than anyone does from memory: filesystem mount options, kernel parameters, authentication policy, audit rules, permissions on sensitive files.

What matters is applying one with judgement. A baseline applied blindly breaks applications, and a broken application gets fixed by turning controls off wholesale — ending worse than before. So each deviation from the baseline gets recorded with a reason, which is also exactly what an auditor asks for. Where a compliance regime names a specific benchmark, that choice is already made for you; see security and compliance needs.

3. Accounts, Filesystems and Boot

• No shared accounts. Named accounts with elevation, so the audit trail identifies a person. This is the foundation that user management builds on.
• Remove default and unused accounts, and ensure service accounts cannot log in interactively.
• Separate filesystems for the volatile paths — temporary directories, logs, variable data — so that filling one cannot take the system down, mounted with options that prevent execution from directories that should only ever hold data.
• Full-disk encryption where the hardware could be physically taken, with the key-custody question answered before install, not after.
• Secure boot and firmware. Update the firmware at build time, set a firmware password where the machine is physically accessible, and disable boot from external media. These are trivial during a build and awkward afterwards.

4. Time, Logging and Auditing From the First Boot

Three things are worth enabling before the machine does anything useful, because they cannot be applied retrospectively:

• Reliable time synchronisation. Correlating logs across machines is impossible if their clocks disagree, and certificate validation depends on it.
• Logs shipped off the host immediately — see log aggregation. Logs that only exist on a compromised machine are the first thing an intruder edits.
• Audit rules for the events you will want later: privilege escalation, changes to authentication configuration, modification of system binaries.

5. Build It Once, Reproducibly

A hardened machine built by hand is hardened until the next one is built slightly differently. The build belongs in code — a golden image, a configuration management role, or both — so that the tenth server is identical to the first and the configuration can be reviewed like any other change. See infrastructure as code.

That also makes the state checkable. A hardened build drifts: someone opens something during an incident, a package pulls in a dependency that starts a service. Re-running the configuration in check mode, or re-scanning against the baseline periodically, is what keeps the build true rather than merely true on the first day.

What You Get

• A documented base build: what is installed, what was removed, and what is listening.
• A named baseline applied, with every deviation recorded and justified.
• The build captured as code, so it is reproducible and reviewable.
• A compliance report against the baseline at handover, and a way to re-run it.