CIS Linux/Windows Server Hardening Blueprint

A fresh server install is optimised for one thing: getting the application running with the fewest support tickets. Every default that makes that easy — enabled legacy protocols, permissive services, broad local admin — is a default that helps an attacker once they’re past the perimeter. Whether an intruder can move laterally, escalate, and stay hidden is decided almost entirely by configuration you set months before the breach.

Ask any penetration tester where the easy wins are and the list is depressingly consistent. LLMNR and NBT-NS still broadcasting on Windows, ready to be poisoned into a credential capture. SSH accepting root logins on Linux. A dozen accounts with local admin because it was simpler than scoping permissions. The CIS Linux/Windows Server Hardening Blueprint shuts these doors systematically rather than one incident at a time — a layered baseline aligned to the CIS Benchmarks that makes the box actively hostile to the techniques that actually get used. Worth being honest up front about the cost, because it’s the part that gets skipped: hardening breaks things, and a blueprint that pretends otherwise will get rolled back the first time it takes down a legacy app in production.

The Scope of the Baseline

Hardening isn’t a project you finish; it’s a standard you defend against drift, because the third week after rollout is when someone re-enables SMBv1 “just to test something” and forgets. This blueprint covers the mixed reality most estates actually run:

• Linux: Ubuntu, Debian, RHEL, CentOS, Fedora, and their variants
• Windows: Server 2019/2022 and Windows 10/11 admin machines
• macOS: Secure configuration for admin engineering workstations

The goal is one consistent standard across the whole fleet, because an attacker only needs the one box that got missed.

Core Hardening Domains

We lock down the parts of the OS that attackers actually use — while leaving the apps you depend on able to run:

Identity & Access Management LAPS on Windows to rotate local admin passwords automatically, which kills the single-shared-local-admin-password pattern that lets one cracked hash open the whole estate. On Linux, enforce password policy through PAM. Remove default and guest accounts — they’re pure attack surface with no operational upside.

Remote Access (SSH/RDP) RDP reachable only from jump hosts, behind Network Level Authentication. SSH with PasswordAuthentication no — keys only, Ed25519 — and access limited to the admin group. The trade-off to plan for: key-only SSH means a lost or unmanaged key locks you out, so the key lifecycle (issuance, rotation, an out-of-band recovery path) has to exist before you disable passwords, not after.

Service Reduction Uninstall roles you don’t use, disable SMBv1 outright (it’s the protocol behind EternalBlue and has no place on a modern network), turn off IPv6 if nothing uses it, and strip weak ciphers. Every service removed is one fewer thing to patch and one fewer thing to exploit.

Audit & Logging auditd on Linux, Advanced Audit Policy on Windows. You specifically need process-creation logging with command line — Event ID 4688 with the command-line auditing GPO enabled, because default 4688 records the process name and nothing about what it was told to do. Add authentication events and PowerShell script-block logging. Without this, an investigation reconstructs nothing, and the gap is invisible until the day you need the logs and they aren’t there.

Network & Host Firewall Default-deny inbound, via firewalld, ufw, or Windows Defender Firewall, opening only what’s explicitly required. One caveat that bites Linux hosts: if Docker is present it writes its own iptables chain that’s consulted before ufw’s rules, so a published container port can be internet-reachable while ufw status insists it’s blocked. Verify from another host with a scan, don’t trust the local status.

File Permissions & Access Lock down /etc/shadow and the sensitive registry hives on Windows. Where the application set is stable, go further and allowlist — AppLocker or WDAC on Windows — so only approved binaries run. Allowlisting is the single strongest control here and also the most operationally demanding, because every legitimate software update becomes a rule you have to maintain.

The Practitioner Tool Stack

Hardening hundreds of servers by hand isn’t a plan, it’s a way to guarantee inconsistency. What actually gets used:

For Assessment: Wazuh SCA, OpenSCAP, or CIS-CAT Pro scan against the benchmark and report the gaps. The value is a concrete number — “we’re at 42%” — and a ranked list, which turns an unbounded security chore into a finite backlog. Treat the percentage as a progress indicator, not a goal; a box at 95% CIS with one misconfigured service can still be trivially owned.

For Enforcement: Group Policy and Desired State Configuration on Windows; Ansible and Bash on Linux. Enforce it from a central definition so a manually “fixed” server drifts back into compliance instead of quietly staying wrong.

For Validation: Ship the audit logs to Splunk or ELK and build a dashboard that confirms they’re actually arriving. This step exists because an agent that reports “connected” while shipping nothing is the most common and most invisible failure in the whole pipeline — verify the logs are flowing, don’t assume it from a green status light.

Practical Policy Implementation Examples

