Czym jest amplifikacja i reflection UDP?
Amplifikacja UDP zamienia małe podszyte zapytanie w wielką odpowiedź lecącą do ofiary. DNS, NTP, memcached, CLDAP i ruch odbity od CDN.
Ostatnia aktualizacja:
Atak reflection polega na tym, że napastnik nie strzela w ofiarę bezpośrednio, tylko odbija ruch od cudzych serwerów. Wysyła zapytania z podrobionym adresem źródłowym, ustawionym na adres ofiary, a odpowiedzi lecą właśnie tam. Gdy odpowiedź jest znacznie większa od zapytania, mówimy o amplifikacji: kilkadziesiąt bajtów wysłane przez atakującego zamienia się w kilka kilobajtów spadających na cel. Współczynnik wzmocnienia decyduje o tym, jak niewielkie zasoby wystarczą, by wygenerować atak liczony w setkach gigabitów.
Protokoły, które się do tego nadają
- DNS: otwarte resolwery odpowiadają na zapytania od kogokolwiek, a odpowiedź bywa kilkadziesiąt razy większa od pytania.
- NTP: stare polecenie monlist potrafiło zwrócić listę setek ostatnich klientów w odpowiedzi na jeden krótki pakiet.
- memcached: wystawiony do internetu bez uwierzytelnienia dawał najwyższe znane współczynniki wzmocnienia, rzędu kilku tysięcy razy.
- CLDAP i SSDP: usługi katalogowe i odkrywanie urządzeń w sieciach lokalnych, przypadkiem wystawione publicznie.
- QUIC i inne protokoły oparte na UDP: wszędzie tam, gdzie serwer odpowiada zanim zweryfikuje, że rozmówca istnieje.
Ruch odbity od CDN i innych zaufanych sieci
Najbardziej kłopotliwy wariant to odbicie od infrastruktury, której nie chcesz i nie możesz zablokować. Atakujący podszywa się pod adres ofiary i wysyła żądania do węzłów brzegowych sieci CDN albo do dużych, publicznych resolwerów. Odpowiedzi przychodzą do ofiary z przestrzeni adresowej wielkich, powszechnie używanych sieci: z poprawnymi nagłówkami i całkowicie prawdziwym adresem nadawcy.
Dla operatora to pułapka. Wpisanie tych zakresów na czarną listę odcina abonentom dostęp do treści, po które faktycznie sięgają, więc lekarstwo boli tak samo jak choroba. Rozstrzygnięcie daje dopiero stan sesji: skoro nikt w sieci nie wysłał zapytania pasującego do tej odpowiedzi, pakiet nie należy do żadnego połączenia i można go odrzucić, nie ruszając samego CDN-a.
Dlaczego to wciąż działa
Cała rodzina tych ataków opiera się na jednym założeniu: że można wysłać pakiet z cudzym adresem źródłowym i nikt po drodze tego nie sprawdzi. Filtrowanie ruchu wychodzącego zgodnie z BCP 38 rozwiązałoby problem u źródła, ale wdrożenie jest dobrowolne i wciąż niepełne, więc podszywanie się pozostaje możliwe. Do tego internet cały czas ma miliony błędnie skonfigurowanych usług, które chętnie odpowiedzą każdemu.
Co robić po stronie ofiary
Odpowiedzi, o które nikt nie prosił, są idealnym materiałem dla filtrowania stanowego, bo z definicji nie pasują do żadnej sesji wychodzącej. Warunek jest jeden: filtr musi stać wyżej niż wąskie gardło. Jeśli wzmocniony ruch zdąży nasycić Twój uplink, sprzęt za nim nie ma już czego bronić. Dlatego mitygację tego typu ataków prowadzi się na brzegu sieci operatorskiej, a nie na serwerze docelowym.
Najczęstsze pytania
Czy mogę po prostu zablokować UDP?
Rzadko, bo zablokujesz przy okazji DNS, QUIC, VPN, VoIP i ruch gier, czyli sporą część tego, po co abonenci płacą. Blokada wybranych portów źródłowych używanych w amplifikacji jest mniej inwazyjna, ale atakujący zmienia porty. Trwałym rozwiązaniem jest filtrowanie stanowe, które odróżnia odpowiedź na Twoje zapytanie od odpowiedzi, o którą nikt nie prosił.
Czy moja sieć może nieświadomie brać udział w takim ataku?
Tak, jeśli udostępniasz publicznie otwarty resolwer DNS, serwer NTP czy memcached. Warto regularnie skanować własną przestrzeń adresową pod kątem takich usług i wdrożyć filtrowanie ruchu wychodzącego zgodne z BCP 38, żeby z Twojej sieci nie dało się wysyłać pakietów z cudzym adresem źródłowym.