Videre til indhold 
TCP SYN-cookies I Linux-kernen holder de håndtryksbelastningen lav ved at krypteret at indkode tilstandsoplysninger i den indledende sekvensnummer (Initial Sequence Number) og først oprette en forbindelse fuldt ud, når der modtages en gyldig ACK. På den måde forhindrer jeg, at SYN-floods tilstopper køen af halvåbne forbindelser og blokerer legitime klienter.
Centrale punkter
- Funktionalitet: Cookie i ISN, status først efter ACK
- Linux-styring: net.ipv4.tcp_syncookies med tilstande 0/1/2
- Fordel: lavt hukommelsesforbrug ved angrebsbelastning
- Grænser: hjælper ikke mod angreb på båndbredden eller mod apps
- Indstilling: Indstil backlog- og retry-værdier omhyggeligt
Hvordan SYN-floods bremser TCP-håndtrykket
En hacker oversvømmer serveren med SYN-pakker og ignorerer de efterfølgende SYN/ACK-svar, hvilket medfører, at halvåbne poster optager plads i SYN-køen. Jeg oplever så, at nye, legitime anmodninger ikke kan komme igennem, og at der opstår en række tidsoverskridelser. Det er netop her, at Syncookies an: Kernen gemmer i første omgang ingen forbindelsesstatus og overfører de nødvendige data til sekvensnummeret. Først et korrekt ACK bekræfter, at der er tale om en ægte modpart, hvorpå opbygningen fortsætter som normalt. LWN.net og TUM-dokumenterne beskriver dette princip som en veletableret, effektiv beskyttelse mod handshake-angreb uden stort hukommelsesforbrug. Denne arkitektur sikrer, at serveren forbliver modtagelig selv under massiv trafik, da den først opretter ressourcekrævende tilstande på et meget sent tidspunkt.
Teknisk fremgangsmåde: Cookie i stedet for det tidligere tilstandsanlæg
Kernen svarer på et SYN med et specielt kodet SYN/ACK, hvis ISN er afledt af en hemmelig nøgle, TCP-optioner og tidsintervaller. Hvis der modtages et ACK med det rigtige nummer, rekonstruerer jeg sessionsparametrene ud fra ISN’et og åbner socketen som normalt. Hvis svaret udebliver, opstår der heller ingen optaget halvåben tilstand, hvilket skåner hukommelse og CPU. Denne tilgang reducerer sårbarheden i modtagelsesfasen drastisk uden at ændre den normale proces permanent. Ifølge dokumentation fra Ubuntu og Red Hat har teknikken fungeret pålideligt i mange kernelgenerationer og træder først i kraft, når køen truer med at gå i stå.
Aktivering og test: tcp_syncookies i praksis
Om sysctl-parameteren net.ipv4.tcp_syncookies Jeg styrer adfærden: 0 = slået fra, 1 = kun ved overbelastning, 2 = permanent. I produktionsmiljøer indstiller jeg som regel til tilstand 1, så standard-handshaken forbliver intakt, og beskyttelsen først træder i kraft, når det er nødvendigt. Jeg kan hurtigt se status i shell'en, og ændringer foretager jeg via sysctl eller permanent i /etc/sysctl.d/. En relevant baggrundsartikel om socket-adfærd og angrebsmønstre hjælper med at planlægge det hele; jeg går nærmere ind på detaljerne i indlægget SYN-oversvømmelsesbeskyttelse. Jeg bruger følgende kommandoer regelmæssigt:
Vis #-status
sysctl net.ipv4.tcp_syncookies
Aktivér # midlertidigt (indtil genstart)
sudo sysctl -w net.ipv4.tcp_syncookies=1
# Indstil permanent
echo "net.ipv4.tcp_syncookies = 1" | sudo tee /etc/sysctl.d/60-syncookies.conf
sudo sysctl --system
Begrænsninger: Hvad SYN-cookies ikke kan
SYN-cookies er primært rettet mod Syn-Queue og forhindrer, at halvåbne tilstande optager hukommelse. De har dog ingen effekt mod en overbelastet forbindelse, en overbelastet applikationslogik eller CPU-mætning. Ved volumetriske angreb har jeg brug for opstrømsfiltre, QoS og eventuelt scrubbing. Også angreb på applikationsniveau, såsom HTTP-GET-oversvømmelser, kræver yderligere kontroller, begrænsninger og cacher. Jeg indlemmer derfor altid syncookies i et flerlagsforsvar, der samler netværks-, kerne- og serviceniveauet.
Tuning: Backlogs, køer og gentagelser
Inden en nødsituation opstår, stemmer jeg Efterslæb og antallet af gentagelser, så legitime spidsbelastninger ikke unødigt udløser beskyttelsestilstanden. tcp_max_syn_backlog påvirker køen af halvåbne forbindelser, mens somaxconn bestemmer den maksimale længde af acceptkøen for forbindelser, der venter på accept(). Med tcp_synack_retries bestemmer jeg, hvor mange gange kernen forsøger at gentage SYN/ACK, før den giver op. Højere backlogs opfanger korte belastningsspidser, men koster hukommelse; færre gentagelsesforsøg frigør slots hurtigere, men medfører risikoen for at ramme fjernklienter for hårdt. Disse kompromiser tester jeg under realistisk belastning med værktøjer som hping3 eller tcp_syn_flooder i et isoleret netværk.
#-kandidater til spidsbelastninger
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
Sammenligning af driftsformer: Konsekvenser og anvendelse
Til hverdagen vælger jeg den Tilstande bevidst, da de påvirker diagnose, målinger og adfærd under pres. Permanente cookies (2) undgår enhver tidlig tilstandsopbygning, ændrer dog måleværdier for gentagne forsøg og kan påvirke sjældne kanttilfælde med TCP-indstillinger. Den adaptive tilstand (1) lader stakken køre normalt og griber ind, når der er risiko for overrun. Tilstanden »slukket« (0) giver kun mening i laboratoriesituationer eller lukkede netværk. Følgende tabel opsummerer dette kortfattet:
| Tilstand | Beskrivelse af | Fordel | Mulig bivirkning | Eksempel |
|---|---|---|---|---|
| 0 | Deaktiveret, ingen cookies | Tydelig baseline-adfærd | Angriberen fylder Syn-køen | Isoleret testnet |
| 1 | Adaptiv, kun ved overløb | Normalt TCP i hvile | Kalibrering af omskiftningspunktet | Offentlige tjenester |
| 2 | Tvunget, altid aktiv | Tidlig aflastning | Analyseværdierne ændrer sig | Hård angrebsposition |
Målbare effekter: forsinkelser og succesrate
Under tryk falder den Krav til hukommelse Dette er tydeligt ved hver forbindelsesoprettelse, da der ikke opstår en halvåben tilstand. Dermed holder SYN-cookies acceptfrekvensen høj, og korte bursts forårsager færre afbrydelser. Under høj trafik observerer jeg en hurtigere genopretning, så snart kilden tørrer ud. Ubuntu- og Tenable-retningslinjer anbefaler adaptiv anvendelse, så normale klienter fungerer uændret. Til regressionstests tester jeg genudsendelser, tabsprocenter og serverlatens ved overgangen til cookie-tilstand.
Yderligere beskyttelseslag: Firewall og begrænsninger
Jeg sletter syncookies med Filterregler og sætter rate limits, så belastningen slet ikke når at trænge ind i TCP-stakken. På Linux foretrækker jeg at bruge nftables-regler til at begrænse eller tidligt afvise overtrædere på baggrund af forbindelseshastigheder. Vejledningen giver et kortfattet overblik over moderne pakkefiltre nftables vs. Netfilter. Derudover hjælper SYNPROXY-scenarier på edge-firewalls, som afbryder handshaken og kun videresender gyldige forbindelser. For udsatte porte definerer jeg strenge åbninger, logningstærskler og et maksimalt antal forbindelsesforsøg pr. kildeadresse.
Højtydende tilgange: XDP og lignende.
Når volumenangreb PPS-hastighed For at øge ydeevnen flytter jeg filterlogikken via XDP ud til netværkskanten på NIC’en. På den måde frasorterer jeg mistænkelige SYN-pakker allerede før socket-laget, hvilket sparer CPU-belastning og aflaster modtagelseskøen. En introduktion til denne teknik gør det lettere at komme i gang med XDP-pakkehåndtering. I kombination med SYN-cookies opstår der et to-trins system: først en grov udvælgelse på kortet, derefter en pålidelig handshake-kontrol i kernen. Denne kæde reducerer angrebsfladen mærkbart og sikrer, at tjenesterne forbliver tilgængelige.
Diagnose: Sådan fortolkes målinger og logoplysninger korrekt
Ved påfaldende Timeouts Jeg tjekker netstat/ss-statistikker, dmesg-meddelelser og Grafana-paneler med forbindelseshastigheder. En stigende andel af SYN-RECV, mange retransmissioner og tab indikerer overgangen til beskyttelsestilstand. Jeg holder øje med meddelelser om SYN-backlog-overløb og sammenholder dem med CPU- og IRQ-belastningen. Pakkefangster med tcpdump dokumenterer sekvensnummerlogikken og hjælper med at identificere falske positiver. Med iptables/nftables-tællere måler jeg desuden, hvor ofte rate-limit-reglerne udløses.
Kompatibilitet: TCP-indstillinger og grænsetilfælde
Programmering af moderne kerner Valgmuligheder som MSS, SACK eller Timestamp, så cookies transporteres på en måde, der gør det muligt at rekonstruere dem. Ældre eller usædvanlige stakke kan udvise særlige egenskaber, derfor tjekker jeg kritiske stier inden implementeringen. Især ved proxyservere, NAT og anycast-topologier observerer jeg adfærden grundigt. LWN.net diskuterer designdetaljer, der forklarer, hvorfor nutidige implementeringer fungerer pålideligt. I meget specifikke scenarier forbliver den tvungne driftsform (2) et værktøj, som jeg kun anvender målrettet.
Typiske misforståelser: Det, jeg ofte retter
Syncookies erstatter ikke DDoS-forsvar i periferien; de beskytter især håndtryksfasen. Et højt somaxconn-tal i sig selv forhindrer ikke overløb, hvis SYN/ACK aldrig besvares. Ligeledes er det en fejlagtig antagelse, at permanente cookies (2) altid er det bedste valg; det går ud over diagnosticering og særlige tilfælde. Uden overvågning mangler jeg signaler til at justere skiftpunkter og grænser. Belastningstests er fortsat uundværlige, så konfigurationen og hardwaren passer til den reelle adgangsdyynamik.
Praksistjek: Trin til en holdbar antagelse
Jeg begynder med Tilstand 1 for tcp_syncookies og verificerer indgrebspunktet under belastning. Derefter øger jeg tcp_max_syn_backlog og somaxconn moderat, samtidig med at jeg sænker tcp_synack_retries og måler succesraterne. Firewall-hastighedsbegrænsninger og geo-/ASN-filtre frasorterer støj før stakken. Jeg gemmer XDP- eller SmartNIC-filtre til situationer med høje PPS-niveauer, så jeg kan anvende ressourcerne målrettet. Til sidst dokumenterer jeg målingerne, så senere justeringer kan baseres på data.
IPv6 og dual-stack: samme switch, samme logik
I dual-stack-miljøer opfører IPv4 og IPv6 er konsekvent i forbindelse med cookies. Knappen net.ipv4.tcp_syncookies styrer beskyttelsen globalt for TCP, altså også for v6-sockets. Jeg tester derfor overgangen til cookie-tilstand på begge protokoller – især hvis upstream-enheder i IPv6 bruger andre filtreringsveje. Vigtigt: SYN-cookies beskytter udelukkende TCP. UDP-tjenester eller QUIC kræver egne hastighedsbegrænsninger og edge-politik, så volumetrisk trafik ikke overbelaster CPU’en.
Metrikker i kernen: pålidelige indikatorer
For at sikre pålidelig overvågning bruger jeg kerneltællere, der eksplicit registrerer cookies. Ud over ss -s Og for at overvåge tilstandsfordelingerne holder jeg øje med tællerne for sendte, modtagne og mislykkede cookies. På den måde kan jeg se, om beskyttelsen virker, om legitime klienter kommer igennem, og om der er fejlkonfigurationer.
# Oversigt
ss -s
ss -ant state syn-recv | wc -l
# Cookie-tæller (Kernel: /proc/net/netstat)
grep -E 'Syncookies|ListenOverflows|ListenDrops' /proc/net/netstat
# Live-visning
watch -n1 'grep -E "Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)" /proc/net/netstat'
# Logmeddelelser (eksempel)
# dmesg viser bl.a.:
# TCP: Mulig SYN-flooding på port 443. Sender cookies. Tjek SNMP-tællere.
Stige ListenOverflows og ListenDrops sideløbende med SyncookiesSent justerer jeg backlogs, retries og upstream-filtre. Forbliver SyncookiesRecv ... tyder det på rene bot-angreb; hvis derimod SyncookiesFailed, tjekker jeg NAT/proxy-ruter og eventuelle manipulationer undervejs.
Proxyservere, load balancere og Kubernetes
På Proxy- og LB-kæder bestemmer placeringen af cookie-beskyttelsen. Hvis en L4-/L7-load-balancer afbryder TCP-håndtrykket, når en SYN-flod slet ikke frem til backend-serverne; i så fald aktiverer jeg cookies ved kanten. Hvis loadbalanceren kun fungerer passivt (DSR, ECMP), skal backend-knudepunkterne beskytte sig selv. I Kubernetes tilpasser jeg sysctls på arbejdsknudepunkterne, især ved NodePort- eller HostNetwork-workloads. For Ingress-controllere med eget SYN-forsvar (SYNPROXY, eBPF) tilpasser jeg politikkerne, så de ikke bremser hinanden. Jeg tager load balancerens sundhedstjek med i betragtning i testene, da korte testvinduer med få gentagelser ellers fejlagtigt kan give indtryk af ustabilitet.
Grænsetilfælde i detaljer: Optioner, tidsintervaller, NAT
Cookies koder kun begrænsede parametre. Moderne Linux-implementeringer rekonstruerer som regel MSS, SACK og Window Scaling pålideligt; tidsstempler og sjældne indstillinger kan dog have begrænsninger afhængigt af kernelniveauet. Jeg foretrækker derfor driftsform (1), så standardvejen dominerer, og cookies kun træder i kraft ved overløb. En cookies gyldighed er bundet til tidsintervaller – ved stærkt asymmetriske ruter eller forsinkelsestoppe kan en legitim ACK ligge lige uden for vinduet. I WAN- og satellitscenarier måler jeg derfor round-trip-variansen, før jeg sænker antallet af gentagne forsøg. NAT og middleboxe, der ændrer sekvensnumre eller optioner, er yderligere kandidater til kanttilfælde; med målrettede datafangster dokumenterer jeg, hvor bits går tabt.
ACK-/RST-floods og varianter ud over SYN-stormen
Ikke alle Transportangreb er en ren SYN-flood. ACK- eller RST-floods er rettet mod CPU’en og pakkeruterne uden at udløse handshaken – cookies hjælper næsten ikke her. Jeg bruger i så fald tidlige filtre (nftables/XDP) med tilstandslogik eller minimal begrænsning af ACK-frekvensen. Især RST-bølger mod etablerede forbindelser afbryder jeg ved hjælp af et regelsæt, der afviser uventede RST'er uden et passende vindue. Også halvt åbne gentagelser (SYN med spoofing plus sene ACK'er) dækker jeg via hastighedsbegrænsninger pr. kildenetværksområde.
Yderligere finjustering: Liste-/acceptkøer og hurtige fejl
Ud over de klassiske parametre bruger jeg supplerende kontakter, der præger adfærden i grænseområdet:
- Backlog vs. somaxconn: Værdien i lister (backlog) pr. proces bestemmes af net.core.somaxconn begrænset. Jeg sørger for, at serversoftwaren og kernen fungerer i harmoni, ellers går optimeringerne til spilde.
- tcp_abort_on_overflow: Om forespørgslerne, når Accept-køen er fuld, enten droppes uden varsel eller besvares aktivt med RST. I API’er med høj trafik kan en hurtig fejl give klienten mulighed for hurtigt at forsøge igen; for TLS- eller ældre klienter foretrækker jeg som regel standarddropping.
- Håndtering af Port- og TIME-WAIT-tilstande: Cookies forhindrer ikke Ephemeral-port-flaskehals. Jeg planlægger ip_local_port_range Vær generøs, og brug TIME-WAIT-optimeringer med omtanke, så Reuse ikke fører til Heisenbugs.
- SO_REUSEPORT: Flere Accept-køer pr. port fordeler belastningen på tværs af worker-processerne og mindsker overbelastning på de enkelte CPU’er.
Testmetoder: reproducerbare og pålidelige
Jeg simulerer belastning, der ligger tæt på virkelige scenarier, og måler skiftetidspunktet til cookie-tilstand, succesraten for legitime forbindelser samt genopretningstiden efter belastningstoppen. I den forbindelse kombinerer jeg syntetiske SYN-floder med reelle applikationsanmodninger.
Generer #-flood (laboratorium!)
sudo hping3 -S -p 443 --flood --rand-source
Varier #-netværksforholdene
sudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%
# Bland legitim trafik
wrk -t8 -c512 -d60s https:///
# Parallel overvågning
watch -n1 'ss -s; echo; grep -E "Syncookies|Listen(Overflows|Drops)" /proc/net/netstat'
Ved hjælp af disse trin kan jeg se, om antallet af gentagne forsøg falder for kraftigt, om upstream-firewalls fejlagtigt filtrerer tidsstempler, eller om acceptkøerne hos enkelte arbejdere løber over i uforholdsmæssigt stort omfang. Jeg dokumenterer nøgletallene (tilnærmelse til 100%-succesrate for legitime forbindelser, cookie-hitrate, latenstidsadfærd) for senere at kunne foretage justeringer på baggrund af data.
Drift og vedligeholdelse: Sikring af stabilitet gennem hele levetiden
I kontinuerlig drift planlægger jeg Hemmelig rotation (automatisk på kernelsiden) og observerer, om skift mellem tidsslots har synlige effekter på strækninger med meget lang RTT. Jeg holder kernelen og driverne opdaterede, så forbedringer i cookie-implementeringen (bedre kodning af indstillinger, robuste tidsslots) kommer til udtryk. Til auditformål noterer jeg, hvornår beskyttelsestilstanden trådte i kraft, hvor mange forbindelser den lod passere, og om der blev aktiveret yderligere filtre. Ved ændringer af MTU, offloading eller NF-stacks (f.eks. nye nftables-sæt) gentager jeg kortvarige tests, så jeg tidligt kan opdage eventuelle interaktionsfejl.
Forkortet version til dem, der har travlt
SYN-cookies gemmer Håndtryksbelastning lille ved først at oprette tilstande efter en bekræftet ACK og dermed beskytte Syn-køen mod overbelastning. Jeg aktiverer tilstand 1, finjusterer backlogs og retries omhyggeligt og måler effekterne med klare målepunkter. Yderligere lag som nftables-rate-limits, SYNPROXY og XDP bremser trafikken allerede før TCP-stakken. Alt i alt sikrer jeg på denne måde web-, mail-, VPN- og API-tjenester mod SYN-floods uden at ulempe almindelige klienter. Den, der konsekvent implementerer disse trin, styrker tilgængeligheden og reducerer nedbrud mærkbart under angrebsbelastning.
