HarryHarcourt.Ansible-RHEL7-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 7.X (getestet 7.1 - 7.7) und CentOS 7.4 (getestet 7.4 - 7.7, beachten Sie, dass CentOS-Versionen unter 7.4 Probleme mit SSH haben können) konvertiert.

Diese Implementierung wurde in vielen Bereichen idempotent gestaltet und bleibt es.

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 gegen Red Hat Linux 7.1, 7.2, 7.3, 7.4, 7.5, 7.6 und 7.7 mit standardmäßigen AWS AMIs entwickelt und getestet. Diese Rolle wurde gegen CentOS 7.4 mit standardmäßigen AWS AMIs entwickelt und getestet.

Warum sollte ich diese Rolle verwenden?

Wenn Sie versuchen, die Konformität mit einem branchenspezifischen Sicherheitsstandard wie PCI DSS, APRA oder ISO 27001 zu erreichen, müssen Sie nachweisen, dass Sie dokumentierte Härtungsstandards auf alle Systeme innerhalb des Bewertungsbereichs 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 Drachen!

Wenn Sie in Erwägung ziehen, diese Rolle auf Server anzuwenden, sollten Sie sich mit dem CIS-Benchmark (oder ähnlichen Benchmarks) auskennen und den Einfluss, den dieser auf ein System haben kann, verstehen.

Bitte nehmen Sie sich die Zeit, um sich mit dem Standard und den konfigurierbaren Standardwerten vertraut zu machen und schließen Sie alle Punkte aus, bevor Sie sie auf ein System anwenden.

Einige Beispiele für Punkte, die sofort für einen Ausschluss (oder zumindest für eine Modifikation der zugehörigen Standardwerte) in Betracht gezogen werden sollten, sind:

3.4.2 und 3.4.3, die beim Standard effektiv 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-RHEL7-CIS-Benchmarks

Ein fortgeschritteneres Beispiel, das Änderungen an den verwendeten Standardwerten sowie den Ausschluss einiger Punkte im Benchmark, die für eine fiktive Umgebung als unnötig erachtet werden, zeigt, 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-RHEL7-CIS-Benchmarks

Beachten Sie, dass die Verwendung von become: yes erforderlich ist, da 99 % der Aufgaben privilegierte Zugriffsrechte benötigen, um ausgeführt zu werden.

Rollvariablen

Siehe defaults/main.yml für Variablen, die gemäß den Vorlieben überschrieben werden können.

Optionen

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

Nur Level-1-Aufgaben ausführen

ansible-playbook playbook.yml -t level-1

Nur Abschnitt-3-Aufgaben ausführen

ansible-playbook playbook.yml -t section-3

Nur die Aufgaben 1.3.1 und 2.2.10 ausführen

ansible-playbook playbook.yml -t 1.3.1,2.2.10

Nur bewertete Aufgaben ausführen

ansible-playbook playbook.yml -t scored

Einschränkungen

Derzeit sind nur die Level-1-Punkte des Benchmarks implementiert. Level-2- Punkte werden bei Möglichkeit hinzugefügt.

Die folgenden Überprüfungen wurden nicht implementiert:

3.6.2. Firewall-Regelsätze sind umgebungsabhängig.
3.6.3. Firewall-Regelsätze sind umgebungsabhängig.
3.6.4. Firewall-Regelsätze sind umgebungsabhängig.
3.6.5. Firewall-Regelsätze sind umgebungsabhängig.
4.2.1.2. Die Bestimmung, was protokolliert werden sollte und das Ziel der Nachrichten, ist umgebungsabhängig.
4.2.2.2. Die Bestimmung, was protokolliert werden sollte und das Ziel der Nachrichten, ist umgebungsabhängig.
4.2.2.3. Inline-Bearbeitung der syslog-ng-Konfigurationsdatei wird als zu ungenau erachtet und sollte besser durch eine bereitgestellte Konfigurationsdatei gelöst werden, die dies und andere verwandte Anforderungen berücksichtigt.
4.2.2.4. Inline-Bearbeitung der syslog-ng-Konfigurationsdatei wird als zu ungenau erachtet und sollte besser durch eine bereitgestellte Konfigurationsdatei gelöst werden, die dies und andere verwandte Anforderungen berücksichtigt.
4.2.2.5. Inline-Bearbeitung der syslog-ng-Konfigurationsdatei wird als zu ungenau erachtet und sollte besser durch eine bereitgestellte Konfigurationsdatei gelöst werden, die dies und andere verwandte Anforderungen berücksichtigt.
4.3. Die Konfiguration von logrotate ist standortspezifisch.
5.3.2. Mehrzeilige Bearbeitung von pam-Konfigurationsdateien wird als zu ungenau und gefährlich erachtet und sollte besser durch eine bereitgestellte Konfigurationsdatei gelöst werden, die dies und andere verwandte Anforderungen berücksichtigt.
5.3.3. Mehrzeilige Bearbeitung von pam-Konfigurationsdateien wird als zu ungenau und gefährlich erachtet und sollte besser durch eine bereitgestellte Konfigurationsdatei gelöst werden, die dies und andere verwandte Anforderungen berücksichtigt.

Kompatibilität

Diese Rolle ist mit den folgenden Versionen von Ansible kompatibel:

2.0.2
2.1.3
2.2.0
2.3.0
2.7.0
2.8.x
2.9.x

Diese Rolle wurde nicht gegen andere Versionen von Ansible getestet.

Tests

Die folgenden Testprozesse werden von dem Entwickler dieser Rolle angewendet:

Die Syntax der Rolle wird überprü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 mit Ansible v2.1.3 und Ansible v2.2 angewendet. Siehe make test.

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

Testanwendung der Rolle gegen das Vagrant mvbcoding/awslinux-Image unter Verwendung des Ansible-Provisioners.

Lizenz

HINWEIS: Es gab einige Verwirrung über die Lizenz, die für diese Ansible-Rolle verwendet werden sollte. Der Ursprungscode dieser Rolle von Anthony Courtney hatte keine Lizenzdatei, jedoch verwies die meta/main.yml auf MIT, während die README (unten) BSD erwähnte. Ohne Rückmeldung von Anthony (durch das Protokollieren eines Problems beim ursprünglichen Quellcode und das Kontaktieren von Anthony über LinkedIn) habe ich beschlossen, die MIT-Lizenz für diese Rolle zu übernehmen.

MIT.