RHEL 8 CIS

Konfigurieren Sie eine RHEL/Rocky/AlmaLinux 8 Maschine für die CIS Konformität

Basierend auf CIS RedHat Enterprise Linux 8 Benchmark v3.0.0 - 11-10-2023

Unterstützung benötigt?

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 chatten.

Vorsichtsmaßnahmen

Diese Rolle wird Änderungen am System vornehmen, die unbeabsichtigte Folgen haben können. Dies ist kein Auditing-Tool, sondern ein Remediations-Tool, das nach einer durchgeführten Prüfung verwendet werden soll.

• Tests sind das Wichtigste, was Sie tun können.

• Überprüfungsmodus wird nicht unterstützt! Die Rolle wird im Überprüfungsmodus ohne Fehler abgeschlossen, aber sie wird 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 Überprüfungsmodus verwendet werden.

• Diese Rolle wurde für eine saubere Installation des Betriebssystems entwickelt. Wenn Sie sie an einem bestehenden System implementieren, überprüfen Sie bitte diese Rolle auf erforderliche spezifische Änderungen.

• Um die Version zu verwenden, weisen Sie bitte auf den Hauptbranch und das entsprechende Release/Tag für den CIS-Benchmark hin, mit dem Sie arbeiten möchten.

• Wenn Sie zwischen Hauptversionen wechseln, z.B. v2.0.0 - v3.0.0, gibt es erhebliche Änderungen an den Benchmarks und Kontrollen. Es wird empfohlen, als neuer Standard zu beginnen, anstatt ein Upgrade durchzuführen.

• Container verweisen auf vars/is_container.yml; dies ist ein Beispiel und muss gemäß Ihren Anforderungen aktualisiert werden.

• Haben wir das Testen erwähnt??

Sicherheitslevel für CIS abstimmen

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

• level1_server
• level1_workstation
• level2_server
• level2_workstation

Die Kontrolle, die in den Standardwerten erwähnt wird, muss ebenfalls dies widerspiegeln, da diese Kontrolle das Testen ist, das erfolgt, wenn Sie die Audit-Komponente verwenden.

Wechsel von einer früheren Version

CIS-Versionen enthalten immer Änderungen. Es wird dringend empfohlen, die neuen Referenzen und verfügbaren Variablen zu überprüfen. Diese haben sich seit der ersten Veröffentlichung von ansible-lockdown erheblich geändert. Dies ist jetzt kompatibel mit python3, wenn es als Standard-Interpreter gefunden wird. Dies kommt mit Voraussetzungen, die das System entsprechend konfigurieren.

Weitere Details finden Sie im Changelog

Auditing (neu)

Dies kann innerhalb der defaults/main.yml-Datei mit der Variable rhel8cis_run_audit aktiviert oder deaktiviert werden. Der Standardwert ist falsch, bitte beachten Sie das Wiki für weitere Details. 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 viel schnellere, sehr leichte Überprüfung (wo möglich), um die Konformität der Konfiguration und der laufenden Einstellungen zu überprüfen.

Eine neue Form des Audits wurde entwickelt, indem ein kleines (12 MB) Go-Programm namens goss zusammen mit den entsprechenden Konfigurationen verwendet wurde, um die Überprüfung durchzuführen. Dies geschieht ohne die Notwendigkeit von Infrastruktur oder anderen Werkzeugen. Dieses Audit überprüft nicht nur, ob die Konfiguration die richtigen Einstellungen hat, sondern zielt auch darauf ab festzustellen, ob es mit dieser Konfiguration läuft, während es versucht, falsche Positivmeldungen im Prozess auszuschließen.

Referenz zu RHEL8-CIS-Audit.

Beispiel Audit-Zusammenfassung

Dies basiert auf einem Vagrant-Image mit aktivierten Auswahlmöglichkeiten, z.B. ohne GUI oder Firewall. Hinweis: Weitere Tests werden während der Prüfung durchgeführt, da wir die Konfiguration und den laufenden Zustand überprüfen.

ok: [default] => {
    "msg": [
        "Die Ergebnisse vor der Behebung sind: ['Gesamtdauer: 5.454s', 'Anzahl: 338, Fehlgeschlagen: 47, Übersprungen: 5'].",
        "Die Ergebnisse nach der Behebung sind: ['Gesamtdauer: 5.007s', 'Anzahl: 338, Fehlgeschlagen: 46, Übersprungen: 5'].",
        "Eine vollständige Aufschlüsselung finden Sie in /var/tmp",
        ""
    ]
}

SPIEL-ZUSAMMENFASSUNG *******************************************************************************************************************************************
default                    : ok=270  geändert=23   unerreichbar=0    fehlgeschlagen=0    übersprungen=140  gerettet=0    ignoriert=0

Dokumentation

• Lies Die Docs
• Erste Schritte
• Rollen anpassen
• Per-Host-Konfiguration
• Das Beste aus der Rolle herausholen

Anforderungen

Allgemein:

