Wzmocniony atak odbity na serwery DNS


11

Termin Amplified reflected attackjest dla mnie nowy i mam kilka pytań na jego temat.

Słyszałem, że najczęściej dzieje się to na serwerach DNS - czy to prawda?
Jak się przed tym zabezpieczyć?
Skąd wiesz, czy twoje serwery mogą być użyte w takim ataku - Czy to problem z konfiguracją?

Odpowiedzi:


22

Po pierwsze, tego rodzaju atak nie jest (głównie) ukierunkowany na sam DNS, jak sugeruje tytuł. Oczywiście spowoduje to dodatkowe obciążenie serwerów DNS, ale głównym celem jest DDoS innej osobie. Zła konfiguracja serwera może pogorszyć sytuację, ale ostatecznie ten problem jest nieodłącznie związany z projektowaniem DNS i UDP, a właściwie z każdym bezstanowym protokołem komunikacyjnym.

Zasadniczo działa to w ten sposób: osoba atakująca wysyła zwykłe zapytania (DNS) do serwera (DNS). Zapytania te mają wyglądać tak, jakby pochodziły z systemu docelowego. Serwer DNS odpowiada teraz na zapytanie, wysyłając odpowiedź z powrotem do swojego rzekomego źródła - ofiary. Dlatego nazywa się to atakiem refleksyjnym .

Jest to możliwe, ponieważ możesz zweryfikować źródło komunikacji bezstanowej (jako DNS przez UDP) tak dobrze, jak możesz zaufać adresowi nadawcy na pocztówce. Serwer po prostu nie ma sposobu, aby zdecydować, czy zapytanie jest uzasadnione, czy jest częścią takiego ataku. DNS jest tutaj najbardziej popularnym protokołem, ponieważ wokół niego jest mnóstwo serwerów i nie potrzebujesz dużo wiedzy technicznej ani specjalnego sprzętu, aby (źle) z niego korzystać.

Co gorsza (i w ogóle efektywność ataku), spójrz na część dotyczącą wzmocnienia . Nie zaszkodziłoby, gdyby ruch atakującego był równy wielkości wynikowego ruchu. Jedyną korzyścią dla atakującego byłoby ukrycie jego adresu za serwerem DNS. Mógłby sfałszować adres nadawcy bezpośrednio, zupełnie nie byłoby potrzeby przekierowywania przez DNS. Ale odpowiedzi DNS i to kolejny punkt, dlaczego DNS jest tutaj tak popularny, może być znacznie większy niż pytanie. Możesz znaleźć różne liczby na ten temat w zależności od dokładnie użytych zapytań, ale może wzrosnąć do 1:60, jeśli serwer jest wystarczająco przyjazny, aby wykonywać zapytania rekurencyjnedla Ciebie. Dlatego atakujący nie potrzebuje wielu kontrolowanych przez siebie maszyn do generowania dużego złośliwego ruchu.

Ponieważ w publicznym Internecie można z łatwością znaleźć setki i tysiące „otwartych” serwerów DNS, można szybko wyliczyć, jak mało pracy musi wykonać osoba atakująca, jeśli każdy z otwartych serwerów DNS, który zna, zwiększy sześciokrotnie swoją wartość docelową. Jak powiedziałem na początku, nie ma naprawdę dobrego sposobu na przeciwdziałanie temu. Oczywiście wiele serwerów DNS jest dostępnych dla wszystkich, a nie powinno, z powodu błędnej konfiguracji. Ale jest tyle otwartych serwerów, które muszą być otwarte, ponieważ dokładnie taki jest ich cel.

Chociaż nie możesz stwierdzić, czy żądanie jest częścią ataku, czy nie, jedyną opcją jest nie uruchamianie serwera. Możesz bawić się ograniczaniem prędkości i innymi zabawkami, ale nie możesz się tego całkowicie pozbyć. Jeśli zapewniasz DNS dla zabawy, możesz umieścić na czarnej liście źródłowy adres IP żądań. Ale jeśli jesteś na większą skalę, to jeszcze bardziej zaszkodzi ofierze. Pamiętaj, wszystko, co możesz zobaczyć na serwerze DNS, to adres ofiary. Wyobraź sobie, że twoja firma jest atakowana przez DNS twojego dostawcy, a twój dostawca decyduje się na odcięcie usługi DNS dla twojej firmy. Atakujący może to zdobyć jako bazillion punktów bonusowych za odmowę usługi .

W każdym razie te ataki zdarzają się przez cały dzień i noc i są uważane za „szum tła” w Internecie. Jeśli skonfigurujesz publiczny (rekurencyjny) serwer DNS, nie potrwa to długo, zanim będziesz uczestniczyć w losowych atakach. Oczywiście, czasem dzieje się naprawdę źle, gdy duże infrastruktury (takie jak nawet serwery root dns) są niewłaściwie wykorzystywane do wzmacniania, ale w takich przypadkach osobiście podejmowane są proaktywne środki zaradcze, dopóki atak nie spadnie do „normalnych” poziomów.


Dotychczasowe nauczanie. Aby wreszcie odpowiedzieć na twoje pytanie:

Wiesz, że twój serwer jest podatny na ataki, jeśli odpowiada na zapytania bez ograniczeń. Kropka. Jeśli udostępniasz zapytania rekurencyjne, Twój serwer może wygenerować wymieniony współczynnik 1:60 dla atakującego. Jeśli służy tylko nierekurencyjnie, nie jest tak źle, ale nadal ...

Więc...

  • upewnij się, że naprawdę musisz uruchomić publiczny serwer DNS
  • jeśli musisz, spójrz na BIND allow-recursioni allow-querydyrektywy
  • jeśli twój serwer DNS będzie autorytatywny dla twojej strefy , w ogóle nie ma potrzeby rekurencji, ustaw allow-recursionna „none”;
  • jeśli chcesz uruchomić program rozpoznawania nazw dla innych domen , ogranicz dozwolonych użytkowników dla zapytań i zapytań rekurencyjnych. Możesz zdefiniować adresy IP, sieci lub listy dostępu we wspomnianych dyrektywach
  • pomyśl o ograniczeniu prędkości ruchu DNS nie tylko w BIND, ale także na poziomie systemu. Jako bardzo prosty przykład, te reguły iptables nie pozwolą na więcej niż 10 zapytań na minutę z każdego adresu IP:

.

iptables -A INPUT -p udp --dport 53 --set --name dnslimit
iptables -A INPUT -p udp --dport 53 -m recent --update --seconds 60 --hitcount 11 --name dnslimit -j DROP

Mając to na uwadze, powinieneś już iść. Od czasu do czasu na twoim serwerze może nadal występować złośliwy ruch, ale nie w ilościach, które zapewniają ci dobry sen.


3
To jest naprawdę dobra odpowiedź. Dziękujemy za poświęcenie czasu na napisanie tego.
jamieb,

1
@mikejanson serverfault.com/questions/450099 - spójrz na to pytanie, aby zobaczyć, jakie inne opcje możesz mieć (szczególnie łatka BIND autorstwa Vixie & Schryver )
the-wabbit

RRL jest teraz standardową funkcją bind i innych serwerów nazw: kb.isc.org/article/AA-01000/189/…
Patrick Mevzek

Generalnie błędem jest mieć ten sam serwer autorytatywny i rekurencyjny. Najlepsze praktyki zalecają podzielenie tego na dwa osobne procesy.
Patrick Mevzek,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.