Bezpieczenstwo DNS

Bezpieczenstwo DNS
Autor: asmie
Email: asmie [at] poczta [dot] onet [dot] pl
http://www.asmie.glt.pl

I. Co to jest DNS i z czym to sie jest ?
II. Bezpieczenstwo DNS

• pola informacyjne
• trasfery stref
• wyszukiwanie odwrotne
• DNSSEC
  III. Bezpieczenstwo DNS w Linux
  IV. Bezpieczenstwo DNS w Windows
  V. DNS cache poisoning - dlaczego tak skuteczne ?
  VI. Zakonczenie

I. Co to jest DNS i z czym to sie jest ?

DNS (Domain Name System) jest to usluga pozwalajaca na rozwiazywanie nazw
konkretnych hostow na ich adresy IP. Komputery w przeciwienstwie do ludzi
nie radza sobie zbyt dobrze z odnajdywaniem sie po nazwie i dlatego
konieczne stalo sie tlumaczenie nazw zrozumialych dla ludzi na adresy
(cyfry) zrozumiale dla komputerow. Jak to wyglada ? Otoz podstawa
DNS jest to, iz nie posiada on jednego centralnego serwera, przechowujacego
wpisy dotyczace nazw domen i ich adresow IP. Kazdy adres domenowy musi
byc obslugiwany przez conajmniej dwa serwer DNS. Dlaczego ? Otoz w
przypadku awarii jednego, drugi jest w stanie wziac na siebie jego
zadanie i w rezultacie odwiedzajacy wcale nie wie, ze adres ktory wpisal
byl przetlumaczony przez zapasowy serwer DNS a nie przez podstawowy.
Serwerow DNS jest bardzo duzo - kazdy moze postawic swoj wlasny i
nie ma co do tego zadnych ograniczen. Istnieje jednak 13 serwerow
glownych, rozmieszczonych na roznych kontynentach. Niemozliwe jest
aby kazdy serwer DNS utrzymywal pelna liste stron jaka mozemy
znalezc w Internecie. Zamiast tego serwery DNS trzymaja liste
innych serwerow DNS, ktore moga znac odpowiedz na praktycznie kazde
zapytanie, jakiego moze zadac uzytkownik. Przesledzmy teraz w jaki sposob
lokalizowane sa konkretne strony WWW. Najlepiej zademonstruje to na
prostym przykladzie:

Uzytkownik --zapytanie o adres www.asmie.strona.net --> serwer DNS
wpisany w ustawieniach
przegladarki np.:
(194.204.159.1)

194.204.159.1 --> serwer DNS wysyla zapytanie do jednego z 13 glownych
serwerow DNS (np.: 204.210.100.1)

204.210.100.1 --> serwer: nie wiem ale zapytam sie serwera DNS
odpowiedzialnego za domeny *.net (np.: 198.110.21.3)

204.210.100.1 --- zapytanie o adres www.asmie.strona.net --> 198.110.21.3

198.110.21.3 --> serwer: nie wiem ale zapytam sie serwera DNS
odpowiedzialnego za domeny *.strona.net
(np. 83.210.22.1)

198.110.21.3 ---zapytanie o adres www.asmie.strona.net --> 83.210.22.1

83.210.22.1 --> serwer: adres www.asmie.strona.net to: 83.55.2.1

83.210.22.1 --- wysylanie odpowiedzi ---> 198.110.21.3

198.110.21.3 --- przekazywanie odpowiedzi --> 204.210.100.1

204.210.100.1 --- przekazywanie odpowiedzi ---> 194.204.159.1

194.204.159.1 --- udzielanie odpowiedzi przegladarce ---> Uzytkownik

