To jest pytanie kanoniczne dotyczące zabezpieczenia publicznych serwerów rozpoznawania nazw DNS

Otwarte serwery DNS wydają się dość schludne i wygodne, ponieważ zapewniają adresy IP, z których możemy konsekwentnie korzystać w całej naszej firmie, niezależnie od tego, gdzie się znajdują. Google i OpenDNS zapewniają tę funkcjonalność, ale nie jestem pewien, czy chcę, aby te firmy miały dostęp do naszych zapytań DNS.

Chcę skonfigurować coś takiego do użytku przez naszą firmę, ale słyszę dużo o tym, że jest to niebezpieczna praktyka (szczególnie w odniesieniu do ataków wzmacniających ) i chcę się upewnić, że robimy to dobrze. O czym należy pamiętać przy budowaniu tego rodzaju środowiska?

Jest kilka rzeczy, które musisz zrozumieć, wchodząc w to:

Jest to problem inżynierii sieci.

Większość osób, które chcą skonfigurować tego rodzaju środowisko, to administratorzy systemu. Fajnie, ja też jestem administratorem systemu! Częścią pracy jest zrozumienie, gdzie kończą się twoje obowiązki, a zaczyna ktoś, i wierz mi, nie jest to problem, który administratorzy systemu mogą rozwiązać samodzielnie. Dlatego:

• UDP to protokół bezstanowy. Nie ma uścisku dłoni klienta.
• Zapytania skierowane do serwera DNS to nieuwierzytelniona dwuetapowa transakcja (zapytanie, odpowiedź). Serwer nie może wiedzieć, czy źródłowy adres IP jest sfałszowany przed odpowiedzią.
• Zanim zapytanie dotrze do serwera, jest już za późno, aby zapobiec sfałszowaniu pakietu UDP. Sfałszowaniu można zapobiec tylko poprzez praktykę znaną jako filtrowanie dostępu , temat opisany w dokumentach BCP 38 i BCP 84 . Są one realizowane przez urządzenia sieciowe znajdujące się przed serwerem DNS.
• Nie możemy dać ci instrukcji, jak skonfigurować centrum danych od początku do końca ani jak wdrożyć te najlepsze praktyki. Te rzeczy są bardzo specyficzne dla twoich potrzeb. Format pytań i odpowiedzi po prostu nie działa, a ta strona nie jest przeznaczona do zastąpienia zatrudniania profesjonalnych osób do wykonywania pracy zawodowej.
• Nie zakładaj, że Twoja firma o wartości zbyt dużej, aby mogła upaść, warta miliard dolarów, poprawnie wdraża filtrowanie wejściowe.

To nie jest najlepsza praktyka. Najlepszą praktyką jest nie robienie tego.

Bardzo łatwo jest skonfigurować internetowy program rozpoznawania nazw DNS. Stworzenie jednego wymaga znacznie mniej badań niż zrozumienie związanych z tym zagrożeń. Jest to jeden z tych przypadków, w których dobre intencje nieumyślnie pozwalają na czyny (i cierpienia) innych.

• Jeśli Twój serwer DNS zareaguje na dowolny źródłowy adres IP, który widzi, masz otwarty resolver. Są one stale wykorzystywane w atakach wzmacniających przeciwko niewinnym stronom. Nowi administratorzy systemu codziennie otwierają resolwery , dzięki czemu złośliwe osoby stale je skanują. Naprawdę nie ma pytania, czy twój otwarty resolver będzie użyty w ataku: od 2015 roku jest to prawie pewne. To może nie być natychmiastowe, ale na pewno się stanie.
• Nawet jeśli zastosujesz ACL przy użyciu oprogramowania DNS (tj. BIND), wszystko to ogranicza limit fałszywych pakietów DNS, na które serwer będzie odpowiadał. Ważne jest, aby zrozumieć, że infrastruktury DNS można używać nie tylko do atakowania urządzeń na liście ACL, ale także do wszelkich urządzeń sieciowych między serwerem DNS a urządzeniami, na które będzie on odpowiadał. Jeśli nie jesteś właścicielem centrum danych, jest to problem nie tylko dla ciebie.

Google i OpenDNS to robią, więc dlaczego nie mogę?

Czasami trzeba porównać entuzjazm z rzeczywistością. Oto kilka trudnych pytań, które możesz sobie zadać:

• Czy jest to coś, co chcesz założyć na kaprys, czy to coś, na co masz kilka milionów dolarów, aby zainwestować w to dobrze?

• Czy masz oddany zespół ds. Bezpieczeństwa? Dedykowany zespół nadużyć? Czy oba mają cykle radzenia sobie z nadużyciami związanymi z nową infrastrukturą i skargami, które otrzymasz od podmiotów zewnętrznych?

• Czy masz zespół prawny ?

• Kiedy wszystko to powiedziano i zrobiono, czy cały ten wysiłek nawet zdalnie zacznie się opłacać, przyniesie zysk firmie, czy przekroczy wartość pieniężną związaną z niedogodnościami, które doprowadziły cię w tym kierunku?

Na koniec wiem, że ten wątek to pytania i odpowiedzi, które są dla niektórych z was rozczarowaniem. Błąd serwera służy do udzielania odpowiedzi, a odpowiedź „to zły pomysł, nie rób tego” zwykle nie jest postrzegana jako bardzo pomocna. Niektóre problemy są znacznie bardziej skomplikowane, niż się wydaje na początku, i to jest jeden z nich.

