Wybrane aspekty bezpieczeństwa DNS

Transkrypt

1 Bi u l e t y n WAT Vo l. LX, Nr 4, 2011 Wybrane aspekty bezpieczeństwa DNS Zbigniew Suski Wojskowa Akademia Techniczna, Wydział Cybernetyki, Instytut Teleinformatyki i Automatyki, Warszawa, ul. S. Kaliskiego 2, zsuski@ita.wat.edu.pl Streszczenie. W artykule opisano wybrane zagrożenia związane z funkcjonowaniem usługi DNS. Należy do nich zaliczyć zatruwanie pamięci podręcznej, ataki DoS oraz nadużywanie mechanizmu dynamicznej aktualizacji bazy serwera. Zostały również przedstawione wyniki eksperymentów, których celem było sprawdzenie podatności najbardziej popularnych serwerów DNS na przedstawione zagrożenia. Celem artykułu jest udowodnienie tezy, że przynajmniej niektóre właściwości usługi DNS są bardzo niebezpieczne, tzn. stanowią duże zagrożenie dla funkcjonowania sieci, gdyż mogą spowodować całkowitą dezorganizację jej pracy. Ponadto ataki wykorzystujące te właściwości są stosunkowo łatwe do przeprowadzenia, co potęguje zagrożenie. Słowa kluczowe: informatyka, bezpieczeństwo sieci komputerowych, zagrożenia DNS 1. Wstęp Podczas opracowywania specyfikacji systemu DNS bezpieczeństwo systemu nie było brane pod uwagę. Można się o tym przekonać, analizując dokumenty RFC specyfikujące ten protokół [11, 12]. Pierwszy problem z protokołem DNS wykryto w roku Z czasem odkrywano kolejne luki w systemie. Wreszcie informacje o zagrożeniach opublikowano w [5]. W dokumencie tym zwrócono również uwagę na zastosowanie DNSSEC 1 i TSIG 2 w celu przeciwdziałania zagrożeniom oraz na niedoskonałości tych rozszerzeń. Opublikowano kolejne dokumenty RFC, w których znaleźć można propozycje dotyczące utwardzenia DNS [2, 3, 4]. Zagadnienia dotyczące 1 2 DNSSEC (ang. DNS Security Extensions) to rozszerzenie systemu DNS mające na celu zwiększenie bezpieczeństwa DNS. DNSSEC zapewnia autoryzację źródeł danych (serwerów DNS) za pomocą kryptografii asymetrycznej oraz podpisów cyfrowych. TSIG mechanizm zabezpieczenia kryptograficznego transakcji transferu stref.

2 282 Z. Suski bezpieczeństwa DNS były również przedmiotem prac magisterskich prowadzonych w WAT [6] i PJWSTK [9] pod kierownictwem autora niniejszego artykułu. Celem artykułu jest udowodnienie tezy, że przynajmniej niektóre właściwości usługi DNS są bardzo groźne, tzn. stanowią duże zagrożenie dla funkcjonowania sieci, gdyż mogą spowodować całkowitą dezorganizację jej pracy. Ponadto ataki wykorzystujące te właściwości są stosunkowo łatwe do przeprowadzenia, co potęguje zagrożenie. Miejsca występowania zagrożeń w DNS przedstawiono na rysunku 1. Jednym z zagrożeń jest możliwość przechwytywania komunikatów DNS pomiędzy serwerem a klientem. Wykorzystywane są w tym przypadku techniki ataku niezwiązane bezpośrednio z samym protokołem DNS. Może to być np. atak typu man-in-the-middle polegający na nieuprawnionym pośredniczeniu komputera atakującego w wymianie informacji pomiędzy serwerem i klientem. Do przechwycenia danych wykorzystane mogą być ataki poprzez podszywanie się, np. IP Spoofing lub ARP Spoofing. Gdy napastnik pozyska zapytanie kierowane do serwera, może na tej podstawie w łatwy sposób wygenerować i wysłać sfałszowaną odpowiedź. Rys. 1. Zagrożone atakami przepływy danych w systemie DNS