Moze sie to wydawac dosc czasochlonne ale tak wyglada procedura ustalania
adresu. Jak sami wiecie przegladajac strony WWW najdluzej trwa i tak
proces ladowania samej strony wiec tak niewielkie opoznienie spowodowane
przez ustalanie adresu IP jest niezauwazalne. Aby wszystko moglo sie
tak szybko rozgrywac serwery DNS utrzymuja w pamieci przez pewien czas
adresy serwerow, o ktore ostatnio pytano. Technika ta nosi nazwe:
DNS cache i jest bardzo dobrym rozwiazaniem nie liczac potencjalnego
niebezpieczenstwa jakie ze soba niesie (ktorym sie zajmiemy w niniejszym
artykule). Dla przykladu jezeli ktos zapyta sie serwer DNS o adres
jakiejs strony i zaraz po nim zapyta sie inny uzytkownik o adres tej
samej strony, serwer DNS nie bedzie juz odpytywal innych serwerow,
a poda ten adres ze swojej pamieci podrecznej. Wazne jest to, iz jeden
adres domenowy wcale nie musi odpowiadac dokladnie jednemu adresowi IP.
Oznacza to, iz na przyklad stronie xxx.yyy.pl moze odpowiadac np.
5 adresow IP.
Skad nasz komputer wie jaki adres DNS odpytac najpierw? Zalezy to od
konfiguracji naszej sieci. Jezeli siec konfiguruje sie nam
automatycznie (DHCP) dostajemy od razu adresy serwerow DNS. Jezeli
konfigurujemy siec manualnie sami musimy podac adresy tych
serwerow. W Linuxie znajduja sie one w pliku /etc/resolv.conf,
natomiast w Windows musimy uruchomic Panel Sterowania, tam Siec,
pozniej zaznaczyc Protokol TCP/IP i tam bedziemy mieli dostep do
skonfigurowania naszych serwerow DNS.

II. Bezpieczenstwo DNS

Mam nadzieje, ze po krotkim wstepie do technologii DNS kazdy juz
zrozumial o co chodzi :). Pora przejsc do meritum tego tekstu,
a mianowicie do zagadnien bezpieczenstwa zwiazanego z DNS. W tym
punkcie skupimy sie na ogolnych zasadach bezpieczenstwa DNS, bez
podzialu na konkretne programy dla konkretnych platform.
Pierwsza bardzo wazna rzecza, o ktora nalezy zadbac probujac
stworzyc bezpieczny serwer DNS sa informacje, jakie potencjalny
napastnik moze uzyskac, wysylajac zapytania do naszego serwera. Istnieje
wiele roznych rekordow DNS, z ktorych tylko niewielka czesc jest uzywana
do translacji adresu domengowego na IP lub odwrotnie. Reszta tych pol
moze stanowic dobry punkt startu dla osoby, chcacej przeprowadzic
udany atak. Przykladowe pole wykorzystywane przez DNS to:

SOA (Start of Authority) - zawiera adres email administratora DNS

• pare innych smieci

A (Address) - adres IP nalezacy do nazwy komputera

CNAME (Canonical Name) - odwolanie do nazwy hosta zamiast to
adresu IP dla danego komputera

PTR (Pointer) - nazwa hosta dla danego adresu IP

HINFO - architektura i system operacyjny hosta

TXT - inne informacje opisujace hosta

RP - adres email osoby odpowiedzialnej za dany komputer

Juz samo sie nasuwa - no jak to ? System operacyjny w polu DNS ? Rekordy
te maja na celu lepsze poinformowanie innych uzytkownikow o polozeniu
i celu danej maszyny. W rzeczywistosci praktycznie nikt z tego nie korzysta
oprocz osob ktore atakuja nasz host :). Poleceniem host -t mozna zadac
serwerowi DNS konkretne pytanie o konkretne pole:

asmie$ host -t txt przyklad.pl
www.przyklad.pl descriptive text: "Serwer firmy X, stoi w pokoju zwierzen"

Niby nic a jednak. Pobieranie takich rekordow moze sie okazac niebezpieczne
w momencie, gdy agresor moze pobrac nazwe i wersje systemu operacyjnego
z rekordu HINFO. Ulatwi mu to rozpoznanie systemu na ktorym pracuje serwer
i w rezultacie bedzie w stanie lepiej dobrac metoda ataku, pod konkretnego
OS'a. Wszystkie rekordy DNS mozemy objerzec uzywajac polecenia:

asmie$ host -t '*' przyklad.pl