Jeśli chcesz spróbować sprawić, by to zadziałało, możesz poprosić nas o pomoc, próbując wdrożyć tego rodzaju rozwiązanie. Najważniejsze do zrozumienia jest to, że sam problem jest zbyt duży, aby można było udzielić odpowiedzi w wygodnym formacie pytań i odpowiedzi. Musisz poświęcić znaczną ilość czasu na badanie tego tematu i zwrócić się do nas z konkretnymi problemami logicznymi, które napotkałeś podczas wdrażania. Celem tych pytań jest lepsze zrozumienie szerszego obrazu i pomoc w zrozumieniu, dlaczego nie możemy odpowiedzieć na tak szerokie pytanie.

Pomóż nam chronić internet! :)

Niezależnie od tego, czy prowadzisz otwarty rekursor DNS, czy autorytatywny serwer DNS, problem jest taki sam, a większość możliwych rozwiązań jest również taka sama.

Najlepszym rozwiązaniem

Pliki cookie DNS to proponowany standard, który umożliwia serwerom DNS wymaganie od klientów wysłania pliku cookie w celu udowodnienia, że ​​adres IP klienta nie został sfałszowany. Będzie to kosztowało jedną dodatkową podróż w obie strony dla pierwszego wyszukiwania, co jest najniższym kosztem, jaki może zaoferować każde rozwiązanie.

Awaryjne dla starszych klientów

Ponieważ pliki cookie DNS nie są jeszcze znormalizowane, konieczne będzie oczywiście wsparcie starszych klientów teraz i przez wiele lat.

Możesz oceniać żądania limitów od klientów bez obsługi plików cookie DNS. Jednak limity prędkości ułatwiają atakującemu wykonanie DoS twojego serwera DNS. Uwaga: niektóre serwery DNS mają funkcję ograniczenia prędkości przeznaczoną tylko dla autorytatywnych serwerów DNS. Ponieważ pytasz o rekurencyjny resolver, takie implementacje ograniczające szybkość mogą nie mieć zastosowania. Limit prędkości z założenia stanie się wąskim gardłem dla twojego serwera, dlatego atakujący będzie musiał wysłać ci mniej ruchu, aby spowodować odrzucenie uzasadnionych żądań, niż gdyby miałby to miejsce, gdyby nie było ograniczenia prędkości.

Jedną z zalet limitów prędkości jest to, że w przypadku, gdy osoba atakująca zalej Twój serwer DNS żądaniami DNS, istnieje większe prawdopodobieństwo, że pozostanie pojemność, która pozwoli ci ssh do serwera i zbadać sytuację. Dodatkowo można zaprojektować limity stawek, aby przede wszystkim usuwać żądania z adresów IP klientów wysyłających wiele żądań, co może wystarczyć do ochrony przed atakiem DoS przed atakami, którzy nie mają dostępu do fałszywych adresów IP klientów.

Z tych powodów ograniczenie prędkości nieco poniżej rzeczywistej pojemności może być dobrym pomysłem, nawet jeśli tak naprawdę nie chroni przed wzmocnieniem.

Korzystanie z TCP

Można zmusić klienta do korzystania z protokołu TCP, wysyłając kod błędu wskazujący, że odpowiedź jest zbyt duża dla protokołu UDP. Ma to kilka wad. Kosztuje dwa dodatkowe okrążenia. I niektórzy wadliwi klienci nie obsługują tego.

Koszt dwóch dodatkowych podróży w obie strony można ograniczyć tylko do pierwszego zapytania przy użyciu tego podejścia:

Gdy adres IP klienta nie zostanie potwierdzony, serwer DNS może wysłać skróconą odpowiedź, aby zmusić klienta do przełączenia się na TCP. Skrócona odpowiedź może być tak krótka jak żądanie (lub krótsza, jeśli klient używa EDNS0, a odpowiedź nie), co eliminuje wzmocnienie.

Dowolny adres IP klienta, który zakończy uzgadnianie TCP i wyśle ​​żądanie DNS dla połączenia, może zostać tymczasowo umieszczony na białej liście. Raz na białej liście, że IP może wysyłać zapytania UDP i odbierać odpowiedzi UDP do 512 bajtów (4096 bajtów, jeśli używasz EDNS0). Jeśli odpowiedź UDP wyzwala komunikat o błędzie ICMP, adres IP jest ponownie usuwany z białej listy.

Metodę można również odwrócić za pomocą czarnej listy, co oznacza po prostu, że adresy IP klientów są domyślnie dozwolone do wysyłania zapytań przez UDP, ale każdy komunikat o błędzie ICMP powoduje, że adres IP jest na czarnej liście i wymaga zapytania TCP, aby zejść z czarnej listy.

Mapa bitowa obejmująca wszystkie istotne adresy IPv4 może być przechowywana w 444 MB pamięci. Adresy IPv6 musiałyby być przechowywane w inny sposób.

Nie wiem, czy jakikolwiek serwer DNS wdrożył to podejście.

Doniesiono również, że niektóre stosy TCP mogą być wykorzystywane w atakach wzmacniających. Dotyczy to jednak każdej usługi opartej na TCP, a nie tylko DNS. Takie luki należy ograniczyć, aktualizując do wersji jądra, w której stos TCP został naprawiony tak, aby nie wysyłał więcej niż jednego pakietu w odpowiedzi na pakiet SYN.