3 Wybrane aspekty bezpieczeństwa DNS 283 Do znaczących luk w protokole DNS należy zaliczyć łatwość generowania przez atakującego spreparowanych komunikatów odpowiedzi serwera, w taki sposób, że klient interpretuje odpowiedź jako prawdziwą i zaczyna korzystać ze sfałszowanych danych, tzn. niezgodnych z rzeczywistością, podstawionych przez atakującego. Zabezpieczenie polegające na stosowaniu 16-bitowego numeru transakcji, który musi być taki sam w komunikacie zapytania i odpowiedzi, nie jest wystarczające. Można je łatwo obejść. Ta technika ataku jest trudniejsza niż przechwytywanie komunikatów, ale może być skuteczna w sieciach rozległych, a nie tylko lokalnych. Wymienione zagrożenia dotyczą możliwości wysyłania komunikatów odpowiedzi, które ofiara będzie traktowała jako autentyczne. Innym zagrożeniem jest możliwość zatruwania pamięci tymczasowej (podręcznej) w celu zdezorganizowania funkcjonowania usługi DNS. Zagrożenie tego typu niejako utrwala skutki przeprowadzonych ataków. Kolejną luką jest możliwość podszywania się pod serwer wybranej domeny. Klient systemu DNS otrzymuje adres serwera DNS np. od swojego dostawcy Internetu lub poprzez mechanizm DHCP w sieci lokalnej. Napastnik może umieścić w sieci własny serwer DNS, bez wiedzy klienta. Atakujący może uzyskać kontrolę częściową, jeśli tylko podszywa się pod serwer wybranej strefy, lub całkowitą, jeśli podszył się pod serwer przekierowujący (forwarding server) lub serwer pamięci tymczasowej (caching server). Zagrożenie wynika z braku mechanizmów pozwalających określić, czy serwer można potraktować jako zaufany. Jak można zauważyć na rysunku 1, każdy element systemu jest potencjalnie zagrożony. Nie wynika to jedynie ze słabości samego protokołu. Zagrożone elementy można podzielić na dwie grupy. W skład pierwszej wchodzą autorytatywne 3 serwery stref (podstawowe i zapasowe), czyli system przechowywania i publikowania informacji. Ewentualny napastnik może bezpośrednio na danym serwerze zmodyfikować pliki konfiguracji. Jak już poprzednio napisano, może również podszyć się pod serwer podstawowy lub zapasowy, zmodyfikować dane przekazywane serwerom zapasowym. Drugą grupą są wszystkie inne serwery pośredniczące w pozyskiwaniu informacji z systemu. Na końcu tego łańcucha jest kliencka stacja robocza lub serwer dowolnej usługi, np. poczty elektronicznej. W tym przypadku na każdym etapie przekazywania informacji może ona zostać zmieniona przez atakującego. Aby uporządkować zagadnienia związane z zagrożeniami wynikającymi z funkcjonowania DNS, celowe jest dokonanie klasyfikacji tych zagrożeń. Jako kryterium klasyfikacji przyjęto źródło zagrożeń. Wówczas podział zagrożeń może wyglądać następująco: zagrożenia wynikające z luk w specyfikacji protokołu (np. zatruwanie pamięci podręcznej); 3 Serwerem autorytatywnym nazywamy serwer, który sprawuje bezpośredni zarząd nad daną strefą jego odpowiedzi są formułowane bezpośrednio na podstawie zawartości bazy danych serwera.

