SYN flood

SYN flood to atak odmowy usługi, w którym napastnik zasypuje serwer żądaniami nawiązania połączenia TCP, czyli pakietami z flagą SYN, i nigdy nie kończy procedury ich otwierania. CISA opisuje go jako wysyłanie żądań połączenia bez dokończenia tak zwanego trójetapowego uzgadniania ^[3]. Serwer rezerwuje zasoby dla każdego rozpoczętego połączenia, aż wyczerpie się limit połączeń na wpół otwartych i prawowici klienci przestają być obsługiwani ^[1]. MITRE ATT&CK klasyfikuje ten atak jako odmianę wyczerpania zasobów systemu operacyjnego, technikę T1499.001 ^[2].

Jak działa

Połączenie TCP otwiera się w trzech krokach. Klient wysyła segment SYN, serwer odpowiada SYN-ACK, a klient potwierdza segmentem ACK. Po otrzymaniu SYN na nasłuchującym porcie serwer przydziela stan dla każdego takiego segmentu i przechodzi w stan SYN-RECEIVED ^[1]. Stan ten zajmuje pamięć w strukturze TCB, a system trzyma limit takich połączeń w kolejce oczekujących ^[1].

Atakujący wysyła SYN, ale nie odsyła ACK. Najczęściej fałszuje adres źródłowy, więc odpowiedź SYN-ACK trafia pod adres, który o niczym nie wie. Według RFC 4987 atak zapełnia kolejkę sfałszowanymi segmentami SYN, które nigdy nie dokończą uzgadniania, i blokuje w ten sposób nawiązywanie prawowitych połączeń ^[1]. MITRE zwraca uwagę, że atak wyczerpuje maksymalną liczbę jednoczesnych połączeń TCP systemu ^[2].

RYS. 1Uzgadnianie TCP i SYN flood

Każda pozycja w kolejce czeka, aż serwer zrezygnuje z ponawiania. W jądrze Linux parametr tcp_synack_retries ma domyślnie wartość 5, co odpowiada około 63 sekundom do ostatecznego porzucenia próby ^[4]. Wystarczy więc stosunkowo niewielki strumień pakietów, żeby utrzymać kolejkę pełną.

Odmiany

SYN flood należy do ataków wolumetrycznych, działających w warstwie sieciowej i transportowej modelu ISO/OSI. Sekurak opisuje je jako zalewanie celu jak największą liczbą pakietów ICMP, SYN TCP lub datagramów UDP ^[5]. Warianty różnią się źródłem pakietów.

Pokrewny atak działa w warstwie aplikacji. Slowloris utrzymuje częściowo otwarte połączenia HTTP i Sekurak zauważa, że można go skojarzyć z SYN floodem ^[7]. Różnica polega na tym, że Slowloris kończy uzgadnianie TCP i wyczerpuje pulę połączeń serwera WWW, a nie jądra. Inną odmianą przeciążenia aplikacji jest HTTP flood.

W WordPressie

SYN flood uderza w system operacyjny serwera, zanim żądanie dotrze do serwera WWW. WordPress, PHP i wtyczki w ogóle go nie widzą: uzgadnianie TCP nie dochodzi do końca, więc nie powstaje żadne żądanie HTTP. Wtyczka bezpieczeństwa nie może więc takiego ataku wykryć ani zatrzymać, a logi strony pozostają puste, choć witryna nie odpowiada.

Obrona leży po stronie hostingu i infrastruktury sieciowej. Na hostingu współdzielonym właściciel strony nie ma dostępu do ustawień jądra; może jedynie zgłosić problem dostawcy. Na własnym serwerze VPS administrator kontroluje parametry TCP opisane niżej. Gdy witryna stoi za CDN albo reverse proxy, połączenia TCP od odwiedzających kończą się na serwerach pośrednika, a nie na serwerze źródłowym. RFC 4987 wymienia przeniesienie nawiązywania połączeń na zapory i serwery pośredniczące jako jedną z metod obrony ^[1]. Warunkiem jest to, by prawdziwy adres serwera nie był publicznie znany.

Zagrożenia i skutki

Skutkiem jest niedostępność usługi. Serwer pozostaje włączony, ale nie przyjmuje nowych połączeń, co CISA opisuje jako wysycenie otwartych portów i uniemożliwienie łączenia się prawowitym użytkownikom ^[3]. Dla sklepu internetowego oznacza to przerwę w sprzedaży, dla każdej strony także utratę zaufania odwiedzających. Atak nie narusza poufności ani integralności danych, ale zużywa pamięć: według dokumentacji jądra Linux każde żądanie w stanie SYN_RECV zajmuje około 304 bajtów ^[4].

Jak się bronić

RFC 4987 omawia osiem metod obrony ^[1]:

• filtrowanie sfałszowanych adresów źródłowych na brzegu sieci;
• powiększenie kolejki połączeń oczekujących;
• skrócenie czasu życia stanu SYN-RECEIVED;
• zastępowanie najstarszego wpisu w kolejce nowym;
• SYN cache, czyli przechowywanie minimalnego stanu w tablicy skrótów;
• SYN cookies, czyli zakodowanie stanu połączenia w numerze sekwencyjnym zamiast rezerwowania pamięci;
• podejścia łączące SYN cache i SYN cookies;
• zapory i serwery pośredniczące przejmujące nawiązywanie połączeń.

Według RFC 4987 SYN cache i SYN cookies to jedyne skuteczne techniki obrony po stronie samego hosta odkryte do czasu publikacji dokumentu ^[1].

W jądrze Linux SYN cookies włącza parametr tcp_syncookies. Wartość 1 jest domyślna i oznacza wysyłanie cookies, gdy kolejka SYN gniazda się przepełni ^[4]. Dokumentacja ostrzega, że SYN cookies poważnie naruszają protokół TCP i nie pozwalają na użycie rozszerzeń TCP, więc nie zastępują właściwego dostrojenia systemu ^[4]. Parametr tcp_max_syn_backlog określa, ile połączeń w stanie SYN_RECV może czekać; jego wartość minimalna to 128, a przy przeciążeniu dokumentacja zaleca jej zwiększenie ^[4].

# /etc/sysctl.d/90-syn.conf — przykładowe ustawienia obronne
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 3

Wykrywanie ułatwia obserwacja proporcji flag TCP. Sekurak wskazuje, że gdy w sieci pojawia się zauważalnie więcej pakietów z flagą SYN niż ACK, zagrożenie (D)DoS staje się realne ^[6]. Takie anomalie wychwytują IDS, IPS i zapory sieciowe. CISA zaleca korzystanie z usługi ochrony przed DoS, która wykrywa nietypowy ruch i odciąga go od sieci, a w trakcie ataku kontakt z dostawcą internetu ^[3]. Filtrowanie fałszywych adresów po stronie operatorów ogranicza też spoofing wykorzystywany w innych atakach.

Historia i przykłady

Według RFC 4987 podatność TCP na zalew segmentami SYN odkryli Bill Cheswick i Steve Bellovin w 1994 roku, ale nie opublikowali opisu ^[1]. Technikę upubliczniono w magazynie Phrack w lipcu 1996 roku, a we wrześniu 1996 roku ataki obserwowano już w sieci ^[1]. CERT wydał wtedy komunikat CA-96-21, po atakach, które dotknęły m.in. serwery pocztowe dostawcy PANIX ^[1]. Dokument RFC 4987 z sierpnia 2007 roku zebrał metody obrony, które powstały w odpowiedzi na te zdarzenia ^[1].