Rola Ansible: Bezpieczeństwo (Podstawy)

Uwaga: BEZPIECZEŃSTWO Twoich serwerów jest TWOJĄ odpowiedzialnością. Jeśli myślisz, że wystarczy dodać tę rolę i ustawić zaporę, aby serwer był bezpieczny, to się mylisz. Przeczytaj o bezpieczeństwie systemów Linux, sieci i aplikacji, ponieważ niezależnie od tego, ile wiesz, zawsze możesz poprawić bezpieczeństwo swojego stosu technologicznego.

Ta rola wykonuje podstawową konfigurację zabezpieczeń na systemach Linux opartych na RedHat i Debian. Próbuję:

• Zainstalować oprogramowanie do monitorowania niepożądanych prób dostępu przez SSH (fail2ban)
• Skonfigurować SSH, aby był bardziej bezpieczny (wyłączenie logowania jako root, wymuszanie uwierzytelniania opartego na kluczu oraz umożliwienie ustawienia niestandardowego portu SSH)
• Ustawić automatyczne aktualizacje (jeśli jest to skonfigurowane)

Są także inne działania, które możesz, ale nie musisz wykonywać (niezawarte w tej roli), aby zapewnić większe bezpieczeństwo swoich serwerów, jak na przykład:

• Używać logwatch lub centralnego serwera logowania do analizy i monitorowania plików dziennika
• Bezpiecznie skonfigurować konta użytkowników i klucze SSH (ta rola zakłada, że nie używasz uwierzytelniania hasłem lub logujesz się jako root)
• Mieć dobrze skonfigurowaną zaporę (zapoznaj się z rolą geerlingguy.firewall w Ansible Galaxy dla elastycznego przykładu)

Jeszcze raz: Bezpieczeństwo twoich serwerów to twoja odpowiedzialność.

Wymagania

Z oczywistych powodów, sudo musi być zainstalowane, jeśli chcesz zarządzać plikiem sudoers za pomocą tej roli.

Na systemach RedHat/CentOS upewnij się, że masz zainstalowane repozytorium EPEL (możesz dodać rolę geerlingguy.repo-epel, aby je zainstalować).

Brak specjalnych wymagań dla systemów Debian/Ubuntu.

Zmienne Roli

Dostępne zmienne są wymienione poniżej wraz z wartościami domyślnymi (zobacz defaults/main.yml):

security_ssh_port: 22

Port, przez który chcesz, aby SSH było dostępne. Domyślnie jest to port 22, ale jeśli prowadzisz serwer w Internecie i nie masz zapory, która blokuje dostęp do portu 22, szybko przekonasz się, że tysiące prób logowania dziennie są na porządku dziennym. Możesz zmienić port na niestandardowy (np. 2849), jeśli chcesz uniknąć tych tysięcy zautomatyzowanych prób włamania.

security_ssh_password_authentication: "no"
security_ssh_permit_root_login: "no"
security_ssh_usedns: "no"
security_ssh_permit_empty_password: "no"
security_ssh_challenge_response_auth: "no"
security_ssh_gss_api_authentication: "no"
security_ssh_x11_forwarding: "no"

Ustawienia bezpieczeństwa dla uwierzytelniania SSH. Najlepiej zostawić je na "no", ale są sytuacje (szczególnie podczas wstępnej konfiguracji serwera lub gdy nie masz jeszcze uwierzytelniania opartego na kluczu), kiedy jedna lub wszystkie te opcje mogą być ustawione na 'yes'. UWAGA: Ważne jest, aby wartości 'yes' lub 'no' były ujęte w cudzysłowy. Nieprzestrzeganie tego może zablokować Ci dostęp do serwera.

security_ssh_allowed_users: []
# - alice
# - bob
# - charlie

Lista użytkowników, którzy mają prawo łączyć się z hostem przez SSH. Jeśli nikt nie jest zdefiniowany na liście, zadanie zostanie pominięte.

security_ssh_allowed_groups: []
# - admins
# - devs

Lista grup, które mają prawo łączyć się z hostem przez SSH. Jeśli żadna grupa nie jest zdefiniowana na liście, zadanie zostanie pominięte.

security_sshd_state: started

Stan demona SSH. Zazwyczaj powinien pozostać started.

security_ssh_restart_handler_state: restarted

Stan handlera restart ssh. Zazwyczaj powinien pozostać restarted.

security_sudoers_passwordless: []
security_sudoers_passworded: []

Lista użytkowników, którzy powinni zostać dodani do pliku sudoers, aby mogli wykonywać dowolne polecenia jako root (za pomocą sudo) bez hasła lub wymagających hasła dla każdego polecenia, odpowiednio.

security_autoupdate_enabled: true

Czy zainstalować/włączyć yum-cron (systemy oparte na RedHat) lub unattended-upgrades (systemy oparte na Debian). Wyłączenia systemu nie odbędą się automatycznie w każdym przypadku, a automatyczne aktualizacje nie są wymówką dla niechlujnego zarządzania łatkami i pakietami, ale automatyczne aktualizacje mogą być pomocne jako dodatkowy środek bezpieczeństwa.

security_autoupdate_blacklist: []

(Tylko Debian/Ubuntu) Lista pakietów, które nie powinny być automatycznie aktualizowane.

security_autoupdate_additional_origins: []
# - "${distro_id}ESM:${distro_codename}-infra-security"
# - "Docker:${distro_codename}"

(Tylko Debian/Ubuntu) Lista źródeł do odniesienia.

security_autoupdate_reboot: false

(Tylko Debian/Ubuntu) Czy zrestartować, gdy zajdzie taka potrzeba podczas automatycznych aktualizacji.

security_autoupdate_reboot_time: "03:00"

(Tylko Debian/Ubuntu) Czas na zainicjowanie restartu, gdy zajdzie taka potrzeba, jeśli security_autoupdate_reboot jest ustawione na true. W formacie zegara 24h "hh:mm".

security_autoupdate_mail_to: ""
security_autoupdate_mail_on_error: true

(Tylko Debian/Ubuntu) Jeśli security_autoupdate_mail_to jest ustawione na niepustą wartość, automatyczne aktualizacje będą wysyłać e-mail na ten adres w przypadku wystąpienia jakiegoś błędu. Możesz to ustawić na pełny adres e-mail: [email protected] lub coś w rodzaju root, co wykorzysta /etc/aliases do przesyłania wiadomości. Jeśli ustawisz security_autoupdate_mail_on_error na false, otrzymasz e-mail po każdej instalacji pakietu.

security_fail2ban_enabled: true

Czy zainstalować/włączyć fail2ban. Nie chcesz używać fail2ban, jeśli już korzystasz z innej usługi do wykrywania loginów i włamań (np. ConfigServer).

security_fail2ban_custom_configuration_template: "jail.local.j2"

Nazwa pliku szablonu, który jest używany do generowania konfiguracji fail2ban.

Zależności

Brak.

Przykładowy Playbook

- hosts: servers
  vars_files:
    - vars/main.yml
  roles:
    - geerlingguy.security

W pliku vars/main.yml:

security_sudoers_passworded:
  - johndoe
  - deployacct

Licencja

MIT (Expat) / BSD

Informacje o autorze

Ta rola została stworzona w 2014 roku przez Jeffa Geerlinga, autora Ansible for DevOps.