Słowo komentarza do chmurowych usług DNS. Większość dostawców częściowo określa wysokość opłat na podstawie liczby zapytań, które odbierze serwer DNS w danej strefie. Jeśli dojdzie do ataku DDoS, liczba zapytań wzrośnie drastycznie i odbędzie się to poza kontrolą klienta. Dlatego w umowie z dostawcą należy uregulować taką sytuację, aby koszty zapytań wygenerowanych w związku z atakiem nie obciążyły klienta.

Jak nie zostać wspólnikiem

Opisane dotychczas sposoby obrony przed atakiem DDoS miały na celu zapewnienie ciągłości działania serwerów nazw. Równie ważne jest, aby firmowe serwery DNS nie stały się narzędziami w ataku na kogoś innego. Atakujący mogą jako wzmacniaczy ruchu użyć zarówno otwartych, rekursywnych serwerów nazw, jak i serwerów autorytatywnych. Raczej żadna firma nie chciałaby, żeby jej serwery stały się takimi wzmacniaczami. W ataku zostaną wykorzystane zarówno zasoby serwera nazw, jak i przepustowość sieci. Jeśli ofiara podejmie kroki mające zablokować ruch z takiego serwera nazw, po zakończeniu ataku ofiara może nie mieć możliwości tłumaczenie adresów znajdujących się danej strefie.

Zobacz również:

• Ministerstwo Cyfryzacji ostrzega przed rosnącym zagrożeniem atakami DDoS
• Wbudowana słabość protokołu HTTP/2 wykorzystana do masowych ataków DDoS

Jeśli problem dotyczy otwartego, rekurencyjnego serwera DNS, rozwiązanie jest proste. Należy taki serwer wyłączyć i więcej go nie włączać. W przypadku firm rzadko zdarza się, aby miały one uzasadniony powód do uruchamiania własnego serwera nazw otwartego na rekurencyjne zapytania. Google Public DNS oraz OpenDNS to właśnie takie uzasadnione przypadki. Pozostałe firmy powinny wdrażać mechanizmy kontroli dostępu do rekursywnych serwerów nazw, aby mieć pewność, żeby będą do nich trafiać zapytania tylko z zaufanych komputerów. To z reguły oznacza ograniczenie możliwości przysyłania zapytań DNS z adresów IP znajdujących się w wewnętrznej sieci przedsiębiorstwa. Jest to proste do skonfigurowania w większości serwerów nazw (wyjątkiem jest Microsoft DNS Server, który nie obsługuje kontroli dostępu na bazie adresów, ale z tym ograniczeniem również można sobie poradzić).

Co jednak, jeśli firma ma własny autorytatywny serwer DNS? Oczywiście, w tym przypadku nie ma możliwości limitowania dostępu na podstawie źródłowych adresów IP, z których zapytania będą akceptowane. W ogóle nie ma specjalnie sposobów filtrowania nadchodzących zapytań, poza zablokowaniem ewidentnie podrobionych adresów IP, jak te wymienione w dokumencie RFC 1918. Można natomiast ograniczać odpowiedzi na zapytania.

Eksperci zaobserwowali, że ataki DDoS wykorzystujące DNS charakteryzują się określonym wzorcem zapytań. Przede wszystkim atakujący wysyłają zapytania, w których powtarzają się: źródłowy adres IP (lub blok adresów) oraz poszukiwana nazwa domeny. Zapytania mogłyby dotyczyć różnych nazw domen, ale atakujący wybierają takie, które generują największe odpowiedzi, a więc zapewniają największe wzmocnienie ruchu. Żaden poprawnie działający, rekursywny serwer nazw tak się nie zachowuje. Po otrzymaniu pierwszej odpowiedzi dotyczącej danej domeny zapisze on otrzymane informacje w swojej pamięci podręcznej i więcej nie będzie wysyłać takich samych zapytań, aż nie upłynie czas ważności danego rekordu.

Te spostrzeżenia legły u podstaw stworzenia mechanizmu Response Rate Limiting (RRL), który umożliwia autorytatywnemu serwerowi nazw śledzenie, jak często wysyła on odpowiedzi na te same żądania. Jeśli częstotliwość i liczba przekroczą zdefiniowany przez administratora poziom, serwer na pewien czas przestanie wysyłać odpowiedzi na te zapytania. Jeśli powtarzające się zapytania przestaną bombardować autorytatywny serwer nazw, ten serwer przestanie blokować wysyłanie odpowiedzi na te zapytania. Dzięki takiemu zabezpieczeniu autorytatywne serwer nazw nigdy nie będą wysyłać odpowiedzi w ilościach większych niż limity ustawione przez administratora, co czyni je nieprzydatnymi w realizowaniu ataków DDoS.

Mechanizm RRL został wbudowany w oprogramowanie BIND od wersji 9.9.4. Jest też w kilku innych implementacjach serwera nazw, m.in. w NSD oraz Knot. Wraz z przechodzeniem coraz większej liczby firm na nowsze wersje oprogramowania serwerów DNS zawierające RRL coraz trudniej będzie atakującym wykorzystywać infrastrukturę DNS do wzmacniania ataków.

Jak przetrwać burzę

Jest kilka środków, które mogą pomóc, jeśli firma stała się celem ataku wzmacnianego przez serwery DNS. Źródłowe adresy IP serwerów DNS przysyłających odpowiedzi nie są sfałszowane. Te adresy identyfikują serwery nazw wykorzystywane do przeprowadzenia ataku. W zależności od nasilenia ataku i własnych chęci do jego ograniczenia, można ustawić limity ruchu z tych źródłowych adresów IP lub użyć reguł filtrowania, które odrzucą podejrzanie duże wiadomości (powyżej 512 bajtów) z odpowiedziami DNS. W ekstremalnej sytuacji można całkowicie zablokować ruch z otwartych, rekursywnych serwerów DNS.

Te działania nie wyeliminują źródeł ataku, a także nie ograniczą ruchu sieciowego przechodzącego przez sieci i przełączniki znajdujące się pomiędzy atakowanymi zasobami a otwartymi, rekursywnymi serwerami nazw. Jeśli zablokuje się całkowicie komunikację z tymi serwerami, efektem ubocznym będzie brak możliwości wysyłania właściwych zapytań DNS do tych serwerów. Przykładowo, niektóre firmy uruchamiają otwarte, rekursywne serwery nazw dla swoich pracowników mobilnych, aby mogli korzystać z zaufanego serwera DNS.

Zapobieganie

Ograniczenie ataków wymaga kompleksowych działań. Dwie kwestie są oczywiste. Po pierwsze, należy dbać o bezpieczeństwo stacji roboczych, żeby nie stawały się częścią botnetów. Po drugie, serwery nazw powinny być bezpiecznie skonfigurowane, aby ograniczyć atakującym możliwości modyfikowania (zwiększania rozmiarów) rekordów DNS wykorzystywanych do wzmacniania ataków.

Dobrym pomysłem jest ograniczenie mechanizmów przekazywania (rekurencji) zapytań przez serwer DNS. Zapytania powinny być przekazywane tylko, jeśli pochodzą z zaufanych źródeł. To znacznie ogranicza możliwość przeprowadzania ataku, a odpowiednie mechanizmy są dostępne w popularnym oprogramowaniu realizującym funkcje serwera DNS (BIND oraz Windows Server od wersji 2003). Jeśli firma korzysta z zewnętrznego serwera nazw, warto sprawdzić, czy obsługuje on otwartą rekurencję. Jeśli tak, powinno się skontaktować z administratorem tego serwera i zasugerować wyłączenie tej luki w bezpieczeństwie.

Jednak nawet suma wszystkich wymienionych środków zapobiegawczych nie da takiego efektu, jak sprawdzanie poprawności źródłowego adresu IP. Przeprowadzając taką walidację, można skutecznie zapobiegać atakom. Jeśli w firmie działa zapora sieciowa lub router wyposażone w funkcje ACL, należy tak zmodyfikować reguły ruchu wychodzącego, aby wypuszczały tylko te pakiety, które zawierają adresy IP należące do podsieci używanych wewnętrznie.

Niestety walidacja źródłowych adresów IP nie jest powszechnie stosowana, mimo wielu zachęt płynących od ekspertów bezpieczeństwa i organizacji doradczych, jak SANS, CERT czy Komitetu SSAC (Security and Stability Advisory Committee) działającego przy ICANN. Krytycy walidacji źródłowych adresów IP wskazują, że realizacja tego zalecenia powoduje wzrost kosztów administracyjnych i spadek wydajność. Jednak ataki DDoS wykorzystujące DNS mają potencjalnie poważniejsze konsekwencje, a częstotliwość i efektywność tych ataków będzie nadal rosnąć, jeśli nadal będzie się ignorować konieczność wdrożenia tego bardzo potrzebnego zabezpieczenia. W sieciach telekomunikacyjnych sprawdzanie poprawności numerów telefonów i adresów w przypadku ruchu przychodzącego jest stosowane od dekad. Najwyższy czas, aby to samo robić w sieciach IP.