Tyle się mówi o bezpieczeństwie. Ochrona przed ransomware. Backup. Dostęp zdalny. Blokowanie portów. I cała masa innych zagadnień.

To są jednak elementy, o których wiedzą wszyscy. Tymczasem w samym linuksie jest cała masa pomijanych elementów. Warto o nie zadbać!

Choćby sam hardening usług. Niewiele osób to stosuje jednak samo Systemd może nam pomóc w znaczącym podniesieniu bezpieczeństwa serwera Linux. Zapraszam do artykułu, w którym wyjaśnię Ci jak posługiwać się tym narzędziem.

1. Dynamic User

Na początek mechanizm separacji uprawnień użytkowników. Jak wiemy, do działania każdej usługi wymagany jest użytkownik. Możesz zdefiniować użytkowników za pomocą User = w sekcji [Service] pliku konfiguracyjnego usługi.

Systemd zapewnia mechanizm tworzenia użytkowników na żądanie. W przypadku wywołania z DynamicUser = yes, do usługi jest przydzielany unikalny numer użytkownika. Numer oznacza tymczasową nazwę użytkownika. To przypisanie nie jest przechowywane w bazie użytkowników linuksa. Zamiast tego jest generowane w locie Po zatrzymaniu usługi numer może zostać później ponownie wykorzystany dla innej usługi.

Kiedy w usłudze powinien być używany zwykły statyczny użytkownik, a kiedy preferowany jest dynamiczny?

Użytkownicy dynamiczni są świetni, gdy tożsamość użytkownika jest ulotna i nie jest potrzebna integracja z innymi usługami w systemie.

Natomiast, nie jest to najlepsze rozwiązanie gdy:

• w bazie danych mamy politykę zezwalającą na dostęp dla określonego użytkownika
• katalogi są współdzielone z określoną grupą lub jakąkolwiek inną konfigurację, w której musimy odnosić się do nazwy użytkownika.

Dzięki parametrowi DynamicUser, Systemd przydziela nowego nieuprzywilejowanego użytkownika przy każdym wywołaniu. Co oznacza, że użytkownik ten nie ma dodatkowych uprawnień w systemie.

Jak coś takiego zrobić?

Wejdź w ustawienia usługi. Przykładowo, gdybyś konfigurował usługę SSH to musiałbyś zmienić plik:

/usr/lib/systemd/system/sshd.service

Dodaj parametr DynamicUser w sekcji [Service]. Tak jak tu:

[Service]
# Generuje użytkownika na starcie.
DynamicUser=yes

2. Mount Namespaces

Pozostajemy bardzo blisko tematu DynamicUser.

Tacy przejściowi użytkownicy są możliwi tylko wtedy, gdy zadaniem usługi nie jest tworzenie danych na dysku.

Gdyby te dane były widoczne dla innych użytkowników w systemie lub nawet mógłby uzyskać do nich dostęp nowy, przejściowy użytkownik o takim samym numerze to mogłoby to spowodować nieautoryzowany dostęp do danych.

Systemd używa przestrzeni nazw montowań. Dzięki temu usługa nie może zapisać danych w kluczowych katalogach systemu. Aby umożliwić przechowywanie na stałe, katalog prywatny jest montowany w drzewie systemu plików widocznym dla usługi.

Mamy tu spore pole do modyfikacji. Poniżej masz ustawienia, które warto poznać i stosować.

ProtectHome=

pozwala nam używać niewspółdzielonej przestrzeni nazw montowania w taki sposób, aby /home był tylko do odczytu lub całkowicie niedostępny.

ProtectSystem=

używamy do ochrony /usr, /boot, and /etc

PrivateTmp=

Używa przestrzeni nazw montowania, aby prywatny katalog był widoczny jako /tmp i /var/tmp dla usługi. Pliki tymczasowe usługi są ukryte przed innymi użytkownikami, aby uniknąć problemów związanych z kolizjami nazw plików lub nieprawidłowymi uprawnieniami.

Widokiem systemu plików można zarządzać na poziomie poszczególnych katalogów poprzez

ustawienia InaccessiblePaths =, ReadOnlyPaths =, . Zapewniają one dostęp do wszystkich części hierarchii systemu plików lub tylko do zapisu w nich.

ReadWritePaths = dotyczy przywracania dostępu, co jest przydatne, gdy chcemy nadać pełny dostęp tylko do określonego katalogu głęboko w hierarchii.

BindPaths = i ReadOnlyBindPaths = pozwalają na przenoszenie katalogów, a dokładniej mówiąc, prywatne łączenie ich w inne miejsce.

Upraszczając, jest to taki trochę sandbox. Z angielskiego piaskownica. Po odpowiednim skonfigurowaniu usługi działają jak wyizolowane byty bez dostępu do innych zasobów.