Otrzymamy wtedy pelna liste rekordow DNS jakie dostarcza nam dany serwer.
Jak temu zapobiec ? Kazdy sie juz pewnie domyslil, ze nalezy tych
konkretnych rekordow nie czynic publicznie dostepnymi. Jak juz wspomnialem
wczesniej jedna z cech DNS jest to, ze mozna posiadac kilka komputerow
w sieci dostarczajacych odpowiedzi na zapytania. Jak pamietacie kazda
domena musi byc utrzymywana przez conajmniej dwa komputery z czego
jeden z nich spelnia role podstawowego serwera DNS, natomiast drugi to
zapasowy serwer DNS, ktory aby utrzymac aktualnosc danych musi dokonywac
transferu calej zawartosci strefy DNS serwera podstawowego, w momencie
gdy dokonywane sa jakiekolwiek zmiany. Problem polega na tym, ze
potencjalny napastnik takze moze sciagnac taki plik strefy, dopoki mu
tego nie uniemozliwimy. Przykladowy trasfer strefy moze wygladac w
nastepujacy sposob:

asmie$ host -t ns przyklad.pl
przyklad.pl name server ns1.przyklad.pl
przyklad.pl name server ns2.przyklad.pl

Tym sposobem uzyskalismy adresy serwerow DNS dla naszej domeny. Teraz
czas na cos bardziej interesujacego:

asmie$ host -l przyklad.pl ns1.przyklad.pl
przyklad.pl name server ns1.przyklad.pl
przyklad.pl name server ns2.przyklad.pl
www.przyklad.pl has address 83.20.22.1
poczta.przyklad.pl has address 83.20.22.2
db.przyklad.pl has address 83.20.22.3
83-20-22-2.przyklad.pl domain name pointer poczta.przyklad.pl

Jak widzimy polecenie host -l dokonala trasferu strefy i wyswietlilo
nam ja. W ten sposob atakujacy moze poznac strukture naszej sieci i
szybko zaczac sie dobierac do interesujacej go maszyny. Juz wie gdzie
trzymana jest baza danych (db.przyklad.pl), gdzie znajdue sie poczta
uzytkownikow itp. W przypadku bardziej rozbudowanych sieci dzieki takim
informacjom moze on sprecyzowac swoj atak tylko na konkretne serwer,
inne zostawiajac w spokoju. Bo i po co ma atakowac serwer poczty, gdy
interesuja go informacje zawarte w bazie danych ? Co z tym zrobic ?
Uzywajac BIND nalezy dodac do strefy opcje allow-trasfer { } gdzie
wpisujemy adresy IP komputerow, ktore maja pozwolenie na transfer
sterfy. Mozna zrobic to takze globalnie:

options {
allow-trasfer {83.20.22.1;}
}

Uzywajac DJBDNS jestesmy mniej narazenie na trasfery sterfy, poniewaz
mozesz byc poddatny na nie w przypadku nieprawidlowej konfiguracji.
Jezeli uzywasz axfrdns mozesz okreslac takze konkretne komputery
dla ktorych dozwolony jest trasfer stref. Jezeli jednak wszystkie Twoje
serwery nazw pracuja pod kontrola DJBDNS i nie masz potrzeby uzywania
BIND'ow jako serwerow zapasowych wystarczy rsync aby zsynchronizowac
wszystkie strefy automatycznie. Jak zapobiegac temu w Windows ? Odpowiedz
w paragrafie V.
Z podobnym problemem borykamy sie dla wyszukiwania odwrotnego. Wyszukiwanie
odwrotne umozliwia uzyskanie nazwy hosta podajac jego adres IP. Jezeli
napastnik zna nasze IP, moze przeskanowac caly blok adresow IP w poszukiwaniu
innych maszyn np. tej samej firmy. Zazwyczaj jest taki problem, ze
dostajac kilka adresow IP (np. od TP) dostajemy je pokolei tzn. roznia
sie tylko ostatnia cyfra. Agresor po odnalezieniu naszego adresu IP
po prostu moze sprawdzic poprzednie i kolejne adresy w poszukiwaniu
innych naszych serwerow. Co mu daje wyszukiwanie odwrotne ? Otoz moze
on poznac przeznaczenie tych maszyn, gdyz czesto stosujemy nazwy
opisujace funkcje jakie spelnia dany serwer. O ile trasfery stref
sa w wielu przypadkach zablokowane, o tyle malo kto mysli zeby nie nadawac
wiele znaczych nazw serwerom przy wyszukiwaniu odwrotnym. Przyklad:

asmie$ host 194.203.11.95
95.11.203.194.IN-ADDR.ARPA domain name pointer www.przyklad.pl

I juz wie ze jest to nasz glowny serwer. Pojedzie troche dalej:

asmie$ host 194.203.11.96
96.11.203.194.IN-ADDR.ARPA domain name pointer db.przyklad.pl

O.. udalo sie znalezc serwer bazy danych. No to super :). Dla nas moze
juz nie byc tak super :P. Rekordy PTR nie musza odzwierciedlac
prawdziwych nazw komputera. Dobrym sposobem jest uzycie
odwroconych nazw hostow, ktore nie beda niosly ze soba nawet
najmniejszych informacji o przeznaczeniu danej maszyny. Dla przykladu:

asmie$ host 194.203.11.96
96.11.203.194.IN-ADDR.ARPA domain name pointer 194-203-11-96.przyklad.pl

I kto sie teraz domysli, ze wlasnie na tym serwerze trzymana jest baza danych ?
Specyfikacja DNS niestety sama w sobie nie oferuje praktycznie
zadnych zabezpieczen. Najwiekszym problemem ostatnich czasow staje sie
technika zwana zatruwaniem pamieci cache, ktora omowie bardzo dokladnie w
rozdziale VI. Tutaj chcialbym wspomniec o jednym ze sposobow rozwiazania tego
problemu. Jest nim DNSSEC, ktory powstal w 1997 roku. Zapewnia on autoryzacje,
integralnosc danych oraz szyfrowanie. Niestety nie jest jeszcze zbyt powszechnie
uzywany aczkolwiek warto sie przyjrzec mu blizej. Wiecej informacji na jego
temat mozecie znalezc pod adresem: http://www.dnssec.net.

III. Bezpieczenstwo DNS w Linux

Czas przejsc do konkretnych serwerow DNS. Zaczniemy od systemu Linux dla ktorego
istnieja dwa glowne serwery DNS: BIND i DJBDNS. Najpopularniejszym serwerem
DNS jest BIND i od niego zaczne omowienie. Obecnie istnieja w zasadzie
3 wersje:

BIND 4.x - starsza wersja, ktorej kod zostal bardzo dokladnie przebadany i
przeanalizowany. Zawiera wszystkie poprawki zabezpieczen dostepne w
wersji 8.x i nadal jest uzywany.

BIND 8.x - nastepca 4.x. Bardziej rozbudowany, wzbogacony zostal o wiele nowych
opcji konfiguracyjnych. Kod zrodlowy jest jednak tak skomplikowany,
ze nie zostal sprawdzony w zwiazku z czym odradzam uzywania tej wersji.

BIND 9.x - zawiera te same funkcje co 8.x + pare dodatkowych. Kod zostal przepisany
jednak nadal nie jest na tyle czytelny jak byc powinien. Jezeli
decydujemy sie na BINDa ta wersja jest najlepszym wyborem.

DJBDNS jest konkurencyjnym serwerem DNS, o wiele bardziej bezpiecznym niz BIND,
oferujacym w zasadzie to samo co BIND. Jest to wedlug mnie najlepszy wybor dla
serwerow, ze wzgledu wlasnie na bezpieczenstwo. Jeszcze nikt nie odebral nagrody
jaka autor DJBDNS oferuje za znalezienie w nim bledu zwiazanego z bezpieczenstwem,
a zatem mozna przypuszczac, ze jeszcze dlugo tego nikt nie zrobi. Dlatego tez
dopoki odpowiednio skonfigurujemy DJBDNS nie pozwalajac na robienie mu dziwnych
rzeczy jak np.: trasfer strefy dla kazdego hosta w sieci, mozemy poki co spac
spokojnie.

Co zrobic natomiast z BINDem ? Odpowiedz jest dosc prosta - zmienic go na
DJBDNS :) Jezeli jednak mamy sentyment do BINDa/szef nam kaze itp. bedziemy
sie musieli sporo napracowac nad tym aby byl on bezpieczny. Po pierwsze musimy
przejrzec serwisy, ktore zajmuja sie oglaszaniem dziur w programach, a takze
zainteresowac sie Bugtraq. Szukamy informacji o BIND oraz problemach z dana
wersja, ktora zamierzamy uzyc. Dobrze jest poczytac na ten temat i w razie czego
zastosowac sie do podanych zalecen aby uniknac roznych przykrych niespodzianek.
Trzeba zaznaczyc, ze przejrzenie w chwili instalacji BINDa podanych wyzej miejsc
nie wystarczy - tylko staly monitoring takich serwisow i list da nam ochrone
(aczkolwiek nikt nie mowi ze w 100%).

