Linux twardy jak skała

Pojawienie się nowego serwera w infrastrukturze rodzi potrzebę zapewnienia mu odpowiedniego poziomu bezpieczeństwa. Cel ten jak zwykle można osiągnąć na wiele sposobów. Zazwyczaj realizowany jest poprzez "wpięcie" serwera w siatkę zewnętrznych mechanizmów ochronnych. Często jednak zapomina się o sprawach najprostszych. Jedną z nich jest utwardzenie systemu operacyjnego. Dzięki temu nie tylko zwiększymy poziom bezpieczeństwa serwera, lecz także podniesiemy jego wydajność.

Niniejszy artykuł jest pierwszym z dwóch, w których będziemy prezentowali proces utwardzania systemów operacyjnych. W pierwszej części hardeningowi poddamy system Linux, w kolejnej - Windows Server.

Omówimy najważniejsze punkty procesu hardeningu, pozostawiając czytelnikowi ich zgłębienie. Z braku miejsca pominiemy także kwestię utwardzania poszczególnych aplikacji. Ponieważ każda seria Linuksa ma odrębne właściwości, postanowiliśmy przykłady podawać dla jednej z nich - ulubionego przez autora CentOS-a.

Na początek

Proces utwardzania można rozpocząć już podczas instalacji systemu operacyjnego, a nawet chwilę wcześniej. Dzieje się to na etapie alokacji zasobów. Dobrą praktyką jest uruchamianie tylko jednej ważnej usługi (np. serwera baz danych) na danej instalacji systemu - niezależnie od tego, czy jest to maszyna fizyczna, czy platforma wirtualna. Chodzi o uniknięcie sytuacji, gdy awaria jednego serwera powoduje paraliż wielu systemów. Warto też pamiętać o ochronie fizycznej samej maszyny (np. autoryzacji dostępu do serwerowni, możliwości otwierania szaf serwerowych itp.). Bezpieczeństwo fizyczne centrum przetwarzania danych to jednak osobny temat.

Jeszcze przed instalacją systemu możemy zabezpieczyć dostęp do parametrów konfiguracyjnych BIOS hasłem, a po jej zakończeniu wyłączyć możliwość uruchamiania systemu z nośników zewnętrznych. Jeżeli kontrola dostępu fizycznego jest na odpowiednio wysokim poziomie, będzie to trudne do przełamania zabezpieczenia.

W trakcie instalacji systemu operacyjnego przechodzimy przez kilka etapów, które mogą stanowić kolejne kroki utwardzania. Jednym z pierwszych jest podział na partycje. Oprócz wymaganej partycji "/" (root) zaleca się utworzenie osobnych partycji przynajmniej dla:

katalogu tymczasowego (/tmp)

katalogów profili użytkowników (/home)

partycji rozruchowej (/boot)

katalogu tzw. danych zmiennych (/var) - tutaj umieszczane są np. dane audytowe, wszelkiego rodzaju logi, bazy danych, kolejki pocztowe

katalogu programów i kodu źródłowego (/usr)

a jeżeli planujemy instalację oprogramowania niestandardowego - przyda się partycja /opt.

Czasami trudno jest z góry przewidzieć wielkość i liczbę wszystkich partycji, dlatego warto skorzystać z mechanizmu LVM (Logical Volume Manager), który zapewnia elastyczność w alokacji miejsca przeznaczonego na każdą z nich. Atrybuty samych partycji zostaną omówione dalej.

Często już na etapie instalowania można przypisać hasło menedżerowi rozruchowemu GRUB (GRand Unified Bootloader), co poza hasłem w BIOS-ie utrudni zmianę parametrów rozruchowych systemu, a także wejście w tryb Single User. Dla przypomnienia, "runlevel 1" lub tryb Single User dają dostęp z uprawnieniami użytkownika root do zasobów komputera bez konieczności podawania hasła. Aby wykorzystać jego możliwości, konieczny jest dostęp konsolowy do systemu, np. poprzez port SERIAL, interfejs DRAC/iLO. Jeśli jednak celem jest destabilizacja systemu, to wywołanie go z poziomu CLI może spowodować odłączenie serwera od sieci. Tryb Single User może zostać wywołany albo podczas restartu systemu i edycję parametrów rozruchowych z poziomu menedżera rozruchowego (np. w GRUB - dodanie wartości "1" na końcu linii "kernel"), albo poprzez użytkownika posiadającego odpowiednie uprawnienia poleceniem /sbin/init 1. O ile z pierwszym przypadkiem można sobie poradzić, ustawiając hasło w menedżerze rozruchowym (por. ramka), o tyle drugi jest trochę bardziej uciążliwy. Teoretycznie normalny użytkownik nie powinien móc go wywołać. Problem w tym, że np. błędna konfiguracja SUDO lub przypisanie zbyt wielu praw w inny sposób może spowodować, że użytkownikowi się to uda. Aby ochronić się przed wejściem w Single User z poziomu powłoki systemu, można posłużyć się małym fortelem. W pliku odpowiadającym za inicjalizację systemu (wywoływanym zaraz po załadowaniu jądra) - /etc/inittab należy dodać linię:

su:S:wait:/sbin/sulogin

bezpośrednio nad wpisem

id:[numer poziomu - z reguły 3 lub 5]:initdefault

To spowoduje, że wywołanie init 1 co prawda się powiedzie, ale użytkownik przed skorzystaniem z jego zalet będzie musiał dodatkowo podać hasło roota.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200