Ubuntu 22 CIS

Konfigurieren Sie eine Ubuntu 22-Maschine, um CIS konform zu sein

Basierend auf dem CIS Ubuntu Linux 22.04 LTS Benchmark v1.0.0 Release

Unterstützung gesucht?

Lockdown Enterprise

Ansible Unterstützung

Community

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

Vorsicht

Diese Rolle wird Änderungen am System vornehmen, die Probleme verursachen könnten. Dies ist kein Auditing-Tool, sondern ein Remediation-Tool, das nach einem durchgeführten Audit verwendet werden sollte.

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

Dokumentation

• Lese die Dokumente
• Erste Schritte
• Anpassen von Rollen
• Per-Host-Konfiguration
• Das Beste aus der Rolle herausholen

Anforderungen

Allgemein:

• Grundkenntnisse in Ansible, hier einige Links zur Ansible-Dokumentation, die Ihnen helfen, falls Sie mit Ansible nicht vertraut sind
  • Hauptdokumentationsseite von Ansible
  • Ansible Erste Schritte
  • Tower-Benutzerhandbuch
  • Ansible Community-Infos
• Funktionierendes Ansible und/oder Tower, installiert, konfiguriert und aktiv. Dazu gehören alle Grundkonfigurationen von Ansible/Tower, installierte benötigte Pakete und die Infrastruktur.
• Bitte lesen Sie die Aufgaben in dieser Rolle, um zu verstehen, was jede Kontrolle tut. Einige der Aufgaben können störend sein und unerwünschte Folgen in einem aktiven Produktionssystem haben. Machen Sie sich auch mit den Variablen in der Datei defaults/main.yml oder der Hauptvariablen-Wiki-Seite vertraut.

Technische Abhängigkeiten:

• Ausführendes Ansible/Tower-Setup (diese Rolle wird gegen Ansible-Version 2.12.1 und neuer getestet)
• Python3 Ansible-Laufzeitumgebung
• goss >= 0.4.4 (falls für das Audit verwendet)

Auditing (neu)

Dies kann in der Datei defaults/main.yml mit der Variablen run_audit ein- oder ausgeschaltet werden. Der Standardwert ist false, bitte beachten Sie das Wiki für weitere Informationen.

Dies ist eine viel schnellere, sehr leichte Überprüfung der Konformität der Konfiguration und der live/laufenden Einstellungen.

Eine neue Art des Audits wurde entwickelt, indem ein kleines (12MB) Go-Binary namens goss zusammen mit den relevanten Konfigurationen verwendet wird. Ohne die Notwendigkeit für Infrastruktur oder andere Tools. Dieses Audit wird nicht nur überprüfen, ob die Konfiguration die richtigen Einstellungen hat, sondern zielt auch darauf ab festzustellen, ob sie mit dieser Konfiguration ausgeführt wird, um falsche Positives zu minimieren.

Hier geht es zum UBUNTU22-CIS-Audit.

Weitere Audit-Dokumentationen finden Sie in Lese die Dokumente

Rollenvariablen

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

Zweige

• devel - Dies ist der Standardzweig und der aktive Entwicklungszweig. Pull-Anfragen der Community werden in diesen Zweig aufgenommen.
• main - Dies ist der Veröffentlichungszweig.
• reports - Dies ist ein geschützter Zweig für unsere Bewertungsberichte, hier sollte niemals Code eingegeben werden.
• gh-pages - Dies ist der GitHub-Seitenzweig.
• alle anderen Zweige - Einzelne Zweige von Community-Mitgliedern.

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, signiert und GPG-signiert haben.
• Alle Pull-Anfragen der Community werden in den Entwicklungszweig aufgenommen.
• Pull-Anfragen in den Entwicklungszweig bestätigen, dass Ihre Commits eine GPG-Signatur haben, signiert sind und ein funktionaler Test vor der Genehmigung durchgeführt wurde.
• Sobald Ihre Änderungen zusammengeführt wurden und eine detailliertere Überprüfung abgeschlossen ist, wird ein autorisiertes Mitglied Ihre Änderungen in den Hauptzweig für eine neue Veröffentlichung zusammenführen.

Pipeline-Tests

verwendet:

• ansible-core 2.12
• Ansible-Kollektionen - lädt die neueste Version basierend auf der Anforderungsdatei
• führt das Audit unter Verwendung des Entwicklungszweigs aus
• Dies ist ein automatischer Test, der bei Pull-Anfragen in den Entwicklungszweig auftritt.

Hinzugefügte Extras

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

pre-commit run