Analiza bezpieczeństwa Red Hata 7.3 w hipotetycznej firmie

-- Sebastian Pawlak, 2003.

Pierwsza wersja pracy wysłanej na konkurs "Grasz o staż" organizowany przez PricewaterhouseCoopers i Gazetę Wyborczą.

1. Założenia i opis konfiguracji serwera

Dobór konfiguracji serwera zależny jest od przyszłych zadań, jakie będzie miał on realizować. Zakładam, że moja firma zajmuje się sprzedażą on-line urządzeń AGD. Struktura sieci przedsiębiorstwa nie jest złożona. Mamy kilka stanowisk z komputerami, przy których pracownicy zarządzają bazą danych dostępnych produktów oraz etapami realizacji zamówień. Należy także wymienić komputery pracujące w księgowości, dziale informatycznym i gabinecie dyrektora. Kluczowy serwer, z nowo zainstalowanym systemem operacyjnym RedHat 7.3, podłączony jest do internetu. Wybrano opcję instalacji "Server". Na komputerze tym utrzymywana jest strona internetowa firmy, na której klienci mogą zapoznać się z nasza ofertą oraz dokonać zamówienia. Strony funkcjonują dzięki serwerowi Apache w wersji 1.3.23, PHP w wersji 4.1.2 i bazie danych Postgresql w wersji 7.2.1, które to pochodzą z dystrybucji RedHat 7.3. Serwer zapewnia także pracownikom dostęp do internetu (masquerade). Zainstalowano na nim serwer ftp WuFtp w wersji 2.6.2, założono pracownikom konta shellowe z możliwością zdalnego logowania (niektórzy pracownicy pracują zdalnie). Zdalny dostęp do serwera zapewnia OpenSSH w wersji 3.1p1-3.

