CIS Benchmark и system hardening (lynis, OpenSCAP)

Что такое CIS Benchmark

Center for Internet Security (CIS), некоммерческая организация, публикует Benchmark'и, guideline'ы по hardening для каждой платформы: RHEL 9, Ubuntu 22.04, Kubernetes, AWS, Docker, etc.

Benchmark, PDF на 800-1000 страниц с пронумерованными recommendations:

1.1.1.1 Ensure mounting of cramfs filesystems is disabled (Automated)

Profile: L1 Server, L1 Workstation

Description: ...

Rationale: ...

Audit: modprobe -n -v cramfs | grep "^install /bin/false"

Remediation: echo "install cramfs /bin/false" >> /etc/modprobe.d/cramfs.conf

Каждое recommendation: что проверить, зачем, как audit'ить, как remediate. Делятся на:

• L1 (Level 1), базовый, без ущерба для функциональности. Цель, большинство production-серверов.
• L2 (Level 2), параноидальный, может ломать legacy. Цель, high-security окружения.
• Server vs Workstation профили, разные приоритеты (например, X11 на сервере не нужен).
• Automated vs Manual, может ли scanner проверить автоматически.

Скачивать после регистрации на cisecurity.org. Бесплатно, лицензия на чтение/использование, не на rebrand.

Зачем

• Compliance: PCI-DSS, HIPAA, SOC 2 требуют какого-то baseline. CIS, самый понятный и широко принятый.
• Reduce attack surface: убрать SUID-биты с лишних бинарей, отключить ненужные сервисы, ограничить kernel-модули.
• Defense in depth: лежит между AppArmor/SELinux на уровне application и firewall на сети.

Альтернативные стандарты

Часто переплетаются: CIS → mapping → PCI control. Auditor хочет видеть Benchmark + результат scan'а.

lynis, quick audit

Bash-скрипт от CISOfy, запускается локально, оценивает hardening по сотне эвристик и выдаёт hardening-index (0-100):

sudo lynis audit system

# Hardening index : 67

# Tests performed : 263

# Plugins enabled : 0

Что проверяет: pam-конфиг, sudo-настройки, [[ssh-hardening|sshd]], firewall, mount-options, kernel-параметры, файлы с миром-write, устаревший софт.

Output даёт Suggestions и Warnings с привязкой к docs. Больше для разработчика-админа (быстро увидеть что не так) чем для compliance-отчёта.

# Только specific section

sudo lynis audit system --tests-from-group "kernel,filesystems"

# Cron для регулярного аудита

0 2 * * * /usr/sbin/lynis audit system --cronjob > /var/log/lynis.log

Минусы: subjective скор, не привязан к конкретному стандарту, bash-only (не remediate).

OpenSCAP, формальный compliance

Стандарт SCAP (Security Content Automation Protocol) от NIST: XML-формат для описания checks, configs, vulns. OpenSCAP open-source-имплементация.

Использует:

• XCCDF (eXtensible Configuration Checklist Description Format) , описание профиля (recommendation'ы)
• OVAL (Open Vulnerability Assessment Language), как проверять
• CPE (Common Platform Enumeration), на каких платформах

Готовые профили: scap-security-guide (SSG), RHEL/Ubuntu/Debian

• CIS / STIG / PCI / HIPAA маппинги.

# установка

dnf install scap-security-guide openscap-scanner

# список профилей

oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# audit по CIS L1 Server

oscap xccdf eval \

  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \

  --report /tmp/cis-report.html \

  --results /tmp/cis-results.xml \

  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Артефакт, HTML-отчёт с pass/fail по каждому правилу, и XML с машиночитаемыми результатами для compliance-системы.

Auto-remediate (с осторожностью)

OpenSCAP может сгенерить remediate-скрипт:

oscap xccdf generate fix \

  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \

  --output remediate.sh \

  /tmp/cis-results.xml

Никогда не запускать вслепую на проде. Прочитать скрипт глазами:

• Может перегенерить SSH-keys → отвалится текущий доступ
• Может ужесточить sudo → перестанут работать automation accounts
• Может включить SELinux → приложения, не подготовленные, упадут

Подход: stage (dev → staging → prod), исключать inappropriate правила, документировать exceptions.

ansible-lockdown, Ansible playbooks

Готовые Ansible-роли по CIS/STIG для разных дистро:

ansible-lockdown/RHEL9-CIS

ansible-lockdown/UBUNTU22-CIS

ansible-lockdown/RHEL9-STIG

Каждое правило, отдельный task с tag (rule_1.1.1.1). Можно включать/выключать pre-task'ами:

vars:

  rhel9cis_rule_1_1_1_1: true             # cramfs disable

  rhel9cis_rule_1_1_1_2: false            # squashfs - оставляем

  rhel9cis_firewall: nftables             # выбор firewall'а

Это production-ready способ применения CIS, версионируемый, идемпотентный, тестируемый. Combine с GitOps.

Что обязательно проверить (короткий список)

Если нет времени на полный CIS, минимум:

1. SSH, keys-only, no root login (см. ssh-hardening)
2. firewall, default-deny, allowlist (см. firewalld-vs-nftables)
3. sudo, не NOPASSWD по умолчанию, audit через [[auditd|auditd]]
4. PAM, pam_faillock (заменил deprecated pam_tally2), pam_pwquality (см. pam)
5. Mount-options, nodev/nosuid/noexec на /tmp, /dev/shm
6. Sysctl, kernel.kptr_restrict=1, kernel.dmesg_restrict=1, net.ipv4.conf.all.rp_filter=1
7. Kernel modules, disable unused (cramfs, freevxfs, jffs2, udf)
8. Auditd rules, execve, identity changes, file changes в /etc
9. Updates, unattended-upgrades хотя бы для security
10. Logging, централизованный syslog, retention 90+ дней

Container / Kubernetes hardening

CIS публикует отдельные Benchmark'и для:

• Docker, daemon-config, image-build, runtime
• Kubernetes, control-plane, node, RBAC, network
• EKS / GKE / AKS, cloud-specific

Tools:

• docker-bench-security, bash-скрипт по CIS Docker
• kube-bench (Aqua), CIS Kubernetes audit. Запускается как Job в кластере, выдаёт report
• kube-hunter, penetration-style сканер k8s

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

kubectl logs -l job-name=kube-bench

Drift и continuous compliance

Однократный hardening, не работает. Через месяц кто-то отключит rule, добавит SUID-bin, ослабит sudoers. Решение, continuous compliance:

• Cron lynis --cronjob или oscap ежедневно, alert при падении score ниже threshold
• Compliance-platform (Wazuh, Tenable, Rapid7) централизует
• GitOps инфраструктура, изменения только через PR

Когда что-то пошло не так

• oscap падает с timeout, медленный диск, или OVAL-content содержит full-fs scan. Можно --remediate исключать sections.
• Lynis выдаёт Hardening Index 30, это subjective. Не паниковать, читать по конкретным Suggestion-ам.
• После apply CIS-roli ssh не работает, typically выключен по ip-list. Использовать out-of-band console (IPMI/serial), откатиться через ansible.
• Auto-remediate сломал cron, частый случай: nodev,noexec на /tmp ломает скрипты, кладущие туда. Исключения через ansible skip_tags.
• Compliance scan не видит правило как fixed, изменение в runtime, но /etc/... config не обновлён. Scan'ит файл, не runtime-state.
• CIS требует Ensure /tmp is on separate partition, на cloud-инстансе с одним диском это painful. Альтернатива: bind-mount в systemd tmp.mount.
• STIG противоречит app-документации, частый кейс с proprietary-софтом. Документировать exception, делать compensating control.

Что не делать

• Не запускайте remediate вслепую на проде, всегда читать скрипт сначала
• Не гонитесь за 100% CIS, некоторые правила не применимы, documented exception > forced compliance
• Не делайте hardening разово, деградирует за месяцы без monitoring'а
• Не путайте audit и remediate, две разные операции, можно audit без modify