BIND ma jeszcze jedna dosc ciekawa wlasciwosc - pole BIND CHAOS. Umozliwia ono
uzyskanie napastnikowi jeszcze wiekszej ilosci informacji na temat atakowanego
hosta. Dla przykladu wersja BIND'a - nic prostszego, wystarczy zapytac sie
samego BINDa o nia :):

asmie$ host -c chaos -t txt version.bind ns1.przyklad.pl
version.bind CHAOS destriptive text "9.1.3"

Zaoszczedza to wiele czasu agresorom, ktorzy wiedza z czym maja do czynienia
i szybko znajduja odpowiednie 'narzedzia' dla tej konkretnej wersji. Co jeszcze
ujawnia pole CHAOS ? Liste nazwisk autorow :) Zapewne wiekszosc mysli, ze jest
to jakas niegrozna informacja - ot, autorzy BINDa chcieli sie pochwalic wiec
sie dodali :) I tu jest problem - lista nazwisk jest dostepna tylko w
BIND 9.x - a zatem jezeli polecenie:

asmie$ host -c chaos -t txt authors.bind ns1.przyklad.pl

zwroci liste nazwisk, atakujacy bedzie wiedzial, ze na pewno uruchomiona zostala
wersja 9.x. Jedynym ratunkiem przed wyciekiem informacji z pol CHAOS jest ich
wylaczenie. Mozna tego dokonac na przyklad poprzez uzycie widokow znanym
kazdemu uzytkownikowi BIND 9.x - jezeli nie wiesz o nich nic przejrzyj google
w poszukiwaniu obslugi widokow w BIND.

Na koniec polecam przejrzec bugtraq oraz inne miejsca gdzie mozna znalezc informacje
o bledach w oprogramowaniu szukajac tym razem DJBDNS - roznica w ilosci
bledow znalezionych w BIND i w zasadzie brak czegokolwiek niebezpiecznego w
DJBDNS powinien na tyle Cie zaskoczyc, ze zaczniesz uzywac DJBDNS :).

IV. Bezpieczenstwo DNS w Windows

W Windows sprawa ma sie troche inaczej niz w Linux. Usluga DNS jest rowniez
bardzo poddatna na bledy, szczegolnie te w zabezpieczeniach. Zajme sie tutaj
usluga serwera DNS dla systemow Windows 2k/2003 z racji tego, ze dokonano tam
ciekawej rzeczy: zintegrowano strefy DNS z usluga Active Directory. Integracja
ta powoduje, ze w przypadku zle skonfigurowanych stref, mozliwe staje sie
opublikowanie pewnych informacji Active Directory w tych strefach, ktore sa
widoczne z zewnatrz. Jak sie kazdy domysla moze byc to bardzo niemile...
Pierwsza niemila rzecz. ktora zaskakuje w Windows DNS jest mnogosc kont, ktore
maja uprawnienia administracyjne w stosunku do serwera DNS. Sa ta:
Administrators, Domain Administrators, Enterprise Admins, Enterprise
Domain Admins Controller oraz DNSAdmins. Przy administrowaniu serwerem
opartym o Windows wazne jest, aby powyzsze grupy miec pod scisla kontrola,
poniewaz to wlasnie userzy tych grup moga namieszac nam przy konfiguracji
DNS. Najlepiej aby samemu zarzadzac danym serwerem DNS lub powierzyc to zadanie
jakiejs zaufanej osobie, ktora nie narazi serwera na niebezpieczenstwo. Nalezy
pamietac ze w Windows trzeba sie bardziej przylozyc do zabezpieczenia serwera
DNS - przyczyna jest prosta - jezeli cos pojdzie nie tak, popelnimy jakis blad,
dzieki integracji DNS i Active Directory mozemy miec sporo balaganu.
Podobnie jak w przypadku maszyn Linuxowych tak i Windows jest narazony na
problemy zwiazane z trasferem strefy. Aby temu zapobiec mamy dwa mozliwe
rozwiazania. Korzystajac z zakladki Zone Trasfers w oknie wlasciwosci strefy
mozemy wybrac jedna z dwoch opcji: ograniczyc transfer stref tylko i wylacznie
do serwerow wpisanych na karcie Serwery nazw. Jezeli administrujemy wieloma
serwerami DNS wtedy jest to bardzo korzystna sprawa, z racji tego iz mozemy
szybko skonfigurowac przesylanie stref pomiedzy nimi, a zaden inny komputer
nie bedzie mial uprawnien aby tego dokonac. Druga opcja jest podanie
konkretnych adresow IP serwerow, ktore sa autoryzwane do tego aby pobrac od
nas strefe. Ktore rozwiazanie jest wygodniejsze zalezy juz tylko od nas i od
ilosci komputerow/serwerow jakie maja dostac zezwolenie do przeprowadzania
takich trasferow strefy.

