Linux-Host mit OpenSCAP gegen eine Baseline prüfen

Ziel

Einen Linux-Host mit OpenSCAP gegen ein veröffentlichtes Sicherheitsprofil auswerten und einen Bericht erzeugen, der genau zeigt, welche Prüfungen bestanden, fehlgeschlagen oder nicht anwendbar sind.

Voraussetzungen

Root-Rechte sind erforderlich (ein Scan ohne Root kann viele der Dateien und Einstellungen, die die Regeln prüfen, nicht lesen). Auf Systemen der RHEL-Familie liefert das Paket openscap-scanner das Programm oscap, scap-security-guide liefert die Inhalte, darunter eine Data-Stream-Datei wie /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml (für andere Releases ssg-rhel8-ds.xml bzw. ssg-rhel10-ds.xml; den Dateinamen nicht raten, sondern das Verzeichnis auflisten). Andere Distributionen paketieren die Inhalte unter anderen Namen oder gar nicht. Das Projekt hiess ursprünglich SCAP Security Guide (SSG) und enthält pro unterstütztem Produkt eine Data-Stream-Datei.

Schritte

1. Die in einer Data-Stream-Datei verfügbaren Profile auflisten: oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml. Jedes Profil hat eine ID wie xccdf_org.ssgproject.content_profile_cis. Welche Profile vorhanden sind (CIS-Stufen, STIG, OSPP usw.), hängt von der Version der Inhalte ab; die ID daher aus dieser Ausgabe übernehmen.
2. Eine Auswertung gegen ein gewähltes Profil ausführen und dabei sowohl eine maschinenlesbare Ergebnisdatei als auch einen HTML-Bericht schreiben: oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis --results-arf arf.xml --report report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml. Die Manpage von oscap dokumentiert genau diese Form xccdf eval --profile PROFILE_ID ... --report REPORT_FILE. In Skripten ist zu beachten: oscap beendet sich mit Exit-Code 2, wenn der Scan abgeschlossen wurde, aber mindestens eine Regel fehlgeschlagen ist, und mit 1 bei einem tatsächlichen Fehler. Nicht jeden Exit-Code ungleich 0 als fehlerhaften Scan behandeln.
3. report.html öffnen (oder vom Host kopieren) und die Anzahl bestandener, fehlgeschlagener und nicht anwendbarer Regeln lesen, bevor etwas geändert wird.
4. Aus den Ergebnissen lässt sich ein Remediation-Skript erzeugen: oscap xccdf generate fix --fix-type bash --output fix.sh --result-id <id> arf.xml (oder --fix-type ansible). Jeden darin enthaltenen Befehl lesen – das Skript ist ein Ausgangspunkt und nicht dazu gedacht, es direkt in eine Shell zu leiten. Auf Produktionshosts oscap xccdf eval --remediate vermeiden: Es wendet während des Scans sämtliche Korrekturen des Profils an.
5. Nur die geprüften und freigegebenen Remediations anwenden und danach denselben Befehl oscap xccdf eval erneut ausführen, um zu bestätigen, dass die betreffenden Regeln nun bestanden werden.
6. Das datierte Paar arf.xml/report.html als Prüfnachweis für diesen Host und diese Profilversion aufbewahren.

Erwartetes Ergebnis

Ein Bericht, der jede Regel des gewählten Profils mit dem Status bestanden, fehlgeschlagen, nicht anwendbar oder Fehler aufführt und sich durch erneutes Ausführen desselben Befehls mit derselben Data-Stream-Datei reproduzieren lässt.

Grenzen und Prüfbasis

oscap meldet den Zustand eines Systems gegenüber den Prüfungen eines Profils; es garantiert nicht selbst, dass diese Prüfungen für eine bestimmte Workload angemessen sind. Vor der Remediation ist eine Prüfung nötig (siehe den Artikel zur CIS/STIG-Baseline). Nichts davon lässt sich mit einem einzelnen Befehl rückgängig machen: Jede Konfigurationsdatei, die oscap oder dessen Remediation verändert, vorher sichern, wie bei jeder anderen manuellen Änderung. Für einen Scan ist kein Neustart nötig; ein Remediation-Schritt kann je nach Änderung einen erfordern.