Bezpieczne i zintegrowane zarządzanie dostępem w środowisku Linux za pomocą FreeIPA
W przypadku większych organizacji problematyczną kwestią staje się utrzymywanie kont i dostępów dla poszczególnych pracowników. Jak wiadomo, jedni pracownicy odchodzą, inni są zatrudniani na ich miejsce, a część może awansować i w konsekwencji wymagać innego zakresu uprawnień. Istotna jest możliwość płynnego wprowadzania takowych zmian. Udzielenie dostępu nie powinno oznaczać konieczności ręcznego zakładania kont we wszystkich kluczowych systemach. Tak samo z odbieraniem tego dostępu — musimy mieć pewność, że dana osoba nie ma już możliwości zalogowania do wybranych usług.
Jednak zanim rozpoczniemy pracę i otrzymamy niezbędne dostępy, trzeba wcześniej zaaplikować na wybrane ogłoszenie oraz skutecznie przejść proces rekrutacji. Jeśli interesuje nas stanowisko związane z administracją IT czy bezpieczeństwem, to możliwe, że właśnie my będziemy odpowiedzialni za zarządzanie uprawnieniami. Oferty pracy z branży IT możemy łatwo znaleźć w serwisie theprotocol.it.
Wyjątkowo wygodnym i użytecznym, a także stosunkowo prostym w konfiguracji i utrzymaniu rozwiązaniem dla środowisk Linux w tym zakresie jest FreeIPA. Jako że zwykli pracownicy raczej korzystają z systemów Windows i kont domenowych Active Directory, FreeIPA sprawdzi się przykładowo do zarządzania dostępem do serwerów Linux dla administratorów. Podejście, w którym korzystamy z niezależnych rozwiązań dla utrzymywania kont Windows i Linux, jest bardzo sensowne.
FreeIPA natywnie może być zainstalowana jedynie na systemach „powiązanych” z RHEL, czyli przykładowo na CentOS, AlmaLinux czy Fedora. W pozostałych systemach możemy natomiast zbudować obraz Docker (dostępne są gotowe pliki Dockerfile) i korzystać z opisywanego narzędzia w formie kontenera. Pokażę oczywiście obie metody.
Instalacja w systemie CentOS Stream 9
Host pełniący rolę serwera FreeIPA musi mieć ustawiony hostname zawierający docelową domenę — w moim przypadku to ipa.avlab.local. Należy też pamiętać, że zarówno nazwa hosta jak i domena muszą koniecznie rozwiązywać na adres serwera. Można nawet dodać zwykły wpis do pliku /etc/hosts w standardowym formacie
<adres_ip> <domena_freeipa> <domena>
np.
10.0.0.25 ipa.avlab.local avlab.local
Jeśli tego nie dopilnujemy, to podczas instalacji poleceniem ipa-server-install proces zostanie przerwany z odpowiednim błędem.
Wybrałem akurat dystrybucję CentOS, aczkolwiek w innych podobnych systemach poszczególnie działania powinny być analogiczne. Pakiet freeipa-server najpewniej będzie dostępny w domyślnym repozytorium, dlatego wykonujemy:
dnf install freeipa-server
Spotkałem się z sytuacją, że skrypt instalacyjny zgłaszał komunikaty „warning” o treści:
/etc/rc.d/rc.local is not marked executable
Rozwiązaniem jest zwykłe nadanie prawa do wykonania dla tego pliku:
chmod +x /etc/rc.d/rc.local
Następnie uruchamiamy właściwy skrypt ipa-server-install. Zakładając, że w sieci już działa inny serwer DNS i nie potrzebujemy korzystać z BIND dostarczanego wraz z FreeIPA (który zresztą wymaga osobnego pakietu ipa-server-dns), to właściwie na każdym etapie instalatora możemy udzielić domyślnej odpowiedzi, naciskając klawisz Enter. Wyjątkiem jest oczywiście ustawienie haseł do Directory Manager i użytkownika admin FreeIPA. Kolejne kroki zostały podane poniżej:
- Do you want to configure integrated DNS (BIND)? [no]
- Server host name [ipa.avlab.local]
- Please confirm the domain name [avlab.local]
- Please provide a realm name [AVLAB.LOCAL]
- Directory Manager password
- Password (confirm)
- IPA admin password
- Password (confirm)
- NetBIOS domain name [AVLAB]
- Do you want to configure chrony with NTP server or pool address? [no]
- Continue to configure the system with these values? [no] (tutaj podajemy wartość yes)
Jeśli w trakcie instalacji wszystko zakończyło się poprawnie, zobaczymy output podobny do tego z poniższego zrzutu ekranu.
Zamierzamy przydzielić użytkownikom prawa do wykonywania poleceń jako sudo, stąd należy dodatkowo aktywować takową możliwość:
authselect enable-feature with-sudo
systemctl restart sssd
Oprócz tego musimy dodać reguły zezwalające na dostęp do kluczowych portów:
firewall-cmd --add-service={http,https,freeipa-ldap,freeipa-ldaps} --permanent
firewall-cmd --reload
Możemy teraz wejść na adres https://ipa.avlab.local, gdzie zobaczymy prośbę o podanie poświadczeń Basic Auth. Możemy to zabezpieczenie zignorować, de facto nie ma ono zastosowania dla systemów Windows.
We właściwym formularzu logowania podajemy użytkownika admin i ustawione wcześniej hasło. Po zalogowaniu zobaczymy panel zarządzania FreeIPA.
Uruchomienie kontenera z FreeIPA
Domyślne ustawienia Docker nie pozwolą na poprawny start kontenera z FreeIPA. Należy utworzyć nowy plik /etc/docker/daemon.json z poniższą zawartością:
{ "userns-remap": "default" }
Kompletne pliki Dockerfile zbudowane z użyciem obrazów różnych dystrybucji możemy znaleźć w repozytorium https://github.com/freeipa/freeipa-container. Modyfikacje tych plików raczej nie są wymagane, wyjątkiem jest jednak ustawienie strefy czasowej. Z racji, że to format Dockerfile, wystarczy dopisać (np. zaraz pod instrukcją FROM) tę linię:
ENV TZ="Europe/Warsaw"
Możemy wybrać dowolny z dostępnych Dockerfile; osobiście korzystam z Dockerfile.centos-9-stream. Składnia polecenia docker build jest zwyczajna:
docker build -t freeipa-server -f Dockerfile.centos-9-stream .
Uruchomienie kontenera do celów wstępnej konfiguracji powinno mieć postać:
docker run --name freeipa-server --sysctl net.ipv6.conf.lo.disable_ipv6=0 -ti -h ipa.avlab.local --read-only -v ~/data:/data freeipa-server
Pojawią się poszczególne kroki zgodne z tymi opisanymi powyżej dla standardowej instalacji. Udana konfiguracja zakończy się komunikatem FreeIPA server configured.
O Docker i jego zastosowaniu szerszej pisałem w poprzednim artykule. Znajomość konteneryzacji to zdecydowanie przydatna i aktualna wiedza. Inne ciekawe materiały z branży IT znajdziemy również na blogu blog.theprotocol.it.
Operowaliśmy teraz w kontenerze, a potrzebujemy „powrócić” do powłoki systemowej. Skróty Ctrl+C czy Ctrl+Z nie przyniosą żadnego efektu. Zakładając, że pracujemy poprzez SSH, to należy połączyć się jeszcze raz (utworzyć drugą sesję) i wykonać:
docker stop freeipa-server
docker rm freeipa-server
Konfiguracja została zapisana w katalogu data, więc usunięcie kontenera nie jest żadnym błędem. Kontener uruchomimy tym poleceniem:
docker run -d --restart unless-stopped -p 80:80 -p 443:443 -p 389:389 -p 636:636 -p 88:88 -p 464:464 -p 88:88/udp -p 464:464/udp -p 123:123/udp --name freeipa-server --sysctl net.ipv6.conf.lo.disable_ipv6=0 -ti -h ipa.avlab.local --read-only -v ~/data:/data freeipa-server
Po wejściu na wskazaną domenę powinniśmy zobaczyć ekran logowania.
Konfiguracja FreeIPA
Przed przystąpieniem do właściwej konfiguracji ważne jest dodanie rekordu do DNS, aby domena serwera FreeIPA była poprawnie rozwiązywana w naszej sieci (po wejściu na adres IP i tak nastąpi przekierowanie na domenę). W moim testowym środowisku za całość obsługi DNS odpowiada Windows Server pełniący rolę kontrolera domeny Active Directory, więc rekord dodaję w DNS Manager.
Jak już wspomniałem, jeśli hosty z Linuxem mają ustawiony inny serwer DNS, wystarczy przypisać domenę FreeIPA do odpowiedniego adresu IP w pliku /etc/hosts — to też zadziała.
Na początek proponuję zmienić domyślną powłokę z /bin/sh na /bin/bash. Dokonamy tego przechodząc do zakładki IPA Server -> Konfiguracja. Ta powłoka będzie stosowana w momencie zalogowania użytkowników, których możemy dodać w zakładce Identity.
Ustawione tutaj hasło jest do zmiany po pierwszym zalogowaniu. Politykę haseł możemy dostosować, przechodząc do Policy -> Password Polices i wybierając domyślną politykę global_policy.
Dostępna we FreeIPA polityka haseł jest w pełni wystarczająca i zgodna ze współczesnymi standardami. Samo wdrożenie podobnych rozwiązań do zarządzania tożsamościami stanowi także jedną z dobrych praktyk z zakresu bezpieczeństwa IT. Wiedza z tej dziedziny jest istotna w pracy związanej z security, a oferty pracy dla specjalistów znajdziemy w serwisie theprotocol.it.
Zdecydowanie najważniejszym ustawieniem jest dodanie polityki sudo. Należy wejść w zakładkę Policy -> Sudo i dalej Sudo Rules. Dodajemy nową regułę i od razu ją edytujemy.
Tutaj mamy do dyspozycji kilka reguł, tzn. możemy określić, dla kogo stosujemy dodaną regułę, do jakich hostów ma zastosowanie, jakie polecenia są dozwolone / zablokowane i w ramach których użytkowników możemy wykonywać polecenia (sudo -u). Najprościej zostawić domyślną opcję (Specified Users and Groups) przy Who, a dla wszelkich pozostałych wybierać drugą z nich, czyli:
- Access this host: Any Host
- Run Commands: Any Command
- As Whom: Anyone i AnyGroup
Dodatkowo polecam dodać do Options wpis !authenticate, aby umożliwić wykonywanie poleceń sudo bez podawania hasła.
Użytkownika możemy przypisać do danej polityki, wchodząc w jego edycję i dalej do karty Sudo Rules.
Dodanie hostów do domeny
Nazwa każdego dodawanego hosta musi zawierać domenę, np. web.avlab.local. Sam proces dodawania nie jest szczególnie trudny, ponieważ wystarczy zainstalować pakiet freeipa-client i wykonać
sudo ipa-client-install --mkhomedir
Parametr –mkhomedir jest dość istotny, ponieważ umożliwi automatyczne tworzenie katalogów domowych przy pierwszym logowaniu danych użytkowników. Ten sam efekt można też osiągnąć odpowiednią modyfikacją modułów PAM, ale zwyczajnie szybciej jest dodać wspomniany parametr.
Ponownie pojawi się kilka kroków, na które musimy odpowiedzieć:
- Provide the domain name of your IPA server (ex: example.com): avlab.local
- Provide your IPA server name (ex: ipa.example.com): ipa.avlab.local
- Proceed with fixed values and no DNS discovery? [no]: yes
- Do you want to configure chrony with NTP server or pool address? [no]
- Continue to configure the system with these values? [no]: yes
- User authorized to enroll computers: admin
- Password for [email protected]: (podajemy ustawione wcześniej hasło)
W przypadku braku błędów logowanie z użyciem kont FreeIPA będzie już możliwe.
Widać, że wymagana była zmiana hasła i został utworzony katalog domowy. Jeśli wykonamy sudo -l to przekonamy się, że faktycznie użytkownik posiada uprawnienia sudo bez konieczności podawania hasła.
Użytkownicy FreeIPA nie są widoczni w plikach /etc/passwd czy /etc/shadow — ich baza jest przechowywana na serwerze FreeIPA, a nie na poziomie lokalnych hostów. Za obsługę takich autoryzacji odpowiada usługa SSSD (System Security Services Daemon), która zresztą wywodzi się właśnie od FreeIPA.
SSSD posiada własny mechanizm cache, dlatego niektóre zmiany wprowadzone w panelu FreeIPA mogą nie być zastosowane ad hoc. Usunięcie użytkownika nie jest co prawda w zakresie tego problemu, ale już przypisanie istniejącego użytkownika do innej Sudo Rules czy dodanie przez niego klucza SSH w celu logowania bez podawania hasła (dodani użytkownicy również mają dostęp do panelu, oczywiście na standardowych uprawnieniach) — niestety jak najbardziej.
Podsumowanie
FreeIPA to użyteczne narzędzie pozwalające na scentralizowane zarządzanie użytkownikami i ich uprawnieniami. Stosowanie podobnych rozwiązań zdecydowanie nie powinno być ograniczone jedynie do dużych organizacji.
Z drugiej strony nie można zapominać o różnych nie do końca autoryzowanych sposobach dostępu do naszych systemów. Przede wszystkim trzeba zwracać uwagę na te elementy infrastruktury, które są publicznie dostępne i ograniczać dla nich otwarte porty czy dozwolone zakresy adresów IP. Ważne jest też przeprowadzanie aktualizacji systemów operacyjnych i zainstalowanego oprogramowania, ponieważ nowe wersje mogą naprawiać ewentualne błędy bezpieczeństwa.
