RHEL 8 DISA STIG

Konfigurieren eines RHEL8-Systems zur Einhaltung des Disa STIG

Dieses Projekt basiert auf dem RHEL 8 DISA STIG: Version 1, Rel 13 veröffentlicht am 24. Januar 2024.

Unterstützung gesucht?

Lockdown Enterprise

Ansible Unterstützung

Community

In unserem Discord-Server können Sie Fragen stellen, Funktionen diskutieren oder einfach mit anderen Ansible-Lockdown-Nutzern plaudern.

Konfigurieren Sie ein RHEL/Rocky 8-System, das DISA STIG konform ist. Nicht störende CAT I, CAT II und CAT III Ergebnisse werden standardmäßig behoben. Die Behebung störender Ergebnisse kann aktiviert werden, indem rhel8stig_disruption_high auf true gesetzt wird.

Aktualisierung

Bei einer vorherigen Version.

Wie bei allen Versionen und Updates wird empfohlen, die Kontrollen zu testen und anzupassen. Es gibt Aktualisierungen und ID-Referenzänderungen gemäß der STIG-Dokumentation.

Prüfung

Dies kann im defaults/main.yml-Datei mit der Variable rhel7cis_run_audit aktiviert oder deaktiviert werden. Der Standardwert ist false. Weitere Details finden Sie im Wiki. Die Standarddatei füllt auch die Goss-Checks aus, um nur die Kontrollen zu überprüfen, die in der Ansible-Rolle aktiviert wurden.

Dies ist eine schnelle, sehr leichte Überprüfung (wo möglich) der Compliance mit den Konfigurationen und der aktuellen/running Einstellungen.

Eine Form der Prüfung wurde entwickelt, indem ein kleines (12MB) Go-Binary namens goss zusammen mit den relevanten Konfigurationen verwendet wurde. Dies ist ohne die Notwendigkeit für Infrastruktur oder andere Werkzeuge möglich. Diese Prüfung überprüft nicht nur, ob die Konfiguration die richtigen Einstellungen hat, sondern versucht auch zu erfassen, ob sie mit dieser Konfiguration funktioniert, während falsche Positive vermieden werden.

Dokumentation

• Lesen Sie die Dokumente
• Erste Schritte
• Rollen anpassen
• Pro Host-Konfiguration
• Das Beste aus der Rolle herausholen

Anforderungen

• RHEL/Rocky/AlmaLinux/OL 8 - Andere Versionen werden nicht unterstützt.
• Andere Betriebssysteme können getestet werden, indem der skip_os_check auf true gesetzt wird.
• Zugriff auf das Herunterladen oder Hinzufügen des Goss-Binaries und dessen Inhalt zum System, wenn die Prüfung verwendet wird. Es gibt Optionen, wie der Inhalt auf das System gelangt.

Abhängigkeiten

Die folgenden Pakete müssen auf dem steuernden Host/Host installiert sein, auf dem Ansible ausgeführt wird:

• python2-passlib (oder einfach passlib, wenn Python3 verwendet wird)
• python-lxml

Die Pakete python(2)-passlib sind für Aufgaben mit benutzerdefinierten Filtern oder Modulen erforderlich. Diese sind auf dem Controller-Host erforderlich, der Ansible ausführt.

Rollenvariablen

Diese Rolle wurde so entworfen, dass der Endbenutzer die Aufgaben selbst nicht bearbeiten muss. Alle Anpassungen sollten über die defaults/main.yml-Datei oder mit zusätzlichen Variablen im Projekt, Job, Workflow usw. erfolgen.

Tags

Es gibt viele Tags für eine präzisere Steuerung. Jede Kontrolle hat ihre eigenen Tags, die die Kontrolnummer sowie die Teile des Systems angeben, die diese Kontrolle betreffen.

Hier ist ein Beispiel des Tag-Bereichs aus einer Kontrolle innerhalb dieser Rolle. Wenn Sie in diesem Beispiel Ihre Ausführung so einstellen, dass alle Kontrollen mit dem Tag ssh übersprungen werden, wird diese Aufgabe übersprungen. Umgekehrt können Sie auch nur Kontrollen ausführen, die mit ssh gekennzeichnet sind.

tags:
    - RHEL-08-010050
    - ssh
    - dod_logon_banner

Beispiel Prüfungszusammenfassung

