Jeśli chodzi o DNS, Cricket Liu dosłownie napisał książkę. Jest współautorem wszystkich pięciu wydań książki O’Reilly „DNS i BIND”, która jest powszechnie uważana za ostateczny przewodnik po wszystkich rzeczach związanych z Domain Name System. Cricket jest obecnie dyrektorem ds. infrastruktury w firmie Infoblox.
DNS jest bez wątpienia krytycznym elementem sieci komputerowych, ale zdarzają się sytuacje, w których narzędzia te mogą być wykorzystywane do złych celów. W tym tygodniu na New Tech Forum, Cricket przygląda się rosnącemu problemowi ataków DDoS opartych na DNS i sposobom radzenia sobie z nimi. — Paul Venezia
Ataki DDoS oparte na DNS: Jak działają i jak je powstrzymać
Ataki DDoS oparte na DNS (distributed denial-of-service attack) stały się jednym z najczęstszych destrukcyjnych ataków w Internecie. Ale jak one działają? I co możemy zrobić, aby się przed nimi bronić?
W tym artykule opiszę, w jaki sposób ataki DDoS zarówno wykorzystują, jak i celują w infrastrukturę DNS. Pokażę również, co można zrobić, aby chronić siebie i innych.
Wielki spoof
Generowanie ataku DDoS z wykorzystaniem infrastruktury DNS jest niezwykle proste: Napastnicy wysyłają zapytania do serwerów nazw w całym Internecie, a te serwery nazw zwracają odpowiedzi. Zamiast jednak wysyłać zapytania z własnych adresów IP, atakujący podszywają się pod adres celu – którym może być serwer WWW, router, inny serwer nazw lub jakikolwiek inny węzeł w Internecie.
Szukanie zapytań DNS jest szczególnie łatwe, ponieważ są one zwykle przesyłane przez UDP (bezpołączeniowy protokół User Datagram Protocol). Wysłanie zapytania DNS z dowolnego adresu IP jest mniej więcej tak proste i ma mniej więcej taki sam efekt, jak napisanie czyjegoś adresu zwrotnego na pocztówce.
Szukanie zapytań nie wystarczy jednak do obezwładnienia celu. Jeśli odpowiedzi na te zapytania nie byłyby większe niż same zapytania, atakujący równie dobrze mógłby zalać cel spoofowanymi zapytaniami. Nie, aby zmaksymalizować szkody wyrządzone celowi, każde zapytanie powinno zwracać bardzo dużą odpowiedź. Okazuje się, że jest to bardzo łatwe do przeprowadzenia.
Od czasu pojawienia się EDNS0, zestawu rozszerzeń do DNS wprowadzonych w 1999 roku, wiadomości DNS oparte na UDP są w stanie przenosić duże ilości danych. Odpowiedź może mieć rozmiar nawet 4096 bajtów. Z drugiej strony, większość zapytań ma długość mniejszą niż 100 bajtów.
Dawno temu znalezienie tak dużej odpowiedzi w przestrzeni nazw Internetu było stosunkowo trudne. Ale teraz, gdy organizacje zaczęły wdrażać DNSSEC, czyli DNS Security Extensions, jest to znacznie łatwiejsze. DNSSEC przechowuje klucze kryptograficzne i podpisy cyfrowe w rekordach w przestrzeni nazw. Są one naprawdę ogromne.
Na moim blogu można zobaczyć przykład odpowiedzi ze strefy isc.org, która zawiera rekordy DNSSEC. Rozmiar odpowiedzi wynosi 4077 bajtów, w porównaniu z zapytaniem o rozmiarze zaledwie 44 bajtów.
Wyobraź sobie teraz atakujących z całego Internetu, którzy wysyłają to sfałszowane zapytanie z adresu IP Twojego serwera WWW do serwerów nazw isc.org. Na każde 44-bajtowe zapytanie, Twój serwer WWW otrzymuje 4077-bajtową odpowiedź, co daje współczynnik wzmocnienia prawie 93 razy.
Zróbmy szybkie obliczenia, aby dowiedzieć się, jak źle może być. Powiedzmy, że każdy atakujący ma stosunkowo skromne połączenie z Internetem o przepustowości 1Mb/s. Może wysłać około 2840 bajtów odpowiedzi. Może on wysłać około 2840 44-bajtowych zapytań przez to łącze na sekundę. Taki strumień zapytań spowodowałby, że do Twojego serwera WWW dotarłoby prawie 93Mbps odpowiedzi. Każdy z 11 atakujących reprezentuje 1Gbps.
Gdzie aspołeczni atakujący mogliby znaleźć 10 przyjaciół, którzy pomogliby im w przeprowadzeniu ataku? Właściwie to nie potrzebują żadnych. Wykorzystają botnet składający się z tysięcy komputerów.
Ostateczny efekt jest druzgocący. W swoim kwartalnym globalnym raporcie o atakach DDoS firma Prolexic (zajmująca się łagodzeniem skutków DDoS) poinformowała o niedawnym ataku opartym na DNS na klienta, który przekroczył 167 Gb/s. Prolexic poinformował również, że średnia przepustowość ataku DDoS wzrosła o 718 procent do 48 Gb/s w ciągu jednego kwartału.
Ale czekaj! Czy serwery nazw isc.org nie mogłyby zostać zmodyfikowane tak, aby rozpoznawały, że są odpytywane w kółko o te same dane, z tego samego adresu IP? Czy nie mogłyby one powstrzymać ataku?
Na pewno mogą. Ale serwery nazw isc.org nie są jedynymi, których napastnik może użyć do wzmocnienia swojego ruchu. Jasne, istnieją inne autorytatywne serwery nazw, które atakujący może wykorzystać, ale jeszcze gorsze są otwarte rekurencyjne serwery nazw.
Otwarty rekurencyjny serwer nazw to po prostu serwer nazw, który przetwarza zapytania rekurencyjne z dowolnego adresu IP. Mogę wysłać do niego zapytanie o dane isc.org, a on odpowie mi i Ty możesz zrobić to samo.
W Internecie nie powinno być wielu otwartych rekurencyjnych serwerów nazw. Zadaniem rekurencyjnego serwera nazw jest wyszukiwanie danych w przestrzeni nazw Internetu w imieniu klientów DNS, takich jak te na twoim laptopie lub smartfonie. Administratorzy sieci, którzy konfigurują rekurencyjne serwery nazw (np. dział IT) zazwyczaj przeznaczają je do użytku przez określoną społeczność (np. Ciebie i Twoich współpracowników). O ile nie korzystają z usług takich jak OpenDNS czy Google Public DNS, nie zamierzają, aby korzystali z nich obywatele Mołdawii. Dlatego administratorzy, którzy mają na uwadze dobro publiczne, bezpieczeństwo i przede wszystkim kompetencje, konfigurują mechanizmy kontroli dostępu do swoich serwerów nazw rekurencyjnych, aby ograniczyć ich użycie do autoryzowanych systemów.
Biorąc to pod uwagę, jak dużym problemem mogą być otwarte serwery nazw rekurencyjnych? Całkiem dużym. Open Resolver Project zebrał listę 33 milionów otwartych rekurencyjnych serwerów nazw. Hakerzy mogą strzelać spoofed zapytania na tyle z nich, jak im się podoba, aby wylać isc.org danych na serwerze WWW, serwer nazwy lub router graniczny, aż dławi.
Tak działają ataki DDoS oparte na DNS. Na szczęście mamy kilka sposobów, aby im przeciwdziałać.
Jak przetrwać burzę
Pierwszą sprawą jest oprzyrządowanie infrastruktury DNS, dzięki czemu będziesz wiedział, kiedy jesteś atakowany. Zbyt wiele organizacji nie ma pojęcia, jakie jest ich obciążenie zapytaniami, więc nigdy nie będą wiedzieć, czy są atakowane.
Określenie obciążenia zapytaniami może być tak proste, jak użycie wbudowanej obsługi statystyk BIND. Serwer nazw BIND zrzuca dane do swojego pliku statystyk, kiedy uruchomisz rndc stats, na przykład, lub w konfigurowalnym interwale statystyk. Możesz zbadać statystyki pod kątem szybkości zapytań, błędów gniazdek i innych oznak ataku. Nie przejmuj się, jeśli nie jesteś pewien, jak będzie wyglądał atak – częścią celu monitorowania DNS jest ustanowienie linii bazowej, abyś mógł zidentyfikować, co jest nienormalne.
Następnie przyjrzyj się swojej infrastrukturze internetowej. Nie ograniczaj się do zewnętrznych autorytatywnych serwerów nazw; sprawdź infrastrukturę przełączników i routerów, zapory sieciowe i połączenia z Internetem. Zidentyfikuj wszystkie pojedyncze punkty awarii. Określ, czy można je łatwo (i efektywnie kosztowo) wyeliminować.
Jeśli to możliwe, rozważ szeroką dystrybucję geograficzną swoich zewnętrznych autorytatywnych serwerów nazw. To pomaga uniknąć pojedynczych punktów awarii, oczywiście, ale to również pomaga, gdy nie jesteś pod atakiem. Rekursywny serwer nazw rozwiązujący nazwę domeny w jednej z Twoich stref będzie próbował odpytywać autorytatywny serwer nazw najbliżej niego, więc rozkład geograficzny będzie miał tendencję do zapewnienia lepszej wydajności dla Twoich klientów i korespondentów. Jeśli Twoi klienci są skupieni w niektórych geograficznych, spróbuj umieścić autorytatywny serwer nazw w ich pobliżu, aby zapewnić najszybsze odpowiedzi.
Prawdopodobnie najbardziej podstawowym sposobem zwalczania ataków DoS jest overprovision swoją infrastrukturę. Dobrą wiadomością jest to, że przeprogramowanie serwerów nazw nie musi być drogie; sprawny serwer nazw może obsłużyć dziesiątki, a nawet setki tysięcy zapytań na sekundę. Nie jesteś pewien, jaką wydajność mają Twoje serwery nazw? Możesz użyć narzędzi zapytań, takich jak dnsperf, aby przetestować wydajność serwerów nazw – najlepiej używając platformy testowej podobnej do produkcyjnych serwerów nazw w laboratorium, a nie samych serwerów produkcyjnych.
Decyzja o tym, jak bardzo przeprocesować serwery nazw, jest subiektywna: Ile jest warta Twoja obecność w sieci? Czy istnieją inne elementy infrastruktury internetowej, które ulegną awarii wcześniej niż serwery nazw? Oczywiście nierozsądnie jest wydawać pieniądze na budowę najwyższej klasy infrastruktury DNS za routerem granicznym lub zaporą ogniową, która zawiedzie, zanim serwery nazw zdążą się choćby spocić.
Jeśli pieniądze nie są przeszkodą, warto wiedzieć, że najnowocześniejsze ataki DDoS na infrastrukturę DNS mogą przekraczać 100 Gb/s.
Używanie Anycast może również pomóc w odparciu ataku DDoS. Anycast jest techniką, która pozwala wielu serwerom dzielić pojedynczy adres IP, a szczególnie dobrze sprawdza się w przypadku DNS. W rzeczywistości główne serwery nazw w Internecie używają Anycast od lat, aby dostarczać dane strefy korzeniowej na całym świecie, jednocześnie pozwalając, aby lista korzeni mieściła się w pojedynczej wiadomości DNS opartej na UDP.
Aby wdrożyć Anycast, hosty obsługujące serwery nazw będą musiały uruchomić dynamiczny protokół routingu, taki jak OSPF lub BGP. Proces routingu rozgłasza swoim sąsiednim routerom trasę do nowego, wirtualnego adresu IP, na którym nasłuchuje Twój serwer nazw. Proces routingu musi być również na tyle inteligentny, aby przestać reklamować tę trasę, jeśli lokalny serwer nazw przestanie odpowiadać. Demona routingu można powiązać ze stanem serwera nazw za pomocą kodu własnej konstrukcji – lub można kupić produkt, który zajmie się tym za nas. NIOS firmy Infoblox, nieprzypadkowo, zawiera obsługę Anycast.
Jak Anycast chroni przed atakami DDoS? Załóżmy, że masz sześć zewnętrznych serwerów nazw w dwóch grupach Anycast (tzn. trzy współdzielące jeden adres IP Anycast i trzy współdzielące inny). Każda grupa zawiera jednego członka w Stanach Zjednoczonych, jednego w Europie i jednego w Azji. Host przeprowadzający atak DDoS przeciwko Tobie może wysyłać ruch tylko do – a zatem atakować – tylko jednego członka każdej z grup z dowolnego miejsca w Internecie w tym samym czasie. Jeśli atakujący nie będą w stanie uzyskać wystarczającej ilości ruchu z Ameryki Północnej, Europy i Azji jednocześnie, aby zalać twoją infrastrukturę, nie odniosą sukcesu.
Wreszcie, istnieje sposób, aby skorzystać z szerokiej dystrybucji geograficznej i Anycast w tym samym czasie, bez znacznych nakładów kapitałowych: Użyj dostawcy DNS opartego na chmurze. Firmy takie jak Dyn i Neustar prowadzą własne serwery nazw Anycast w centrach danych na całym świecie. Płacisz im za hostowanie Twoich stref i odpowiadanie na zapytania dotyczące Twoich danych. I można nadal utrzymywać bezpośrednią kontrolę nad danymi strefy, prosząc dostawcę, aby skonfigurować swoje serwery nazw jako sekundarne dla swoich stref, ładując dane z głównego serwera nazw, który wyznaczasz i zarządzasz we własnym zakresie. Tylko upewnij się, że uruchomisz główny ukryty (to znaczy, bez rekordu NS wskazującego na niego), lub ryzykujesz, że atakujący będzie celował w niego jako pojedynczy punkt awarii.
Jedno słowo ostrzeżenia przy korzystaniu z opartych na chmurze dostawców DNS: Większość z nich wystawia Ci rachunek przynajmniej częściowo w oparciu o liczbę zapytań, jakie ich serwery nazw otrzymują dla danych w Twoich strefach. W przypadku ataku DDoS te zapytania mogą gwałtownie wzrosnąć (całkowicie poza Twoją kontrolą i wcale nie na Twoją korzyść), więc upewnij się, że dostawcy mają przepisy pozwalające radzić sobie z atakami DDoS bez przerzucania kosztów ruchu na Ciebie.
Jak uniknąć stania się wspólnikiem w atakach DDoS
Teraz już wiesz, jak skonfigurować infrastrukturę DNS, aby odeprzeć atak DDoS. Równie ważne jest jednak, aby upewnić się, że nie jesteś współwinny ataku DDoS na kogoś innego.
Pamiętasz opis tego, jak serwery DNS mogą wzmacniać ruch? Atakujący mogą używać zarówno otwartych rekurencyjnych serwerów nazw, jak i autorytatywnych serwerów nazw jako wzmacniaczy, wysyłając spoofed zapytania, które powodują, że serwery nazw wysyłają odpowiedzi ponad 100 razy większe niż zapytanie do dowolnych celów w Internecie. Oczywiście nie chcesz być celem takiego ataku, ale nie chcesz też być jego wspólnikiem. Atak wykorzystuje zarówno zasoby serwerów nazw, jak i przepustowość łącza. Jeśli cel podejmie środki w celu zablokowania ruchu z twojego serwera nazw do swojej sieci, to po zakończeniu ataku, cel może nie być w stanie rozwiązać nazw domen w twoich strefach.
Jeśli uruchomisz otwarty rekurencyjny serwer nazw, rozwiązanie jest proste: Nie rób tego. Istnieje bardzo niewiele organizacji, które mają jakiekolwiek uzasadnienie dla uruchomienia serwera nazw otwartego na zapytania rekursywne. Google Public DNS i OpenDNS to dwie organizacje, które przychodzą mi na myśl, ale jeśli to czytasz, to pewnie nie jesteś jedną z nich. Reszta z nas powinna zastosować kontrolę dostępu do naszych serwerów nazw rekurencyjnych, aby upewnić się, że tylko autoryzowani użytkownicy z nich korzystają. Prawdopodobnie oznacza to ograniczenie zapytań DNS do adresów IP w naszych sieciach wewnętrznych, co jest łatwe do zrobienia w każdej implementacji serwera nazw wartej swojej soli. (Serwer DNS firmy Microsoft nie obsługuje kontroli dostępu do zapytań opartej na adresach IP. Przeczytaj, co chcesz na ten temat.)
Ale co, jeśli używasz autorytatywnego serwera nazw? Oczywiście, nie możesz ograniczyć adresów IP, z których będziesz akceptować zapytania — a w każdym razie nie bardzo (możesz odrzucać zapytania z ewidentnie fałszywych adresów IP, takich jak adresy RFC 1918). Ale możesz ograniczyć odpowiedzi.
Dwa długoletnie internetowe „białe kapelusze”, Paul Vixie i Vernon Schryver, zdały sobie sprawę, że ataki DDoS, które wykorzystują autorytatywne serwery nazw do wzmocnienia, wykazują pewne wzorce zapytań. W szczególności, napastnicy wysyłają do serwerów nazw to samo zapytanie z tego samego spreparowanego adresu IP (lub bloku adresów) w kółko, dążąc do maksymalnego wzmocnienia. Żaden dobrze działający rekurencyjny serwer nazw nie zrobiłby tego. Przechowywałby odpowiedź w pamięci podręcznej i nie pytałby ponownie, dopóki nie upłynąłby czas życia rekordów w odpowiedzi.
Vixie i Schryver wymyślili sprytny mechanizm, zwany ograniczaniem szybkości odpowiedzi (Response Rate Limiting, RRL), który pozwala autorytatywnemu serwerowi nazw śledzić, jak często wysyłał tę samą odpowiedź do tego samego pytającego. Jeśli wskaźnik ten przekroczy pewien konfigurowalny próg, serwer nazw przestanie wysyłać tę odpowiedź do pytającego na określony czas. Jeśli querier przestanie zasypywać autorytatywny serwer nazw tym samym pytaniem, autorytatywny serwer nazw przestanie tłumić tę odpowiedź. Efekt jest taki, że autorytatywny serwer nazw nigdy nie wyśle żadnej odpowiedzi do queriera z szybkością wyższą niż próg, co czyni go bezużytecznym w ataku DDoS.
RRL został włączony do serwerów nazw BIND w wersji 9.9.4, a kilka innych implementacji serwerów nazw teraz go obsługuje, w tym NSD i Knot. Ponieważ ludzie uaktualniają swoje serwery nazw do nowszych wersji lub nowych implementacji, które obsługują RRL, powinno to stopniowo utrudniać atakującym wykorzystywanie infrastruktury DNS jako wzmacniaczy.
Mam nadzieję, że ta dyskusja pomogła Wam zrozumieć, w jaki sposób infrastruktura DNS jest wykorzystywana w atakach DDoS oraz w jaki sposób możecie najlepiej oprzeć się atakom DDoS i upewnić się, że Wasze serwery nazw nie biorą w nich udziału, o czym nie wiecie.
New Tech Forum zapewnia środki do badania i omawiania pojawiających się technologii dla przedsiębiorstw w niespotykanej dotąd głębi i szerokości. Wybór jest subiektywny, oparty na naszym wyborze technologii, które uważamy za ważne i najbardziej interesujące dla czytelników InfoWorld. InfoWorld nie przyjmuje do publikacji materiałów marketingowych i zastrzega sobie prawo do redagowania wszystkich dostarczonych treści. Wszelkie pytania prosimy kierować na adres [email protected].
Ten artykuł, „The ultimate guide to preventing DNS-based DDoS attacks”, został pierwotnie opublikowany w serwisie InfoWorld.com. Aby uzyskać najnowsze informacje na temat technologii biznesowych, śledź InfoWorld.com na Twitterze.