Ataki SYN-ACK reflection - kiedy ruch wygląda legalnie, a mimo to jest atakiem

W ostatnich miesiącach coraz więcej polskich operatorów ISP mierzy się z tą samą sytuacją: telefon lub e-mail z groźbą ataku DDoS, jeśli firma nie zapłaci okupu. To, co odróżnia tę falę od klasycznego szantażu, to typ ataku, którym grożą - i który faktycznie następuje, gdy operator nie ulegnie presji. Chodzi o SYN-ACK reflection, atak trudny do zatrzymania standardowymi metodami filtracji.

Mechanizm opiera się na wykorzystaniu infrastruktury, która nie weryfikuje adresów źródłowych ruchu wychodzącego (brak wdrożonego BCP38 po stronie atakującego lub operatora, u którego atakujący ma serwer).

Atakujący wysyła masowo pakiety SYN do legalnych, publicznych serwerów - popularnych portali, usług chmurowych, dowolnych hostów odpowiadających na połączenia TCP - podmieniając adres źródłowy na adres IP ofiary. Serwery, które otrzymały te pakiety, odpowiadają zgodnie ze specyfikacją TCP - pakietem SYN-ACK. Ponieważ adres źródłowy został sfałszowany, odpowiedzi trafiają nie do atakującego, lecz bezpośrednio do ofiary.

Efekt: ofiara zostaje zalana tysiącami pakietów SYN-ACK na sekundę, pochodzących z adresów IP, które same w sobie są całkowicie legalne i rozpoznawalne - żadna baza reputacji IP ich nie oznaczy jako zagrożenie.

Standardowe podejście do mitygacji ataków wolumetrycznych opiera się na dwóch mechanizmach: FlowSpec, czyli precyzyjnych regułach filtrowania generowanych na podstawie cech ruchu (port, protokół, długość pakietu), oraz RTBH (Remote Triggered Black Hole), czyli blokowaniu całego ruchu do zaatakowanego adresu IP.

Oba mechanizmy sprawdzają się bardzo dobrze przy typowych atakach - UDP flood, amplifikacji, fragmentacji IP. Problem pojawia się, gdy ruch ataku nie różni się strukturalnie od ruchu legalnego. Systemy bezstanowe, w tym rozwiązania oparte wyłącznie na próbkowaniu Netflow/sFlow, analizują pakiet w oderwaniu od kontekstu połączenia. Pojedynczy pakiet SYN-ACK z adresu znanego, publicznego serwera nie wygląda podejrzanie - dopóki nie spojrzy się na to, czy faktycznie poprzedzało go wysłane wcześniej żądanie SYN z sieci operatora.

To wymaga inspekcji stanowej - śledzenia par SYN/SYN-ACK w czasie rzeczywistym, a nie tylko klasyfikacji pojedynczych pakietów na podstawie nagłówków. Większość systemów anty-DDoS dostępnych obecnie na rynku, zwłaszcza tych opartych na próbkowaniu ruchu i regułach statycznych, nie ma takiej warstwy - i to wyjaśnia, dlaczego ataki tego typu są coraz częściej wybierane jako narzędzie szantażu. Atakujący wiedzą, że standardowa ochrona operatora sobie z tym nie poradzi.

Ataki SYN-ACK reflection nie są nowością od strony teoretycznej - opisywane są od lat jako jeden z wariantów reflection/amplification. Nowością jest skala i systematyczność, z jaką są wykorzystywane przeciwko polskim operatorom telekomunikacyjnym w ramach prób wymuszenia okupu. To przesuwa ciężar odpowiedzialności na dostawców systemów ochrony - klasyczna para FlowSpec plus RTBH przestaje wystarczać jako kompletna odpowiedź na realne zagrożenia, z jakimi mierzy się dziś polski rynek ISP.

W LiveShield śledzimy tego typu przypadki na bieżąco, ponieważ pracujemy bezpośrednio z operatorami, którzy się z nimi zetknęli - nie jako abstrakcyjny scenariusz z raportu branżowego, tylko jako realny incydent u konkretnego klienta. Jesteśmy zespołem działającym w Polsce, więc kiedy pojawia się nowy wzorzec ataku wymierzony akurat w polskich operatorów, mamy bezpośredni kontakt ze zgłoszeniami i możliwość reagowania szybciej niż dostawcy dużych, globalnych platform anty-DDoS, dla których lokalna specyfika tego segmentu rynku jest mniej istotna.

Rozwijamy mechanizmy wykrywania i mitygacji w kierunku pokrycia właśnie takich przypadków - ataków, które klasyczna para FlowSpec/RTBH trudno rozpoznaje, ponieważ ruch pochodzi z legalnych źródeł. To naturalny kierunek rozwoju systemu, wynikający wprost z tego, z czym mierzą się nasi klienci.