RHEL 9 CIS

Richten Sie eine RHEL 9 Maschine so ein, dass sie den CIS Standards entspricht.

Basierend auf dem CIS RedHat Enterprise Linux 9 Benchmark v1.0.0 - 30.11.2022

Suchen Sie Unterstützung?

Lockdown Enterprise

Ansible Unterstützung

Community

Treten Sie unserem Discord-Server bei, um Fragen zu stellen, Funktionen zu diskutieren oder einfach mit anderen Ansible-Lockdown-Nutzern zu plaudern.

Mitwirken

Probleme und Pull-Requests sind willkommen. Bitte stellen Sie sicher, dass alle Commits signiert und gpg-signiert sind. Siehe Beitragsrichtlinien

Vorsicht(en)

Diese Rolle wird Änderungen am System vornehmen, die unbeabsichtigte Folgen haben können. Dies ist kein Prüfwerkzeug, sondern ein Wiederherstellungstool, das nach einer Prüfung verwendet werden sollte.

Der Prüfmodus wird nicht unterstützt! Die Rolle wird im Prüfmodus ohne Fehler abgeschlossen, wird jedoch nicht unterstützt und sollte mit Vorsicht verwendet werden. Die RHEL8-CIS-Audit-Rolle oder ein Compliance-Scanner sollten für die Compliance-Prüfung im Prüfmodus verwendet werden.

Diese Rolle wurde gegen eine saubere Installation des Betriebssystems entwickelt. Wenn Sie dies auf einem vorhandenen System implementieren, überprüfen Sie bitte diese Rolle auf erforderliche spezifische Änderungen.

Um die Release-Version zu verwenden, verweisen Sie auf den main-Branch und das relevante Release für den CIS-Benchmark, mit dem Sie arbeiten möchten.

Übereinstimmung mit einem Sicherheitslevel für CIS

Es ist möglich, nur Kontrollen der Stufen 1 oder 2 für CIS auszuführen. Dies wird über Tags verwaltet:

• level1-server
• level1-workstation
• level2-server
• level2-workstation

Die Kontrolle, die im defaults-Hauptbereich gefunden wird, muss dies ebenfalls widerspiegeln, da diese Kontrolle der Test ist, der durchgeführt wird, wenn Sie die Prüfkomponente verwenden.

Von einer vorherigen Version kommend

Die CIS-Version enthält immer Änderungen. Es wird dringend empfohlen, die neuen Referenzen und verfügbaren Variablen zu überprüfen. Dies hat sich seit der ursprünglichen Veröffentlichung von ansible-lockdown erheblich geändert. Dies ist jetzt mit Python 3 kompatibel, sofern es als Standardinterpreter gefunden wird. Dies kommt mit Voraussetzungen, die das System entsprechend konfigurieren.

Weitere Einzelheiten sind im Changelog zu finden.

Prüfung (neu)

Dies kann in der Datei defaults/main.yml mit den Variablen setup_audit und run_audit ein- oder ausgeschaltet werden. Der Wert ist standardmäßig false. Bitte beziehen Sie sich auf das Wiki für weitere Einzelheiten. Die Standarddatei enthält auch die Goss-Checks, um nur die Kontrollen zu überprüfen, die in der Ansible-Rolle aktiviert sind.

Dies ist eine viel schnellere, sehr leichte Überprüfung (wo möglich) der Konformität von Konfigurationen und laufenden Einstellungen.

Eine neue Form der Prüfung wurde durch die Verwendung einer kleinen (12 MB) Go-Binärdatei namens goss zusammen mit den relevanten Konfigurationen entwickelt, um zu überprüfen, ohne dass Infrastruktur oder andere Werkzeuge erforderlich sind. Diese Prüfung wird nicht nur überprüfen, ob die Konfiguration die richtige Einstellung hat, sondern zielt auch darauf ab, zu erfassen, ob sie auch mit dieser Konfiguration läuft und versucht, falsche positive Ergebnisse im Prozess zu beseitigen.

Siehe RHEL9-CIS-Audit.

Dokumentation

• Lese Die Dokumentation
• Erste Schritte
• Anpassen von Rollen
• Pro-Host-Konfiguration
• Das Beste aus der Rolle herausholen

Anforderungen

RHEL 9 Almalinux 9 Rocky 9 OracleLinux 9

• Zugriff, um die Goss-Binärdatei und den Inhalt auf das System herunterzuladen oder hinzuzufügen, wenn die Prüfung verwendet wird (andere Optionen sind verfügbar, um den Inhalt auf das System zu bringen).

CentOS Stream - auch wenn dies allgemein funktioniert, wird es nicht unterstützt und erfordert die folgende Variablenänderung:

os_check: false

Allgemein:

