Przejdź do treści 
Pliki cookie TCP SYN W jądrze systemu Linux obciążenie związane z uzgadnianiem połączenia jest ograniczane poprzez kryptograficzne zakodowanie informacji o stanie w początkowym numerze sekwencji (Initial Sequence Number) oraz poprzez pełne nawiązanie połączenia dopiero po otrzymaniu prawidłowego potwierdzenia (ACK). W ten sposób zapobiegam sytuacji, w której ataki typu SYN-flood zatykałyby kolejkę połączeń półotwartych i blokowałyby legalnych klientów.
Punkty centralne
- Funkcjonalność: Cookie w ISN, stan dopiero po otrzymaniu potwierdzenia (ACK)
- Sterowanie w systemie Linux: net.ipv4.tcp_syncookies z trybami 0/1/2
- Korzyści: niewielkie zapotrzebowanie na pamięć przy obciążeniu atakiem
- Granice: nie chroni przed atakami na przepustowość ani atakami na aplikacje
- Strojenie: Należy starannie ustawić wartości zaległości i ponownych prób
W jaki sposób ataki typu SYN-Flood spowalniają proces uzgadniania połączenia TCP
Atakujący zalewa serwer Pakiety SYN i ignoruje kolejne odpowiedzi SYN/ACK, przez co wpisy półotwarte zajmują miejsce w kolejce SYN. Zauważam wtedy, że nowe, prawidłowe żądania nie znajdują miejsca, co prowadzi do częstych przekroczeń limitu czasu. Właśnie w tym miejscu wkraczają Syncookies : Jądro początkowo nie zapisuje stanu połączenia i przenosi niezbędne dane do numeru sekwencyjnego. Dopiero prawidłowe potwierdzenie ACK potwierdza istnienie prawdziwego odbiorcy, dzięki czemu nawiązywanie połączenia przebiega normalnie. Serwis LWN.net oraz dokumentacja TUM opisują tę zasadę jako sprawdzoną i skuteczną ochronę przed atakami typu handshake, która nie wymaga dużego zużycia pamięci. Architektura ta pozwala serwerowi zachować wydajność nawet przy natłoku ruchu, ponieważ kosztowne stany są tworzone dopiero w bardzo późnym etapie.
Schemat techniczny: plik cookie zamiast dawnego systemu stanu
Jądro odpowiada na SYN za pomocą specjalnie zakodowanego pakietu SYN/ACK, którego numer ISN jest wyprowadzony z tajnego klucza, opcji TCP i przedziałów czasowych. Jeśli nadejdzie pakiet ACK z odpowiednim numerem, odtwarzam na podstawie ISN parametry sesji i otwieram gniazdo w normalny sposób. Jeśli odpowiedź nie nadejdzie, nie powstaje zajęty stan półotwarty, co oszczędza pamięć i procesor. Takie podejście radykalnie zmniejsza podatność fazy przyjmowania połączeń na awarie, nie zmieniając trwale standardowej ścieżki. Zgodnie z dokumentacją Ubuntu i Red Hat technika ta działa niezawodnie od wielu generacji jądra i uruchamia się dopiero wtedy, gdy kolejka grozi przepełnieniem.
Włączanie i sprawdzanie: tcp_syncookies w praktyce
O przełączniku sysctl net.ipv4.tcp_syncookies kontroluję zachowanie: 0 = wyłączone, 1 = tylko w przypadku przeciążenia, 2 = stale. W środowiskach produkcyjnych zazwyczaj ustawiam tryb 1, aby standardowy proces uzgadniania pozostał nienaruszony, a ochrona uruchamiała się dopiero w razie potrzeby. Stan mogę szybko sprawdzić w powłoce, a zmiany wprowadzam za pomocą sysctl lub na stałe w katalogu /etc/sysctl.d/. Odpowiedni artykuł wprowadzający na temat zachowania gniazd i schematów ataków pomaga w planowaniu całości; szczegóły omówię w artykule Ochrona przeciwpowodziowa SYN. Regularnie korzystam z następujących poleceń:
Wyświetlenie stanu #
sysctl net.ipv4.tcp_syncookies
Tymczasowe włączenie # (do ponownego uruchomienia)
sudo sysctl -w net.ipv4.tcp_syncookies=1
Ustaw # na stałe
echo "net.ipv4.tcp_syncookies = 1" | sudo tee /etc/sysctl.d/60-syncookies.conf
sudo sysctl --system
Ograniczenia: Czego pliki cookie SYN nie potrafią
Pliki cookie SYN dotyczą przede wszystkim Syn-Queue i zapobiegają zajmowaniu pamięci przez stany półotwarte. Nie chronią jednak przed przeciążeniem łącza, przeciążeniem logiki aplikacji ani nasyceniem procesora. W przypadku ataków wolumetrycznych potrzebuję filtrów na wcześniejszych etapach, QoS i, w razie potrzeby, scrubbingu. Również ataki na poziomie aplikacji, takie jak zalewy HTTP GET, wymagają dodatkowych mechanizmów kontroli, limitów i pamięci podręcznych. Dlatego zawsze włączam syncookies do wielopoziomowej strategii obrony, łączącej poziom sieci, jądra i usług.
Optymalizacja: zaległości, kolejki i ponowne próby
Zanim dojdzie do sytuacji kryzysowej, zgadzam się zaległości oraz liczbę ponownych prób, aby uzasadnione skoki obciążenia nie uruchamiały niepotrzebnie trybu ochronnego. tcp_max_syn_backlog wpływa na kolejkę połączeń częściowo otwartych, a somaxconn na maksymalną długość kolejki akceptacji dla połączeń oczekujących na funkcję accept(). Za pomocą parametru tcp_synack_retries określam, ile razy jądro będzie próbowało powtórzyć wysłanie SYN/ACK, zanim zrezygnuje. Wyższe wartości backlogów pozwalają złagodzić krótkie szczyty obciążenia, ale zajmują pamięć; mniejsza liczba ponownych prób szybciej zwalnia sloty, ale wiąże się z ryzykiem zbyt surowego potraktowania odłączonych klientów. Te kompromisy testuję przy realistycznym obciążeniu za pomocą narzędzi takich jak hping3 lub tcp_syn_flooder w izolowanej sieci.
# – ustawienia na okresy szczytowego obciążenia
sudo sysctl -w net.core.somaxconn=4096
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sudo sysctl -w net.ipv4.tcp_synack_retries=3
Porównanie trybów pracy: skutki i zastosowanie
Na co dzień wybieram Tryby należy o tym pamiętać, ponieważ wpływają one na diagnostykę, wskaźniki i zachowanie w sytuacjach stresowych. Trwałe pliki cookie (2) pozwalają uniknąć wczesnego ustalania stanu, jednak zmieniają wartości pomiarowe dotyczące ponownych prób i mogą wpływać na rzadkie przypadki graniczne związane z opcjami TCP. Tryb adaptacyjny (1) pozwala stosowi działać normalnie i interweniuje w przypadku zagrożenia przepełnieniem. Tryb wyłączony (0) ma sens co najwyżej w warunkach laboratoryjnych lub w sieciach zamkniętych. Poniższa tabela zawiera zwięzłe podsumowanie:
| Tryb | Opis | Przewaga | Potencjalne skutki uboczne | Przykład |
|---|---|---|---|---|
| 0 | Wyłączone, brak plików cookie | Wyraźne zachowanie linii bazowej | Atakujący zapełnia kolejkę Syn | Izolowana sieć testowa |
| 1 | Adaptacyjne, tylko w przypadku przepełnienia | Standardowy protokół TCP w stanie spoczynku | Kalibracja punktu przełączania | Usługi publiczne |
| 2 | Wymuszone, zawsze aktywny | Wczesne odciążenie | Wartości analityczne ulegają zmianie | Trudna sytuacja ofensywna |
Wymierne efekty: opóźnienia i wskaźnik skuteczności
Pod ciśnieniem spada Wymagania dotyczące pamięci jest wyraźnie widoczne przy nawiązaniu każdego połączenia, ponieważ nie powstaje stan półotwarty. Dzięki temu pliki SYN Cookies utrzymują wysoki wskaźnik akceptacji, a krótkie impulsy powodują mniej przerw. W warunkach natężonego ruchu obserwuję szybszą regenerację, gdy tylko źródło ruchu wysycha. Wytyczne Ubuntu i Tenable zalecają stosowanie adaptacyjne, aby zwykłe klienty działały bez zmian. W ramach testów regresyjnych sprawdzam retransmisje, wskaźniki utraty pakietów oraz opóźnienia serwera podczas przechodzenia w tryb plików cookie.
Dodatkowe warstwy zabezpieczeń: zapora sieciowa i limity
Pliki syncookies usuwam za pomocą Reguły filtrowania oraz ograniczenia szybkości, aby obciążenie w ogóle nie dotarło do stosu TCP. W systemie Linux najchętniej stosuję reguły nftables, aby ograniczać lub wcześnie odrzucać podmioty naruszające zasady na podstawie szybkości połączeń. Zwięzły przegląd nowoczesnych filtrów pakietów zawiera ten przewodnik nftables a Netfilter. Dodatkowo pomocne są scenariusze SYNPROXY w zaporach brzegowych, które przerywają proces uzgadniania połączenia i przepuszczają wyłącznie prawidłowe połączenia. W przypadku narażonych portów definiuję ścisłe ustawienia otwarcia, progi rejestrowania oraz maksymalną liczbę prób nawiązania połączenia na adres źródłowy.
Rozwiązania o wysokiej wydajności: XDP i inne.
Gdy ataki masowe powodują, że Współczynnik PPS Aby zwiększyć wydajność, przenoszę logikę filtrowania za pomocą XDP na brzeg sieciowy karty sieciowej (NIC). W ten sposób odrzucam podejrzane pakiety SYN jeszcze przed warstwą gniazda, co zmniejsza obciążenie procesora i odciąża kolejkę przyjmowania. Rozpoczęcie pracy z tą techniką ułatwia wprowadzenie do Przetwarzanie pakietów XDP. W połączeniu z plikami cookie SYN powstaje system dwuetapowy: najpierw zgrubna selekcja na karcie, a następnie niezawodna weryfikacja protokołu handshake w jądrze systemu. Ten łańcuch znacznie ogranicza powierzchnię ataku i zapewnia dostępność usług.
Diagnoza: jak prawidłowo interpretować wskaźniki i wpisy w dzienniku
W przypadku widocznych Limity czasu Sprawdzam statystyki netstat/ss, komunikaty dmesg oraz panele Grafana z danymi dotyczącymi szybkości połączeń. Rosnący odsetek pakietów SYN-RECV, duża liczba retransmisji i utraty pakietów wskazują na przejście w tryb ochronny. Zwracam uwagę na komunikaty o przepełnieniu kolejki SYN i koreluję je z obciążeniem procesora oraz IRQ. Przechwytywanie pakietów za pomocą tcpdump potwierdza logikę numerów sekwencyjnych i pomaga wykrywać fałszywe alarmy. Za pomocą liczników iptables/nftables dodatkowo mierzę liczbę trafień w regułach ograniczania przepustowości.
Zgodność: opcje TCP i skrajne przypadki
Programowanie nowoczesnych jądra Opcje takie jak MSS, SACK czy Timestamp, tak aby pliki cookie były przesyłane w sposób umożliwiający ich odtworzenie. Starsze lub nietypowe stosy protokołów mogą wykazywać pewne specyficzne zachowania, dlatego przed wdrożeniem sprawdzam ścieżki krytyczne. Szczególnie w przypadku serwerów proxy, NAT i topologii anycast dokładnie obserwuję zachowanie systemu. Serwis LWN.net omawia szczegóły projektowe, które wyjaśniają, dlaczego współczesne implementacje działają niezawodnie. W bardzo specyficznych scenariuszach wymuszony tryb pracy (2) pozostaje narzędziem, z którego korzystam wyłącznie w konkretnych przypadkach.
Typowe błędne przekonania: to, co często prostuję
Syncookies nie zastępują Obrona przed atakami DDoS na obrzeżach sieci; chronią one przede wszystkim fazę uzgadniania połączenia. Sama wysoka wartość somaxconn nie zapobiega przepełnieniom, jeśli na pakiety SYN/ACK nigdy nie udziela się odpowiedzi. Równie mylne jest założenie, że trwałe pliki cookie (2) są zawsze najlepszym wyborem; negatywnie wpływa to na diagnostykę i przypadki szczególne. Bez monitorowania brakuje mi sygnałów niezbędnych do dostosowania punktów przełączania i limitów. Testy obciążeniowe pozostają niezbędne, aby konfiguracja i sprzęt były dostosowane do rzeczywistej dynamiki dostępu.
Sprawdzenie w praktyce: kroki prowadzące do sformułowania wiarygodnego założenia
Zaczynam od Tryb 1 dla tcp_syncookies i sprawdzam punkt interwencji pod obciążeniem. Następnie umiarkowanie zwiększam wartości tcp_max_syn_backlog i somaxconn, jednocześnie zmniejszając tcp_synack_retries i mierząc wskaźniki skuteczności. Ograniczenia przepustowości zapory oraz filtry geograficzne i ASN odfiltrowują szum przed stosem. Filtry XDP lub SmartNIC zachowuję na sytuacje wymagające wysokiej liczby PPS, aby móc celowo wykorzystywać zasoby. Na koniec dokumentuję wskaźniki, aby późniejsze dostosowania opierały się na danych.
IPv6 i Dual-Stack: ten sam przełącznik, ta sama logika
W środowiskach typu dual-stack zachowują się IPv4 i IPv6 jest spójny w kontekście plików cookie. Przycisk net.ipv4.tcp_syncookies zarządza ochroną globalnie dla protokołu TCP, a więc również dla gniazd v6. Dlatego testuję przejście do trybu cookie w obu protokołach – zwłaszcza gdy urządzenia upstream w sieci IPv6 korzystają z innych ścieżek filtrowania. Ważne: pliki cookie SYN chronią wyłącznie protokół TCP. Usługi UDP lub QUIC wymagają własnych limitów przepustowości i polityki brzegowej, aby ruch oparty na objętości nie przeciążał procesora.
Wskaźniki w jądrze systemu: wiarygodne wskaźniki
Aby zapewnić niezawodny monitoring, korzystam z liczników jądra, które wyraźnie identyfikują pliki cookie. Oprócz ss -s Aby monitorować rozkłady stanów, obserwuję liczniki wysłanych, przyjętych i nieudanych plików cookie. W ten sposób mogę stwierdzić, czy zabezpieczenia działają, czy legalni klienci mają dostęp oraz czy występują błędy w konfiguracji.
Przegląd #
ss -s
ss -ant state syn-recv | wc -l
Licznik plików cookie # (jądro: /proc/net/netstat)
grep -E 'Syncookies|ListenOverflows|ListenDrops' /proc/net/netstat
# Widok na żywo
watch -n1 'grep -E "Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)" /proc/net/netstat'
# Wskazówki z logów (przykładowy komunikat)
# dmesg wyświetla m.in.:
# TCP: Możliwe zalanie pakietami SYN na porcie 443. Wysyłanie plików cookie. Sprawdź liczniki SNMP.
Wznosić się Przepełnienia list oraz ListenDrops równolegle do SyncookiesSent , dostosowuję zaległości, ponowne próby i filtry upstream. Pozostają SyncookiesRecv ... to wskazuje na zwykłą falę botów; jeśli natomiast częściej zdarzają się SyncookiesFailed, sprawdzam ścieżki NAT/proxy oraz ewentualne manipulacje w trakcie transmisji.
Serwery proxy, urządzenia równoważące obciążenie i Kubernetes
Na stronie Łańcuchy serwerów proxy i równoważenia obciążenia Decyduje o tym rozmieszczenie mechanizmu ochrony plików cookie. Jeśli moduł równoważenia obciążenia L4/L7 przerywa proces uzgadniania połączenia TCP, zalew pakietów SYN w ogóle nie dociera do serwerów backendowych; w takim przypadku aktywuję pliki cookie na obrzeżu sieci. Jeśli moduł równoważenia obciążenia działa wyłącznie pasywnie (DSR, ECMP), węzły backendowe muszą zapewnić ochronę samodzielnie. W Kubernetes dostosowuję ustawienia sysctl na węzłach roboczych, zwłaszcza w przypadku obciążeń korzystających z NodePort lub HostNetwork. W przypadku kontrolerów Ingress z własną ochroną przed atakami SYN (SYNPROXY, eBPF) dostosowuję zasady tak, aby nie hamowały one wzajemnie swojego działania. W testach uwzględniam kontrole stanu (health checks) modułu równoważenia obciążenia, ponieważ w przeciwnym razie krótkie okna testowe z małą liczbą ponownych prób mogą fałszywie wskazywać na niestabilność.
Przypadki graniczne w szczegółach: opcje, przedziały czasowe, NAT
Pliki cookie kodują jedynie parametry ograniczone. Nowoczesne implementacje systemu Linux zazwyczaj niezawodnie odtwarzają MSS, SACK i skalowanie okna; jednak znaczniki czasu i rzadko stosowane opcje mogą podlegać ograniczeniom w zależności od wersji jądra. Dlatego preferuję tryb pracy (1), aby dominowała ścieżka standardowa, a pliki cookie miały zastosowanie tylko w przypadku przepełnienia. Ważność pliku cookie jest powiązana z przedziałami czasowymi – w przypadku silnie asymetrycznych ścieżek lub szczytów opóźnień prawidłowe potwierdzenie (ACK) może znajdować się tuż poza oknem. W scenariuszach sieci WAN i satelitarnych mierzę zatem wariancję czasu przelotu w obie strony, zanim zmniejszę liczbę ponownych prób. NAT i urządzenia pośredniczące, które modyfikują numery sekwencyjne lub opcje, są kolejnymi potencjalnymi źródłami skrajnych przypadków; za pomocą ukierunkowanych przechwyceń ustalam, gdzie dochodzi do utraty bitów.
Ataki typu ACK/RST flood i ich odmiany wykraczające poza burzę SYN
Nie każdy Atak transportowy to czysta zalewka SYN. Zalewki ACK lub RST atakują procesor i ścieżki pakietów, nie uruchamiając procedury uzgadniania połączenia – pliki cookie niewiele tu pomagają. W takich przypadkach stosuję wczesne filtry (nftables/XDP) z logiką stanową lub minimalnym ograniczeniem częstotliwości ACK. W szczególności fale RST skierowane przeciwko nawiązanym połączeniom przerywam za pomocą zestawu reguł, który odrzuca nieoczekiwane pakiety RST bez odpowiedniego okna. Również półotwarte powtórzenia (pakiety SYN ze spoofingiem oraz opóźnionymi potwierdzeniami ACK) blokuję poprzez ograniczenia szybkości dla poszczególnych przestrzeni sieciowych źródłowych.
Dalsze dostosowania: kolejki listy/akceptacji i szybkie błędy
Oprócz klasycznych parametrów stosuję dodatkowe przełączniki, które wpływają na zachowanie w warunkach granicznych:
- Backlog kontra somaxconn: Wartość w listy (zaległości) na proces jest określana przez net.core.somaxconn ograniczone. Dbam o to, by oprogramowanie serwera i jądro działały w harmonii, w przeciwnym razie optymalizacje pójdą na marne.
- tcp_abort_on_overflow: Czy w przypadku zapełnienia kolejki Accept żądanie zostanie po cichu odrzucone, czy też zostanie wysłana aktywna odpowiedź z pakietem RST. W przypadku interfejsów API o dużym natężeniu ruchu szybki błąd może umożliwić klientowi szybką ponowną próbę; w przypadku klientów TLS lub starszych wersji zazwyczaj preferuję domyślne odrzucanie żądań.
- Zarządzanie stanami Port i TIME-WAIT: Pliki cookie nie zapobiegają Wąskie gardło portu efemerycznego. Planuję ip_local_port_range zachowaj elastyczność i rozważnie stosuj optymalizacje TIME-WAIT, aby ponowne wykorzystanie nie prowadziło do błędów typu Heisenbug.
- SO_REUSEPORT: Kilka kolejek Accept na port pozwala rozłożyć obciążenie na procesy robocze i ograniczyć przeciążenia poszczególnych procesorów.
Metody badawcze: powtarzalne i miarodajne
Symuluję obciążenie w warunkach zbliżonych do rzeczywistych i mierzę punkt przejścia do trybu „cookie”, wskaźnik powodzenia prawidłowych połączeń oraz czas powrotu do normy po szczycie obciążenia. W tym celu łączę syntetyczne zalewy pakietów SYN z rzeczywistymi żądaniami aplikacji.
Generowanie ruchu typu # (w laboratorium!)
sudo hping3 -S -p 443 --flood --rand-source
Zmiana warunków sieciowych #
sudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%
# Mieszanie ruchu legalnego
wrk -t8 -c512 -d60s https:///
# Równoległe monitorowanie
watch -n1 'ss -s; echo; grep -E "Syncookies|Listen(Overflows|Drops)" /proc/net/netstat'
Dzięki tym krokom mogę sprawdzić, czy liczba ponownych prób zmniejsza się zbyt gwałtownie, czy zapory sieciowe po stronie upstream błędnie filtrują znaczniki czasu, czy też kolejki akceptacji poszczególnych węzłów roboczych przepełniają się w nieproporcjonalnym stopniu. Dokumentuję wskaźniki (współczynnik powodzenia prawidłowych połączeń zbliżony do 100%, współczynnik trafień plików cookie, zachowanie opóźnień), aby móc później wprowadzać dostosowania w oparciu o dane.
Eksploatacja i konserwacja: zapewnienie stabilności przez cały okres eksploatacji
W trybie ciągłym planuję Tajna rotacja (automatycznie po stronie jądra) i obserwuję, czy zmiany przedziałów czasowych mają zauważalny wpływ na trasy o bardzo długim RTT. Dbam o aktualność jądra i sterowników, aby ulepszenia w implementacji cookie (lepsze kodowanie opcji, stabilne przedziały czasowe) przyniosły oczekiwane efekty. Na potrzeby audytów notuję, kiedy włączył się tryb ochronny, ile połączeń przepuścił oraz czy włączono dodatkowe filtry. W przypadku zmian dotyczących MTU, offloadingu lub stosów NF (np. nowych zestawów nftables) powtarzam krótkie testy, aby wcześnie wykryć niepożądane interakcje.
Skrócona wersja dla tych, którym się spieszy
Pliki cookie SYN przechowują Obciążenie związane z uściskiem dłoni w niewielkim stopniu, tworząc stany dopiero po otrzymaniu potwierdzonego ACK, co chroni kolejkę SYN przed zalaniem. Aktywuję tryb 1, ostrożnie dostosowuję wartości backlogów i liczby ponownych prób oraz mierzę efekty za pomocą przejrzystych wskaźników. Dodatkowe warstwy, takie jak ograniczenia szybkości w nftables, SYNPROXY i XDP, hamują ruch jeszcze przed stosem TCP. Podsumowując, w ten sposób zabezpieczam usługi internetowe, pocztowe, VPN i API przed atakami typu SYN-flood, nie utrudniając przy tym działania zwykłych klientów. Kto konsekwentnie wdraża te kroki, znacznie zwiększa dostępność i ogranicza awarie w obliczu obciążenia atakami.
