Jeśli włamywacz internetowy nie potrafi zaatakować głównych serwerów DNS, może skierować swoje działania ku łatwiej dostępnym serwerom, np. działającym w ramach systemu autonomicznego w swoim kraju. Tutaj ma większe pole do popisu - regionalne systemy DNS nie są już tak dobrze strzeżone jak root DNS. Atak na klaster serwerów DNS u dużego dostawcy Internetu może wywołać różne skutki - od wyłączenia serwerów w ogóle (to nie jest takie trudne, niejednokrotnie się to udawało), poprzez okresowe zakłócanie funkcjonowania, aż do niszczenia ich zawartości.

Ten ostatni atak może mieć dwie formy - włamania na serwer i podmiany plików konfiguracyjnych serwera DNS, albo też włamania wykorzystującego błąd w nim samym i skutkującego nadpisaniem cache serwera DNS. Wykorzystanie pierwszej z tych dróg w systemach typu Unix daje się dość łatwo ograniczyć poprzez zastosowanie jednocześnie kilku mechanizmów zabezpieczeń, np. chroot(), dobre ustawienie zabezpieczeń, techniki uniemożliwiające nadpisanie plików konfiguracyjnych nawet przez proces systemowy UID 0.

Błąd skutkujący nadpisaniem cache (tzw. cache poisoning) może być bardzo poważny w skutkach. Systemy z rodziny Windows posiadają zupełnie inne mechanizmy zabezpieczeń niż systemy typu Unix, co nie znaczy, że są bezpieczniejsze. Bezpieczeństwo zależy głównie od administratora - to jego wiedza ma zapewniać prawidłową pracę serwera. Jeśli nie aktualizuje oprogramowania, nie stosuje dobrych zabezpieczeń, jego system stoi otworem. Cache poisoning nie musi być ostatecznym celem atakującego. Taki atak to bardzo dobra przygrywka do masowego phishingu, polegającego np. na kierowaniu wszystkich użytkowników banku online do fałszywej witryny przez sam serwer DNS!

Myśleć przed szkodą

Doświadczony administrator i projektant systemowy wyciąga wnioski ze zdarzeń, jakie miały miejsce w przeszłości. Zatem zamiast jednego serwera w jednej lokalizacji zainstaluje dwa w dwóch różnych miejscach, połączone zdublowaną infrastrukturą. Każdy z tych serwerów będzie miał redundantne elementy, takie jak zasilacz czy dyski. Zniszczenie jednej z lokalizacji lub inna poważna awaria nie wyłączy systemu z pracy.

Praktyka pokazuje, że nawet elementy zwielokrotniane mogą ulegać wyłączeniom. Przyczyna takiego wyłączenia, które teoretycznie nigdy nie powinno nastąpić, leży w tym, że przy projekcie popełniono błąd, nie uwzględniając jakiegoś czynnika. Oto przykład: w firmie umieszczono klaster kilku serwerów Microsoft Windows 2000 Advanced Server. Serwery umieszczono w dwóch lokalizacjach, łącząc zdublowanymi łączami. Na tych serwerach umieszczono wszystkie najważniejsze usługi wykorzystywane w firmie - pocztę elektroniczną, bazy danych wszystkich programów, serwer aplikacyjny firmowego intranetu.

Rzecz w tym, że projektanci nie przewidzieli jakiegokolwiek zapasowego rozwiązania, gdy wszystkie serwery w obu lokalizacjach przestaną działać. To prawda, że unieruchomienie klastra poprzez awarię sprzętową jest naprawdę mało prawdopodobne. Ale przecież nie sam sprzęt ulega uszkodzeniom. Awaria była spowodowana wirusem przyniesionym na laptopie - wirus zaraził wszystkie maszyny w klastrze i spowodował całkowite jego logiczne wyłączenie w formie stuprocentowego wykorzystania wszystkich procesorów.

Błąd polegał na umieszczeniu wszystkich usług w jednym systemie i wynikał z założenia, że całe oprogramowanie będzie działać prawidłowo. Rozwiązaniem jest podział usług i umieszczenie części z nich na maszynach o innej konstrukcji. Dla przykładu firma wykorzystująca serwery Microsoftu do przechowywania plików i współdzielenia drukarek powinna skorzystać z bazy danych takiej jak Oracle, umieszczonej na komputerach o innej konstrukcji systemów operacyjnych - np. na systemach Linux lub Unix.

Utrzymanie będzie trudniejsze, gdyż będzie wymagało większej wiedzy od administratorów, ale odporność na ataki, a także niezawodność systemu jako całości będzie lepsza. Przecież trudniej uszkodzić kilka systemów o różnej konstrukcji niż zestaw podobnych serwerów Microsoftu lub kilka maszyn z systemem Linux na pokładzie. W razie unieruchomienia serwera, przynajmniej część usług będzie funkcjonowała.

Gdy zaś chodzi o bezpieczeństwo usług wykorzystywanych publicznie, takich jak DNS, poczta elektroniczna czy WWW, doświadczony administrator zastosuje system o solidnych podstawach, jak Unix lub utwardzony Linux, np. jedną z "najtwardszych" dystrybucji, jaką jest Adamantix, albo też OpenWall Linux. Również dobrze skonfigurowany system OpenBSD będzie dość bezpieczny.

Kon-fi-gu-rac-ja!

Warunkiem koniecznym zachowania bezpieczeństwa i prawidłowej eksploatacji serwerów jest ich poprawna konfiguracja. Konfiguracja zakładająca minimalne przywileje dla użytkownika, na prawach którego ona pracuje, po drugie, minimalne konieczne uprawnienia ustawiane w systemie plików. Na przykład, jeśli proces pracuje z siecią, łącząc się na wysokim porcie (powyżej 1024), to samo połączenie nie wymaga uprawnień superużytkownika. Jeśli zaś program korzysta z cache i plików konfiguracji, uprawnienia zapisu do plików powinny obejmować zapis tylko do plików cache. Dla plików konfiguracji, a także innych plików (w tym wykonywalnych oraz bibliotek) wystarczy uprawnienie do odczytu bibliotek i uruchomienia aplikacji.