# CIS/STIG-Mapping der `os_hardening`-Rolle

Diese Rolle deckt eine bewusst ausgewählte, für einen dedizierten Jumphost
(Debian/Ubuntu-Familie) relevante Teilmenge der CIS Debian/Ubuntu Linux
Benchmarks sowie einzelner DISA-STIG-typischer Controls ab. Sie ist **kein**
vollständiger, zertifizierter Benchmark-Lauf — dafür fehlt ein automatisiertes
Compliance-Scanning-Tool. Empfehlung: nach dem Rollout zusätzlich mit
`oscap xccdf eval` (OpenSCAP) gegen das jeweils zutreffende Profil prüfen und
diese Tabelle bei Abweichungen als Startpunkt für die Nacharbeit nutzen.

Referenz-Control-IDs folgen der CIS-Nummerierung *sinngemäß* (Benchmark-Version
kann je nach Debian/Ubuntu-Release leicht abweichen); wo passend ist zusätzlich
vermerkt, wenn ein Control STIG-typisch, aber nicht CIS-nummeriert ist.

| Bereich | CIS-Control (sinngemäß) | Umsetzung | Status |
|---|---|---|---|
| Unsichere Legacy-Dienste | 2.1.x | `tasks/packages.yml` | Implementiert |
| Automatische Sicherheitsupdates | 1.9 | `tasks/packages.yml` | Implementiert |
| Deaktivierung seltener Dateisystemtreiber | 1.1.1.1–1.1.1.8 | `tasks/kernel_modules.yml` | Implementiert |
| Deaktivierung seltener Netzwerkprotokolle | 3.4.1–3.4.4 | `tasks/kernel_modules.yml` | Implementiert |
| USB-Speichermedien deaktivieren | 1.1.23 | `tasks/kernel_modules.yml` | Implementiert |
| Netzwerk-/Kernel-sysctl-Härtung | 3.x, 1.5.x | `tasks/sysctl.yml` | Implementiert |
| Core Dumps deaktivieren | 1.5.1 | `tasks/sysctl.yml` | Implementiert |
| `/tmp`, `/dev/shm` mit noexec/nosuid/nodev | 1.1.2.x | `tasks/mounts.yml` | **Best-Effort** — nur wirksam, wenn bereits eigene Mountpoints existieren (siehe unten) |
| Passwortqualität (Länge/Komplexität) | 5.4.1 | `tasks/pam_password_policy.yml` | Implementiert (lokale OS-Konten) |
| Account-Lockout (pam_faillock) | 5.3.1 | `tasks/pam_password_policy.yml` | Implementiert, siehe Einschränkung unten |
| Passwort-Historie | 5.4.2 | `tasks/pam_password_policy.yml` | Implementiert |
| Passwort-Ablauf (`login.defs`) | 5.4.1.1–5.4.1.4 | `tasks/pam_password_policy.yml` | Implementiert |
| Erweiterte auditd-Regeln (Identität, Zeit, Netzwerk, Logins, Kernelmodule) | 4.1.3–4.1.14 | `tasks/auditd.yml` | Implementiert |
| auditd-Log-Handling (keep_logs, space_left_action) | 4.1.2.3, 4.1.2.4 | `tasks/auditd.yml` | Implementiert |
| auditd unveränderlich (`-e 2`) | 4.1.1.4 (STIG) | `tasks/auditd.yml` | Implementiert, **standardmäßig deaktiviert** (Opt-in `os_hardening_auditd_immutable`, da Reboot zum Ändern nötig) |
| Datei-Integritäts-Monitoring (AIDE) | 1.4.1, 1.4.2 | `tasks/aide.yml` | Implementiert |
| Rootkit-Scanner (rkhunter, ergänzend) | STIG-typisch, nicht CIS-nummeriert | `tasks/rootkit_scan.yml` | Implementiert |
| Anmelde-Banner | STIG-typisch (Legal Notice) | `tasks/banners.yml`, `tasks/sshd.yml` | Implementiert |
| cron/at auf autorisierte Nutzer beschränken | 2.4.1.x | `tasks/cron_at.yml` | Implementiert |
| Berechtigungen kritischer Dateien (`/etc/shadow` etc.) | 6.1.x | `tasks/file_permissions.yml` | Implementiert |
| sudo-Logging (`log_input`, `log_output`, `use_pty`) | STIG-typisch | `tasks/file_permissions.yml` | Implementiert |
| `su` auf Gruppe `sudo` beschränken | 5.6 | `tasks/file_permissions.yml` | Implementiert |
| SSH-Daemon-Härtung (Ciphers/KEX/MACs, kein Root-Login, etc.) | 5.2.x | `tasks/sshd.yml` | Implementiert |
| IPv6 deaktivieren | 3.1.1 | `tasks/sysctl.yml` | Implementiert, **Opt-in** (`os_hardening_disable_ipv6`, Default aus) |

