Czy ktoś coś zmieniał?

W wielu programach daje się zauważyć tendencja do bezgranicznego zaufania dla poszczególnych składników systemu operacyjnego. Biblioteki są ładowane bez sprawdzania sumy kontrolnej, zawartości czy choćby opisu twórcy, daty i wielkości pliku. Ręce opadają... Wystarczy "strojanowanie" kilku ważnych bibliotek systemowych i każda aplikacja, która z nich korzysta - stoi otworem dla włamywacza.

Co istotne, w tym wypadku do włamania nie jest konieczny żaden błąd w kodzie programu, np. przepełnienia bufora. Jest to natomiast poważny błąd koncepcyjny, mogący pojawić się w każdym bez wyjątku systemie operacyjnym. Jako pierwszy pojawił się w systemach typu Unix i częstym obiektem ataku (i zostawienia konia trojańskiego) był program /bin/login, a także niektóre biblioteki w /usr/lib.

Obrona przed takimi niespodziankami jest dość prosta - sprawdzanie sum kontrolnych plików. Prawidłowo skonfigurowane systemy Unix zawierają oprogramowanie do wykrywania intruzów, które szybko wykrywają wszelkie zmiany w plikach systemowych. Może to zrobić nawet zwykły skrypt powłoki, który każdy doświadczony administrator może stworzyć prawie od ręki. W niektórych systemach operacyjnych (takich jak Solaris, OpenBSD czy Linux z łatami SE) można administracyjnie uniemożliwić nadpisanie konkretnych plików.

To zabezpieczenie jest bardzo skuteczne, bowiem nawet uzyskanie przez włamywacza uprawnień użytkownika root nie jest równoznaczne z możliwością pozostawienia w systemie "konia trojańskiego" w plikach systemowych. Sztuczka polega na tym, że aby móc cokolwiek zmodyfikować, należy przeładować system do trybu jednoużytkownikowego, co praktycznie wyklucza zdalny atak tą drogą. To jednak nie zwalnia administratora z dbałości o inne zabezpieczenia.

W porównaniu z Windows systemy Unix są nieporównywalnie bardziej bezpieczne - niejako z definicji. Ale bądźmy czujni - wróg nie śpi. Rootkity (w tej kwestii odsyłam do artykułu Macieja Bryłki na str. 22) pracujące jako moduły jądra Linuxa to nie science fiction, tylko coś, co ma miejsce od lat. Podobnie nie są niczym nowym programy szpiegujące, działające jako sterowniki klawiatury ładowane do jądra Windows XP. Bezpieczeństwo zależy przede wszystkim od doświadczenia i woli administratora.

Potrzebne wprawne oko

Obecnie częstym celem ataków są systemy Windows, które nie zostały zabezpieczone przed instalacją trojanów i/lub podmianą plików systemowych. Same sumy kontrolne bazujące na skrótach kryptograficznych mogą okazać się za słabym zabezpieczeniem - pojawiły się wirusy, które potrafią mechanizmy kontrolne obchodzić lub wyłączać. Będzie to łatwe zawsze wtedy, gdy użytkownik pracuje na koncie z prawami administratora.

W typowej instalacji systemu Windows proces o uprawnieniach systemowych może nadpisać dowolny plik, a mało który administrator śledzi zmiany w plikach systemu operacyjnego. Dość często pojawiające się łaty związane z bezpieczeństwem powodują konieczność dokonywania zmian w plikach, a więc ponowne obliczanie ich skrótów. Czyni śledzenie zadaniem żmudnym, co nie znaczy, że nie można go zautomatyzować, pisząc prosty skrypt. Trzeba też, co warte jest podkreślania przy każdej okazji, odpowiednio ustawić opcję zapisu do systemu plików.

Najciekawsze jest to, że systemy Windows posiadają całkiem niezłe zabezpieczenia, tyle że są one rzadko wykorzystywane. Mało kto stawia sobie ambitny cel w postaci ustawienia w Active Directory listy dozwolonych aplikacji i ich skrótów. W związku z coraz większymi obawami odnośnie do MD5, warto użyć skrótu generującego dłuższy ciąg - np. SHA1 z kluczem co najmniej 160-bitowym.

To prawda - właściwe ustawienie takich zabezpieczeń jest bardzo pracochłonne, każda aktualizacja oprogramowania wymaga zmian w ustawieniach polityki, zaś programy często wywołują swoje składniki w osobnych plikach wykonywalnych. Bywa też, że odmowa wykonania tego czy innego pliku EXE jest sygnalizowana przez program w sposób niepowodujący wywołania alarmu bezpieczeństwa. Zdarza się, że nie jest sygnalizowana w ogóle, ponieważ program staje się niestabilny i zostaje wyłączony. Brak mechanizmu automatyzującego czynności w tym zakresie to jeden z poważniejszych mankamentów w dziedzinie zarządzania systemami Windows. W praktyce konieczne jest zakupienie i wdrożenie osobnego, "dużego" produktu, jakim jest MOM.

Kolejna kwestia budząca wątpliwości wobec Windows to brak znanej od lat w systemach Unix i sprawdzonej w praktyce zasady, że programów nie wolno uruchamiać z katalogów, do których prawa zapisu posiadają zwykli użytkownicy. Zasada separacji przestrzeni użytkownika od przestrzeni systemu jest prosta i niebywale skuteczna, bo nawet jeśli złoczyńca zdobędzie uprawnienia użytkownika, nie będzie mógł uruchomić złośliwego oprogramowania. Jest to prawda, pod warunkiem że oprogramowanie nie ma poważnych luk w zabezpieczeniach.

Oczywiście, atrybut zabraniający wykonywania kodu z katalogu użytkownika (czy też procesu na jego prawach) da się obejść, ale nie jest to trywialne - nie każdy to potrafi. Gdyby opcja obecna w systemach Unix/BSD istniała w systemach Windows, była równie łatwa w konfiguracji jak to jest przy systemach, szerzenie się wirusów i programów szpiegujących byłoby znacznie utrudnione.

Byłoby dobrze

Narzędzia są ważne, lecz nie najważniejsze. Analizując powyższe fakty, nie można nie dojść do wniosku, że bezpieczeństwo informacji i infrastruktury informatycznej nie zależy od narzędzi, ale głównie od postaw ludzi: decydentów biznesowych, wykonawców systemów oraz ich administratorów. Każda z tych kategorii osób może istotnie przyczynić się do poprawy bezpieczeństwa. Byłoby najlepiej, gdyby zrobili to wspólnie, wzajemnie się koordynując i ucząc się od siebie nawzajem.

Przekonanie, że to "oni" odpowiadają za bezpieczeństwo skutkuje w praktyce pustymi gestami i wdrażaniem "magicznych" narzędzi, które, co zdarzało się niejednokrotnie, niewiele do bezpieczeństwa wnoszą. Wszystko to oczywiście ma sens tylko wtedy, jeśli bezpieczeństwo informacji jest dla organizacji sprawą o znaczeniu fundamentalnym, strategicznym. W przeciwnym razie, czy nie może zostać tak, jak jest?