72 lines
6.5 KiB
Markdown
72 lines
6.5 KiB
Markdown
# 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.
|