4 284 Z. Suski zagrożenia wynikające z niewłaściwej konfiguracji serwerów DNS (np. transfer strefy, sprawdzanie wersji, dynamiczna aktualizacja); zagrożenia wynikające z niewłaściwej implementacji (np. przepełnienie bufora); zagrożenia wynikające z luk w platformie systemowej, na której posadowiono serwer DNS (np. ataki typu odmowa usługi). W niniejszym artykule przedstawiono niektóre, przeprowadzone w Instytucie Teleinformatyki i Automatyki badania, których celem była eksperymentalna weryfikacja podatności najbardziej popularnych serwerów DNS [1, 8, 10] na wybrane zagrożenia. Szczegółowe wyniki wybranych badań zostały opublikowane w Biuletynie IAiR [7, 13]. W trakcie badań wykorzystywano elementy sieci przedstawione na rysunku 2. Ich szczegółowa specyfikacja została przedstawiona w tabeli 1. Są to głównie serwery DNS posadowione na różnych platformach systemowych obsługujące domeny wymienione na rysunku 2 i w tabeli 1. Rys. 2. Struktura sieci służącej do przeprowadzenia badań

5 Wybrane aspekty bezpieczeństwa DNS 285 Charakterystyka systemów wykorzystywanych podczas eksperymentów Tabela 1 Maszyna wirtualna 1 FQDN domena odwr. glowny.tst 1.10.in-addr.arpa. System operacyjny Adres IP Serwer DNS Inne Windows MS DNS A_srv atak.intruz.tst Windows MS DNS WWW A_lin lin.intruz.tst Debian brak R_dns rdns.robocza.tst 3.10.in-addr.arpa. Windows MS DNS podstawowy R_lbind lbind.robocza.tst Debian BIND zapasowy R_wbind wbind.robocza.tst Windows BIND zapasowy R_msdns msdns.robocza.tst 3.10.in-addr.arpa. R_kl klient.robocza.tst Windows Z_www zwww.zasoby.tst Windows Windows MS DNS zapasowy Z_dns zdns.zasoby.tst Windows MS DNS podstawowy Lin linbind.lin.tst Windows BIND podstawowy 2. Zatruwanie pamięci podręcznej Zatruwanie pamięci podręcznej (cache poisoning) polega na wprowadzeniu do pamięci podręcznej serwera lub klienta DNS fałszywego tzw. rekordu zasobu, który będzie wiązał nazwę z fałszywym adresem IP [14]. Zawartość takiego rekordu będzie pamiętana przez czas określony przez parametr TTL (Time To Live). Gdy jakikolwiek klient zapyta o nazwę występującą w takim rekordzie, zostanie mu zwrócony fałszywy adres IP. Największa trudność po stronie agresora polega na konieczności odgadnięcia identyfikatorów transakcji, które powinien on umieścić w wysyłanej, spreparowanej odpowiedzi. Obecnie można rozróżnić następujące typy ataku zatruwania bufora: atak klasyczny, zmodyfikowany atak klasyczny, atak dnia narodzin. Atak klasyczny polega na wysłaniu przez atakującego zapytania o nazwę do serwera DNS i zmuszeniu go w ten sposób do poszukiwania odpowiedzi u innych serwerów DNS. Następnie agresor powinien wysłać odpowiedź z poprawnym numerem transakcji (ID). Ponieważ pole ID składa się z 16 bitów, więc wartość numeru transakcji może przyjmować wartości z przedziału od 1 do Aby atak się powiódł, atakujący musi przesłać od 1 do fałszywych odpowiedzi w czasie krótszym niż czas odpowiedzi właściwego serwera DNS.

6 286 Z. Suski Zmodyfikowany atak klasyczny polega na wysyłaniu na każde zadane zapytanie do serwera DNS pewnej sekwencji odpowiedzi. Odpowiedzi są generowane w pętli z losowo generowanymi numerami ID. Ważne przy tym jest, aby przy każdym przejściu pętli były to zawsze te same numery ID. Liczba fałszywych odpowiedzi w tym przypadku jest dużo mniejsza niż Atak dnia narodzin (birthday attack) oparty jest na paradoksie dnia narodzin. Jest on związany z odpowiedzią na pytanie: ile osób należy wybrać, żeby prawdopodobieństwo tego, że co najmniej dwie osoby mają urodziny tego samego dnia, było większe od ½. W naszym przypadku chodzi o odpowiedź na pytanie: ile należy wysłać fałszywych odpowiedzi, aby przynajmniej jedno zapytanie i jedna odpowiedź miały ten sam numer identyfikacyjny. Prawdopodobieństwo powodzenia takiego ataku można wyrazić wzorem: nn ( 1) 2 1 P = 1 1, t gdzie t oznacza ilość wszystkich pakietów mogących być odpowiedzią, a n ilość wysłanych pakietów DNS. Z powyższego wzoru wynika, że przy n = 700 wysłanych pakietach zawierających fałszywą odpowiedź t = = , prawdopodobieństwo powodzenia ataku wynosi 0, Jak widać, znacznie ułatwia to intruzowi przeprowadzenie ataku. Na rysunku 3 przedstawiono ilustrację ataku poprzez zatruwanie pamięci podręcznej. Rys. 3. Zatruwanie pamięci podręcznej: 1) agresor wysyła zapytanie o nazwę; 2) agresor wysyła fałszywe odpowiedzi do serwera; 3) klient zadaje pytanie o adres; 4) serwer odpowiada fałszywym adresem IP Ofiarą ataku w trakcie eksperymentu polegającego na zatruwaniu pamięci podręcznej (cache poisoning) był serwer podstawowy (rdns) domeny robocza.tst, zbudowany w oparciu o oprogramowanie MSDNS w systemie Windows 2003 Server. Eksperyment rozpoczął się od sprawdzenia poprawności współdziałania komputera klient.robocza.tst z serwerem DNS rdns.robocza.tst. Sprawdzenie to polegało na weryfikacji konfiguracji interfejsu sieciowego klienta za pomocą programu ipconfig (rys. 4) oraz badaniu poprawności rozwiązywania nazwy i osiągalności komputera (rys. 5). Na podstawie zamieszczonych obrazów można

7 Wybrane aspekty bezpieczeństwa DNS 287 stwierdzić, że klient poprawnie współpracuje ze swoim serwerem DNS. Po tych czynnościach wstępnych zrealizowano czyszczenie pamięci podręcznej resolvera systemu klient.robocza.tst. Rys. 4. Konfiguracja interfejsu sieciowego komputera klient.robocza.tst Rys. 5. Wynik badania poprawności rozwiązywania nazwy i osiągalności komputera Ostatnim etapem weryfikacji wstępnej była próba pobrania strony www z serwera Próba taka zakończy się powodzeniem. Na rysunku 6 zamieszczono obraz ruchu sieciowego realizowanego podczas pobierania strony z serwisu Jego prześledzenie jest istotne ze względu na wychwycenie różnic, które będzie można zaobserwować po udanym ataku. Na przedstawionym obrazie można zauważyć, że najpierw klient ( ) zwraca się do swojego serwera DNS ( ) z żądaniem rozwiązania nazwy www. zasoby.tst. Ponieważ nie jest to serwer autorytatywny domeny zasoby.tst, więc zwraca się on z takim żądaniem do serwera głównego ( ). Otrzymuje od niego informację, że z takim żądaniem powinien się zwrócić do serwera , co też czyni. Uzyskuje informację, że system ulokowany jest pod adresem i taką informację przekazuje swojemu klientowi ( ). Po otrzymaniu

8 288 Z. Suski adresu systemu klient inicjuje z nim połączenie TCP na porcie 80 i realizowana jest sekwencja związana z przesłaniem żądania klienta i przesłaniem strony przez serwer www. Wreszcie następuje zamknięcie połączenia TCP. Dla porządku przedstawiono jeszcze zawartość pamięci podręcznej resolvera systemu klient.robocza.tst (rys. 7) i serwera rdns.robocza.tst (rys. 8). Rys. 6. Obraz ruchu sieciowego realizowanego podczas pobierania strony z serwera Rys. 7. Zawartość pamięci podręcznej resolvera systemu klient.robocza.tst po operacji pobrania strony

9 Wybrane aspekty bezpieczeństwa DNS 289 Rys. 8. Zawartość pamięci podręcznej serwera rdns.robocza.tst po operacji pobrania przez klienta strony Teraz przeprowadzany jest sam atak. Wykorzystano do tego skrypt opracowany i zamieszczony w [9]. Skrypt ten generuje zapytanie o określoną nazwę, a następnie wysyła do pytanego serwera DNS sfałszowane odpowiedzi. Obraz ruchu sieciowego generowanego przez ten skrypt przedstawiono na rysunku 9. Należy zwrócić uwagę, że sfałszowane, wygenerowane przez skrypt odpowiedzi informują, że system www. zasoby.tst jest ulokowany pod adresem Pod tym adresem intruz ulokował serwis www, który zamierza podstawić klientowi w miejsce serwisu Pole adresu źródłowego ( ) wskazuje na komputer, który pełni rolę serwera DNS w domenie zasoby.tst. Ten komputer poprzednio udzielał odpowiedzi. W czasie przeprowadzonego ataku nie powinien być aktywny. W trakcie prawdziwego ataku zatruwania bufora oznacza to zwykle przeprowadzenie dowolnego ataku DoS skierowanego na ten komputer. W trakcie eksperymentu atak DoS zasymulowano, wyłączając system Rys. 9. Obraz ruchu sieciowego podczas ataku zatruwania bufora serwera DNS

10 290 Z. Suski Po ataku, w buforze serwera DNS znalazła się informacja, że system jest ulokowany pod adresem (rys. 10). Klient żądający rozwiązania nazwy otrzyma nieprawdziwą odpowiedź, co zobrazowano na rysunku 11. Zawartość bufora klienta przedstawiono na rysunku 12. Rys. 10. Zatruta zawartość bufora zaatakowanego serwera DNS Rys. 11. Nieprawdziwa odpowiedź udzielona klientowi przez zaatakowany serwer DNS W wyniku całego opisanego procesu, klient żądający dostępu do strony www. zasoby.tst otrzyma stronę podstawioną przez intruza pod adresem

11 Wybrane aspekty bezpieczeństwa DNS 291 Rys. 12. Zatruta zawartość bufora klienta zaatakowanego serwera DNS 3. Atak DoS DNSflood Celem ataków typu odmowa usługi (DoS Denial of Service) jest całkowite lub częściowe zablokowanie możliwości korzystania z danej usługi. Podstawowe ataki DoS przeprowadzane są z jednego komputera. Uchronienie się przed nimi jest możliwe poprzez zablokowanie adresu IP, z którego prowadzony jest atak. Udoskonaloną wersją ataku DoS jest atak typu rozproszonego (DDoS Distributed Denial of Service). W przypadku ataku DDoS atak jest przeprowadzany z wielu komputerów jednocześnie. Komputery te znajdują się w różnych miejscach sieci, a ich użytkownicy najczęściej nie są świadomi tego, że biorą udział w przeprowadzanym ataku. Aby możliwe było wykorzystanie takiego komputera w czasie rozproszonego ataku DDoS, musi zostać na nim umieszczony odpowiedni złośliwy program. Może to być np. koń trojański, który aktywowany zostanie przez sygnał wysłany przez agresora. Ataki typu DDoS są trudniejsze do opanowania i często nawet firmy dysponujące niemal nieograniczonymi środkami na ochronę informacji nie są w stanie obronić się przed nimi. Serwery DNS mogą być podatne na ataki typu odmowa dostępu (DoS). Napastnik może wykorzystać w tym celu mechanizm odpytywania rekursywnego. Wysyła pojedyncze zapytania do serwera. Jeżeli odpytywany serwer nie jest w stanie udzielić odpowiedzi na podstawie posiadanych przez siebie danych, to jego reakcja polegać będzie na wysyłaniu zapytań do kolejnych serwerów autorytatywnych stref szukanej nazwy domeny. Jeśli atakujący prześle dużą ilość zapytań dotyczących domeny,

