HarryHarcourt.ansible_rhel8_cis_benchmarks

HarryHarcourt.Ansible-RHEL8-CIS-Benchmarks

Alle Anerkennung geht an anthcourtney für das ursprüngliche Framework, das hier zu finden ist: https://github.com/anthcourtney/ansible-role-cis-amazon-linux

Diese Implementierung wurde für Red Hat Enterprise Linux 8.X und CentOS 8.X umgewandelt (Hinweis: noch nicht getestet).

Diese Implementierung wurde an vielen Stellen idempotent gemacht und bleibt es weiterhin.

Diese Implementierung ermöglicht das Aktivieren und Konfigurieren einiger Dienste.

Das CIS RHEL Linux Benchmark. https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_Enterprise_Linux_7_Benchmark_v2.1.1.pdf

Diese Rolle wurde entwickelt und getestet mit Red Hat Linux 8.0 unter Verwendung der AWS AMI: ami-079596bf7a949ddf8

Warum sollte ich diese Rolle verwenden?

Wenn Sie versuchen, die Compliance mit einem von der Industrie akzeptierten Sicherheitsstandard zu erreichen, wie PCI DSS, APRA oder ISO 27001, müssen Sie nachweisen, dass Sie dokumentierte Härtungsstandards auf alle Systeme im Prüfungsbereich angewendet haben.

Wenn Sie Red Hat Linux verwenden, versucht diese Rolle, ein Teil der Lösung für das Compliance-Puzzle bereitzustellen.

Hier gibt es Herausforderungen!

Wenn Sie in Erwägung ziehen, diese Rolle auf Server anzuwenden, sollten Sie eine grundlegende Vertrautheit mit dem CIS Benchmark (oder ähnlichen Benchmarks) haben und die Auswirkungen verstehen, die dies auf ein System haben kann.

Bitte nehmen Sie sich die Zeit, sich mit dem Standard und den konfigurierbaren Standardwerten vertraut zu machen und schließen Sie vor der Anwendung auf ein System alle Punkte aus, die nicht gelten.

Beispielhaft sollten die folgenden Punkte sofort auf die Ausschlussliste (oder zumindest zur Modifikation der betreffenden Standardwerte) gesetzt werden:

3.4.2 und 3.4.3, die standardmäßig den Zugriff auf den Host (einschließlich über ssh) nur auf localhost beschränken.

Beispiel-Playbook

Ein Beispiel-Playbook, das diese Rolle verwendet, sieht wie folgt aus:

---

- hosts: localhost
  connection: local
  gather_facts: true
  become: yes

  roles:
    - Ansible-RHEL8-CIS-Benchmarks

Ein fortgeschritteneres Beispiel, das Änderungen an den verwendeten Standardwerten sowie den Ausschluss einiger Punkte im Benchmark enthält, die für eine fiktive Umgebung als unnötig erachtet werden, sieht wie folgt aus:

---

- hosts: localhost
  connection: local
  gather_facts: true
  become: yes

  vars:
    cis_level_1_exclusions:
      - 5.4.4
      - 3.4.2
      - 3.4.3
      - 6.2.13   
    cis_pass_max_days: 45
    cis_umask_default: 002
 
  roles:
    - Ansible-RHEL8-CIS-Benchmarks

Hinweis: Die Verwendung von become: yes ist erforderlich, da 99 % der Aufgaben privilegierten Zugriff benötigen, um ausgeführt zu werden.

Rollenvariablen

Siehe defaults/main.yml für Variablen, die je nach Vorliebe überschrieben werden können.

Optionen

Tags (und Kombinationen davon) können verwendet werden, um ein bestimmtes Level des CIS-Standards, einen Abschnitt oder eine einzelne Empfehlung auszuführen. Zum Beispiel:

Führen Sie nur Level 1 Aufgaben aus

ansible-playbook playbook.yml -t level-1

Führen Sie nur Abschnitt 3 Aufgaben aus

ansible-playbook playbook.yml -t section-3

Führen Sie nur die Aufgaben 1.3.1 und 2.2.10 aus

ansible-playbook playbook.yml -t 1.3.1,2.2.10

Führen Sie nur bewertete Aufgaben aus

ansible-playbook playbook.yml -t scored

Einschränkungen

Derzeit sind nur die Level 1 Punkte des Benchmarks implementiert. Level 2 Punkte werden hinzukommen, sobald es die Zeit erlaubt.

Die folgenden Prüfungen wurden nicht implementiert:

3.6.2. Firewall-Regeln sind umgebungsspezifisch.
3.6.3. Firewall-Regeln sind umgebungsspezifisch.
3.6.4. Firewall-Regeln sind umgebungsspezifisch.
3.6.5. Firewall-Regeln sind umgebungsspezifisch.
4.2.1.2. Die Bestimmung, was protokolliert werden sollte und der Zielort der Nachrichten ist umgebungsspezifisch.
4.2.2.2. Die Bestimmung, was protokolliert werden sollte und der Zielort der Nachrichten ist umgebungsspezifisch.
4.2.2.3. Inline-Bearbeitung der syslog-ng-Konfigurationsdatei gilt als zu ungenau und wird am besten durch eine bereitgestellte Konfigurationsdatei gelöst, die dies und andere verwandte Anforderungen adressiert.
4.2.2.4. Inline-Bearbeitung der syslog-ng-Konfigurationsdatei gilt als zu ungenau und wird am besten durch eine bereitgestellte Konfigurationsdatei gelöst, die dies und andere verwandte Anforderungen adressiert.
4.2.2.5. Inline-Bearbeitung der syslog-ng-Konfigurationsdatei gilt als zu ungenau und wird am besten durch eine bereitgestellte Konfigurationsdatei gelöst, die dies und andere verwandte Anforderungen adressiert.
4.3. Die Konfiguration von logrotate ist standortspezifisch.
5.3.2. Mehrzeilige Bearbeitung von pam-Konfigurationsdateien gilt als zu ungenau und gefährlich und wird am besten durch eine bereitgestellte Konfigurationsdatei gelöst, die dies und andere verwandte Anforderungen adressiert.
5.3.3. Mehrzeilige Bearbeitung von pam-Konfigurationsdateien gilt als zu ungenau und gefährlich und wird am besten durch eine bereitgestellte Konfigurationsdatei gelöst, die dies und andere verwandte Anforderungen adressiert.

Kompatibilität

Diese Rolle ist kompatibel mit den folgenden Versionen von Ansible:

2.0.2
2.1.3
2.2.0
2.3.0

Diese Rolle wurde nicht gegen andere Versionen von Ansible getestet.

Tests

Die folgenden Testprozesse werden vom Entwickler dieser Rolle angewendet:

Die Syntax der Rolle wird geprüft. Siehe make syntax.
ansible-review wird gegen die Rolle ausgeführt und alle Warnungen, die als angemessen erachtet werden, werden behoben. Siehe make review.
Die Rolle wird gegen einen Docker-Container sowohl mit ansible v2.1.3 als auch mit ansible v2.2 getestet. Siehe make test.

Die folgenden Tests wurden flagiert, sind aber noch nicht implementiert: