DNS narzędziem ataków DDoS

Ataki DDoS wykorzystujące serwery DNS stale się nasilają, a przyczyną tego są od dawna znane luki, które wciąż nie zostały załatane przez administratorów IT. Dlatego warto wiedzieć jak przebiega taki atak i jak można się przed nim bronić.

DNS to oczywiście kluczowy element sieci komputerowych, ale zdarza się, że jest wykorzystywany niezgodnie z przeznaczeniem. Rosnącym problemem są ataki DNS przeprowadzane właśnie na bazie DNS. Jak przebiega taki atak? Jak można się przed nim bronić?

Ataki DNS stały się powszechnym zagrożeniem w Internecie, a dość prostym sposobem ich przeprowadzenia jest właśnie użycie infrastruktury DNS. Są to tzw. ataki odbite bądź zwielokrotnione. Atakujący wysyła zapytania do różnych serwerów nazw, które odpowiadają na te żądania. Jednakże atakujący w miejsce źródłowego adresu IP zamiast swojego wstawia adres ofiary. Może to być adres serwera WWW, routera, innego serwera nazw czy dowolnego urządzenia podłączonego do Internetu. Taki zmodyfikowany pakiet nie ma praktycznego zastosowania, ponieważ po dotarciu do serwera docelowego odpowiedź zostanie wysłana pod sfałszowany adres, a nie do nadawcy. Jest to jednak stan pożądany przez osoby planujące atak. Ważnym ograniczeniem ataków z podmienionym adresem źródła jest brak możliwości nawiązania pełnej sesji protokołu TCP. Natomiast nadają się one do wykorzystania w przypadku bezstanowego protokołu UDP, którego używa się do przesyłania komunikatów DNS.

Zobacz również:

Możliwość łatwej podmiany adresu źródłowego to nie wszystko, co sprawiło, że serwery DNS są narzędziem stosowanym w atakach DDoS. Gdyby odpowiedź na zapytanie nie była większa niż samo zapytanie, atakujący mógłby po prostu zalewać ruchem sieciowym bezpośrednio cel ataku. Aby zwiększyć siłę rażenia, atakujący szukają jak największych odpowiedzi na zapytania. Ich znalezienie nie jest trudne. Odkąd w 1999 r. został wprowadzony EDNS0, zestaw rozszerzeń protokołu DNS, komunikaty UDP z odpowiedziami DNS mogą przenosić dużej ilości danych. Odpowiedź może mieć nawet 4096 bajtów. Jednocześnie większość zapytań ma długość mniejszą niż 100 bajtów.

Alternatywnie, zamiast szukać rekordu DNS, który zwraca długą odpowiedź, atakujący może również włamać się do źle zabezpieczonego serwera nazw i zmodyfikować wybrane rekordy tak, aby generowały odpowiedź o rozmiarach zbliżonych do 4000 bajtów.

Początkowo znalezienie tak dużych odpowiedzi w przestrzeni nazw internetowych było trudne. Jednak od kilku lat firmy wdrażają DNSSEC i znalezienie odpowiedzi o dużych rozmiarach stało się znacznie łatwiejsze. DNSSEC przechowuje klucze kryptograficzne i podpisy cyfrowe w rekordach dotyczących nazw domen. Tego rodzaju dane mają duże rozmiary. Przykład, jak może wyglądać odpowiedź zawierająca rekord DNSSEC jest dostępny, np. na stroniehttp://tinyurl.com/atakidns. W tym przypadku zapytanie ma zaledwie 44 bajty, natomiast odpowiedź liczy 4077 bajtów. Załóżmy, że potencjalny agresor zaczyna wysyłać sfabrykowane zapytania DNS zawierające podstawiony adres IP serwera WWW ofiary. Każde żądanie liczące 44 bajty spowoduje, że serwer DNS odeśle odpowiedź do serwera WWW mającą 4077 bajtów, czyli prawie 93 razy więcej.

