UBUNTU18 CIS

Konfigurieren Sie eine Ubuntu18-Maschine, um CIS konform zu sein.

Basierend auf CIS Ubuntu1804 Benchmark v2.1.0

Unterstützung gesucht?

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.

Vorsicht(en)

Dieses Rollenskript wird Änderungen am System vornehmen, die unbeabsichtigte Folgen haben können. Es handelt sich nicht um ein Auditing-Tool, sondern um ein Korrektur-Tool, das nach einem durchgeführten 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 UBUNTU18-CIS-Audit-Rolle oder ein Compliance-Scanner sollten für die Compliance-Prüfung 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 notwendige spezifische Änderungen.

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

Sicherheitslevel für CIS anpassen

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 im Standard festgelegten Kontrollen müssen ebenfalls dies widerspiegeln, da dies die Tests steuert, die durchgeführt werden, wenn Sie die Audit-Komponente verwenden.

Ab Version zuvor kommen

CIS-Releases enthalten immer Änderungen. Es wird 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 jetzt kompatibel mit Python3, wenn es als Standard-Interpreter gefunden wird. Es gibt jedoch Voraussetzungen, die das System entsprechend konfigurieren.

Weitere Einzelheiten finden Sie im Changelog

Auditing (neu)

Dies kann innerhalb der Datei defaults/main.yml mit der Variable run_audit ein- oder ausgeschaltet werden. Standardmäßig ist der Wert falsch. Bitte beachten Sie das Wiki für weitere Details. Die Datei mit den Standardeinstellungen füllt auch die Goss-Prüfungen 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 immer möglich) der Konformität der Konfiguration und der laufenden Einstellungen.

Eine neue Form des Audits wurde entwickelt, indem ein kleines (12 MB) Go-Binary namens goss zusammen mit den relevanten Konfigurationen zur Überprüfung verwendet wurde. Dies erfordert keine Infrastruktur oder andere Tools. Dieses Audit überprüft nicht nur, ob die Konfiguration die richtige Einstellung hat, sondern zielt darauf ab festzustellen, ob sie auch mit dieser Konfiguration läuft, um falsche Positivmeldungen zu vermeiden.

Siehe UBUNTU18-CIS-Audit.

Beispiel-Audit-Zusammenfassung

Dies basiert auf einem Vagrant-Image mit aktivierten Auswahlmöglichkeiten, z. B. ohne GUI oder Firewall. Hinweis: Während des Audits werden mehr Tests durchgeführt, da wir Konfiguration und laufenden Zustand überprüfen.

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

SPIELRÜCKBLICK *******************************************************************************************************************************************
default                    : ok=270  geändert=23   unerreichbar=0    fehlgeschlagen=0    übersprungen=140  gerettet=0    ignoriert=0

Dokumentation

• Read The Docs
• Erste Schritte
• Anpassen von Rollen
• Pro-Host-Konfiguration
• Das Beste aus der Rolle herausholen

Anforderungen

Allgemein:

• Grundkenntnisse in Ansible. Hier sind 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, das installiert, konfiguriert und in Betrieb ist. Dies umfasst alle grundlegenden Ansible/Tower-Konfigurationen, benötigte Pakete und die Infrastruktur.

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

Technische Abhängigkeiten:

• Zugriff zum Herunterladen oder Hinzufügen der goss-Binärdatei und Inhalte zum System, falls Auditing verwendet wird (andere Optionen sind verfügbar, um den Inhalt zum System zu bringen).
• Python3
• Ansible 2.10.1+
• python-def
• libselinux-python

Rollenvariablen

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

Tags

Es gibt viele Tags, um eine genauere Steuerung zu ermöglichen. Jede Kontrolle hat ihren eigenen Satz von Tags, die das Level, ob sie bewertet wird oder nicht, welches Betriebssystemelement sie betrifft, ob es sich um einen Patch oder ein Audit handelt, und die Regelnummer angeben.

Nachfolgend 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 "services" übersprungen werden, wird diese Aufgabe übersprungen. Das Gegenteil kann auch geschehen, wenn Sie nur Kontrollen ausführen, die mit "services" gekennzeichnet sind.

      tags:
      - level1-server
      - level1-workstation
      - bewertet
      - 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 mit GPG signiert haben.
• Alle Community-Pull-Anfragen werden in den Entwicklungs-Branch aufgenommen.
• Pull-Anfragen in den Entwicklungs-Branch bestätigen, dass Ihre Commits eine GPG-Signatur, eine Unterschrift und einen funktionalen Test haben, bevor sie genehmigt werden.
• Sobald Ihre Änderungen zusammengeführt werden und eine detailliertere Überprüfung erfolgt ist, wird ein autorisiertes Mitglied Ihre Änderungen in den Hauptzweig für ein neues Release zusammenführen.

Bekannte Probleme

cloud0init - aufgrund eines Fehlers funktioniert dies nicht, wenn noexec zu /var hinzugefügt wird. ubtu18cis_rule_1_1_3_3

bug 1839899

Pipeline-Tests

verwendet:

• ansible-core 2.16
• Ansible-Kollektionen - zieht die neueste Version basierend auf der Anforderungen-Datei
• führt das Audit unter Verwendung des Entwicklungs-Branches durch
• Dies ist ein automatisierter Test, der bei Pull-Anfragen in den Entwicklungs-Branch erfolgt.

Zusätzliche Extras

• pre-commit kann getestet und innerhalb des Verzeichnisses ausgeführt werden.

pre-commit run