ansible-lockdown.rhel7_cis

Przegląd Wersje Wgląd

RHEL 7 CIS

Skonfiguruj maszynę RHEL/Centos 7 zgodnie z wymaganiami CIS

Zgodnie z CIS RedHat Enterprise Linux 7 Benchmark v4.0.0 - 21-12-2023

Release Tag Release Date

Devel Commits

Issues Open Issues Closed Pull Requests

License

Szukasz wsparcia?

Lockdown Enterprise

Wsparcie Ansible

Społeczność

Na naszym serwerze Discord możesz zadawać pytania, omawiać funkcje lub po prostu rozmawiać z innymi użytkownikami Ansible-Lockdown

Ostrzeżenia

Ta rola wprowadzi zmiany w systemie, które mogą mieć niezamierzone konsekwencje. To nie jest narzędzie audytowe, ale raczej narzędzie do usuwania problemów, które powinno być używane po przeprowadzeniu audytu.

Tryb sprawdzania nie jest obsługiwany! Rola zakończy się w trybie sprawdzania bez błędów, ale nie jest to obsługiwane i należy z niej korzystać ostrożnie. Rola RHEL7-CIS-Audit lub skanery zgodności powinny być używane do sprawdzania zgodności w trybie sprawdzania.

Ta rola została opracowana na czystej instalacji systemu operacyjnego. Jeśli wdrażasz ją na istniejącym systemie, proszę zapoznać się z tą rolą, aby sprawdzić, czy są potrzebne jakiekolwiek zmiany specyficzne dla lokalizacji.

Aby używać wersji wydania, proszę wskazać na główną gałąź i odpowiednie wydanie dla benchmarku cis, z którym chcesz pracować.

Dopasowanie poziomu bezpieczeństwa do CIS

Możliwe jest uruchomienie tylko kontroli poziomu 1 lub poziomu 2 dla CIS. Jest to zarządzane przy pomocy tagów:

level1-server
level1-workstation
level2-server
level2-workstation

Kontrola znajdująca się w domyślnych ustawieniach także musi to odzwierciedlać, ponieważ to ta kontrola testuje, co się dzieje, jeśli korzystasz z komponentu audytowego.

Przejście z wcześniejszej wersji

Wydania CIS zawsze zawierają zmiany, dlatego zaleca się zapoznanie się z nowymi odniesieniami i dostępnymi zmiennymi. Zmiany te są znaczące od momentu wydania ansible-lockdown. To teraz jest zgodne z python3, jeśli jest uznawany za domyślny interpreter. Wymaga to wstępnych konfiguracji, które odpowiednio dostosowują system.

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 rhel7cis_run_audit. Wartość domyślna to false, proszę zapoznać się z wiki, aby uzyskać więcej szczegółów. Plik domyślny również wypełnia kontrole goss, aby sprawdzić tylko te kontrole, które są włączone w roli ansible.

To szybkie, bardzo lekkie sprawdzenie (gdzie to możliwe) zgodności konfiguracji oraz uruchamiania.

Nowa forma audytu została opracowana przy użyciu małego (12MB) binarnego pliku go o nazwie goss oraz odpowiednich konfiguracji do sprawdzenia. Bez potrzeby używania infrastruktury lub innych narzędzi. Ten audyt nie tylko sprawdzi, czy konfiguracja ma prawidłowe ustawienia, ale również ma na celu uchwycenie, czy działa z tą konfiguracją, usiłując usunąć fałszywe pozytywy w tym procesie.

Dokumentacja

Wymagania

Ogólne:

Podstawowa znajomość Ansible, poniżej kilka linków do dokumentacji Ansible, które pomogą w rozpoczęciu, jeśli nie jesteś zaznajomiony z Ansible:
Funkcjonująca instalacja Ansible i/lub Tower, skonfigurowana i działająca. Obejmuje to wszystkie podstawowe konfiguracje Ansible/Tower, potrzebne pakiety oraz skonfigurowaną infrastrukturę.
Proszę przeczytać zadania w tej roli, aby zrozumieć, co robi każda kontrola. Niektóre z zadań mogą być inwazyjne i mogą prowadzić do niezamierzonych konsekwencji w działającym systemie produkcyjnym. Również zapoznaj się ze zmiennymi w pliku defaults/main.yml.

Wymagania techniczne:

Działająca konfiguracja Ansible/Tower (ta rola została przetestowana z Ansible w wersji 2.9.1 i nowszych)
Środowisko uruchomieniowe Ansible w Python3
python-def (powinien być zawarty w RHEL/CentOS 7) - Pierwsze zadanie konfiguruje wstępne wymagania (Tag pre-reqs) dla python3 i python2 (gdzie to wymagane)
- libselinux-python
- python3-rpm (pakiet używany przez py3 do użycia pakietu rpm)

Zmienne roli

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

Tagi

Dostępnych jest wiele tagów dla lepszej kontroli. Każda kontrola ma własny zestaw tagów wskazujących, jaki poziom, czy jest oceniana/nieoceniana, do jakiego elementu systemu operacyjnego się odnosi, czy jest to poprawka, czy audyt oraz numer reguły.

Poniżej znajduje się przykład sekcji tagów z kontrolą w tej roli. Używając tego przykładu, jeśli ustawisz swoje uruchomienie, aby pominąć wszystkie kontrole z tagiem services, to to zadanie zostanie pominięte. Może również wydarzyć się odwrotność, gdzie uruchomisz tylko kontrole oznaczone tagiem services.

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

Wkład społeczności

Zachęcamy Cię (społeczność) do przyczynienia się do tej roli. Proszę zapoznaj się z zasadami poniżej.

Twoja praca jest realizowana w swojej własnej indywidualnej gałęzi. Upewnij się, że wszystkie zatwierdzenia są podpisane i oznakowane jako GPG.
Wszystkie zgłoszenia Pull Request społecznościową są włączane do gałęzi devel.
Zgłoszenia Pull Request do devel potwierdzą, że Twoje zatwierdzenia mają podpis GPG, zostały oznaczone oraz przeszły testy funkcjonalne przed zatwierdzeniem.
Po scaleniu zmian i zakończeniu bardziej szczegółowego przeglądu, uprawniony członek połączy Twoje zmiany z gałęzią główną dla nowego wydania.

Testowanie pipeline

używa:

ansible-core 2.12
kolekcje ansible - pobiera najnowszą wersję na podstawie pliku wymagań
przeprowadza audyt przy użyciu gałęzi devel
To jest zautomatyzowany test, który odbywa się przy zgłoszeniach Pull Request do devel