Policzmy szybko, jak poważne skutki może mieć taki atak. Jeśli atakujący ma łącze o szybkości wysyłania 1 Mbit/s, umożliwia mu to wysłanie w ciągu sekundy 2840 zapytań. Taki strumień zapytań przełoży się na prawie 93 Mbit/s transmisji składającej się z odpowiedzi na te zapytania. Ruch ten będzie trafiał do atakowanego serwera, a jeśli atakujący będzie miał do dyspozycji 11 komputerów, łącznie wygenerują one atak o wielkości 1 Gbit/s. Oczywiście nie będą to komputery należące do kolegów naszego agresora. Zamiast tego zostanie wykorzystany botnet składający się z tysięcy komputerów. Ostateczny efekt może być niszczycielski. Firmy zajmujące się analizowaniem ataków DDoS rejestrowały już ataki wykorzystujące opisaną technikę, które sięgały 200 Gbit/s. Jednocześnie szybko rośnie średnia wielkość tego typu ataków.

Nasuwa się pytanie, czy serwer DNS zasypywany fałszywymi zapytaniami może wykrywać ten fakt i nie wysyłać odpowiedzi? Owszem, może. Jednak atakujący nie posługują się jednym serwerem DNS do wzmacniania ruchu. Do dyspozycji są przecież inne autorytatywne serwery nazw, a sytuację pogarszają jeszcze bardziej otwarte, rekursywne serwery DNS. Są to serwery, które bezpośrednio odbierają zapytania DNS i je przetwarzają. Do takiego serwera można wysłać zapytanie dotyczące dowolnej domeny, np. isc.org, której dotyczy omawiany przykład.

Teoretycznie nie powinno być wiele otwartych rekurencyjnych serwerów nazw w Internecie. Ich funkcją jest wyszukiwanie danych w przestrzeni nazw internetowych w imieniu klientów DNS (klientem jest, np. przeglądarka internetowa uruchamiania na komputerze użytkownika). Administratorzy sieci tworzący rekurencyjne serwery nazw z reguły robią to na użytek danej społeczności (na przykład pracowników danej firmy). Jeśli nie są to takie usługi, jak OpenDNS czy Google Public DNS, intencją ich twórcy nie jest publicznie ich udostępnianie. Odpowiedzialny administrator IT zadba o właściwą kontrolę dostępu do rekurencyjnego serwera nazw, aby mogli korzystać z niego tylko upoważnieni użytkownicy. Praktyka wygląda jednak inaczej. W ramach Open Resolver Project wykryto grubo ponad 30 milionów otwartych, rekursywnych serwerów DNS. Hakerzy mogą dowolnie czerpać z tej listy.

DNS odporny na ataki

Podstawowym zadaniem jest monitorowanie infrastruktury DNS, aby wykrywać trwające ataki. Zbyt wiele organizacji nie ma pojęcia, jakie zapytania przychodzą do serwera nazw, więc nie mają sposobu, aby wiedzieć, czy są atakowane. Określenie, jaka jest zawartość zapytania nie wymaga zaawansowanych umiejętności i narzędzi, wystarczy skorzystać z mechanizmów wspierających raportowanie wbudowanych w oprogramowanie BIND. Ten serwer nazw może zapisywać zawartość zapytań do pliku statystyk w momencie użycia przez administratora komendy rndc stats lub regularnie w zadanych interwałach. Zebrane dane można analizować pod kątem częstotliwości zapytań, występujących błędów czy innych oznak ataku. Nie trzeba się martwić ewentualnym brakiem wiedzy, jak wygląda atak – jednym z celów monitorowania DNS jest ustalenie punktu odniesienia, aby można było określić, co jest anomalią.

Następnym krokiem jest przyjrzenie się firmowym urządzeniom odpowiadającym za łączność z Internetem. Nie chodzi tylko o zewnętrzne serwery DNS. Należy sprawdzić routery i przełączniki, zapory sieciowe oraz połączenie internetowe. Robi się to w celu zidentyfikowania pojedynczych punktów awarii. Następnym krokiem jest określenie, czy można je łatwo i niedużymi kosztami wyeliminować.

Jeśli to możliwe, warto rozważyć możliwie najszersze geograficzne rozproszenie zewnętrznych, autorytatywnych serwerów nazw. Jest to sposób na wyeliminowanie jednego z pojedynczych punków awarii, ale ma zalety również wtedy, kiedy firma nie jest pod atakiem. Rekursywny serwer DNS będzie wysyłał zapytania do najbliższego geograficznie serwera autorytatywnego, więc rozproszenie przełoży się na poprawę wydajności. Jeśli klienci firmy znajdują się w określonych rejonach geograficznych, warto umieścić autorytatywny serwer nazw blisko nich, aby skrócić czas oczekiwania na odpowiedź.