Co poza tym mozemy zrobic w Windows ? Ciekawa sprawa jest wlaczenie IPSec
pomiedzy klientem a serwerem dla polaczen DNS. Przed wyslaniem jakiejkolwiek
kwerendy klient musi negocjowac z serwerem bezpieczne polaczenie, ktore w
przypadku nie dojscia do skutku serwer moze zablokowac. IPSec posiada do tego
taka ciekawa wlasciwosc, iz obsluguje w zasadzie 2 rodzaje autoryzacji: AH czyli
wymaganie autoryzacji przed nawiazaniem polaczenia i wyslaniem kwerendy, jednak
same dane nie sa szyfrowane, a zatem sa nadal narazone na przechwycenie przez
agresora. ESP umozliwia szyfrowanie calego polaczenia zatem staje sie ono
zupelnie nieczytelne dla osoby przechwytujacej pakiety.

W Windows istnieje jeszcze jeden typ rekordow - SRV, ktore umozliwiaja usludze
Active Directory byc oglaszana w DNS. SRV sa rekordami zasobow o nastepujacej budowie:

_nazwa_uslugu._protokol.nazwa_domeny TTL SRV priorytet port_nasluchujacy nazwa_hosta

Co z tego wynika ? Jezeli strefy powiazemy z Active Directory to mozliwe staje sie
przechowywanie informacji o nich w bazie danych Active Directory nie zas w
normalnych plikach. Informacje o strefach replikowane sa do innych kontrolerow domeny
skad moga czerpac klienci DNS, natomiast Active Directory nie zapewnia replikacji stref
DNS do innych domen lasu. Ponadto kazdy z rekordow moze posiadac wlasna liste
kontroli dostepu co umozliwa pelniejsze kontrolowanie tego co i kto pobiera od
nas. O zabezpieczaniu bufora DNS w Windows dowiecie sie juz w nastepnym rozdziale,
ktory poswiecony jest wlasnie takim atakom. A bedzie to...

V. DNS cache poisoning - dlaczego tak skuteczne ?

DNS cache poisoning (zatruwanie bufora cache DNS) stalo sie w ostatnim czasie bardzo
popularne. Co umozliwia ta technika? Rozwazmy pewna hipotetyczna sytuacje:

Pan X chce wejsc na strone swojego banku aby dokonac przelewu. W tym celu musi
wejsc na strone np.: www.bank.pl. 2 min przed nim pewien pan Y wykonal pewna sztuczke.
Wyslal do serwera DNS, z ktorego takze korzysta pan X zapytanie o adres IP domeny
bank.pl -> serwer DNS wyslal zapytanie do jednego z glownych serwerow i oczekuje na
odpowiedz. Zanim jednak ja otrzyma pan Y wysyla do tego serwera DNS spreparowana
odpowiedz o adres bank.pl -> podajac przy tym adres IP swojego wlasnego komputera.
Wczesniej pan Y przygotowal strone wygladajaca zupelnie tak jak strona bank.pl i
umiescil ja na swoim komputerze. Serwer DNS akceptuje ta odpowiedz i wysyla panu
Y odpowiedz, ze adresem bank.pl jest adres jego wlasnego komputera. Pana Y bardzo
to ucieszylo, poniewaz bylo to tym co chcial. Serwer DNS w celu przyspieszenia
wyszukiwania dodal taki wpis do swojej pamieci bufora. W tej chwili wedlug
serwera DNS adresem bank.pl jest adres komputera pana Y. Kiedy nadeszla poprawna
odpowiedz na zapytanie ktore wyslal serwer DNS, zostala ona zignorowana poniewaz
informacja o tym znajdowala sie juz w pamieci. Pan X otwiera przegladarke i wpisuje
adres www.bank.pl. Jego komputer wysyla zapytanie do serwera DNS o adres bank.pl.
Niestety serwer utrzymuje w pamieci cache odpowiedz, ktorej udzielil przed chwila
panu Y (ta sfalszowana). Pan X nieswiadomy niczego wchodzi na strone banku, ktora
wyglada identycznie jak prawdziwa. Niczego nie podejrzewajac wpisuje swoj login oraz
haslo, ktore przechwytuje pan Y. Blyskawicznie laczy sie z prawdziwym bankiem,
wpisuje login i haslo pana X a zleca przelew na swoje konto.

