Ograniczenie dostępu użytkownika do konta root

18.10.2019 | Tomasz Mzyk

Wstęp

Zacznijmy nietypowo ...

Kto z was korzysta w domu z komputera, notebooka, telefonu? Z dużą dozą prawdopodobieństwa wszyscy.
Zadajmy sobie jeszcze jedno pytanie. Ilu z was pracuje na koncie administratora, czując się panem własnego ogródka? Odpowiedź będzie prawdopodobnie taka, jak przy pierwszym pytaniu.

O ile używanie konta wysoko uprzywilejowanego administrator/root w domu jest powszechne, to o tyle w firmach i przedsiębiorstwach jest już inaczej. W dobie dzisiejszych systemów do automatyzacji procesów w jak najmniejszym stopniu powinniśmy używać konta o wysokich uprawnieniach.

Dlaczego nie powinniśmy używać konta administrator/root? Najważniejszym powodem jest bezpieczeństwo. Pracując na użytkowniku standardowym mamy ograniczony dostęp do zasobów używanego sprzętu: nie możemy wykonać operacji, które mogą mieć wpływ na konta innych użytkowników oraz stabilność naszego systemu. Gdy korzystamy z konta administrator/root mamy dostęp do wszystkich zasobów komputera, wszystkich użytkowników itp. Przy włamaniu na takie konto, poprzez błędy w przeglądarce, protokole sieciowym itp., wszystkie dane, jakie mamy na komputerze będą dostępne. W przypadku, gdyby zaistniała taka sytuacja, w której pracowalibyśmy na normalnym użytkowniku, dane innych użytkowników oraz system będą bezpieczne.

Dlatego zrodził się pomysł zabezpieczenia użytkowników poprzez ograniczenie a wręcz całkowite zablokowanie korzystania z użytkownika administrator/root.

Konfiguracja sudo

Na systemach z rodziny Unix, odkąd pamiętam, było polecenie sudo, umożliwiające wykonywanie komend na prawach root. Konfiguracja może nie jest łatwa i przyjemna, jednak po pewnym czasie można się do niej przekonać.

Po konfiguracji profilu sudo zwykły użytkownik może wykonać komendy z uprawnieniami użytkownika root. Na przykład:
- montowanie dysków,
- czytanie logów,
- konfiguracja sieciowa.

Konfigurację sudo możemy przeprowadzać zarówno dla pojedynczego użytkownika jak i dla grup użytkowników: lokalnych oraz np. z domeny Active Directory, czy katalogu LDAP.

Dla przykładu prosta konfiguracja sudo pozwalająca na montowanie i odmontowanie dysku.

# Example sudo profile
Cmnd_Alias CMD_MOUNT_DISK = /bin/mount, \
					/bin/umount, \
					/sbin/mount.cifs, \
					/sbin/mount.nfs, \
					/sbin/mount.nfs4, \
					/bin/umount, \
					/sbin/umount.cifs, \
					/sbin/umount.nfs, \
					/sbin/umount.nfs4, \
					/usr/sbin/showmount

user_sudo   ALL=(root)  NOPASSWD: CMD_MOUNT_DISK

Jeżeli zobaczymy teraz uprawnienia użytkownika, mamy:

Poprzez sudo można w bardzo prosty sposób dodać opcję logowania na użytkownika root, którą możemy dopisać do naszego pliku konfiguracyjnego o ile zajdzie taka potrzeba:

# You became root
user_sudo   ALL=NOPASSWD:/bin/su -

Po wykonaniu komendy sudo su – logujemy się bezpośrednio na użytkownika root:

Ograniczenie systemu do używania konta root

Pracując z systemami operacyjnymi z rodziny Unix, zauważyliśmy, że wielu użytkowników (analitycy, developerzy, administratorzy aplikacji) wykorzystywali konto root do konfiguracji aplikacji, systemu operacyjnego często powodując, że systemy po aktualizacji lub restarcie nie nadają się do użytku.

Zgodnie z obowiązującymi standardami, zmiany systemowe powinny być nanoszone w udokumentowany sposób, przez aplikacje do zarządzania typu: Chef, Ansible, Puppet. Przy wszystkich za i przeciw, w dyskusjach doszliśmy do wniosku, że używanie konta root powinno zostać zminimalizowane.

Jak to bywa w dużych firmach, hasła kont są (a przynajmniej powinny) być utrzymywane w bazach i systemach typu Vault, aby można było w łatwy sposób zarządzać dla nierzadko dużego wolumenu systemów. Z aplikacji typu Vault powinna być możliwość pobrania hasła do pojedynczego lub wielu systemów. Z takiej możliwości często korzystała wspomniana wyżej grupa kolegów z IT.

