Linux Server Hardening Baseline (CIS + NIST Guide)

Most "Linux hardening checklists" online are copy-pasted lists of sysctl flags with no source behind them. This one sticks to what CIS, NIST, and CISA actually publish — and where they leave decisions up to you.

Ask five different sysadmins what "hardening a Linux server" means and you'll get five different answers — disable root SSH, maybe run a scanner, maybe just apply updates and call it done. That inconsistency is exactly the gap that formal baselines exist to close. The Center for Internet Security (CIS), NIST, and CISA all publish guidance for this, and they largely agree with each other, even though none of them hand you a single button to press.

What a hardening baseline actually is

A baseline isn't a script. It's a documented, repeatable starting configuration that removes or restricts everything a default install leaves open "for convenience." NIST SP 800-123, the Guide to General Server Security, frames this as a lifecycle: plan the server's role, install and configure it securely, then maintain that configuration over time through patching, logging, and periodic reassessment [2]. The point isn't a one-time lockdown — it's a posture you keep, because configurations drift the moment someone SSHes in to "just quickly" open a port.

CIS approaches the same problem from a different angle: instead of general principles, it publishes benchmark documents for specific operating systems — Ubuntu, RHEL, Debian, and others — with concrete, testable settings organized into Level 1 (practical, minimal-disruption) and Level 2 (stricter, higher-security-impact) profiles, each split further into Server and Workstation variants [1]. Canonical has built tooling directly around this structure: the Ubuntu Security Guide (USG) automates both remediation and auditing against the four profile combinations (Server/Workstation × Level 1/Level 2) [5].

CISA's Cross-Sector Cybersecurity Performance Goals sit above both of these as a prioritization layer — a shorter, sector-agnostic list of the practices that matter most for organizations that can't implement every CIS safeguard at once, covering account security, device security, and configuration management as connected categories rather than isolated OS settings [3].

Installation and minimization

Hardening starts before the server does anything useful. NIST's guidance is blunt about this: install only what the server's role requires, and remove or disable everything else — unused services, default sample applications, unnecessary compilers and packages on production systems [2]. Every running service is something that needs patching, monitoring, and eventually justifying to an auditor. A minimal install isn't about disk space; it's about shrinking the number of things that can go wrong.

Practically, that means picking a server (not desktop) variant of your distribution, disabling automatic installation of "recommended" packages, and reviewing `systemctl list-unit-files --state=enabled` right after first boot — not six months later when nobody remembers why `avahi-daemon` is running on a database host.

Identity, authentication, and SSH

This is the layer CISA's performance goals treat as the highest priority, and for good reason — weak or default credentials remain one of the most common ways servers get compromised [3]. A workable baseline here typically includes:

• Disabling direct root login over SSH and requiring sudo with individually attributable accounts.
• Preferring key-based SSH authentication over passwords, or enforcing MFA where password auth is unavoidable.
• Removing or disabling unused local accounts and default credentials shipped with any pre-installed software.
• Setting a password aging and complexity policy consistent with your organization's identity provider, rather than inventing a separate one per server.
• Locking automatic session timeouts on interactive shells.

These map directly onto CIS Control 4's account-related safeguards and onto the account-security category of NIST SP 800-123's authentication guidance [4] [2]. None of this is exotic — it's the boring stuff that gets skipped under deadline pressure, which is exactly why it shows up first in every serious baseline.

Network exposure and firewalling

CIS Control 4 explicitly calls out firewall management on servers as a foundational safeguard, not an optional add-on [4]. On a Linux host that means a default-deny inbound policy (via `nftables`, `ufw`, or `firewalld`, whichever your distribution ships), explicit allow rules per service, and — critically — checking that the firewall is actually enabled at boot, not just configured. It's a surprisingly common gap: a correctly written ruleset that never loads because the service isn't enabled.

Logging, auditing, and integrity checking

NIST SP 800-123 lists audit and accountability as one of its core control families for server security, alongside configuration management and system integrity [2]. In practice that's `auditd` capturing privilege escalation and authentication events, centralized log shipping so an attacker who gets root can't simply delete the evidence locally, and a file-integrity tool (AIDE, or equivalent) that flags unexpected changes to binaries and configuration files. None of this prevents an intrusion by itself — it's what lets you notice one, and reconstruct what happened afterward.

Where automated tooling fits — and where it doesn't

This is the part vendors tend to gloss over: tooling applies a benchmark, it doesn't decide whether Level 2 is appropriate for your workload. A Level 2 control that disables core dumps or restricts kernel modules might be exactly right for an internet-facing web tier and genuinely disruptive on a host running specialized scientific software. CIS explicitly separates these profiles for that reason — Level 1 assumes broad applicability with low operational risk, Level 2 assumes a higher security requirement that may need testing before rollout [1]. Applying a Level 2 profile blindly to production without staging it first is how hardening projects get abandoned after the first outage.

What a baseline can't do for you

Worth saying plainly: none of this replaces patch management, network segmentation, or an incident response plan — it's one layer among several that NIST and CISA both describe as complementary, not substitutable [2] [3]. A perfectly CIS-compliant server running an unpatched, vulnerable application is still a compromised server waiting to happen. Hardening reduces the attack surface and the blast radius; it doesn't make patching optional.

A practical starting checklist

• Install the server-minimal variant of your distribution; audit enabled services on first boot.
• Pick a CIS Level 1 profile as your default; evaluate Level 2 per-workload before rollout.
• Disable root SSH login and password authentication where feasible.
• Enable a default-deny firewall and verify it starts at boot.
• Turn on `auditd` and ship logs off-host.
• Schedule a recurring OpenSCAP or Lynis audit — not a one-time run.
• Document exceptions to the baseline, with a named owner and a review date.

Sources & References

1. CIS Ubuntu Linux Benchmark — Center for Internet Security
2. NIST SP 800-123, Guide to General Server Security — NIST CSRC
3. Cross-Sector Cybersecurity Performance Goals — CISA
4. CIS Critical Security Controls v8 — Control 4 — Center for Internet Security
5. Hardening automation for CIS benchmarks — Ubuntu / Canonical