Atak DNS z amplifikacją: jak nie być źródłem i jak przetrwać jako cel

Ataki DNS z amplifikacją należą do najczęstszych wektorów wolumetrycznych i mają jedną cechę, która odróżnia je od większości pozostałych: ta sama sieć może być w nich zarówno celem, jak i narzędziem. Napastnik nie wysyła ruchu bezpośrednio do ofiary: wykorzystuje cudze serwery DNS, żeby zrobiły to za niego, przy okazji wielokrotnie zwiększając wolumen.

Ten artykuł opisuje obie strony zagadnienia: jak nie stać się źródłem takiego ataku i jak ograniczyć jego skutki, gdy celem jest nasza sieć.

Mechanizm w trzech zdaniach

Napastnik wysyła zapytanie DNS ze sfałszowanym adresem źródłowym, podstawiając adres ofiary. Serwer DNS, nie mając jak zweryfikować nadawcy, odsyła odpowiedź pod ten adres. Ponieważ odpowiedź bywa wielokrotnie większa od zapytania, a napastnik rozsyła zapytania do tysięcy serwerów jednocześnie, ofiara dostaje ruch o objętości nieporównywalnej z tym, co napastnik musiał wysłać.

Z tego mechanizmu wynikają dwa wnioski praktyczne. Po pierwsze, ruch dociera do ofiary z ogromnej liczby prawdziwych, niesfałszowanych adresów, to są rzeczywiste serwery DNS, nie boty. Po drugie, atak jest możliwy tylko dlatego, że gdzieś po drodze ktoś pozwolił na sfałszowanie adresu źródłowego i ktoś inny wystawił serwer odpowiadający obcym.

Część pierwsza: nie być źródłem

To jest ta część, o której łatwo zapomnieć, bo problem nie boli własnej sieci. A jednak: otwarty resolwer w Państwa adresacji oznacza, że sieć bierze udział w atakach na innych, generuje ruch wychodzący, obciąża własne łącza i trafia na listy zgłoszeniowe, a stamtąd wraca w postaci ograniczeń u operatorów tranzytowych.

Sprawdzenie, czy mamy otwarte resolwery

Najprościej przeskanować własne prefiksy pod kątem serwerów odpowiadających na zapytania rekurencyjne z zewnątrz. Zapytanie testowe wysłane spoza sieci powinno zostać odrzucone; jeżeli wraca poprawna odpowiedź, resolwer jest otwarty:

dig @<adres-serwera> +short example.com A

Ten sam test warto powtórzyć dla adresów klientów, jeśli świadczą Państwo usługi dostępowe: otwarte resolwery na routerach abonenckich są znacznie częstsze niż na serwerach operatora.

Ograniczenie rekursji

Serwer rekurencyjny powinien odpowiadać wyłącznie własnym użytkownikom, a serwer autorytatywny nie powinien świadczyć rekursji w ogóle. W BIND rozdziela się to jawnie:

acl "zaufane" { 10.0.0.0/8; 192.0.2.0/24; localhost; };

options {
    recursion yes;
    allow-recursion { zaufane; };
    allow-query-cache { zaufane; };
    additional-from-cache no;
};

Jeżeli serwer pełni rolę autorytatywną, ustawiamy recursion no; i pozostawiamy allow-query { any; }; wyłącznie dla stref, które faktycznie obsługuje.

Ograniczenie tempa odpowiedzi

Serwer autorytatywny, którego nie da się zamknąć przed światem, chronimy mechanizmem ograniczania tempa odpowiedzi. Wykrywa on powtarzalne, identyczne zapytania z jednego zakresu i zaczyna część odpowiedzi pomijać albo skracać, co odbiera atakowi sens ekonomiczny:

rate-limit {
    responses-per-second 10;
    window 5;
    slip 2;
};

Wartości dobiera się do profilu ruchu konkretnego serwera: powyższe traktujcie jako punkt wyjścia do obserwacji, nie jako gotową receptę.

Blokowanie fałszowania adresów u źródła

To jest najskuteczniejszy pojedynczy środek przeciwko całej klasie ataków z amplifikacją, a jednocześnie najczęściej pomijany. Jeżeli sieć nie wypuszcza pakietów ze źródłami spoza własnej adresacji, nie da się z niej przeprowadzić ataku z fałszowanym adresem.

Na brzegu w stronę klientów włącza się kontrolę zgodności adresu źródłowego z tablicą routingu, w trybie ścisłym tam, gdzie ruch jest jednokierunkowy, i luźnym tam, gdzie trasy bywają asymetryczne.

Juniper:  set interfaces ge-0/0/0 unit 0 family inet rpf-check
Cisco:    ip verify unicast source reachable-via rx

Część druga: być celem

Kiedy to nasz adres jest celem, sytuacja wygląda inaczej. Ruch przychodzi z prawdziwych serwerów DNS rozsianych po całym świecie, więc blokowanie po adresie źródłowym nie ma sensu: lista byłaby nieskończona, a przy okazji odcięlibyśmy serwery, z których faktycznie korzystamy.

Co daje się odfiltrować

Charakterystyczne dla tego wektora jest to, że ruch ma stały port źródłowy 53 i protokół UDP, a odpowiedzi są duże i często pofragmentowane. To wystarczy, żeby zbudować regułę filtrującą, o ile w danym momencie nie potrzebujemy odbierać odpowiedzi DNS na atakowanym adresie.

Reguła BGP FlowSpec dopasowująca ten wzorzec działa na routerze brzegowym i odrzuca ruch, zanim wejdzie w głąb sieci. WanGuard po wykryciu anomalii generuje ją automatycznie na podstawie rozpoznanego wektora, a operator może ją zawęzić lub rozszerzyć.

Czego odfiltrować się nie da

Warto znać granicę tej metody, żeby nie budować fałszywych oczekiwań. Jeżeli atak korzysta z losowych portów źródłowych albo miesza kilka wektorów naraz, kryteria dopasowania przestają być rozłączne i filtrowanie zaczyna obejmować ruch poprawny. W takiej sytuacji zostaje ograniczanie przepustowości dla danego wzorca albo odcięcie adresu blackholem.

Podobnie z fragmentacją: fragmenty dalsze nie zawierają nagłówków warstwy czwartej, więc reguła dopasowująca port źródłowy ich nie obejmie. Trzeba je traktować osobno.

Blackhole jako ostateczność

Gdy wolumen zagraża łączom, jedynym wyjściem bywa odcięcie ruchu do atakowanego adresu. Blackholing kończy atak kosztem dostępności tego jednego adresu, chroniąc resztę sieci. Warunkiem, żeby zadziałał poprawnie i nie obciążył konsoli ani routera, jest właściwa konfiguracja trasy odrzucającej: opisaliśmy ją w osobnym artykule o bezpiecznym blackholingu.

Lista kontrolna

• Prefiksy przeskanowane pod kątem otwartych resolwerów, także w adresacji abonenckiej.
• Serwery rekurencyjne odpowiadają wyłącznie własnym użytkownikom.
• Serwery autorytatywne mają wyłączoną rekursję.
• Serwery wystawione publicznie mają włączone ograniczanie tempa odpowiedzi.
• Kontrola adresu źródłowego działa na łączach abonenckich (i nie jest włączona w trybie ścisłym na stykach tranzytowych).
• Progi detekcji obejmują wektor DNS, a reguły filtrujące są przygotowane przed atakiem, nie w jego trakcie.
• Procedura blackholingu przetestowana poza atakiem.

Zalecenia dotyczące blokowania fałszowania adresu źródłowego opierają się na BCP 38 (RFC 2827) oraz BCP 84 (RFC 3704).