W Internecie na ten czas brakowało konkretnych informacji na temat blokowania konta root, więc przystąpiliśmy sami do działania. Najczęściej pojawiała się opcja użycia modułów PAM (Pluggable Authentication Modules), które w przystępny sposób umożliwiały konfigurację autentykacji, autoryzacji różnego typu aplikacji.

Niestety większość artykułów, rozwiązań, dokumentacji opisywała sytuację, w której chcemy, aby dostęp do konta root miała niewielka grupa użytkowników. Możemy to w łatwy sposób konfigurować poprzez następującą konfigurację:

Dodanie użytkownika do grupy wheel
```
usermod -G wheel >username<
```

W pliku ⁄etc⁄pam.d⁄su musimy odkomentować linię:

#auth           sufficient      pam_wheel.so trust use_uid

Przy takiej konfiguracji użytkownicy z grupy wheel mogą spokojnie przelogować się na root bez podawania hasła:

Pierwsze koty za płoty. Jednak tutaj zaczęły się schody i wyzwania.

Co zrobić, aby można było np:
- dawać dostęp więcej niż jednej grupie ?
- co w przypadku, gdy mamy wykorzystać autoryzację na podstawie grup domenowych ?

Niestety rozwiązanie z grupą wheel w przypadku integracji z domeną nie działa. Próbowałem również poprzez profile w katalogu ⁄etc⁄profile jednak to również nie zdało egzaminu.

Po przeanalizowaniu dokumentacji modułów PAM oraz artykułów, stworzyłem następujące rozwiązanie:

Tworzymy dodatkowy plik ⁄etc⁄pam.d⁄su-noroot i linkujemy do ⁄etc⁄pam.d⁄su

#%PAM-1.0
auth            sufficient      pam_rootok.so
auth            required        pam_exec.so expose_authtok debug log=⁄tmp⁄debug.log ⁄usr⁄bin⁄noroot.sh
auth            substack        system-auth
auth            include         postlogin
account         sufficient      pam_succeed_if.so uid = 0 use_uid quiet
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         include         postlogin
session         optional        pam_xauth.so

Tworzymy skrypt ⁄usr⁄bin⁄noroot.sh :

#!⁄bin⁄bash

# grupy z dostepem do root
GROUP_ROOT_ACCESS=(grupa_ad_01 grupa_ad_02)
# sprawdzamy id logoujacego sie uzytkownika
USER_NAME=$(id -nu)
SUM_ACCESS=0

for i in ${GROUP_ROOT_ACCESS[@]}
do
    if [[ "$(id -nG ${USER_NAME})" =~ "${i}" ]];then
        SUM_ACCESS=$(expr ${SUM_ACCESS} + 1)
    fi
done

if [[ "${SUM_ACCESS}" -eq 0 ]];then
    if [[ ${PAM_USER} == 'root' ]];then
        kill -HUP $PPID 2>&1 > ⁄dev⁄null
    fi

fi

Ustawiamy uprawnienia do skryptu na 750
```
chmod 750 ⁄usr⁄bin⁄noroot.sh
```
Ustawiamy właściciela pliku na root.root
```
chown root.root ⁄usr⁄bin⁄noroot.sh
```
Testujemy!

Po zalogowaniu się użytkownikiem, który należy do grupy domenowej z listy GROUP_ROOT_ACCESS (dla przykładu: grupa_admin), użytkownik po otrzymaniu hasła root może swobodnie przelogować się na użytkownika administrator⁄root.

W przypadku użytkowników, którzy nie mają grupy domenowej z listy, po próbie zalogowania wyskakuje komunikat : HANGUP.

Podsumowanie

To już jest koniec... W prosty sposób korzystając z powyższych komend oraz plików konfiguracyjnych możemy ograniczyć praktycznie do zera korzystanie z konta root. Tak jak pisałem powyżej, jeżeli nie musimy, nie korzystajmy z tego konta. Lepiej korzystać z narzędzi automatyzujących. Oczywiście dobrze byłoby wprowadzić sobie np. monitoring plików, które uważamy za wrażliwe. Można do tego używać na systemach Linux np. narzędzi: aide, tripwire. Ale to już inna bajka i historia.

Spis treści

Wstęp
Konfiguracja sudo
Ograniczenie systemu do używania konta root
Podsumowanie