Jakie rodzaje luk w zabezpieczeniach udostępnia DNSSEC?

Planowałem podpisać moją strefę DNS za pomocą DNSSEC. Moja strefa, rejestrator i mój serwer DNS (BIND9) obsługują DNSSEC. Jedynym, który nie obsługuje DNSSEC, jest mój drugi dostawca serwerów nazw (a mianowicie buddyns.com ).

Na swojej stronie internetowej podają to w odniesieniu do DNSSEC:

BuddyNS nie obsługuje DNSSEC, ponieważ naraża na pewne luki nieodpowiednie dla dużej usługi DNS.

Cóż, myślałem, że użycie DNSSEC jest obecnie w jakiś sposób wątpliwe, ponieważ większość programów tłumaczących nie sprawdza, czy rekordy są poprawnie podpisane. Nie wiedziałem jednak, że - zgodnie z ich oświadczeniem - wydaje się, że pod warunkiem ujawnienia pewnego rodzaju luk w zabezpieczeniach.

Jakie są te „podatności na zagrożenia”?

DNSSEC ma pewne ryzyko, ale nie są one bezpośrednio związane z refleksją lub wzmocnieniem. W tym przypadku rozszerzenie rozmiaru EDNS0 to czerwony śledź. Pozwól mi wyjaśnić.

Wszelkie wymiany pakietów, które nie zależą od poprzedniego dowodu tożsamości, podlegają nadużyciom ze strony osób atakujących DDoS, które mogą wykorzystywać tę nieuwierzytelnioną wymianę pakietów jako reflektor, a być może także jako wzmacniacz. Na przykład ICMP (protokół stojący za „ping”) może być w ten sposób nadużywany. Podobnie jak pakiet TCP SYN, który żąda do 40 pakietów SYN-ACK, nawet jeśli SYN został sfałszowany, aby pochodził od ofiary, która nie chce tych pakietów SYN-ACK. I oczywiście wszystkie usługi UDP są podatne na ten atak, w tym NTP, SSDP, uPNP i, jak zauważono w innych odpowiedziach tutaj, w tym również DNS.

Większość urządzeń do wykrywania włamań, zapobiegania włamaniom i równoważenia obciążenia to wąskie gardła, niezdolne do nadążenia za ruchem o „szybkości linii”. Również wiele routerów nie może działać z prędkością linii, a niektóre przełączniki. Te wąskie gardła, będąc najmniejszą rzeczą „na ścieżce” i mniejsze niż same linki, są faktycznym celem ataków DDoS opartych na przeciążeniu. Jeśli utrzymasz czyjąś zaporę zajętą ​​ruchem atakującym, dobry ruch nie przejdzie, nawet jeśli łącza nie będą pełne. A to, co spowalnia zaporę ogniową, to nie całkowita liczba bitów na sekundę (którą można zwiększyć za pomocą większych wiadomości, a EDNS0 i DNSSEC to zrobią), ale raczej całkowita liczba pakietów na sekundę.

Istnieje wiele miejskich legend na temat tego, jak DNSSEC pogarsza DDoS z powodu większego rozmiaru wiadomości DNSSEC, i chociaż ma to intuicyjny sens i „brzmi dobrze”, jest po prostu fałszywe. Ale gdyby istniała odrobina prawdy w tej legendzie, prawdziwa odpowiedź nadal leżałaby gdzie indziej - [ponieważ DNSSEC zawsze używa EDNS0, ale EDNS0 można używać bez DNSSEC], a wiele normalnych odpowiedzi innych niż DNSSEC jest tak dużych jak DNSSEC odpowiedzią byłoby. Rozważ rekordy TXT używane do reprezentowania zasad SPF lub kluczy DKIM. Lub po prostu duży zestaw rekordów adresów lub MX. Krótko mówiąc, żaden atak nie wymaga DNSSEC, a zatem wszelkie skupienie się na DNSSEC, ponieważ ryzyko DDoS jest źle wykorzystane.

DNSSEC ma ryzyko! Jest trudny w użyciu i trudniejszy do prawidłowego użycia. Często wymaga to nowego przepływu pracy w celu zmiany danych strefy, zarządzania rejestratorem, instalacji nowych instancji serwera. Wszystko to należy przetestować i udokumentować, a gdy tylko coś się zepsuje, co jest związane z DNS, technologia DNSSEC musi zostać zbadana jako możliwa przyczyna. Rezultatem, jeśli zrobisz wszystko dobrze, będzie to, że jako sygnatariusz strefy, twoja własna treść i systemy online będą bardziej wrażliwe dla twoich klientów. Jako dalekosiężny operator serwerów, wynik będzie taki, że zawartość i systemy innych osób będą dla ciebie bardziej kruche. Ryzyko to często przeważa nad korzyściami, ponieważ jedyną korzyścią jest ochrona danych DNS przed modyfikacją lub zamianą podczas lotu. Ten atak jest tak rzadki, że nie jest wart całego tego wysiłku. Wszyscy mamy nadzieję, że DNSSEC stanie się wszechobecny pewnego dnia, ze względu na nowe aplikacje, które włączy. Ale prawda jest taka, że ​​dziś DNSSEC jest kosztem, bez korzyści i obarczony wysokim ryzykiem.

