Bezpieczniejszy LINUKS

Pojawienie się nowego serwera w infrastrukturze rodzi potrzebę zapewnienia mu odpowiedniego poziomu bezpieczeństwa. Jednym ze stosowanych rozwiązań jest "wpięcie" go w siatkę zewnętrznych mechanizmów ochronnych. Często jednak zapomina się o sprawach najprostszych, takich jak utwardzenie (hardening) systemu operacyjnego. Dzięki takiej operacji nie tylko zwiększymy poziom bezpieczeństwa serwera, lecz także podniesiemy jego wydajność.

Omówimy tu najważniejsze punkty procesu hardeningu, pozostawiając czytelnikowi ich dokładne 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.

Na etapie instalacji postarajmy się również ograniczyć instalowane usługi. Jeżeli np. instalujemy system Centos 5.x, wybierzmy jako rolę "Server" (bez GUI), a następnie odznaczmy niepotrzebne aplikacje czy moduły serwerowe (np. FTP Server, Network Servers czy Server Configuration Tools). Upewnijmy się także, że nie instalujemy systemu X-Windows. Jeżeli tak się stanie, po instalacji systemu zawsze można naprawić ten błąd, wykonując polecenie yum groupremove "X Window System".

Niepotrzebne usługi systemowe

Na początek dobrze jest też przyjąć zasadę, że wszystkie połączenia do i z serwera powinny być szyfrowane. Należy więc wyeliminować usługi, które z racji swojej konstrukcji przesyłają dane otwartym tekstem, np. FTP, rsh, telnet.

Jeżeli sami instalowaliśmy system, to mamy pełnię kontroli nad instalowanymi aplikacjami. Zdarza się jednak, że serwer przygotowuje Helpdesk, instalując go z jakiegoś szablonu. W takim przypadku musimy sami zadbać o wyeliminowanie niepotrzebnych usług.

Zakładając, że nie mamy X-ów, będziemy korzystali z runlevel 3. Trzeba więc sprawdzić, jakie usługi działają na tym poziomie. Najprościej zrobić to z wykorzystaniem narzędzia chkconfig:

# chkconfig -list | grep 3:on

Poziomy (runlevels) w Linuksie

0 - system zatrzymany1 - tryb single user (oznaczany często symbolem "S")  2 - tryb single user (z obsługą sieci) 3 - tryb wielu użytkowników (tryb CLI - brak środowiska graficznego - najczęściej wykorzystywany dla serwerów) 4 - tryb specjalny (niewykorzystywany) 5 - tryb wielu użytkowników (z obsługą środowiska graficznego - typowo stosowany w stacjach roboczych) 6 - ponowne uruchomienie systemuWywołanie określonego trybu: # init [numer poziomu]

Zwykle znajdziemy tam wiele usług, z których część nie będzie potrzebna, co jednak zależy od przeznaczenia serwera. Możemy więc spokojnie wyłączyć m.in. wsparcie dla drukarek (cups), zmodyfikowaną wersję cron-a (anacron), firewalla dla IPv6 (ip6tables) czy obsługę HAL (haldaemon).

Tutaj znowu wykorzystujemy polecenie chkconfig:

# chkconfig [nazwa usługi] off Można też od razu pozbyć się usługi raz na zawsze - wówczas "off" zastępujemy "del".

Możemy również ułatwić sobie życie i zamiast kolejno wyłączać/usuwać każdą kolejną usługę - wykorzystać prostą pętlę for. Wystarczy wcześniej przygotować plik tekstowy z usługami, których nie chcemy (np. lista_uslug.txt):

# for usluga in (<'lista_uslug.txt'); do chkconfig usluga off; done

Oprócz chkconfig jest też prościutkie i bardziej okienkowe narzędzie ntsysv.

Na wszelki wypadek warto też w analogiczny sposób sprawdzić runlevel 5.

A skoro mowa o usługach. Trudno wyobrazić sobie skuteczne zarządzanie Linuksem bez dostępu zdalnego przez SSH. Dlatego na jedną rzecz w konfiguracji tej usługi warto zwrócić uwagę. Grzechem numer jeden (niestety często popełnianym) jest pozostawienie możliwości zalogowania się zdalnego od razu na konto roota. Aby sprawdzić/wyeliminować obecność tej luki, trzeba poszukać parametru PermitRootLogin w pliku /etc/ssd/sshd_config. Powinien mieć wartość "no".

źródło: http://www.networld.pl