Wybór dystrybucji RedHat 7.3 (Valhalla) nie jest zły. Można było jedynie zastanowić się nad zainstalowaniem nowszej wersji systemu. W przypadku starszej wersji należy wnieść większy wkład pracy w zabezpieczenie. Nie bez znaczenia, w podejmowaniu decyzji o wyborze RedHata, był fakt, że producent zapewnia bardzo dobre wsparcie w aspekcie szybkiej reakcji na wykryte w systemie błędy. Dodatkowo, RedHat zatrudnia uznanych hakerów (jak choćby Alana Cox`a), którzy wprowadzają innowacje do kernela, kompilatora gcc i oprogramowania. Wydaje się, że RedHat ma ambicje tworzyć system przyjazny zarówno dla zwykłych użytkowników, jak i dla administratorów. Niestety, domyślne aktywowanie wielu, często zbytecznych, usług, nadawanie wysokich praw nawet grom komputerowym, nie idzie w parze z podnoszeniem bezpieczeństwa. RedHat nadaje się świetnie na serwery - świadczą o tym, chociażby produkowane przez IBM, serwery z preinstalowanym tymże systemem. Po prostu, instalacja tej dystrybucji na serwerze, wiąże się z wieloma pracami konfiguracyjnymi, by uczynić system bezpiecznym.

2. Ocena bezpieczeństwa

Przed podjęciem innych działań, mających na celu ocenę bezpieczeństwa systemu, należy zapoznać się z zawartością erraty na stronach RedHata, pod adresem: https://rhn.redhat.com/errata/rh73-errata.html Oczom naszym ukaże się pokaźna lista luk datowanych od połowy 2002 roku. Wiele z wymienionych tam pozycji, ma krytyczne znaczenie i należy wprowadzić stosowne poprawki do systemu.

Oceny bezpieczeństwa, w pewnych jego aspektach, można dokonać bez wyspecjalizowanych narzędzi. Doświadczony administrator wie jakie elementy danego systemu mogą sprawić problem, jest w stanie sprawdzić ich aktualną konfigurację i w razie potrzeby ją zmienić. Niestety, w mojej ocenie, obecnie nie ma dobrych i uaktualnianych programów do przeprowadzania wewnętrznej inspekcji systemu. Programy tego typu są na ogół od dawna nie rozwijane, a obszar zainteresowań ich autorów przeniósł się w stronę tzw. skanerów sieciowych. Z tego względu administrator musi polegać na swojej wiedzy. Przykładowo w wersji kernela dostarczonej wraz z RedHatem 7.3 jest błąd umożliwiający lokalny atak typu DOS. Będąc zalogowanym na konto zwykłego użytkownika należy skompilować i uruchomić, dostępny w internecie program napisy w języku C, autorstwa Christophe`a Devine`a: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=77834. Działanie tego exploita kończy się tzw. Kernel Panic i zawieszeniem komputera. Test ten dowiódł, że RedHat 7.3 jest łatwo podatny na zawieszenie przez zwykłego użytkownika. Rozwiązaniem tego, bardzo poważnego, problemu może być instalacja łaty albo nowego kernela. Osobiście zalecam dodatkowo instalację tzw. łaty bezpieczeństwa "grsecurity", która stanowi potężne narzędzie, zabezpieczające system na różne ewentualności (m.in. pośrednio zabezpiecza przed atakiem poprzez demony zawierające błędy, szczegółowo loguje różne zdarzenia w systemie). Brak zainstalowanego firewalla wpływa na obniżenie bezpieczeństwa. Postulowałbym utworzenie firewalla, który skutecznie separowałby ruch w sieci lokalnej od reszty świata. Pozostawiłbym jedynie otwarte porty, na których nasłuchują usługi takie jak serwer http, ftp i ssh. Za pomocą polecenia "df" uzyskujemy informację o podziale dysku twardego na partycje. Nasz RedHat 7.3 został zainstalowany na jednej partycji (plus partycja swap). To rozwiązanie nie jest poprawne i stwarza wiele możliwości destabilizacji pracy systemu. Przykładowo, włamywacz mógłby zapełnić swój katalog domowy lub katalog /tmp tak aby na dysku nie pozostało miejsce dla logów systemowych. W ten sposób jego dalsze poczynania nie byłby rejestrowane oraz praca innych użytkowników byłaby praktycznie niemożliwa. Zalecałbym instalację z podziałem na oddzielne partycje dla następujących katalogów: /boot, /usr, /home, /var, /tmp, /. Zainstalowany serwer OpenSSH umożliwia zdalne zalogowanie się na konto roota. Taki stan rzeczy podwyższa ryzyko włamania i nie jest właściwy. Należy zabronić w odpowiednim pliku konfiguracyjnym takiej możliwości. Chcemy by możliwe było zalogowanie się na konto roota bezpośrednio z konsoli lub zdalnie po uprzednim zalogowaniu na inne, uprzywilejowane konto (czasem administrator musi pracować zdalnie; dobrze wyznaczyć adresy hostów, z których można się logować; należy wyznaczyć użytkowników uprzywilejowanych do użycia polecenia 'su'). W świeżo postawionym systemie RedHat 7.3 nie ma ustalonych limitów przydzielanej pamięci, miejsca na dysku, dopuszczalnego obciążenia procesora, itp. Brak troski w tym obszarze grozi możliwością zawłaszczenia zasobów systemu przez użytkownika, co implikuje destabilizację pracy systemu. Kolejnym rutynowym zadaniem, po instalacji systemu, jest usunięcie SUIDów (oraz GUIDów) programom rzadko albo wcale nie używanym oraz takim, których ewentualności uruchamiania, ze specjalnymi przywilejami, nie chcemy. SUIDy są groźne, zwłaszcza gdy posiadające je programy mają błędy - wtedy włamywacz może np. uzyskać uprawnienia roota. Za pomocą sekwencji: "find / -type f \( -perm -04000 -o -perm -02000 \) \-exec ls -lg {} \;" należy wylistować programy, które posiadają SUIDy. Zbędnym aplikacjom powinno się je odebrać (chmod a-s nazwaProgramu). Dobrze przysłuży się instalacja programu, który śledzi zamiany w liście "uprzywilejowanych" aplikacji. Pewne zagrożenie stanowi domyślnie włączona odpowiedź systemu na pingi - stwarza to możliwość ataku DOS. Poprzez wpisanie jedynki do odpowiedniego pliku konfiguracyjnego można zaradzić temu problemowi. Podobnie należy postąpić w celu uodpornienia serwera na stanie się źródłem spoofingu, na zdefragmentowane pakiety oraz inne wypadki. Wszystkie opisane działania są powtarzalne i żmudne. Administrator może stworzyć własny skrypt automatyzujący proces "utwardzania" systemu, bądź posłużyć się gotowym narzędziem. Bastille jest aplikacją wspomagającą proces tzw. hardeningu (czyli utwardzania, zabezpieczania systemu).

O jakości zabezpieczeń serwera można dowiedzieć się dokonując prób jego penetracji. Testy penetracyjne można podzielić na zewnętrzne i wewnętrzne. Testy zewnętrzne polegają na testowaniu zabezpieczeń z komputera znajdującego się poza siecią lokalną - w ten sposób symulujemy ataki crackerów próbujących wedrzeć się na nasz serwer. Testy wewnętrzne pozwalają na symulacje ataków, wymierzonych w serwer, z komputerów znajdujących się w sieci lokalnej lub z samego serwera. Penetracja wewnętrzna pozwala ocenić odporność na zagrożenia płynące ze strony samych pracowników, jak również crackerów, którzy w uzyskali dostęp do serwera. Testy penetracyjne wykonuje się za pomocą ogólnie dostępnych programów zwanych skanerami. Jedną z lepszych tego typu aplikacji jest Nessus. Składa się on z dwóch części. Pierwsza to program demona, który możemy zainstalować na dowolnym komputerze - z tego komputera będzie odbywało się testowanie. Drugą stanowi graficzny interfejs, w którym ustawiamy opcje przeprowadzania testów. Dzięki takiej architekturze Nessus umożliwia wygodne skanowanie z dowolnego komputera, a wyniki możemy oglądać na ekranie monitora ustawionego na naszym biurku. Nessus zawiera dużą bazę często aktualizowanych wtyczek, które zajmują się testowaniem serwera na okoliczność wystąpienia wcześniej wykrytych dziur. Po kilkunastu minutach testów, oczom naszym ukazuje się raport.
I tak, po wykonaniu testów z demona Nessusa zainstalowanego na badanym serwerze, zostajemy poinformowani o wykryciu 8 dziur i ostrzeżeni o 12 możliwych zagrożeniach. Wszystkim "usterkom" zostaje dodatkowo przypisany poziom ryzyka jakie stwarzają. Najgroźniejsze okazały się m.in. błędy w demonach OpenSSH. W RedHat 7.3 występuje OpenSSH w wersji 3.1p1-3. Nessus zakomunikował, że w wersjach OpenSSH starszych niż 3.2.1 istnieje dziura umożliwiająca atak poprzez tzw. przepełnienie buforów generując specjalny ciąg bajtów i zdobycie uprawnień roota. Kolejne ostrzeżenie dotyczy również OpenSSH, lecz tym razem rozchodzi się o błąd umożliwiający zdobycie dostępu do shella. RedHat twierdzi, że przy OpenSSH zainstalowanym z domyślnymi ustawieniami nie ma żadnego niebezpieczeństwa. Mimo wszystko zalecałbym instalację nowej wersji OpenSSH. Jedno z ostrzeżeń wygenerowanych przez Nessusa dotyczy ustawionej wersji protokołu SSH - zalecane jest ustawienie w pliku konfiguracyjnym protokołu 2.
Nie wolny od błędów okazuje się być także serwer http. Etykietę luki o wysokim współczynniku ryzyka dostał mod_ssl (włamywacz może uruchomić program z prawami serwera http). Błąd w mod_ssl został też zaznaczony na stronach z erratą RedHata. Poważną sprawą jest także podatność serwera Apache na tzw. Apache Web Server Chunk Handling Vulnerability. Nessus ostrzega, że posiadana przez nas wersja Apache`a (starsza niż 1.3.27) zawiera szereg luk i najlepiej zainstalować nową. Kolejne ostrzeżenia tyczące się serwera http to m.in. podatność na ataki cross-site-scripting, możność podsłuchu i deszyfracji niektórych danych (za sprawą starej wersji OpenSSL) i zbyt obszerne informowanie przez serwer o zainstalowanym oprogramowaniu (Apache/1.3.23 (Unix) (Red-Hat/ Linux) mod_ssl/2.8.7 OpenSSL/ 0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26). Na jednym z wysokich portów, Nessus odnalazł działający serwis "statd". Ze względu na szereg luk pojawiających się w tym programie, od początku jego istnienia, zalecane jest wyłączenie go lub instalacja nowej wersji. Ten sam postulat tyczy się wykrytego serwisu "fam".
Nie polecam użytkowania, dostarczanych wraz z RedHatem, demona ftp Wu-ftp oraz poczty Sendmail - w zamian proponowałbym odpowiednio ProFTPD i Postfix. Jakkolwiek Nessus jest bardzo dobrym narzędziem to nie można przeceniać jego możliwości. Warto za pomocą polecenia "lsof -i" wylistować nasłuchujące usługi, a następnie sprawdzić w internecie czy wykryto w nich jakieś błędy.

Teoretyzując nad bezpieczeństwem systemu również można dojść do ciekawych wniosków.
Hipotetyczny złoczyńca mógłby wejść niespostrzeżenie do siedziby firmy i dokonać penetracji sieci korzystając z komputera, którego użytkownik zostawił otwartą sesję i oddalił się od stanowiska. W celu zapobieżenia takim ewentualnościom nasza firma, już dawno temu, wprowadziła elektroniczne karty chipowe, bez których nie można wejść na teren. Zdajemy sobie sprawę, że najsłabszym ogniwem systemu zabezpieczeń, jest człowiek. Z tego też względu przeprowadzamy regularne szkolenia pracowników. Uczymy m.in. jak należy tworzyć hasła, przypominamy, że pod żadnym względem nie można ich zapisywać na przyklejanych do monitora karteczkach. Uczulamy na konieczność zabezpieczenia komputera wygaszaczem ekranu z hasłem, przed oddaleniem się od stanowiska pracy. Zdumiewające jak przestrzeganie takich prostych zaleceń potrafi znakomicie podnieść bezpieczeństwo systemu. Słynny haker Kevin Mitnick, który promował w Polsce swoją książkę o wymownym tytule "Sztuka podstępu. Łamałem ludzi, nie hasła", stwierdził, że manipulując ludźmi (tzw. inżynieria społeczna) można wedrzeć się do potężnie zabezpieczonych systemów. Zagrożenie może też przyjść ze strony, z której niewielu ludzi by się go spodziewało. Odpowiednie służby państwowe, posiadają mobilne jednostki przeznaczone do nasłuchu przestrzeni celem "podsłuchiwania" wszechobecnych fal elektromagnetycznych emitowanych przez komputery, kable sieciowe, itd. Choć urządzenia takie są drogie, to nie można wykluczyć ewentualności, że znajdują się one na wyposażeniu niektórych komputerowych włamywaczy. Na szczęście siedziba naszej firmy położona jest na wysokim piętrze wieżowca i znajduje się od strony, od której dojazd ewentualnego pojazdu, z systemem nasłuchu, jest niemożliwy. Dodatkowym rozwiązaniem byłoby szyfrowanie transmitowanych danych. Rozpatrywany serwer z systemem RedHat 7.3 nie posiada indywidualnego zasilacza awaryjnego UPS. Nasza firma posiada główny UPS, do którego podłączona jest sieć energetyczna. Moim zdaniem jest to złe rozwiązanie. W przypadku braku zasilania, UPS obciążany jest przez zbędne urządzenia podłączone do sieci energetycznej. Rozwiązaniem byłoby stworzenie awaryjnej sieci energetycznej, do której podłączone byłyby tylko krytyczne elementy systemu informatycznego. Mimo wszystko optuję za zakupem dodatkowego UPSa przeznaczonego wyłącznie do zasilania serwera. Dzięki temu wyeliminujemy dodatkowe niebezpieczeństwo związane z uszkodzeniem sieci awaryjnej - np. przez elektryków manipulujących przy instalacji (takie incydenty zdarzają się w codziennym życiu). Im mniej wiadomo o systemie tym lepiej. W celu podniesienia poziomu bezpieczeństwa powinno się wyłączyć informacje o wersjach różnorakich programów.
Hasło BIOSu serwera zabezpieczone jest hasłem. To samo tyczy się boot loadera. Pod tym względem postąpiono zgodnie z zasadami sztuki. Wszystkie zabezpieczenia na nic się zdadzą, gdy złodziej wedrze się do siedziby firmy i ukradnie serwer. Może on odczytać, bez najmniejszego problemu, dane zgromadzone na dysku twardym. Taki stan rzeczy spowodowany jest brakiem szyfrowania danych w RedHat 7.3. Rozwiązaniem tego problemu byłoby zainstalowanie programu (np. w postaci łaty na kernel), który szyfrowałby dane zapisywane na dysk twardy (także do katalogu /tmp oraz na partycję swap).

3. Wnioski

Bezpieczeństwo systemu informatycznego nie jest dobrem danym raz na zawsze. System wymaga stałej pielęgnacji. Od administratora wymaga się ciągłego czuwania - śledzenia serwisów informujących o błędach w oprogramowaniu, stosowania poprawek, tworzenia kopii zapasowych, wykonywania testów penetracyjnych, śledzenia logów, używania programów sprawdzających integralność systemu plików, itd.
Błędem byłoby też skupienie się na nadzorowaniu jedynie głównego serwera z systemem RedHat 7.3. Bezpieczeństwo serwera zależy także od otoczenia, w którym on pracuje, dlatego w pracy tej wykroczyłem poza analizę wyłącznie systemu RedHat.