RHEL 8 CIS

Konfiguracja maszyny RHEL/Rocky/AlmaLinux 8 zgodnie z wymogami CIS

Na podstawie CIS RedHat Enterprise Linux 8 Benchmark v3.0.0 - 11-10-2023

Szukasz wsparcia?

Lockdown Enterprise

Wsparcie Ansible

Społeczność

Dołącz do naszej serwera Discord, aby zadawać pytania, dyskutować o funkcjach lub po prostu pogadać z innymi użytkownikami Ansible-Lockdown.

Ostrzeżenia

Ta rola wprowadzi zmiany w systemie, które mogą mieć niezamierzone konsekwencje. To narzędzie nie jest narzędziem audytowym, ale narzędziem naprawczym, które należy używać po przeprowadzeniu audytu.

• Testowanie jest najważniejszą rzeczą, jaką możesz zrobić.

• Tryb sprawdzania nie jest wspierany! Rola zakończy działanie w trybie sprawdzania bez błędów, ale nie jest wspierana i należy jej używać ostrożnie. Rolę RHEL8-CIS-Audit lub skaner zgodności należy używać do sprawdzania zgodności, a nie trybu sprawdzania.

• Ta rola została opracowana dla czystej instalacji systemu operacyjnego. Jeśli wdrażasz na istniejącym systemie, proszę sprawdzić tę rolę pod kątem wszelkich zmian specyficznych dla lokalizacji.

• Aby użyć wersji wydania, należy wskazać główną gałąź i odpowiednie wydanie/tag dla benchmarku CIS, nad którym chcesz pracować.

• Jeśli przechodzisz przez główne wydania, np. z v2.0.0 do v3.0.0, nastąpiły znaczne zmiany w benchmarkach i kontrolach, dlatego zaleca się rozpoczęcie jako nowy standard, a nie aktualizację.

• W kontenerach odniesienia vars/is_container.yml to przykład, który należy zaktualizować według własnych wymagań.

• Czy wspomnieliśmy o testowaniu??

Dopasowanie poziomu bezpieczeństwa dla CIS

Możliwe jest uruchomienie tylko kontroli poziomu 1 lub poziomu 2 dla CIS. Zarządzane jest to za pomocą tagów:

• level1_server
• level1_workstation
• level2_server
• level2_workstation

Kontrola znajdująca się w głównych domyślnych ustawieniach również musi to odzwierciedlać, ponieważ kontroluje to testowanie, które ma miejsce, jeśli używasz komponentu audytowego.

Przechodząc z poprzedniej wersji

Wersje CIS zawsze zawierają zmiany, dlatego zdecydowanie zaleca się przegląd nowych odniesień i dostępnych zmiennych. Zmieniły się one znacząco od początkowego wydania ansible-lockdown. Jest teraz zgodne z python3, jeśli zostanie znalezione jako domyślny interpreter. To wiąże się z pre-rekwizytami, które konfigurują system odpowiednio.

Dalsze szczegóły można znaleźć w Dzienniku zmian

Audyt (nowość)

Można go włączyć lub wyłączyć w pliku defaults/main.yml za pomocą zmiennej rhel8cis_run_audit. Wartość domyślna to false, proszę zapoznać się z wiki po więcej szczegółów. Plik domyślny również popularyzuje kontrole goss, aby sprawdzić tylko kontrole, które zostały włączone w roli ansible.

To znacznie szybsza, bardzo lekka kontrola zgodności konfiguracji i ustawień uruchamianych.

Opracowano nową formę audytu, używając małego (12MB) binarnego programu go o nazwie goss wraz z odpowiednimi konfiguracjami do sprawdzenia. Bez potrzeby korzystania z infrastruktury lub innych narzędzi. Ten audyt nie tylko sprawdzi, czy konfiguracja ma odpowiednie ustawienia, ale także ma na celu wychwycenie, czy działa z tą konfiguracją, starając się jednocześnie wyeliminować fałszywe pozytywy w tym procesie.

Zobacz RHEL8-CIS-Audit.

Przykład Podsumowania Audytu

To jest oparte na obrazie vagrant z włączonymi opcjami, np. bez GUI lub zapory. Uwaga: Więcej testów jest przeprowadzanych podczas audytu, gdy sprawdzamy konfigurację i stan uruchomiony.

ok: [default] => {
    "msg": [
        "Wyniki przed zażądaniem są: ['Całkowity czas: 5.454s', 'Liczba: 338, Nieudane: 47, Ominięte: 5'].",
        "Wyniki po zażądaniu są: ['Całkowity czas: 5.007s', 'Liczba: 338, Nieudane: 46, Ominięte: 5'].",
        "Szczegółowe informacje można znaleźć w /var/tmp",
        ""
    ]
}

PODSUMOWANIE GRY *******************************************************************************************************************************************
default                    : ok=270  changed=23   unreachable=0    failed=0    skipped=140  rescued=0    ignored=0

Dokumentacja

• Przeczytaj dokumentację
• Jak zacząć
• Dostosowywanie ról
• Konfiguracja per-host
• Jak najlepiej wykorzystać rolę

Wymagania

Ogólne:

• Podstawowa znajomość Ansible, poniżej znajdują się linki do dokumentacji Ansible, które pomogą rozpocząć, jeśli nie jesteś zaznajomiony z Ansible

  • Główna strona dokumentacji Ansible
  • Jak zacząć z Ansible
  • Podręcznik użytkownika Tower
  • Informacje o społeczności Ansible

• Działający Ansible i/lub Tower, zainstalowane, skonfigurowane i działające. Obejmuje to wszystkie podstawowe konfiguracje Ansible/Tower, potrzebne pakiety i skonfigurowaną infrastrukturę.

• Proszę zapoznać się z zadaniami w tej roli, aby zrozumieć, co robi każda kontrola. Niektóre zadania mogą powodować zakłócenia i mieć niezamierzone konsekwencje w żywym systemie produkcyjnym. Również zapoznaj się ze zmiennymi w pliku defaults/main.yml.

Zależności techniczne:

RHEL/AlmaLinux/Rocky/Oracle 8 - Inne wersje nie są wspierane.

• AlmaLinux/Rocky był testowany na 8.8 (włączenie kryptografii (sekcje 1.10 i 1.11) przerywa aktualizacje lub instalacje: 01 lipca 2021)
• Dostęp do pobrania lub dodania binarnego pliku goss i treści do systemu, jeśli używasz audytu (są dostępne inne opcje dotyczące sposobu dostarczenia treści do systemu).
• Python3.8
• Ansible 2.11+
• python-def (powinien być włączony w RHEL 8)
• libselinux-python

Zmienne roli

Ta rola została zaprojektowana w taki sposób, aby użytkownik końcowy nie musiał edytować samych zadań. Całe dostosowywanie powinno być wykonywane za pomocą pliku defaults/main.yml lub z dodatkowymi zmiennymi w projekcie, zadaniu, przepływie pracy itp.

Tagii

Dostępnych jest wiele tagów dla dodatkowej precyzji kontroli. Każda kontrola ma własny zestaw tagów wskazujących, jaki to poziom, czy jest oceniany/nieoceniany, do jakiego elementu systemu operacyjnego się odnosi, czy jest poprawką czy audytem, oraz numer reguły.

Poniżej znajduje się przykład sekcji tagów z kontroli w tej roli. Jeśli w tym przykładzie ustawiłeś swoje uruchomienie, aby pominąć wszystkie kontrole z tagiem services, to zadanie zostanie pominięte. Może też zdarzyć się odwrotna sytuacja, w której uruchamiasz tylko kontrole oznaczone jako services.

      tags:
      - level1-server
      - level1-workstation
      - scored
      - avahi
      - services
      - patch
      - rule_2.2.4

Wkład społeczności

Zachęcamy cię (społeczność) do wnoszenia wkładu do tej roli. Proszę zapoznać się z poniższymi zasadami.

• Twoja praca jest wykonywana w twojej własnej indywidualnej gałęzi. Upewnij się, że wszystkie zatwierdzenia są podpisane i mają podpis GPG, które zamierzasz scalować.
• Wszystkie zapytania Pull Request od społeczności są wciągane do gałęzi devel.
• Zapytania Pull Request do devel potwierdzą, że twoje zatwierdzenia mają podpis GPG, są podpisane i przeszły testy funkcjonalne przed zatwierdzeniem.
• Po scaleniu twoich zmian i przeprowadzeniu dokładniejszej oceny, autoryzowany członek wciągnie twoje zmiany do głównej gałęzi na nową wersję.

Znane problemy

cloud0init - z powodu błędu przestanie działać, jeśli noexec zostanie dodane do /var. rhel8cis_rule_1_1_3_3

bug 1839899

Repozytoria Almalinux BaseOS, EPEL oraz wielu dostawców chmury nie pozwalają na repo_gpgcheck w regule_1.2.3, co spowoduje problemy podczas uruchamiania skryptu, chyba że znajdzie się rozwiązanie obejściowe.

Testowanie Pipelines

używszy:

• ansible-core 2.12
• kolekcje ansible - pobierają najnowszą wersję na podstawie pliku wymagań
• uruchamia audyt przy użyciu gałęzi devel
• To jest zautomatyzowany test, który zachodzi na zapytania Pull Request w devel

Testowanie lokalne

Molecule można wykorzystać do pracy nad tą rolą i testowania w różnych scenariuszach.

przykłady

molecule test -s default
molecule converge -s wsl -- --check
molecule verify -s localhost

Testowanie lokalne używa:

• ansible 2.13.3
• molecule 4.0.1
• molecule-docker 2.0.0
• molecule-podman 2.0.2
• molecule-vagrant 1.0.0
• molecule-azure 0.5.0

Dodatkowe funkcje

• pre-commit można testować i uruchamiać z poziomu katalogu

pre-commit run

Podziękowania

Ogromne dzięki dla fantastycznej społeczności i wszystkich jej członków. Wielkie podziękowania i uznanie dla początkowych autorów i utrzymujących projekt. Josh Springer, Daniel Shepherd, Bas Meijeri, James Cassell, Mike Renfro, DFed, George Nalen, Mark Bolwell