Zwróć uwagę na to, że te zabezpieczenia są niezależne od podstawowego mechanizmu kontroli dostępu do plików przy użyciu uprawnień systemowych. Jeśli system plików jest zamontowany tylko do odczytu, nawet użytkownicy, którzy mogliby modyfikować określone pliki w oparciu o standardowe uprawnienia, nie mogą tego zrobić, dopóki system plików nie zostanie ponownie zamontowany w trybie odczytu i zapisu. Zapewnia to ochronę przed błędami w zarządzaniu plikami.

3. Automatyczne tworzenie katalogów dla usługi

Systemd zarządza dostępem do katalogów za pomocą parametrów ConfigurationDirectory =, CacheDirectory =, StateDirectory =, LogsDirectory = i RuntimeDirectory =.

Automatyczne zarządzanie katalogami dobrze łączy się z ustawieniem DynamicUser = i automatycznie tworzonymi użytkownikami, zapewniając usługę, która działa jako oddzielny użytkownik. Co oznacza, że nie może modyfikować większości drzewa systemu plików (nawet jeśli pozwolą na to uprawnienia dostępu do plików). Usługa może nadal uzyskiwać dostęp do wybranych katalogów i przechowywać tam dane, bez żadnej konfiguracji innej niż konfiguracja pliku jednostki.

Przykładowo, takie ustawienie:

[Service]
DynamicUser=yes
ProtectHome=yes
StateDirectory=webserver
WorkingDirectory=/srv/www/content

Gwarantuje nam, że usługa działał jako użytkownik przejściowy bez możliwości modyfikowania systemu plików czy dostępu do danych użytkownika.

Kiedy dobrze rozumiemy, co robi i czego potrzebuje usługa, możemy zastanowić się, jakie przywileje są wymagane, a co możemy im odebrać. Im bardziej pozwolimy Systemd na skonfigurowanie rzeczy za nas, tym większe prawdopodobieństwo, że usługa będzie mogła pomyślnie działać jako użytkownik nieuprzywilejowany. Często usługa wymaga dostępu do określonego podkatalogu i możemy to osiągnąć za pomocą parametru ReadWritePaths =.

4. Audyt Systemd

Dodanie środków bezpieczeństwa w jakikolwiek sposób automatyczny jest niemożliwe. Bez dobrego zrozumienia potrzeb usługi w różnych scenariuszach konfiguracji i dla różnych operacji nie możemy zdefiniować tych parametrów.

Dlatego też moja sugestia jest tu taka. Jeżeli w pracy dostaniesz zadanie administrowania jakąś konkretną aplikacją lub usługą to zachęcam do jak najbardziej dogłębnego przestudiowania jej dokumentacji. Pozwoli Ci to zrozumieć co dokładnie robi aplikacja. Czy zrozumieć na jakich plikach i katalogach pracuje. Tym samym zrozumiesz do czego może mieć dostęp użytkownik wykorzystywany przez usługę, a do czego nie powinien.

Liczba możliwych ustawień jest duża, a nowe są dodawane z każdym wydaniem Systemd. Nadążanie za tym jest trudne. Na szczęście Systemd zapewnia narzędzie, które pozwala nam poznać działanie usług i wymagania jakie posiadają.

Służy do tego polecenie:

systemd-analyze security

Dla przykładu zróbmy:

systemd-analyze security sshd.service

Jak widzisz, jest tu cała masa parametrów, które Systemd sugeruje, by poprawić:

By była jasność to, że mamy tu taki wynik to nie oznacza, że serwer nie jest zabezpieczony. Najzwyczajniej jednak jest sporo rzeczy do poprawienia.

Na szczęście kolumna Description od razu daje nam podpowiedź co należy zrobić, by poprawić bezpieczeństwo. I wiele z nich da się łatwo naprawić. Np. Service runs as root user. Wydaje mi się, że nie muszę tłumaczyć co z tym trzeba zrobić :)

Wytłumaczę za to gdzie to zmienić. Ponownie, w pliku ustawień usługi:

sudo vi /usr/lib/systemd/system/sshd.service

Dodaj:

[Service]
User=twój_użytkownik
Group=grupa

Aha, polecenie:

systemd-analyze security

da Ci podgląd na wszystkie usługi w systemie. Im wyższa punktacja tym z większą uwagą powinieneś się przyjrzeć usłudze.

Zatem jeżeli masz czas lub trafisz do działu związanego z bezpieczeństwem to jak najbardziej warto to sprawdzić i systematycznie poprawić.

Sporo dłubania. Ale ciekawego dłubania.

I naturalnie, pamiętaj, by nie odkrywać koła na nowo. Jak nie wiesz jak zmienić konkretne ustawienie to Google zna odpowiedź.