Dies basiert auf einem Vagrant-Image mit aktivierten Auswahlmöglichkeiten, z.B. kein GUI oder Firewall. Hinweis: Mehr Tests werden während der Prüfung ausgeführt, da wir den Konfigurations- und Betriebsstatus überprüfen.

ok: [rocky8_efi] =>
  msg:
  - 'Die Ergebnisse vor der Behebung sind: Anzahl: 804, Fehlgeschlagen: 416, Dauer: 6.488s.'
  - 'Die Ergebnisse nach der Behebung sind: Anzahl: 804, Fehlgeschlagen: 28, Dauer: 68.687s.'
  - Eine vollständige Aufschlüsselung finden Sie in /opt

SPIEL-ZUSAMMENFASSUNG **************************************************************************************************************
rocky8_efi                 : ok=482  geändert=269  unerreichbar=0    fehlgeschlagen=0    übersprungen=207  gerettet=0    ignoriert=0

Zweige

• devel - Dies ist der Standardzweig und der Arbeitsentwicklungszweig. Community-Pull-Anfragen werden in diesen Zweig gezogen.
• main - Dies ist der Release-Zweig.
• reports - Dies ist ein geschützter Zweig für unsere Bewertungsberichte, hier sollte nie Code eingefügt werden.
• gh_pages - GitHub-Seiten.
• alle anderen Zweige - Individuelle Zweige der Community-Mitglieder.

Container - Tests

• system_is_container

Dies wird standardmäßig in defaults/main.yml auf false gesetzt. Wenn festgestellt wird, dass es sich um einen Container-Typ handelt oder ansible_connection == docker, wird es auf true gesetzt. Einige Kontrollen werden übersprungen, wenn dies wahr ist, da sie nicht zutreffend sind. Andere führen eine Teilmenge von Kontrollen aus, die in vars/is_container.yml basierend auf einem vom Anbieter bereitgestellten unveränderten Image gefunden werden.

UNVERÄNDERTES VENDOR IMAGE.

• container_vars_file: is_container.yml

Diese Variablen-Datei gruppiert die Kontrollen in Tags, sodass, wenn der Container später ssh hat, dies durch Laden einer alternativen Variablen-Datei wieder aktiviert werden kann.

Community-Beitrag

Wir ermutigen Sie (die Community), zu dieser Rolle beizutragen. Bitte lesen Sie die folgenden Regeln.

• Ihre Arbeit erfolgt in Ihrem eigenen individuellen Zweig. Stellen Sie sicher, dass Sie alle Commits, die Sie zusammenführen möchten, signieren und mit GPG signieren.
• Alle Community-Pull-Anfragen werden in den Entwicklungszweig gezogen.
• Pull-Anfragen in devel bestätigen, dass Ihre Commits ein GPG-Signatur, ein Sign-off und einen funktionalen Test haben, bevor sie genehmigt werden.
• Sobald Ihre Änderungen zusammengeführt und einer detaillierteren Überprüfung unterzogen wurden, wird ein autorisiertes Mitglied Ihre Änderungen in den Hauptzweig für eine neue Version zusammenführen.

Pipeline-Tests

Verwendet:

• ansible-core 2.12
• Ansible-Sammlungen - zieht die neueste Version basierend auf der Anforderungsliste
• führt die Prüfung unter Verwendung des Entwicklungszweigs aus
• Dies ist ein automatisierter Test, der bei Pull-Anfragen in den Entwicklungszweig erfolgt.

Bekannte Probleme

Wenn Sie die STIG-Regel RHEL-08-040134 anwenden,

wird dies cloud init betreffen, wie in Bug 1839899 beschrieben.

Unterstützung

Dies ist ein Gemeinschaftsprojekt und wird entsprechend verwaltet.

Wenn Sie an dedizierter Unterstützung interessiert sind, um zu helfen oder maßgeschneiderte Setups bereitzustellen,

• Ansible Counselor
• Testen Sie uns

Credits

Dieses Repository stammt von der Arbeit von Sam Doran.

Zusätzliche Extras

• makefile - dies dient rein für Test- und Einrichtungszwecke.
• pre-commit kann getestet und innerhalb des Verzeichnisses ausgeführt werden.

pre-commit run

Danksagungen

Ein großes Dankeschön an die fantastische Community und all ihre Mitglieder. Ein besonderer Dank geht an die ursprünglichen Autoren und Pflegepersonen.

Josh Springer, Daniel Shepherd, Bas Meijeri, James Cassell, Mike Renfro, DFed, George Nalen, Mark Bolwell