anthcourtney.cis-amazon-linux

Status budowy

Gałąź	Status
Master
Build

Rozwój

Zamierzamy używać gałęzi "master" tylko do w pełni przetestowanych zmian.

Proszę przesyłać swoje prośby o włączenie do gałęzi "build".

Potrzebujemy wsparcia społeczności, aby wprowadzać zmiany i, co najważniejsze, testować oraz przeglądać te zmiany. Jeśli chcesz uczestniczyć w tym projekcie, napisz do Anth lub Chandan.

Główne prace do wykonania to:

CIS Benchmark v2.2.0
Ansible 2.5 i wyższe
Amazon Linux 2 LTS

Wprowadzenie

Ta rola ansible stosuje wersję 2.0.0 CIS Amazon Linux Benchmark. https://benchmarks.cisecurity.org/tools2/linux/CIS_Amazon_Linux_Benchmark_v2.0.0.pdf

Ta rola została opracowana i przetestowana na Amazon Linux 2016.03. Testowano ją również na Amazon Linux 2016.09 z równym powodzeniem.

Dlaczego powinienem użyć tej roli?

Jeśli próbujesz uzyskać zgodność z akceptowanym standardem bezpieczeństwa, takim jak PCI DSS, APRA lub ISO 27001, musisz wykazać, że zastosowałeś udokumentowane standardy zabezpieczeń do wszystkich systemów w zakresie oceny.

Jeśli korzystasz z Amazon Linux, to ta rola ma na celu dostarczenie jednego z rozwiązań w układance związanej z zgodnością.

Uwaga!

Jeśli rozważasz zastosowanie tej roli do jakichkolwiek serwerów, powinieneś mieć podstawową znajomość CIS Benchmark (lub innych podobnych benchmarków) oraz zrozumienie wpływu, jaki może to mieć na system.

Proszę poświęcić czas na zapoznanie się z tym standardem oraz z konfigurowalnymi wartościami domyślnymi, a także wyłączyć wszelkie elementy przed zastosowaniem ich w systemie.

Przykłady elementów, które powinny być natychmiast rozważone do wykluczenia (lub przynajmniej do zmodyfikowania powiązanych wartości domyślnych) to:

3.4.2 i 3.4.3, które domyślnie ograniczają dostęp do hosta (w tym przez ssh) tylko do localhosta.

Amazon Linux i SE Linux

Domyślnie SElinux jest wyłączony w Amazon Linux.

Aby go włączyć, edytuj:

/boot/grub/menu.lst

Zmień selinux=0 na selinux=1

touch /etc/selinux/config

Zainstaluj również następujący pakiet, aby umożliwić działanie modułu SElinux ansible na hoście.

yum install libselinux-python

Będzie konieczne ponowne uruchomienie systemu, aby zmiany mogły wejść w życie.

Przykładowy playbook

Przykładowy playbook, który używa tej roli, wygląda następująco:

---

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

  roles:
    - anthcourtney.cis-amazon-linux

Bardziej zaawansowany przykład, który obejmuje modyfikacje domyślnych wartości oraz wykluczenie niektórych elementów benchmarku, które uznano za niepotrzebne w fikcyjnej konfiguracji, wygląda następująco:

---

- 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:
    - anthcourtney.cis-amazon-linux

Zauważ, że użycie become: yes jest wymagane, ponieważ 99% zadań wymaga dostępu uprzywilejowanego.

Zmienne roli

Zobacz defaults/main.yml, aby poznać zmienne, które można nadpisać zgodnie z preferencjami.

Opcje

Tagi (i ich kombinacje) mogą być używane do uruchomienia określonego poziomu standardu CIS, sekcji lub pojedynczej rekomendacji. Na przykład:

Uruchom tylko zadania Poziomu 1

ansible-playbook playbook.yml -t level-1

Uruchom tylko zadania Sekcji 3

ansible-playbook playbook.yml -t section-3

Uruchom tylko zadania 1.3.1 i 2.2.10

ansible-playbook playbook.yml -t 1.3.1,2.2.10

Uruchom tylko zadania oceniane

ansible-playbook playbook.yml -t scored

Ograniczenia

Na chwilę obecną zaimplementowane są tylko elementy Poziomu 1 benchmarku. Elementy Poziomu 2 zostaną dodane w miarę możliwości.

Poniższe kontrole nie zostały zaimplementowane:

3.6.2. Reguły zapory są specyficzne dla środowiska.
3.6.3. Reguły zapory są specyficzne dla środowiska.
3.6.4. Reguły zapory są specyficzne dla środowiska.
3.6.5. Reguły zapory są specyficzne dla środowiska.
4.2.1.2. Określenie, co powinno być rejestrowane i cel wiadomości, jest specyficzne dla środowiska.
4.2.2.2. Określenie, co powinno być rejestrowane i cel wiadomości, jest specyficzne dla środowiska.
4.2.2.3. Edytowanie pliku konfiguracyjnego syslog-ng w sposób inline jest uważane za zbyt nieprecyzyjne i najlepiej rozwiązać problem, dostarczając plik konfiguracyjny, który to uwzględnia oraz inne wymagania.
4.2.2.4. Edytowanie pliku konfiguracyjnego syslog-ng w sposób inline jest uważane za zbyt nieprecyzyjne i najlepiej rozwiązać problem, dostarczając plik konfiguracyjny, który to uwzględnia oraz inne wymagania.
4.2.2.5. Edytowanie pliku konfiguracyjnego syslog-ng w sposób inline jest uważane za zbyt nieprecyzyjne i najlepiej rozwiązać problem, dostarczając plik konfiguracyjny, który to uwzględnia oraz inne wymagania.
4.3. Konfiguracja logrotate jest specyficzna dla lokalizacji.
5.3.2. Edytowanie wielu linii plików konfiguracyjnych pam jest uważane za zbyt nieprecyzyjne i niebezpieczne, a najlepiej rozwiązać ten problem, dostarczając plik konfiguracyjny, który to uwzględnia oraz inne wymagania.
5.3.3. Edytowanie wielu linii plików konfiguracyjnych pam jest uważane za zbyt nieprecyzyjne i niebezpieczne, a najlepiej rozwiązać ten problem, dostarczając plik konfiguracyjny, który to uwzględnia oraz inne wymagania.

Zgodność

Ta rola jest zgodna z następującymi wersjami ansible:

Ta rola nie była testowana na żadnych innych wersjach ansible.

Testowanie

Do testów stosowane są następujące procesy przez twórcę tej roli:

Sprawdzana jest składnia roli. Zobacz make syntax.
ansible-review jest uruchamiane na roli, a wszelkie ostrzeżenia, które uznano za stosowne, są usuwane. Zobacz make review.
Rola jest stosowana w kontenerze docker przy użyciu zarówno ansible v2.1.3, jak i ansible v2.2. Zobacz make test.

Poniższe testy zostały oznaczone, ale nie zostały jeszcze wdrożone: