SYN flood - Jak chronić serwer przed atakiem na TCP handshake?

Atak na handshake TCP to jedno z tych zagrożeń, które wyglądają banalnie, a potrafią sparaliżować usługę w kilka minut. W tym artykule pokazuję, jak działa SYN flood, po czym go rozpoznać i jak ograniczać go na poziomie serwera, sieci oraz ochrony u dostawcy. To właśnie syn flood potrafi zablokować nowe połączenia nawet wtedy, gdy transfer nie wygląda na duży.

Jak działa atak na handshake TCP

TCP zestawia połączenie w trzech krokach: klient wysyła SYN, serwer odpowiada SYN-ACK, a klient domyka rozmowę pakietem ACK. To proste założenie jest wygodne dla zwykłej komunikacji, ale staje się słabym punktem, gdy ktoś zaczyna wysyłać ogromną liczbę żądań i nie kończy ich poprawnie.

1. Napastnik wysyła dużo pakietów SYN do usługi.
2. Serwer odpowiada i rezerwuje zasoby dla połączenia w stanie półotwartym.
3. Odpowiedź ACK nie nadchodzi, więc wpis w kolejce czeka na timeout.

W praktyce serwer musi pamiętać o tych niedokończonych sesjach w tablicy stanu albo w kolejce połączeń, czyli w backlogu. Gdy takich wpisów robi się zbyt dużo, nowe, legalne połączenia zaczynają czekać, zwalniać albo być odrzucane. Jeżeli ruch pochodzi z wielu źródeł, mamy już klasyczny DDoS, a nie pojedynczy, łatwy do odfiltrowania incydent.

Najważniejsze jest tu jedno: atak nie musi być szczególnie szybki, żeby był skuteczny. Wystarczy, że zmusza serwer do wykonywania kosztownej pracy po swojej stronie, a nie po stronie napastnika. To tłumaczy, dlaczego ten typ nadużycia od lat pozostaje jednym z podstawowych problemów w ochronie usług TCP.

Mechanizm jest prosty, ale skutki rozchodzą się szerzej niż tylko na jeden proces aplikacji, dlatego warto od razu zobaczyć, co dokładnie pada pierwsze.

Dlaczego skutki są realne, nawet bez wielkiego ruchu

W takim ataku zwykle nie wygrywa ten, kto ma większe łącze, tylko ten, kto lepiej zużywa cudze zasoby. Po stronie ofiary obciążenie dotyczy nie tylko samego serwera WWW, ale też pośrednich urządzeń, które trzymają stan połączenia albo analizują każdy nowy handshake.

Jak podaje AWS, współczesne systemy często chronią się przed przepełnieniem tablicy stanu za pomocą SYN cookies, ale wąskie gardło może pojawić się również na firewallu, load balancerze albo w mechanizmach connection tracking. Właśnie dlatego objawy nie zawsze wyglądają jak klasyczna awaria aplikacji.

• Serwer TCP - trzyma wpisy o półotwartych połączeniach i zużywa pamięć oraz CPU.
• Firewall stanowy - może zapchać swoją tablicę połączeń i zacząć odrzucać nowe sesje.
• Load balancer lub proxy - przyjmuje ruch za usługę i sam staje się celem wyczerpania zasobów.
• Łącze i system kolejkowania - przy dużej skali rośnie opóźnienie, a legalny ruch widzi timeouty.

To jest też powód, dla którego sama redukcja pasma nie rozwiązuje problemu. Atak bywa skuteczny, bo wywołuje kosztowny stan po stronie infrastruktury, a nie tylko dlatego, że generuje dużo pakietów. W praktyce można mieć niezłe łącze i nadal tracić dostępność, jeśli brakuje warstwy, która umie odsiać śmieciowy handshake wcześniej.

Gdy już wiemy, gdzie boli najmocniej, następny krok jest prosty: trzeba nauczyć się rozpoznać incydent po metrykach, a nie po samej intuicji.

Jak rozpoznać problem w praktyce

Ja zwykle patrzę najpierw na trzy rzeczy: liczbę nowych połączeń, stan kolejki SYN oraz zachowanie urządzeń pośrednich. Jeśli te wskaźniki rosną jednocześnie, a użytkownicy zgłaszają timeouty, mamy mocny sygnał, że problem dotyczy handshake TCP, a nie wyłącznie samej aplikacji.

• Wzrost liczby pakietów SYN bez proporcjonalnego wzrostu ACK.
• Rosnąca liczba połączeń w stanie SYN-RECV lub half-open.
• Timeouty przy łączeniu się z usługą, mimo że aplikacja jeszcze odpowiada na część żądań.
• Obciążenie CPU albo tablicy conntrack na firewallu i load balancerze.
• Problemy z nowymi sesjami, podczas gdy istniejące połączenia działają jeszcze poprawnie.