Podstawowym sposobem zwalczania ataków DDoS jest jednak zapewnianie nadmiarowej infrastruktury. Najczęściej uruchamianie dodatkowych serwerów nazw nie jest kosztowne. Wydajny serwer DNS potrafi obsłużyć setki, a nawet tysiące zapytań na sekundę. Aby sprawdzić wydajność firmowych serwerów nazw, można posłużyć się takim narzędziem, jak dnsperf. Aby nie zakłócać działania maszyny produkcyjnej, dobrym pomysłem jest użycie do takich testów serwera o podobnej konfiguracji w środowisku testowym.

Decyzja, o ile nadmiarowy będzie serwer nazw, jest subiektywna i zależy od tego, jak ważna dla firmy jest ciągła dostępność jej serwisów internetowych. Czy są inne elementy infrastruktury sieciowej, które w przypadku ataku zawiodą szybciej niż serwer nazw? Oczywiście, wydawanie pieniędzy na budowę wydajnej infrastruktury DNS za brzegowym routerem czy firewallem, które przestaną działać zanim serwer DNS wejdzie w ogóle na wyższe obroty, jest ryzykowne. Jeśli środki finansowe nie są przeszkodą, warto wiedzieć, że średnio ataki DDoS z wykorzystaniem DNS przekraczają 50 Gbit/s.

Kolejnym sposobem odpierania ataków DDoS jest technika Anycast, która umożliwia współdzielenie jednego adresu IP przez kilka serwerów. Sprawdza się ona szczególnie dobrze w przypadku DNS. W praktyce główne serwery DNS w Internecie od lat działają z wykorzystaniem Anycast. Aby wdrożyć Anycast, maszyna z serwerem nazw musi mieć uruchomiony dynamiczny protokół routingu, np. OSPF lub BGP. Proces routingu będzie rozgłaszał do najbliższych routerów trasę do nowych, wirtualnych adresów IP, na których nasłuchują pozostałe maszyny z serwerami nazw. Proces routingu powinien działać w taki sposób, aby wstrzymywać rozgłaszanie tej trasy, jeśli lokalny serwer nazw przestanie odpowiadać. Można powiązać proces routingu z mechanizmami monitorowania stanu serwerów pisząc własny kod lub korzystając z gotowych rozwiązań.

W jaki sposób Anycast chroni przed atakami DDoS? Przyjmijmy, że firma ma sześć zewnętrznych serwerów nazw połączonych w dwie grupy Anycast (każda grupa ma własny adres IP, który współdzielą wchodzące w jej skład trzy serwery). W każdej grupie poszczególne serwery znajdują się w różnych rejonach geograficznych. Komputer, z którego inicjowany jest atak DDoS, może wysyłać fałszywe zapytania tylko do jednego serwera w grupie. Dopóki atakujący nie będzie w stanie generować ruchu w każdym z trzech regionów geograficznych, tak długo jego atak nie zakończy się sukcesem.

Co ważne, można korzystać z techniki Anycast i geograficznego rozproszenia serwerów nazw bez ponoszenie znacznych wydatków. Rozwiązaniem są chmurowe usługi DNS. Takie firmy, jak Dyn czy Neustar oferują serwery nazw z włączonym Anycast we własnych centrach danych zlokalizowanych w różnych miejscach na całym świecie. Klient płaci tylko za hosting jego serwerów nazw. Jednocześnie może zachować bezpośrednią kontrolę nad tymi serwerami, jeśli dostawca usługi skonfiguruje je jako podrzędne serwery nazw dla danej strefy, a następnie będzie wczytywać dane z podstawowego serwera nazw działającego w sieci lokalnej klienta. Trzeba przy tym pamiętać, żeby ten podstawowy serwer był ukryty (nie może być dla niego rekordu NS, który prowadziłby do tego serwera). W przeciwnym razie atakujący może wybrać za cel właśnie ten podstawowy serwer nazw.


TOP 200