## Bewusst nicht automatisiert (mit Begründung)

| Bereich | CIS-Control (sinngemäß) | Warum nicht automatisiert |
|---|---|---|
| Getrenntes Partitionslayout (`/tmp`, `/var`, `/var/log`, `/var/log/audit`, `/home` als eigene Partitionen) | 1.1.1–1.1.1.30 | Erfordert eine Neupartitionierung der Festplatte — nur zum Zeitpunkt der OS-Installation sinnvoll setzbar, nicht nachträglich per Ansible auf ein laufendes System ohne Datenverlustrisiko. **Empfehlung:** beim Erstellen des Basis-Images/der VM-Vorlage bereits mit diesem Layout provisionieren. |
| Bootloader-Passwort (GRUB) | 1.4.1 (ältere CIS-Nummerierung) | Erfordert physischen/Konsolen-Zugriff zum Testen und ist bei Cloud-/Hypervisor-Images oft irrelevant oder sogar kontraproduktiv (verhindert automatisierten Neustart). Bewusst dem jeweiligen Betreiber überlassen. |
| Volltext-Festplattenverschlüsselung | Nicht CIS-nummeriert, STIG-typisch | Muss bei der OS-Installation eingerichtet werden (LUKS o.ä.), nicht nachträglich per Ansible. In Cloud-Umgebungen häufig durch Provider-seitige Verschlüsselung (z.B. verschlüsselte Volumes) abgedeckt — separat prüfen. |
| Physische Sicherheit / BIOS-UEFI-Passwort | Nicht CIS-nummeriert | Außerhalb der Reichweite von Ansible; organisatorische/physische Maßnahme. |
| Zentrales Log-Forwarding an SIEM/Syslog-Server | Nicht CIS-nummeriert, aber im Jumphost-Konzept Kap. 6.9 gefordert | Erfordert Kenntnis der Ziel-SIEM-Infrastruktur (Empfänger-Host, Protokoll, TLS-Zertifikate) — als eigener Konfigurationspunkt vorgesehen, aber nicht Teil dieser Rolle (siehe Konzept Kap. 6.9, Erweiterungspunkt). |
| Netzwerksegmentierung / Firewalling *zwischen* Zielsystemen | Außerhalb des Jumphost-Scopes | Betrifft die Netzwerkinfrastruktur rund um den Jumphost, nicht den Jumphost selbst — Bestandteil des übergeordneten Netzwerkkonzepts. |

## Bekannte Einschränkungen

- **`pam_faillock`-Einbindung** (`tasks/pam_password_policy.yml`) fügt einen
  Block direkt in `/etc/pam.d/common-auth` ein. Auf Systemen, die
  `pam-auth-update --force` als Teil eines anderen Automatisierungsschritts
  laufen lassen, kann dieser Block überschrieben werden. Für produktive
  Systeme mit häufigen PAM-Änderungen wird empfohlen, stattdessen ein
  eigenes `pam-auth-update`-Profil unter `/usr/share/pam-configs/` zu
  pflegen (sauberer, upgrade-fest) — hier aus Gründen der Nachvollziehbarkeit
  als direkter Block-Insert gehalten.
- **`/tmp`/`/dev/shm`-Remount** wirkt nur, wenn diese Pfade bereits eigene
  Mountpoints sind. Ist das nicht der Fall, gibt die Rolle eine Debug-Meldung
  aus, ändert aber nichts automatisch am Partitionslayout (siehe Tabelle oben).
- Diese Rolle wurde in dieser Session **nicht** gegen ein reales
  Debian/Ubuntu-System ausgeführt (kein Root-/Zielsystem verfügbar) — nur
  `ansible-playbook --syntax-check` sowie YAML-/Jinja2-Parsing wurden
  verifiziert (siehe README, Abschnitt „Was bewusst noch offen ist"). Ein
  `--check`-Lauf (Dry-Run) und ein realer Rollout-Test in einer
  Staging-Umgebung stehen vor dem Produktivbetrieb noch aus.