Na Linuksie pomocne bywa szybkie sprawdzenie stanu połączeń, na przykład przez ss -ant state syn-recv. To nie jest dowód ataku sam w sobie, ale dobry punkt startowy. Jeśli widzisz gwałtowny wzrost tych wpisów razem z alarmami z urządzeń brzegowych, obraz zaczyna być bardzo spójny.

Kiedy mam już pewność, że to nie zwykły wzrost ruchu, przechodzę do ochrony warstwowej, bo pojedynczy ruch obronny rzadko wystarcza.

Jak się bronić na poziomie systemu i sieci

Najlepsza obrona nie polega na jednym przełączniku. Działa dopiero wtedy, gdy serwer, firewall, load balancer i zewnętrzna ochrona przejmują różne części kosztu handshake. W praktyce najczęściej zaczynam od ustawień systemowych, potem wzmacniam brzeg sieci, a dopiero na końcu dokładam cięższą ochronę upstream.

Jak podaje AWS, nowoczesne systemy często mają SYN cookies włączone domyślnie, ale ja nie traktuję tego jako zamknięcia tematu. To raczej solidna pierwsza linia, którą trzeba połączyć z ochroną na brzegu sieci i sensownym monitoringiem. Cloudflare opisuje podobny model działania w swojej sieci ochronnej: handshake kończy się możliwie daleko od serwera źródłowego, dzięki czemu koszt obsługi fałszywych połączeń nie spada na samą usługę.

Ważne jest też rozróżnienie między warstwami. WAF pomaga przy atakach aplikacyjnych, ale sam z siebie nie zatrzyma przeciążenia na poziomie TCP. Jeśli publiczna usługa ma być stabilna, potrzebuje ochrony L4, a nie tylko filtra treści.

Gdy ochrona jest ustawiona, kolejnym krokiem jest procedura reagowania. Bez niej nawet dobre narzędzia potrafią zostać użyte zbyt późno albo w złej kolejności.

Co zrobić, gdy atak trwa już teraz

W incydencie stawiam na porządek działań, bo chaotyczne klikanie zwykle tylko pogarsza sytuację. Najpierw trzeba potwierdzić, że problem jest po stronie TCP, potem odciążyć najbardziej narażony punkt, a dopiero później wracać do szczegółowej analizy.

1. Sprawdź, czy rośnie liczba nowych prób zestawienia połączeń, a nie tylko błędów aplikacji.
2. Włącz lub zweryfikuj ochronę upstream: CDN, scrubbing, load balancer, usługę anty-DDoS.
3. Upewnij się, że SYN cookies działają i że backlog nie jest sztucznie zbyt niski.
4. Jeśli usługa jest wewnętrzna, ogranicz źródła ruchu do zaufanych zakresów.
5. Zapisz metryki, logi i próbki ruchu, zanim zaczniesz zmieniać konfigurację.
6. Skontaktuj się z operatorem lub dostawcą chmury, jeśli atak wychodzi poza możliwości lokalnej ochrony.

Nie polecam zaczynać od ręcznego blokowania pojedynczych adresów IP, chyba że masz pewność, że źródła są rzeczywiste i niepodszyte. Przy spoofingu łatwo walczyć z cieniem. Dużo skuteczniejsze bywa przesunięcie punktu filtracji wyżej, tam gdzie ruch można odsiać zanim trafi do zasobów produkcyjnych.

Jeżeli musisz działać szybko, priorytetem jest utrzymanie usługi przy życiu, a nie idealna elegancja konfiguracji. Tę można dopracować później, ale najpierw trzeba odzyskać kontrolę nad połączeniami.

Dlaczego warstwowa obrona wygrywa z pojedynczą blokadą

Najbardziej praktyczny wniosek jest prosty: nie opieram się na jednym zabezpieczeniu, bo ten typ ataku jest zbyt dobry w obchodzeniu pojedynczych progów. Największą różnicę robi przeniesienie kosztu handshake poza serwer, ograniczenie liczby stanów pośrednich i wczesne wykrywanie anomalii w metrykach.

• Serwer powinien jak najpóźniej rezerwować zasoby dla niedokończonych połączeń.
• Warstwa brzegowa ma odrzucać lub kończyć fałszywy ruch zanim dotrze do originu.
• Monitoring ma pokazać różnicę między skokiem ruchu a realnym przeciążeniem.

Jeśli miałbym zostawić jedną radę dla właściciela usługi, brzmiałaby tak: traktuj ochronę przed atakami na TCP jak element projektu infrastruktury, a nie awaryjny dodatek. Wtedy nawet groźny SYN flood przestaje być nagłym zaskoczeniem, a staje się incydentem, na który masz plan, narzędzia i miejsce na reakcję.