# CIS Benchmark и system hardening (lynis, OpenSCAP)

_Безопасность · LinuxLab Knowledge Base_

**TL;DR:** CIS Benchmark - стандарт hardening Linux. Lynis - быстрый локальный
audit со скором, OpenSCAP - формальный с XCCDF-профилями и SCAP-
репортом. ansible-lockdown - remediate. Audit и remediate раздельно.


## Что такое 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 Benchmark** | CIS (industry) | universal, основа compliance |
| **STIG** | DISA (US DoD) | гос-сектор США |
| **DISA SRG** | DISA | контейнеры, облако |
| **NIST SP 800-53** | NIST | high-level controls, не recipe |
| **PCI-DSS** | Card industry | где обрабатываются карты |

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

## lynis, quick audit

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

```bash
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-отчёта.

```bash
# Только 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 маппинги.

```bash
# установка
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-скрипт:

```bash
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'ами:

```yaml
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](/kb/ssh-hardening.md))
2. **firewall**, default-deny, allowlist (см. [firewalld-vs-nftables](/kb/firewalld-vs-nftables.md))
3. **sudo**, не NOPASSWD по умолчанию, audit через
   [[auditd|auditd]]
4. **PAM**, `pam_faillock` (заменил deprecated `pam_tally2`),
   `pam_pwquality` (см. [pam](/kb/pam.md))
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](/kb/unattended-upgrades.md) хотя бы для 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

```bash
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


## Команды

```bash
sudo lynis audit system
```
Полный audit ноды одной командой - hardening-index и список Suggestion

```bash
sudo lynis audit system --cronjob > /var/log/lynis.log
```
Non-interactive режим для cron - регулярный мониторинг

```bash
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
```
Список доступных профилей в SCAP-content для дистро

```bash
oscap xccdf eval --profile cis_server_l1 --report report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
```
Audit по CIS L1 Server профилю с HTML-отчётом для compliance-аудитора

```bash
ansible-playbook -i inventory rhel9cis.yml --tags level1-server --check
```
Dry-run remediate через ansible-lockdown - покажет что изменится

```bash
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml && kubectl logs -l job-name=kube-bench
```
kube-bench audit kubernetes-кластера по CIS K8s benchmark

```bash
find / -perm -4000 -type f 2>/dev/null
```
Все SUID-бинари в системе - быстрый audit лишних привилегий


## См. также

- [SSH hardening - закрытие сервера](/kb/ssh-hardening.md)
- [auditd - syscall и file audit](/kb/auditd.md)
- [SELinux policy - типы, домены, audit2allow](/kb/selinux-policy.md)
- [firewalld vs nftables - что выбрать](/kb/firewalld-vs-nftables.md)
- [PAM - Pluggable Authentication Modules](/kb/pam.md)