W przytoczonym powyzej przykladzie pan X padl ofiara ataku zwanego DNS cache
poisoning i w zasadzie nie mial nawet najmniejszej szansy aby sie przed nim
obronic. Wprawdzie pan Y nie mial mozliwosci spreparowania certyfikatu, ktorym
legitymuje sie bank, jednak mogl wstawic inny, falszywy, o ktorym poinformowala
by przegladarka u pana X. Jednak wiekszosc ludzi widzac ostrzezenia o tym, ze
certyfikat moze byc sfalszowany nie widzi w tym najmniejszego problemu i klika
po prostu "Zaakceptuj" po czym nie widzi zadnego problemu. Sek w tym, ze problem jest
i to jest bardzo powazny. Wymieniony wyzej przyklad jest jednym z bardziej
czarnych scenariuszy ale ofiara takiego ataku moze pasc w zasadzie kazda domena.
Do zadan administratora nalezy dbalosc o to, azeby takie ataki nie mialy miejsca.

Co jest potrzebne do przeprowadzenia udanego ataku ? Otoz napastnik musi znac
ID zapytania DNS - jest to dosc prosta sprawa poniewaz wartosc ID miesci sie w
zakresie od 1 do 65535 - wysylajac tyle pakietow ile mozliwosci ID agresor ma
pewnosc, ze ktores ID bedzie odpowiednie. Druga sprawa jest troszke trudniejsza
poniewaz musimy wiedziec, ktory glowny serwer nazw zostanie odpytany przez
serwer DNS, ktorego pamiec cache chcemy zatruc. Tym samym w sfalszowanej odpowiedzi
oprocz samego ID musimy takze uzyc adresu IP serwera glownego, ktory zostanie
odpytany przez serwer DNS, ktory atakujemy. Jezeli nie wiesz jak zrobic - poszukaj
na googlach :). Czasem moze sie okazac, ze problemem bedzie tez port docelowy,
na ktory musi wplynac odpowiedz. Tutaj ujawnia sie kolejny problem serwerow
typu BIND, dla ktorych wyslanie odpowiedzi na port 53 zostanie zawsze
zaakceptowane, a zatem napastnik nie bedzie mial najmniejszego problemu z
przewidzeniem portu. DJBDNS uzywa losowych portow zrodlowych do wysylania zapytan
i akcpetuje odpowiedzi wyslane tylko na ten port docelowy, ktory byl portem
zrodlowym w zapytaniu. Dlatego tez DJBDNS jest zdecydowanie mniej poddatny na
klasyczny atak DNS cache poisoning. Chyba wspominalem juz wczesniej, ze DJBDNS
jest zdecydowanie lepsza alternatywa od BIND'a i tutaj ujawnia sie nastepny
powod, dla ktorego warto go uzywac.

Niestety nie wszystko wyglada tak rozowo. Mimo, iz normalnie napastnik musi
wyslac 65535 pakietow, aby miec pewnosc, ze jego ID zostanie zaakceptowane to
wprowadzono pewna modyfikacje tej metody. Pozwala ona ograniczyc wyslana ilosc
sfalszowanych pakietow do ok. 700 aby uzyskac bardzo wysokie prawdopodobienstwo
sukcesu. Modyfikacja ta opiera sie na wyslaniu wiekszej ilosci sfalszowanych
odpowiedzi na wieksza ilosc zapytan. Dzieki temu nie wysylamy jednego zapytania
i wielu odpowiedzi, a wiele zapytan i wiele odpowiedzi. Ogolnie schemat dzialania
przedstawia sie nastepujaco: agresor wysyla duzo zapytan z wielu sfalszowanych
adresow IP o te sama nazwe domeny, pozniej wysyla duzo sfalszowanych odpowiedzi,
rowniez z wielu adresow IP ustawiajac ID losowo - w ten sposob nie trzeba
ustawiac ID po kolei od 1 do 65535, a mozna liczyc na szczescie.