12 292 Z. Suski o których atakowany serwer nazw nie posiada informacji w swojej pamięci podręcznej, to wykona on dużą ilość zapytań iteracyjnych. Atak typu SYNflood polega na wysyłaniu pakietów SYN na określony port. W przypadku serwera DNS będzie to port 53. W czasie tego ataku inicjowane są połączenia TCP, ale pozostają one w stanie półotwarcia. Powoduje to przede wszystkim zużycie zasobów pamięciowych, czasu procesora i pasma medium transmisyjnego. Serwer DNS może zostać również wykorzystany jako źródło ataku DoS. Ponieważ komunikat odpowiedzi może być wielokrotnie dłuższy od zapytania, więc wysłanie przez napastnika pojedynczego, krótkiego żądania może spowodować wysyłanie przez serwer długich odpowiedzi, które będą obciążały ofiarę. Udane ataki są możliwe, gdyż często serwery nazw podłączone są do szybkich łączy sieciowych, szybszych niż łącza ofiary. Atak tego typu polega na wysyłaniu dużej liczby poprawnie sformatowanych zapytań DNS. W niniejszym artykule przedstawiono wyniki eksperymentu polegającego na przeprowadzeniu ataku DNSflood na serwer DNS. Dla potrzeb tego eksperymentu opracowano program (eksploit) o nazwie DNSFLOOD. Przed rozpoczęciem ataku zbadano czas odpowiedzi serwera rdns.robocza.tst w normalnych warunkach eksploatacji sieci testowej. Uzyskane wyniki przedstawiono na rysunku 13. Rys. 13. Wyniki badania czasu odpowiedzi serwera rdns.robocza.tst w normalnych warunkach eksploatacji sieci testowej Następnie zainicjowano atak DNSflood. Na rysunku 14 zaprezentowano obraz ruchu sieciowego podczas ataku. Pakiety zawierające poprawne zapytania DNS kierowane są do atakowanego komputera o adresie na port 53 TCP(DNS). Zwrotnie przekazywane są odpowiedzi serwera. Po stronie serwera DNS daje się zauważyć wydłużenie czasu odpowiedzi udzielanej przez serwer podczas ataku. W obserwowanym przypadku wyniósł on

13 Wybrane aspekty bezpieczeństwa DNS 293 Rys. 14. Obraz ruchu sieciowego podczas ataku DNSflood na serwer DNS 625 ms patrz ramka na rysunku 15. Jednocześnie mierzono obciążenie procesora i karty sieciowej atakowanego komputera. Na rysunku 16 można zauważyć, że przed atakiem obciążenie tych zasobów było znikome, wręcz niezauważalne. Podczas ataku obciążenie procesora oscylowało w przedziale %. Obciążenie to przedstawia górna krzywa. Znacznie wzrosło też obciążenie karty sieciowej krzywa dolna. Rys. 15. Wyniki badania czasu odpowiedzi serwera rdns.robocza.tst podczas ataku DNSflood

