Bezpieczeństwo i kontrola dostępu do systemu Linux jest jednym z najważniejszych aspektów, które każda organizacja i administrator powinni traktować priorytetowo. Do systemu Linux najczęściej logujemy się za pomocą konsoli SSH. Istnieją proste metody, które pozwalają znacząco zwiększyć bezpieczeństwo logowania do SSH.
Logowanie za pomocą kluczy od dawna uchodzi za złoty standard w ochronie systemów, eliminując wiele zagrożeń związanych z tradycyjnymi hasłami. Klucze SSH są trudniejsze do przejęcia, nie podlegają łatwym do odgadnięcia wzorcom i skutecznie chronią przed atakami brute-force. To rozwiązanie zaleca się stosować wszędzie tam, gdzie jest to możliwe – w szczególności na serwerach produkcyjnych, urządzeniach sieciowych i wszelkich środowiskach wymagających wysokiego poziomu bezpieczeństwa. Niemniej jednak nie wszystkie przypadki użytkowania pozwalają na wdrożenie logowania za pomocą kluczy SSH np. w środowisku opartym na systemie z rodziny RHEL, CentOS 9 Stream.
Istnieją sytuacje, w których tradycyjne logowanie hasłem jest konieczne, np. w środowiskach awaryjnych, gdzie klucze nie są dostępne, w systemach zarządzanych przez mniej zaawansowanych użytkowników lub podczas pracy w środowiskach tymczasowych, takich jak laboratoria czy serwery testowe. Często spotyka się też takie logowanie na hostingach współdzielonych, gdzie klucz jest standardem, ale to hasło najczęściej wybierają użytkownicy. Co więcej, dostęp hasłem może być jedyną opcją w systemach standalone, gdzie nie przewidziano możliwości generowania i przechowywania kluczy. W takich przypadkach, aby zapewnić odpowiedni poziom ochrony, konieczne jest wdrożenie dodatkowych mechanizmów zwiększających bezpieczeństwo logowania.
Jednym z efektywnych rozwiązań jest wykorzystanie narzędzi takich jak authselect i SSSD, które upraszczają zarządzanie uwierzytelnianiem i pozwalają na implementację zaawansowanych polityk bezpieczeństwa, takich jak blokady po błędnych próbach logowania, wymuszenie silnych haseł oraz precyzyjna kontrola dostępu. W dalszej części zostanie pokazane, jak wzmocnić ochronę logowania hasłem przy użyciu tych narzędzi, mając na uwadze, że tam, gdzie to możliwe, zalecane jest korzystanie z kluczy.
Authselect – co to takiego i czy warto tego używać?
Authselect to nowoczesne narzędzie dostępne w systemach opartych na Red Hat (w tym CentOS i Fedora), które upraszcza zarządzanie konfiguracją stosu uwierzytelniania. Zostało stworzone jako bezpieczniejsza i bardziej zautomatyzowana alternatywa dla starszych narzędzi, takich jak authconfig.
Authselect opiera się na predefiniowanych profilach, takich jak `minimal`, `sssd` czy `winbind`, które są zoptymalizowane pod kątem różnych scenariuszy uwierzytelniania. Dzięki temu eliminuje ryzyko błędów, jakie mogą wystąpić przy ręcznej edycji plików konfiguracyjnych, takich jak `/etc/pam.d/system-auth` czy `/etc/nsswitch.conf`. Narzędzie zapewnia nie tylko wygodę zarządzania, ale także zwiększa poziom bezpieczeństwa dzięki wykorzystaniu sprawdzonych i testowanych ustawień. Wprowadzenie authselect jako warstwy abstrakcji pozwala na łatwe wdrażanie zaawansowanych polityk bezpieczeństwa bez konieczności głębokiej znajomości skomplikowanych mechanizmów PAM.
Jednym z kluczowych kroków w podnoszeniu poziomu bezpieczeństwa systemu jest przejście z domyślnej konfiguracji na profile authselect. Poniżej przedstawiono jakie mamy możliwości i dlaczego został wybrany ten konkretny przykład, nawet jeśli mamy serwer typu standalone bez zaawansowanej i złożonej wielopoziomowej warstwy dostępowej.
Authselect oferuje 3 różne poziomy:
authselect list
– minimal Dla lokalnego uwierzytelniania
– sssd Włącza SSSD dla autentykacji, także jeśli uży wamy go tylko lokalnie
– winbind Włącza winbind dla logowania, np domenowego
Możemy dodawać też customowe konfiguracje, które po wylistowaniu pojawią się.
Tworzymy jeden zestaw customowy, który w dalszej części zostanie szerzej opisany. Będzie bazował on na profilu sssd. Dlaczego ten profil, a nie minimal?
SSSD wykorzystuje System Security Services Daemon (SSSD). W odróżnieniu od profilu `minimal`, który opiera się wyłącznie na lokalnych plikach, takich jak `/etc/passwd` i `/etc/shadow`, profil `sssd` wprowadza dodatkowe funkcje, takie jak buforowanie danych, zaawansowane zarządzanie politykami haseł oraz możliwość integracji z centralnymi katalogami tożsamości (LDAP, Active Directory). Nawet w systemach standalone, gdzie centralne katalogi nie są wykorzystywane, SSSD oferuje większą elastyczność i możliwość implementacji takich mechanizmów jak blokowanie logowania po wielokrotnych nieudanych próbach czy wymuszenie złożoności haseł.
Wdrożenie SSSD pozwala również na efektywniejsze zarządzanie lokalnymi użytkownikami, dzięki wsparciu dla filtracji i dokładniejszego monitorowania. Przejście na authselect z profilem `sssd` to istotny krok w kierunku zwiększenia bezpieczeństwa i odporności systemu na potencjalne zagrożenia związane z uwierzytelnianiem.
Włączenie obsługi authselect, instalacja i konfiguracja
Na początek instalujemy niezbędne paczki:
dnf -y install authselect sssd
Tworzymy customowy profil:
authselect create-profile custom-sssd –base-on sssd
Tworzymy dwa pliki konfiguracyjne dla system-auth I password-auth. Nie operujemy na systemowych plikach domyślnych gdyż każda aktualizacja nadpisze naszą konfigurację.
Co zmieniamy w stosunku do domyślnej konfiguracji? Włączamy 3 bardzo istotne rzeczy z punktu widzenia logowania hasłami:
– Blokadę po 5 próbach błędnego logowania – na 5 minut
– Wymuszamy skomplikowane hasła
– Ukrywamy błędy logowania przez użytkownikiem
– Zapisujemy zdarzenia do logów
– Pamięć ostatnich haseł. Jeśli wymusimy zmianę hasła użytkownik nie będzie mógł użyć tego samego co poprzednie 10 razy.
nano /etc/authselect/custom/custom-sssd/system-auth
auth required pam_env.so
auth required pam_faillock.so preauth silent audit deny=5 unlock_time=300
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=300
auth required pam_deny.so
account required pam_unix.so
account required pam_faillock.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid >= 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3
password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok remember=10
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
nano /etc/authselect/custom/custom-sssd/password-auth
auth required pam_env.so
auth required pam_faillock.so preauth silent audit deny=5 unlock_time=300
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=300
auth required pam_deny.so
account required pam_unix.so
account required pam_faillock.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid >= 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3
password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok remember=10
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
Tworzymy konfigurację dla usługi sssd:
nano /etc/ssd/sssd.conf
[sssd]
domains = LOCAL
services = nss, pam
config_file_version = 2
# Ustawienia debugowania (opcjonalne podczas testowania)
debug_level = 0x0200
[domain/LOCAL]
id_provider = files
auth_provider = files
access_provider = permit
# Opcjonalne ustawienia cache (dla standalone, buforowanie może być pomocne)
cache_credentials = true
entry_cache_timeout = 600
entry_cache_user_timeout = 600
entry_cache_group_timeout = 600
# Blokowanie dostępu dla użytkowników systemowych (opcjonalne)
enumerate = false
filter_users = root
filter_groups = root
Restartujemy usługę:
systemctl restart sssd
Aplikujemy ustawienia authselect na nasze:
authselect select custom/custom-sssd –force
Testowanie konfiguracji
Próbujemy zalogować się na konto użytkownika “test”, które przed chwilą utworzyłem.
Po przekroczeniu błędnych prób logowania konto zostaje czasowo zablokowane i w logach odkładana jest informacja:
Jeśli wymuszono nam zmianę hasła lub sami chcemy je zmienić i spróbujemy wykorzystać jedno z poprzednich 10 haseł, otrzymamy stosowny komunikat:
Jeśli przy zmianie hasła nie spełnimy minimalnych założeń skomplikowania hasła dostaniemy również odpowiednią informację:
Podsumowanie
To jedynie niewielki wycinek tego co można zrobić przy pomocy authselect jednak na pewno jest to dobry punkt wyjścia do tego, aby rozpocząć pracę nad podnoszeniem świadomości i bezpieczeństwa systemu. Przejście na authselect i wybór profilu sssd zamiast pozostawienia domyślnej konfiguracji po instalacji systemu to pierwszy krok w podnoszeniu bezpieczeństwa, elastyczności i łatwości zarządzania uwierzytelnianiem w systemie Linux.
Authselect upraszcza proces konfiguracji modułów PAM oraz Name Service Switch (NSS), eliminując ryzyko błędów wynikających z ręcznej edycji plików i zapewniając zgodność z nowoczesnymi standardami. Profil sssd, w odróżnieniu od minimalnego, oferuje zaawansowane funkcje, takie jak buforowanie danych użytkowników, obsługę centralnych katalogów tożsamości (LDAP, Active Directory) oraz możliwość implementacji bardziej złożonych polityk bezpieczeństwa.
Dzięki zmianie sposobu logowania możliwe jest wdrożenie takich mechanizmów jak blokady po wielokrotnych nieudanych próbach logowania, wymuszanie silnych haseł czy zapobieganie recyklingowi haseł. Nawet w systemach standalone SSSD zapewnia większą elastyczność i przyszłościowość, umożliwiając łatwą integrację z bardziej zaawansowanymi środowiskami w razie potrzeby. Wybór authselect i profilu sssd to inwestycja w bezpieczeństwo systemu i wygodę zarządzania, co jest szczególnie ważne w środowiskach produkcyjnych, gdzie ochrona danych i zgodność z politykami bezpieczeństwa mają kluczowe znaczenie.
Zostaw komentarz
Musisz się zalogować lub zarejestrować aby dodać nowy komentarz.