BIND w wersji 8 nie obsluguje kolejkowania zapytan, a zatem powyzsza modyfikacja
ma racje bytu, atak przedstawiony na poczatku (klasyczny) takze, poniewaz
wszystkie odpowiedzi na port 53 beda akceptowane. BIND 9 kolejkuje zapytania
czyniac modyfikacje ataku klasycznego bezuyteczna (na wiele zapytan do serwera DNS,
wysyla on tylko jedno zapytanie do serwerow glownych). Nadal jednak wersja 9 przyjmuje
odpowiedzi na port 53 nie zglaszajac zadnych problemow. DJBDNS jest praktycznie
niemozliwy do zaatakowania w zwiazku z tym ze generuje losowe numery portow,
zatem agresor poza ID musialby zgadnac numer portu. Zanim by mu sie to udalo
nadeszlaby poprawna odpowiedz z glownego serwera i z ataku nici. Zawsze mozna jednak
przeprowadzic atak na glowny serwer (DDoS) aby spowolnic wyslanie odpowiedzi,
jednak czas ktory jest potrzebny na odpowiednie odgadniecie tego wszystkiego jest
zbyt dlugi. W przypadku Windows atak taki latwiej jest przeprowadzic na klienta
DNS a nie na serwer, poniewaz np. Win XP wysyla zapytania zawsze z tego samego
portu, natomiast ID jest zwiekszane o 1. Coz.. zabezpieczenia Windows nie sa
zbyt mocne w tym wzgledzie :).

Co mozemy zrobic jako administratorzy uslug DNS ? Po pierwsze uzywac DJBDNS,
ktory jest zdecydowanie mniej poddatny na atatki DNS cache poisoning. Dobrym
rozwiazaniem jest wylaczen zapytan rekurencyjnych i uzywanie zapytan
iteracyjnych. Czym sie one roznia ? Otoz model zapytan rekurencyjnych opiera
sie na tym, iz serwer DNS jezeli nie zna odpowiedzi na nasze zapytanie
sam pyta dalej oraz szuka tej odpowiedzi, po czym ja umieszcza w cache, a
wynik zwaraca do pytajcego. W modelu iteracyjnym jezeli serwer DNS nie zna
odpowiedzi sam nie wysyla innych zapytan, zwraca natomiast pytajacemu adres
innego serwera DNS, ktory jego zdaniem bedzie w stanie obsluzyc zapytanie.
Niezbyt zalecanym choc najbezpieczniejszym rozwiazaniem jest wylaczenie
pamieci cache serwera nazw, jednak na pewno spowoduje to opoznienie w
dzialaniu uslug korzystajacych z DNS.
Ponownie najlepszym rozwiazaniem o ktorym juz wczesniej wspominalem jest
uzycie DNSSEC.
Zabezpieczenie sie przed atakami DNS cache poisoning jest najskuteczniejsze
wtedy gdy wspodzialaja ze soba administratorzy DNS, tworcy WWW oraz sami
uzytkownicy. O ile metody zabezpieczenia sie adminow DNS opisalem powyzej
o tyle tworcy WWW i uzytkownicy dysponuja mniejszym orezem w walce z tym
procederem. Tworcy WWW moga zastosowac SSL do uwierzytelniania ich stron
jednak, aczkolwiek jest to mozliwe do obejscia poprzez technike zwana
IDN (!google IDN). Najlepszym wyjsciem byloby gdyby uzytkownicy nie
uzywali nazw domenowych, a adresow IP jednak z racji tego iz jest to
ekstremalnie niewygodne raczej nie ma na to co liczyc :).

VI. Zakonczenie

Artykul mial na celu przedstawienie problemow zwiazanych z bezpieczenstwem
DNS, w zadnym wypadku nie sluzyl jako instruktaz dla dzieci, ktore wlasnie
nie maja pieniedzy na nawego laptopa i chca podmieniac strony bankow :-).
Wszlekie uwagi prosze slac na adres podany u gory.