Co to jest SYN flood?
SYN flood to atak DDoS wyczerpujący tablice połączeń przez zalew niedokończonych handshake'ów TCP. Jak działa, dlaczego boli i jak go blokować.
Ostatnia aktualizacja:
SYN flood to jeden z najstarszych i wciąż najskuteczniejszych ataków DDoS. Atakujący wysyła lawinę pakietów TCP SYN, czyli pierwszych pakietów nawiązania połączenia, i nigdy nie kończy rozpoczętych sesji. Każdy taki pakiet zmusza serwer do zarezerwowania miejsca w tablicy połączeń i czekania na odpowiedź, która nie przyjdzie. Atak mierzy się nie w gigabitach, tylko w pakietach na sekundę, dlatego łącze może wyglądać na niemal puste w momencie, gdy usługa już nie odpowiada.
Gdzie atak łamie three-way handshake
Normalne połączenie TCP zaczyna się trzema krokami: klient wysyła SYN, serwer odpowiada SYN-ACK i rezerwuje zasoby na to półotwarte połączenie, a klient potwierdza pakietem ACK. Atakujący zatrzymuje się po pierwszym kroku. Serwer odsyła SYN-ACK w pustkę i trzyma wpis w tablicy do czasu wygaśnięcia timera, zwykle kilkadziesiąt sekund. Przy kilkuset tysiącach takich pakietów na sekundę tablica zapełnia się szybciej, niż wpisy z niej znikają, a nowe, prawdziwe połączenia dostają odmowę.
Adresy źródłowe w takim ataku są zwykle sfałszowane, i to z premedytacją. Podszycie się pod losowe adresy sprawia, że każdy pakiet wygląda na inne połączenie, więc proste liczenie połączeń per adres IP nie wychwytuje wzorca. Utrudnia też odwet i zaciera pochodzenie ataku.
Dlaczego boli bardziej niż sam wolumen
Pakiet SYN jest malutki, więc nawet atak o skromnej przepustowości generuje ogromną liczbę pakietów. Wąskim gardłem nie staje się pasmo, tylko tablice stanów: na serwerze, na zaporze, na load balancerze i na routerze brzegowym. Urządzenie z zapasem pasma może położyć się na wyczerpaniu pamięci trzymającej stan połączeń. Dlatego SYN flood bywa mylnie diagnozowany jako awaria aplikacji, skoro wykresy ruchu nie pokazują niczego dramatycznego.
Obrona: SYN cookies i SYN proxy
- SYN cookies: serwer nie rezerwuje pamięci po odebraniu SYN, tylko koduje potrzebne informacje w numerze sekwencyjnym SYN-ACK. Stan powstaje dopiero, gdy wróci poprawny ACK, więc tablica nie ma czego wypełnić.
- SYN proxy: urządzenie przed serwerem samo kończy handshake z klientem i dopiero po jego pomyślnym zakończeniu otwiera połączenie do serwera. Ruch od źródeł, które nigdy nie odpowiadają, nie dociera dalej.
- Limity tempa nowych połączeń per źródło: pomagają przy prostszych atakach, ale przy sfałszowanych i rozproszonych źródłach szybko tracą skuteczność.
- Filtrowanie stanowe wyżej w sieci: pakiety spoza kontekstu sesji odpadają zanim dotrą do sprzętu, którego tablice miały paść.
Gdzie postawić obronę
Ochrona wpięta bezpośrednio przed serwerem działa tylko dopóki łącze do tego serwera ma zapas. Jeśli atak nasyci uplink albo tablice urządzenia brzegowego, wszystko za nim przestaje odpowiadać niezależnie od konfiguracji. Dlatego operatorzy przenoszą filtrowanie wyżej, na brzeg sieci dostawcy, gdzie jest pojemność, by wchłonąć ruch ataku i odrzucić go zanim zacznie konkurować z ruchem prawdziwych użytkowników.
Najczęstsze pytania
Czy SYN flood da się odróżnić od nagłego wzrostu ruchu?
Tak, choć nie po samym wolumenie. Charakterystyczny jest rozjazd między liczbą pakietów SYN a liczbą kończonych handshake'ów: prawdziwy skok popularności przynosi SYN, ACK i transfer danych w normalnej proporcji, a atak zostawia górę półotwartych połączeń bez dalszego ciągu. Pomaga też rozkład adresów źródłowych, bo w ataku bywa on równomiernie rozsypany po całej przestrzeni adresowej, co nie zdarza się w naturalnym ruchu.
Czy SYN cookies wystarczą?
Chronią przed wyczerpaniem tablicy, ale nie przed wyczerpaniem łącza ani procesora, który musi obsłużyć każdy przychodzący pakiet. Przy dużych wolumenach potrzebne jest filtrowanie wyżej w sieci, zanim ruch dotrze do serwera. SYN cookies traktuj jako ostatnią linię, a nie jedyną.

