RHEL 7 CIS

Konfigurieren Sie eine RHEL/Centos 7 Maschine, um CIS konform zu sein

Basierend auf CIS RedHat Enterprise Linux 7 Benchmark v4.0.0 - 21-12-2023

Suchen Sie Unterstützung?

Lockdown Enterprise

Ansible Unterstützung

Gemeinschaft

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

Vorsicht

Diese Rolle wird Änderungen am System vornehmen, die unbeabsichtigte Konsequenzen haben können. Dies ist kein Auditing-Tool, sondern ein Werkzeug zur Behebung von Problemen, das nach einem Audit verwendet werden sollte.

Der Prüfmodus wird nicht unterstützt! Die Rolle wird im Prüfmodus ohne Fehler abgeschlossen, aber es wird nicht unterstützt und sollte mit Vorsicht verwendet werden. Die RHEL7-CIS-Auditrolle oder ein Compliance-Scanner sollten für die Compliance-Überprüfung über den Prüfmodus verwendet werden.

Diese Rolle wurde gegen eine saubere Installation des Betriebssystems entwickelt. Wenn Sie sie auf einem bestehenden System implementieren, überprüfen Sie bitte diese Rolle auf etwaige standortspezifische Änderungen, die erforderlich sind.

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

Sicherheitsstufen für CIS

Es ist möglich, nur die 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 in den Standardwerten des Hauptsystems gefundene Kontrolle muss ebenfalls dies widerspiegeln, da diese Kontrolle die Tests steuert, die durchgeführt werden, wenn Sie die Audit-Komponente verwenden.

Kommen von einer vorherigen 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 ursprünglichen Veröffentlichung von ansible-lockdown erheblich geändert. Dies ist nun mit Python 3 kompatibel, wenn es als Standard-Interpreter gefunden wird. Dies bringt einige Voraussetzungen mit sich, die das System entsprechend konfigurieren.

Weitere Details finden Sie im Changelog.

Auditing (neu)

Dies kann im defaults/main.yml-Datei mit der Variable rhel7cis_run_audit ein- oder ausgeschaltet werden. Der Standardwert ist false. Bitte beachten Sie das Wiki für weitere Informationen. Die Standarddatei befüllt auch die Goss-Überprüfungen, um nur die Kontrollen zu überprüfen, die in der Ansible-Rolle aktiviert wurden.

Dies ist eine viel schnellere, sehr leichtgewichtige Überprüfung (wo möglich), die die Konformität der Konfiguration und der laufenden Einstellungen überprüft.

Eine neue Form des Auditing wurde entwickelt, indem ein kleines (12MB) Go-Binary namens goss zusammen mit den relevanten Konfigurationen zur Überprüfung verwendet wurde. Dies geschieht ohne die Notwendigkeit von Infrastruktur oder anderen Werkzeugen. Dieses Audit überprüft nicht nur, ob die Konfiguration die richtige Einstellung hat, sondern zielt auch darauf ab, festzustellen, ob sie mit dieser Konfiguration läuft und dabei versucht, falsche Positiven zu vermeiden.

Dokumentation

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

Anforderungen

Allgemein:

• Grundkenntnisse in Ansible. Unten finden Sie einige Links zur Ansible-Dokumentation, die Ihnen beim Einstieg helfen, wenn Sie mit Ansible nicht vertraut sind.

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

• Funktionierende Ansible- und/oder Tower-Installation, konfiguriert und betriebsbereit. Dies umfasst alle grundlegenden Ansible/Tower-Konfigurationen, installierte benötigte Pakete und einrichtete Infrastruktur.

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

Technische Abhängigkeiten:

• Funktionsfähige Ansible/Tower-Installation (diese Rolle wurde gegen Ansible-Version 2.9.1 und neuer getestet)
• Python3 Ansible-Laufumgebung
• python-def (sollte in RHEL/CentOS 7 enthalten sein) - Die erste Aufgabe installiert die Voraussetzungen (Tag pre-reqs) für python3 und python2 (wo erforderlich)
  • libselinux-python
  • python3-rpm (Paket, das von py3 verwendet wird, um das rpm-Paket zu nutzen).

Rollenvariablen

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 zusätzliche Steuergenauigkeit. Jede Kontrolle hat ihr eigenes Set an Tags, die angeben, welches Niveau, ob es bewertet/nicht bewertet ist, welches Betriebssystemelement es betrifft, ob es ein Patch oder Audit ist und die Regelnummer.

Hier ist ein Beispiel für den Tag-Bereich aus einer Kontrolle innerhalb dieser Rolle. Wenn Sie in diesem Beispiel Ihre Ausführung so einstellen, dass alle Kontrollen mit dem Tag "services" übersprungen werden, wird diese Aufgabe übersprungen. Umgekehrt kann es auch passieren, dass Sie nur Kontrollen ausführen, die mit "services" getaggt sind.

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

Gemeinschaftsbeteiligung

Wir ermutigen Sie (die Gemeinschaft), zu dieser Rolle beizutragen. Bitte lesen Sie die untenstehenden Regeln.

• Ihre Arbeit erfolgt in Ihrem eigenen individuellen Branch. Stellen Sie sicher, dass alle Commits, die Sie zusammenführen möchten, signiert sind und ein GPG-Signatur aufweisen.
• Alle Community-Pull-Anfragen werden in den Entwicklungsbranch übernommen.
• Pull-Anfragen in die Entwicklung bestätigen, dass Ihre Commits eine GPG-Signatur haben, signiert sind und einer funktionalen Prüfung unterzogen wurden, bevor sie genehmigt werden.
• Sobald Ihre Änderungen zusammengeführt werden und eine detailliertere Überprüfung abgeschlossen ist, wird ein autorisiertes Mitglied Ihre Änderungen in den Hauptbranch für eine neue Veröffentlichung zusammenführen.

Pipeline-Tests

verwendet:

• ansible-core 2.12
• Ansible-Kollektionen - zieht die neueste Version basierend auf der Anforderungen-Datei
• führt das Audit unter Verwendung des Entwicklungsbranches aus
• Dies ist ein automatischer Test, der bei Pull-Anfragen in die Entwicklung erfolgt

Lokale Tests

• 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

Hinzugefügte Extras

• pre-commit kann getestet und aus dem Verzeichnis heraus ausgeführt werden.

pre-commit run

Danksagungen

Ein riesiges Dankeschön an die fantastische Gemeinschaft und all ihre Mitglieder.

Ein großer Dank und Anerkennung gilt den ursprünglichen Autoren und Betreuern.

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