• Grundkenntnisse in Ansible. Unten sind einige Links zur Ansible-Dokumentation, um Ihnen den Einstieg zu erleichtern, wenn Sie mit Ansible nicht vertraut sind.

  • Hauptseite der Ansible-Dokumentation
  • Ansible Erste Schritte
  • Tower-Benutzerhandbuch
  • Ansible Community Informationen

• Funktionsfähiges Ansible und/oder Tower installiert, konfiguriert und läuft. Dazu gehören alle Basis-Configurations von Ansible/Tower, benötigte Pakete installiert und Infrastruktur eingerichtet.

• Bitte lesen Sie die Aufgaben in dieser Rolle, um zu verstehen, was jede Kontrolle bewirken soll. Einige der Aufgaben sind störend und können unbeabsichtigte Konsequenzen in einem Live-Produktionssystem haben. Machen Sie sich auch mit den Variablen in der Datei defaults/main.yml vertraut.

Technische Abhängigkeiten:

• Python3
• Ansible 2.10+
• python-def (sollte in RHEL 9 enthalten sein)
• libselinux-python
• pip-Pakete
  • jmespath
• Sammlungen, die in collections/requirements.yml zu finden sind

pre-commit ist verfügbar, wenn es auf Ihrem Host für Pull-Request-Tests installiert ist.

Rollenvariablen

Diese Rolle ist so gestaltet, dass der Endbenutzer die Aufgaben selbst nicht bearbeiten muss. Alle Anpassungen sollten durch Überschreiben der erforderlichen Variablen in der Datei defaults/main.yml erfolgen, z.B. unter Verwendung von Inventory, group_vars, extra_vars.

Tags

Es gibt viele Tags für eine präzisere Steuerung. Jede Kontrolle hat ihr eigenes Set von Tags, die das Level, ob es punktiert/nicht punktiert ist, auf welches OS-Element es sich bezieht, ob es ein Patch oder ein Audit ist und die Regelnummer zeigen.

Unten finden Sie ein Beispiel des Tag-Bereichs aus einer Kontrolle innerhalb dieser Rolle. Mit diesem Beispiel können Sie, wenn Sie Ihre Ausführung so einstellen, dass alle Kontrollen mit dem Tag „services“ übersprungen werden, diese Aufgabe überspringen. Das Gegenteil kann auch passieren, indem Sie nur Kontrollen ausführen, die mit „services“ getaggt sind.

      tags:
      - level1-server
      - level1-workstation
      - punktiert
      - avahi
      - services
      - patch
      - rule_2.2.4

Community-Beitrag

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

• Ihre Arbeit erfolgt in Ihrem eigenen individuellen Branch. Stellen Sie sicher, dass Sie all Ihre Commits, die Sie zusammenführen möchten, signiert und GPG-signiert haben.
• Alle Community-Pull-Requests werden in den Entwicklungs-Branch aufgenommen.
• Pull-Requests in die Entwicklung bestätigen, dass Ihre Commits eine GPG-Signatur haben, signiert sind und einen funktionalen Test bestanden haben, bevor sie genehmigt werden.
• Nachdem Ihre Änderungen zusammengeführt wurden und eine detailliertere Überprüfung abgeschlossen ist, wird ein autorisiertes Mitglied Ihre Änderungen in den Hauptbranch für ein neues Release zusammenführen.

Bekannte Probleme

CIS 1.2.4 - repo_gpgcheck wird für RedHat-Hosts nicht durchgeführt, da die Standard-Repos diese Funktion nicht haben. Dies betrifft auch EPEL (nicht von der Variablen abgedeckt). - Rocky und Alma sind nicht betroffen. Verwenden Sie die Variable, um dies zu deaktivieren. rhel9cis_rhel_default_repo: true # auf false setzen, wenn Sie ein Repo verwenden, das diese Fähigkeit hat.

Pipeline-Test

Verwendet:

• ansible-core 2.12
• Ansible-Sammlungen - ruft die neueste Version basierend auf der Anforderungsdatei ab.
• Führt das Audit unter Verwendung des Entwicklungsbranches aus.
• Führt die pre-commit-Setup-Überprüfung bei Pull-Requests durch, um sicherzustellen, dass alles wie erwartet eingerichtet ist.
• Dies ist ein automatischer Test, der bei Pull-Requests in die Entwicklung erfolgt.

Lokaler Test

• Ansible

  • ansible-base 2.10.17 - python 3.8
  • ansible-core 2.13.4 - python 3.10
  • ansible-core 2.15.1 - python 3.11

Zusätzliche Extras

• makefile - dies dient ausschließlich Test- und Einrichtungszwecken.
• pre-commit kann getestet und innerhalb des Verzeichnisses ausgeführt werden.

pre-commit run

Danksagungen

Basierend auf einem ursprünglichen Konzept von Sam Doran.

Massiven Dank an die fantastische Community und all ihre Mitglieder.

Ein besonderer Dank und Anerkennung gebührt den ursprünglichen Autoren und Betreuern.

Mark Bolwell, George Nalen, Steve Williams, Fred Witty