• Grundkenntnisse in Ansible, unten finden Sie einige Links zur Ansible-Dokumentation, um Ihnen den Einstieg zu erleichtern, falls Sie mit Ansible nicht vertraut sind:

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

• Funktionierendes Ansible und/oder Tower, installiert, konfiguriert und läuft. Dazu gehören alle Basisconfigurationen von Ansible/Tower, die erforderlichen Pakete installiert und die Infrastruktur eingerichtet.

• Bitte lesen Sie die Aufgaben in dieser Rolle, um ein Verständnis dafür zu gewinnen, was jede Kontrolle tut. Einige Aufgaben sind störend und können unbeabsichtigte Folgen in einem aktiven Produktionssystem haben. Machen Sie sich auch mit den Variablen in der defaults/main.yml-Datei vertraut.

Technische Abhängigkeiten:

RHEL/AlmaLinux/Rocky/Oracle 8 - Andere Versionen werden nicht unterstützt.

• AlmaLinux/Rocky wurde auf 8.8 getestet (Aktivierung von Crypto (Abschnitte 1.10 & 1.11) verhindert Updates oder Installationen: 1. Juli 2021)
• Zugriff zum Herunterladen oder Hinzufügen des Goss-Binärprogramms und des Inhalts zum System, wenn Auditing verwendet wird (es gibt andere Möglichkeiten, den Inhalt auf das System zu bringen).
• Python3.8
• Ansible 2.11+
• python-def (sollte in RHEL 8 enthalten sein)
• libselinux-python

Rollenvorlagen

Diese Rolle ist so gestaltet, dass der Endbenutzer die Aufgaben selbst nicht bearbeiten muss. Alle Anpassungen sollten über die defaults/main.yml-Datei oder mit zusätzlichen Variablen innerhalb des Projekts, Jobs, Workflows usw. erfolgen.

Tags

Es gibt viele Tags für eine zusätzliche Kontrollgenauigkeit. Jede Kontrolle hat ihr eigenes Set von Tags, die angeben, auf welchem Level sie sich befindet, ob sie bewertet oder nicht bewertet ist, auf welches Betriebssystemelement sie sich bezieht, ob es sich um einen Patch oder ein Audit handelt und die Regelnummer.

Im Folgenden ist ein Beispiel des Tags-Abschnitts aus einer Kontrolle innerhalb dieser Rolle zu sehen. Mit diesem Beispiel, wenn Sie Ihre Ausführung so einstellen, dass alle Kontrollen mit dem Tag "services" übersprungen werden, wird diese Aufgabe übersprungen. Das Gegenteil kann auch passieren, wenn Sie nur Kontrollen ausführen, die mit "services" gekennzeichnet sind.

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

Community-Beitrag

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

• Ihre Arbeit erfolgt in Ihrem eigenen individuellen branch. Stellen Sie sicher, dass Sie alle Commits, die Sie zusammenführen möchten, signiert und GPG-signiert haben.
• Alle Pull-Requests der Community werden in den devel-branch aufgenommen.
• Pull-Requests in devel erfordern Ihre Commits mit einer GPG-Signatur, signiert und einen funktionalen Test, bevor sie genehmigt werden.
• Nachdem Ihre Änderungen zusammengeführt wurden und eine detailliertere Überprüfung abgeschlossen ist, wird ein autorisierter Benutzer Ihre Änderungen in den Hauptbranch für ein neues Release zusammenführen.

Bekannte Probleme

cloud0init - aufgrund eines Fehlers wird dies nicht mehr funktionieren, wenn noexec zu /var hinzugefügt wird. rhel8cis_rule_1_1_3_3

Fehler 1839899

Almalinux BaseOS, EPEL und viele Cloud-Provider-Repositories erlauben kein repo_gpgcheck gemäß Regel_1.2.3. Dies wird während des Playbooks Probleme verursachen, es sei denn, es wird ein Workaround gefunden.

Pipeline-Tests

verwendet:

• ansible-core 2.12
• ansible-Collections - zieht die neueste Version basierend auf der Anforderungen-Datei.
• führt das Audit mit dem devel-branch aus.
• Dies ist ein automatischer Test, der bei Pull-Requests in devel erfolgt.

Lokale Tests

Molecule kann verwendet werden, um an dieser Rolle zu arbeiten und in unterschiedlichen Szenarien zu testen.

Beispiele

molecule test -s default
molecule converge -s wsl -- --check
molecule verify -s localhost

lokale Tests verwenden:

• ansible 2.13.3
• molecule 4.0.1
• molecule-docker 2.0.0
• molecule-podman 2.0.2
• molecule-vagrant 1.0.0
• molecule-azure 0.5.0

Zusätzliche Extras

• 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 riesiges Dankeschön und Anerkennung gilt den ursprünglichen Autoren und Maintainer: Josh Springer, Daniel Shepherd, Bas Meijeri, James Cassell, Mike Renfro, DFed, George Nalen, Mark Bolwell