Więc jeśli nie chcesz korzystać z DNSSEC, to twoja przywilej, ale nie daj się zwieść, że problemem DNSSEC jest jego rola jako wzmacniacza DDoS. DNSSEC nie odgrywa koniecznej roli jako wzmacniacz DDoS; istnieją inne tańsze lepsze sposoby wykorzystania DNS jako wzmacniacza DDoS. Jeśli nie chcesz korzystać z DNSSEC, niech tak będzie, ponieważ nie wypiłeś jeszcze Kool Aid i chcesz zostać ostatnim (później), a nie pierwszym (teraz).

Należy zapobiegać nadużywaniu serwerów treści DNS, zwanych czasem „serwerami urzędowymi” jako wzmacniaczy odzwierciedlających DNS, ponieważ DNS używa UDP, a ponieważ UDP jest nadużywany przez sfałszowane pakiety źródłowe. Aby zabezpieczyć serwer treści DNS przed tego rodzaju nadużyciami, nie należy blokować UDP ani wymuszać TCP (przy użyciu sztuczki TC = 1), ani blokować DOWOLNEGO zapytania ani rezygnować z DNSSEC. Żadna z tych rzeczy ci nie pomoże. Potrzebujesz ograniczenia szybkości odpowiedzi DNS(DNS RRL), całkowicie darmowa technologia, która jest teraz obecna na kilku serwerach nazw open source, w tym BIND, Knot i NSD. Nie można naprawić problemu z odbiciem DNS za pomocą zapory, ponieważ tylko skrzynka pośrednia uwzględniająca zawartość, taka jak sam serwer DNS (z dodanym RRL) wie wystarczająco dużo o żądaniu, aby móc dokładnie odgadnąć, co jest atakiem, a co nie. Chciałbym jeszcze raz podkreślić: DNS RRL jest bezpłatny i każdy serwer urzędów powinien go uruchomić.

Na zakończenie chcę ujawnić moje uprzedzenia. Napisałem większość BIND8, wynalazłem EDNS0 i współtworzyłem DNS RRL. Pracuję nad DNS od 1988 roku jako 20-coś, a teraz jestem zrzędliwy 50-coś, z coraz mniejszą cierpliwością dla na wpół upieczonych rozwiązań dla źle zrozumianych problemów. Proszę przyjąć moje przeprosiny, jeśli ta wiadomość brzmi zbyt podobnie jak „hej, dzieci, zejdźcie z mojego trawnika!”

Znam dwie szczególne luki. Jest odbicie / wzmocnienie wspomniane przez Håkan. I istnieje możliwość wyliczenia strefy.

Odbicie / wzmocnienie

Odbicie oznacza ataki, w których żądania ze sfałszowanym źródłowym adresem IP są wysyłane do serwera DNS. Podrabiany host jest główną ofiarą ataku. Serwer DNS nieświadomie wyśle ​​odpowiedź do hosta, który nigdy o nią nie prosił.

Wzmocnienie odnosi się do każdego ataku odbicia, w którym odpowiedź odbita składa się z większej liczby bajtów lub większej liczby pakietów niż pierwotne żądanie. Przed DNSSEC + EDNS0 wzmocnienie w ten sposób pozwoliłoby na wysłanie tylko 512 bajtów. Dzięki DNSSEC + EDNS0 możliwe jest wysłanie 4096 bajtów, które zwykle obejmują 3-4 pakiety.

Możliwe są środki zaradcze dla tych ataków, ale nie znam żadnego serwera DNS, który je zaimplementuje.

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.

Wyliczenie strefy

To, czy wyliczenie strefy jest podatne na zagrożenia, jest przedmiotem debaty. Ale jeśli nie chcesz, aby wszystkie nazwy w Twojej strefie były znane publicznie, prawdopodobnie uznałbyś to za lukę. Wyliczenie strefy można w większości złagodzić dzięki wykorzystaniu rekordów NSEC3.

Problem, który nadal występuje, nawet przy użyciu NSEC3, polega na tym, że osoba atakująca może znaleźć skrót każdej etykiety, po prostu wyszukując losowe nazwy. Gdy atakujący ma już wszystkie wartości skrótu, można wykonać na nich atak siłowy off-line.

Właściwa obrona przed wyliczeniem strefy wymagałaby od atakującego wykonania zapytania do autorytatywnego serwera dla każdego odgadnięcia. Jednak w DNSSEC nie ma takiej obrony.

To, co przychodzi mi na myśl, nie jest tak naprawdę specyficzne dla DNSSEC, ale raczej na temat rozszerzenia EDNS0, na którym opiera się DNSSEC.

EDNS0 pozwala na większe ładunki UDP, a większe ładunki UDP mogą pozwolić na gorsze ataki odbicia / wzmocnienia ruchu.

Nie wiem, jaki jest odsetek sprawdzania poprawności resolverów, ale wydaje się, że popularne oprogramowanie serwera nazw jest domyślnie dostarczane z włączoną funkcją sprawdzania poprawności i łatwo można znaleźć znanych dostawców usług, którzy są otwarci na ich weryfikację, takich jak Comcast i publiczne resolwery Google.

Na tej podstawie sądzę, że procent sprawdzania poprawności resolwerów jest prawdopodobnie w znacznie lepszym stanie niż procent podpisanych stref.