The controls below map directly to techniques testers use, which is why they’re the ones worth enforcing first:

Linux SSH Hardening: PermitRootLogin no removes root as a direct login target, so admins authenticate as themselves and escalate with sudo — which also means the audit log shows who did the privileged thing, not an anonymous root session.

PasswordAuthentication no ends SSH brute-forcing entirely. Keys only. (See the key-lifecycle caveat above — this is the setting that locks you out if the recovery path doesn’t exist.)

AllowUsers [admin_group] limits SSH to the admin group. Everyone else is refused before authentication even starts.

Windows Server Hardening: Disable NTLMv1 — it’s cryptographically broken and trivially relayed. Move to NTLMv2 or, better, Kerberos. Expect this to surface an old appliance or scanner that only speaks NTLMv1; that discovery is the control doing its job.

Enable PowerShell Constrained Language Mode, which blocks the reflection and API calls that offensive scripts rely on unless the code is signed and trusted. A real friction point for attackers — and occasionally for your own admin tooling, which is why you test it in staging first.

Enable SMB Signing to shut down NTLM relay by authenticating each packet. The trade-off is a measurable CPU and throughput cost on high-volume file servers, which is real but almost always worth paying against how common relay attacks are.

Managing Exceptions for Business Continuity

Security that breaks the business gets overruled, and rightly so. Some legacy app will genuinely need SMBv1; some ERP system a decade past its prime will fall over when you disable a protocol. Pretending otherwise is how hardening projects die. The answer isn’t to skip the control — it’s a formal exception process, so the risk is a documented decision rather than a silent gap:

1. Identify which CIS control is failing, for which specific business need.
2. Document why the exception is required, and get sign-off in writing from someone who owns the risk — not from the engineer who’s simply blocked.
3. Compensate with a mitigating control. If SMBv1 must stay, that host goes in a firewalled VLAN with no internet route and tight egress, so the weak protocol can’t be reached from anywhere an attacker is likely to be.
4. Register the exception with an expiry date and revisit it quarterly. Undated exceptions are how a “temporary” SMBv1 box is still running SMBv1 five years later, long after the app that needed it was retired.

The goal was never a perfect score. It’s risk that’s been seen, decided on, and mitigated — which is a defensible position in a way an unexamined gap never is.

Deliverables

The Baseline Checklist Every CIS control actually implemented, tailored to your environment — including the ones you deliberately didn’t, and why. A generic benchmark PDF isn’t a baseline; the decisions you made against it are.

Compliance Scorecard Before-and-after numbers — “30% to 85%” — as measurable evidence of progress for management and auditors. Presented as a trend, not a trophy.

Remediation Scripts & Automation Exported GPOs for Windows, Ansible and Bash for Linux, ready to redeploy across the fleet. This is also what makes the baseline repeatable on the next server build instead of a one-off heroic effort.

Exception Register Every exception with its control, justification, compensating control and expiry date. This is the artefact SOC 2, PCI-DSS and ISO 27001 auditors specifically look for, because it demonstrates governed risk rather than negligence.

SIEM Alerting Recommendations Queries and dashboards that fire when a hardening control gets disabled — SMB signing turned off, an audit policy reverted — so drift and deliberate tampering both surface as an alert rather than as a finding in next year’s pentest.

60-Day Server Hardening Roadmap

Days 1–15: Audit & Discovery Run Wazuh SCA or OpenSCAP read-only across the fleet. Change nothing — just measure. Most estates land at 30–40%, and that number is the baseline you’ll report progress against. Use this window to identify which applications will need exceptions before you break them, not after.

Days 16–30: Dev/Test & QA Push the GPOs and scripts to staging and deliberately try to break things, with the app teams watching. Every failure you find here is a production incident you didn’t have. This phase is the one under pressure to skip, and skipping it is the single most reliable way to turn a hardening rollout into an outage.

Days 31–45: Exceptions & Phased Production Rollout Document each exception with its compensating control, then roll out in order of blast radius — infrastructure servers first where a mistake is survivable, business-critical systems last once the pattern is proven. Never big-bang the whole fleet in one change window.

Days 46–60: Validation & Monitoring Re-scan; you should clear 85%. Then hand the drift-detection alerts to the SOC, because the real risk after rollout isn’t the initial config — it’s the slow re-loosening over the following year as people work around controls they find inconvenient.

Hardening is a force multiplier for everything else you do: it doesn’t stop the initial intrusion, but it turns a trivial lateral-movement-and-escalate into a slow, noisy grind that your logging now has a chance to catch. It won’t make a box unbreachable — nothing does — but it moves you from easy prey to a target expensive enough that most intrusions stall before they matter.