14 294 Z. Suski Rys. 16. Obciążenie procesora i karty sieciowej przed atakiem i podczas ataku DNSflood 4. Dynamiczna aktualizacja Jednym z ułatwień, jakie może oferować serwer DNS, jest możliwość dynamicznego wprowadzania danych do bazy serwera przez jego klientów. Funkcja ta jest np. wykorzystywana przez komputery w sieci lokalnej, które nie mają przypisanego stałego adresu IP. Podczas uruchamiania, system operacyjny stara się uaktualnić właściwy rekord w lokalnym serwerze DNS. Brak autoryzacji klienta może spowodować wprowadzenie do bazy serwera dowolnych sfałszowanych danych. Funkcja dynamicznej aktualizacji może być wykorzystywana przez komputery w sieci lokalnej, które nie mają przypisanego stałego adresu IP. Podczas uruchamiania, system operacyjny stara się uaktualnić właściwy rekord w zasobach serwera DNS. To rozszerzenie dotyczące funkcjonowania DNS zostało zdefiniowane w RFC 2136 [15]. Podczas badań przeprowadzono eksperyment, którego celem było wprowadzenie do bazy serwera DNS rekordu przygotowanego przez potencjalnego intruza. Eksperyment przeprowadzono dla serwera msdns (rdns.robocza.tst) i bind (linbind.lin.tst). Na rysunkach 17 i 18 przedstawiono wyniki pobierania informacji o strefie z obu serwerów przed rozpoczęciem eksperymentu. Na rysunkach 19 i 20 pokazano zawartość plików strefowych rezydujących na obu serwerach (przed rozpoczęciem eksperymentu). Dodatkowo na rysunku 21 przedstawiono obraz konsoli graficznej służącej do zarządzania serwerem msdns (przed rozpoczęciem eksperymentu). Po opisanych czynnościach wstępnych uruchomiono opracowany program (exploit). Jego zadaniem było zrealizowanie procedury dynamicznej aktualizacji ze

15 Wybrane aspekty bezpieczeństwa DNS 295 Rys. 17. Wyniki pobrania informacji o strefie utrzymywanej przez serwer rdns.robocza.tst za pomocą programu nslookup Rys. 18. Wyniki pobrania informacji o strefie utrzymywanej przez serwer bind (linbind.lin.tst) za pomocą programu nslookup strony klienta. Można wykorzystać również program nsupdate dostępny w dystrybucji pakietu bind. Obraz ruchu sieciowego spowodowanego uruchomieniem tego programu przedstawiono na rysunkach 22 i 23. Ramkami zaznaczono najważniejsze pakiety zawierające dane aktualizacyjne. Jak się można było spodziewać, ruch sieciowy w obu przypadkach jest podobny, ale nie identyczny. Skutki ataków można obejrzeć na rysunkach Na wszystkich tych rysunkach ramkami zaznaczono elementy, które są skutkiem przeprowadzonych ataków. Na rysunkach 24 i 25 przedstawiono wyniki pobierania informacji o strefie z obu serwerów po przeprowadzonym ataku. Na rysunkach 26 i 27 pokazano zawartość plików strefowych rezydujących na obu serwerach. Dodatkowo na rysunku 28 przedstawiono obraz konsoli graficznej służącej do zarządzania serwerem rdns. robocza.tst (po ataku).

16 296 Z. Suski Rys. 19. Zawartość pliku robocza.tst.dns zawierającego informacje o strefie utrzymywanej przez serwer rdns.robocza.tst przed rozpoczęciem eksperymentu Rys. 20. Zawartość pliku lin.tst.dns zawierającego informacje o strefie utrzymywanej przez serwer bind (linbind.lin.tst) przed rozpoczęciem eksperymentu

17 Wybrane aspekty bezpieczeństwa DNS 297 Rys. 21. Obraz konsoli służącej do zarządzania serwerem rdns.robocza.tst przed rozpoczęciem eksperymentu Rys. 22. Obraz ruchu sieciowego podczas ataku dynamicznej aktualizacji serwera rdns.robocza.tst

18 298 Z. Suski Rys. 23. Obraz ruchu sieciowego podczas ataku dynamicznej aktualizacji serwera bind (linbind.lin.tst) Rys. 24. Wyniki pobrania informacji o strefie utrzymywanej przez serwer rdns.robocza.tst za pomocą programu nslookup po ataku

19 Wybrane aspekty bezpieczeństwa DNS 299 Rys. 25. Wyniki pobrania informacji o strefie utrzymywanej przez serwer bind (linbind.lin.tst) za pomocą programu nslookup po ataku Rys. 26. Zawartość pliku robocza.tst.dns zawierającego informacje o strefie utrzymywanej przez serwer rdns.robocza.tst po ataku

