CIS Security Baseline: Linux Server Hardening Standard

CIS Benchmarks are consensus-based configuration standards maintained by cybersecurity experts worldwide, covering more than 25 product families. They include mainstream systems such as Ubuntu, Debian, Red Hat, Alibaba Cloud Linux, and Tencent Cloud, as well as common components like Docker, Kubernetes, NGINX, MySQL, and PostgreSQL. They turn "hardening" from an experience-driven activity into a checklist that can be compared, audited, and repeated.

What a CIS baseline is and how to choose

The core of a CIS baseline is a "configuration baseline", usually split into two tiers:

  • Level 1: recommended settings with a clear security impact and little effect on business; enable them by default.
  • Level 2: stronger security that may affect availability or performance; suitable for high-security and compliance scenarios.

Selection is based on: the operating system and distribution version (for example Ubuntu 22.04/24.04, RHEL 9) and the deployment form (physical, cloud instance, or container). Major cloud vendors typically offer baselines tailored to their platforms.

Common baseline items

A Linux server baseline typically covers:

  • Accounts and permissions: remove or lock unnecessary accounts, prohibit empty passwords, and enforce password policy and account lockout.
  • File system permissions: tighten permissions on sensitive files and directories and restrict SUID/SGID bits.
  • SSH configuration: disable root login and enable key authentication (see SSH Hardening).
  • Kernel and network: disable unnecessary services, harden sysctl network parameters, and deploy a Firewall with a default-deny policy.
  • Auditing and logging: enable auditd and system logging, integrated with Security Log Auditing.

Implementation steps

  1. Select a baseline version: download the CIS Benchmark matching your system (requires registration).
  2. Scan and assess: use CIS-CAT Pro or an open-source alternative to measure the current gap.
  3. Remediate: fix items in Level 1 then Level 2 order, validating major changes on a test machine first.
  4. Verify: rescan to confirm compliance rates and generate a report.
  5. Sustain: bake the baseline into initialization scripts with Ansible/Shell and include it in the new-server onboarding flow (see the Server Initialization Security Script).

CIS also offers CIS Hardened Images (pre-hardened images) and Build Kits that can significantly reduce manual configuration effort.

Concrete configuration snippets

On Ubuntu 22.04, several high-frequency baseline items map to concrete files. SSH hardening (SSH configuration baseline):

# /etc/ssh/sshd_config.d/hardening.conf
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
AllowUsers deploy

sysctl network hardening (kernel and network baseline):

# /etc/sysctl.d/99-hardening.conf
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv4.ip_forward = 0

Password policy (accounts and permissions baseline, PAM):

# /etc/pam.d/common-password — append
password requisite pam_pwquality.so retry=3 minlen=12 dcredit=-1 ucredit=-1

Audit rules (auditing and logging baseline):

# /etc/audit/rules.d/hardening.rules
-w /etc/passwd -p wa -k identity
-w /etc/ssh/sshd_config -p wa -k sshd_config
-a always,exit -F arch=b64 -S execve -k exec_events

Apply with sysctl --system and systemctl restart sshd auditd, then rescan. When changing items one by one, back up the original file and validate on a test machine first so you never break a production box.

Why common baseline items are hardened that way

A few high-frequency items show the logic behind the baseline:

  • Password policy and lockout: minimum length, maximum age, and failure lockout reduce weak-password and brute-force risk; pair it with two-factor authentication for stronger results.
  • SUID/SGID management: audit and remove unneeded privilege bits to shrink local privilege-escalation paths.
  • sysctl network parameters: disable IP forwarding (outside gateways) and source routing, and enable reverse-path filtering to shrink the network attack surface.
  • Service minimization: remove or disable unused services and packages to reduce potential vulnerability entry points.
  • auditd auditing: record key file and login events to provide an evidence chain for incident response.

A real hardening walkthrough

Say you just received a fresh Ubuntu 22.04 cloud instance and the target is Level 1. The process looks like this: run a CIS-CAT Pro Assessor scan to get a gap report (often a PDF running to tens of thousands of lines); remediate item by item — first low-impact changes like file permissions and audit rules, then anything with side effects, such as disabling password login only after confirming keys are in place; rescan and push compliance from an initial 60%-70% to above 95%; finally bake the fixes into an Ansible playbook as the default action for new-server onboarding. Once the flow is familiar, taking a bare machine from zero to baseline takes roughly half a day — far faster than manual item-by-item triage.

Reference scan command (CIS-CAT Pro):

java -jar CIS-CAT.jar assess -i -b profiles/Ubuntu_Linux_22.04-LTS-Benchmark-v2.0.0.xml -p Level_1

Higher compliance is not always better — some Level 2 items trade away availability. First decide whether the goal is a hard regulatory/audit requirement or an internal security bar, then pick the target level.

Baseline maintenance and version upgrades

A baseline is not a one-time action: re-assess after major OS upgrades, new software rollouts, and whenever CIS releases a new benchmark revision. Run a baseline inspection at least quarterly, and write "new servers must pass the baseline" into the onboarding flow so the security bar does not decay as the server fleet grows.

FAQ

No dedicated security staff — where should I start? Start with the Level 1 baseline for your system and cover the high-frequency items first: SSH, passwords, and auditing. Is CIS-CAT Pro mandatory/paid? For personal assessment, use the community edition or open-source alternatives like Lynis for initial checks; use the commercial edition for formal compliance audits. Are cloud vendor images already secure? Most are only minimally configured — you still need to verify each baseline item. How often should I rescan? After every version upgrade and major software change, and at least quarterly.

16IDC Observation

For sites without a dedicated security team, the biggest value of a CIS baseline is turning "I do not know where to start" into "tick items off a checklist". Make it the default action for server onboarding and periodic inspection, and combine it with Vulnerability Scanning for a "configuration baseline plus continuous vulnerability management" double safeguard. Browse more options back in the Security Hardening category.

References: CIS Benchmarks official https://www.cisecurity.org/cis-benchmarks; CIS-CAT Pro Assessor https://www.cisecurity.org/cybersecurity-tools/cis-cat-pro/cis-cat-pro-assessor; CIS Workbench (registration required to download benchmarks) https://workbench.cisecurity.org/