20 300 Z. Suski Rys. 27. Zawartość pliku lin.tst.dns zawierającego informacje o strefie utrzymywanej przez serwer bind (linbind.lin.tst) po ataku Rys. 28. Obraz konsoli służącej do zarządzania serwerem rdns.robocza.tst po ataku 5. Podsumowanie W artykule zostały przedstawione wybrane zagrożenia związane z funkcjonowaniem usługi DNS oraz wyniki eksperymentów, których celem było sprawdzenie podatności wybranych serwerów DNS na ataki. Można się zorientować, że przeprowadzenie wielu ataków jest bardzo proste i możliwe do wykonania nawet przez niezbyt zaawansowanego napastnika. Przykłady zamieszczone w niniejszym artykule być może spowodują wzrost świadomości wśród administratorów systemów i przyczynią się do wzrostu bezpieczeństwa systemów, którymi się opiekują.

21 Wybrane aspekty bezpieczeństwa DNS 301 Dla części opisanych luk występujących w najbardziej popularnych implementacjach serwerów DNS opracowano już łaty programowe. Należy jednak zdawać sobie sprawę, że opracowanie łaty nie rozwiązuje problemu. Jest dopiero pierwszym krokiem na drodze do zbudowania bezpiecznego serwera. Taką łatę należy jeszcze zainstalować. Wydaje się to truizmem. Niestety należy o tym przypominać, gdyż większość użytkowników nie realizuje żadnych zabiegów pielęgnacyjnych w stosunku do używanego przez siebie oprogramowania. Można zaryzykować stwierdzenie, że teza postawiona we wstępie do niniejszego artykułu została udowodniona. Artykuł wpłynął do redakcji r. Zweryfikowaną wersję po recenzji otrzymano w czerwcu 2011 r. LITERATURA [1] P. Albitz, C. Liu, DNS and BIND. Edition 5, O Reilly Media Inc., Sebastopol, [2] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, DNS Security Introduction and Requirements, RFC IETF, [3] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, Resource Records for the DNS Security Extensions, RFC IETF, [4] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, Protocol Modifications for the DNS Security Extensions, RFC IETF, [5] D. Atkins, R. Austein, Threat Analysis of the Domain Name System (DNS), RFC IETF, [6] M. Borzym, Weryfikacja bezpieczeństwa serwerów DNS, praca magisterska, WAT, Warszawa, [7] M. Borzym, Z. Suski, Zagrożenia usługi DNS, Biul. IAiR, 25, 2008, WAT, Warszawa, [8] A. Daniels, H. Knief, J. Graham, R. Abell, Windows 2000 DNS, Helion, Gliwice, [9] G. Hałajko, Bezpieczeństwo serwerów DNS, praca magisterska, PJWSTK, Warszawa, [10] C. Liu, M. Larson, R. Allen, DNS on Windows Server 2003, Edition 3 O Reilly Media Inc., Sebastopol, [11] P. Mockapetris, Domain Names Concepts And Facilities, RFC IETF, [12] P. Mockapetris, Domain Names Implementation And Specification, RFC IETF, [13] Z. Suski, Badania podatności usługi DNS na wybrane zagrożenia, Biul. IAiR 28, WAT, Warszawa, [14] M. Tomaszewski, Pharming-Ataki DNS cache poisoning, Hakin9, 4, 2005, [15] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, Dynamic Updates in the Domain Name System (DNS UPDATE), RFC IETF, 1997.

22 302 Z. Suski Z. SUSKI Selected aspects of DNS security Abstract. The paper presents the threats connected with DNS. To those threats, we can count cache poisoning, DoS attacks, and dynamic updating of server database abusing. The paper presents the results of penetrative tests. The goal of those tests was verification of DNS servers susceptibility to some threats. The goal of the presented work is to prove a thesis that at least some properties of DNS are dangerous. They can provoke total disruption of the network. Moreover, attacks that utilize presented susceptibility are relatively easy to perform them. Keywords: informatics, computer networks security, DNS threats