Hoppa till innehåll 
TCP SYN-cookies I Linux-kärnan håller handskakningsbelastningen låg genom att kryptografiskt koda tillståndsinformation i Initial Sequence Number och först upprätta en fullständig anslutning vid ett giltigt ACK. På så sätt förhindrar jag att SYN-översvämningar överbelastar kön med halvöppna anslutningar och blockerar legitima klienter.
Centrala punkter
- Funktionalitet: Cookie i ISN, status först efter ACK
- Linux-styrning: net.ipv4.tcp_syncookies med lägena 0/1/2
- Förmån: lågt lagringsbehov vid attackbelastning
- Gränser: hjälper inte mot bandbredds- eller app-attacker
- Tuning: Ställ in värdena för backlog och retry noggrant
Hur SYN-floods bromsar upp TCP-handskakningen
En angripare överbelastar servern med SYN-paket och ignorerar de efterföljande SYN/ACK-svaren, vilket leder till att halvöppna poster tar upp plats i SYN-kön. Jag märker då att nya, legitima förfrågningar inte får plats och att tidsöverskridanden blir allt vanligare. Det är just här som Syncookies an: Kärnan lagrar inledningsvis ingen anslutningsstatus och överför nödvändiga data till sekvensnumret. Först ett korrekt ACK bekräftar att det finns en verklig motpart, varpå uppkopplingen fortsätter som vanligt. LWN.net och TUM-dokumentationen beskriver denna princip som ett etablerat, effektivt skydd mot handskakningsattacker utan hög minnesanvändning. Denna arkitektur gör att servern förblir mottaglig även vid hög trafikbelastning, eftersom den först mycket sent skapar resurskrävande tillstånd.
Teknisk process: Cookie istället för det tidigare tillståndssystemet
Kärnan svarar på ett SYN med ett särskilt kodat SYN/ACK, vars ISN härleds från en hemlig nyckel, TCP-alternativ och tidsintervall. Om ett ACK med rätt nummer anländer rekonstruerar jag sessionsparametrarna utifrån ISN och öppnar socketen på vanligt sätt. Om svaret uteblir finns det inte heller något upptaget halvöppet tillstånd, vilket sparar på minne och CPU. Denna metod minskar sårbarheten i mottagningsfasen drastiskt utan att permanent ändra den vanliga vägen. Enligt dokumentation från Ubuntu och Red Hat har tekniken fungerat tillförlitligt i många generationer av kärnan och träder i kraft först när kön hotar att överbelastas.
Aktivera och testa: tcp_syncookies i praktiken
Om sysctl-flaggan net.ipv4.tcp_syncookies Jag styr beteendet: 0 = av, 1 = endast vid överbelastning, 2 = permanent. I produktionsmiljöer ställer jag oftast in läge 1, så att standardhandshaken förblir intakt och skyddet aktiveras först vid behov. Jag kan snabbt se statusen i shellen och gör ändringar via sysctl eller permanent i /etc/sysctl.d/. En lämplig bakgrundsartikel om socketbeteende och attackmönster underlättar planeringen av det hela; jag går in på detaljerna i inlägget SYN översvämningsskydd. Följande kommandon använder jag regelbundet:
# Visa status
sysctl net.ipv4.tcp_syncookies
# Aktivera tillfälligt (tills omstart)
sudo sysctl -w net.ipv4.tcp_syncookies=1
# Ställ in permanent
echo "net.ipv4.tcp_syncookies = 1" | sudo tee /etc/sysctl.d/60-syncookies.conf
sudo sysctl --system
Begränsningar: Vad SYN-cookies inte klarar av
SYN-cookies riktar sig främst till Syn-Queue och förhindrar att halvöppna tillstånd tar upp minnesutrymme. De har dock ingen effekt mot en överbelastad anslutning, en överbelastad applikationslogik eller CPU-mättnad. Vid volymetriska attacker behöver jag uppströmsfilter, QoS och vid behov scrubbing. Även attacker på applikationsnivå, såsom HTTP-GET-översvämningar, kräver ytterligare kontroller, begränsningar och cacher. Jag integrerar därför alltid syncookies i ett flerstegsförsvar som förenar nätverks-, kärn- och tjänstenivåerna.
Tuning: Eftersläpningar, köer och nya försök
Innan en nödsituation inträffar, gör jag följande: Eftersläpningar och antalet försök, så att legitima toppar inte utlöser skyddsläget i onödan. tcp_max_syn_backlog påverkar kön med halvöppna anslutningar, medan somaxconn påverkar den maximala längden på kön för anslutningar som väntar på accept(). Med tcp_synack_retries bestämmer jag hur många gånger kärnan försöker skicka ett SYN/ACK innan den ger upp. Högre backloggar hanterar korta belastningstoppar, men tar upp minne; färre försök frigör platser tidigare, men medför risken att avbrutna klienter drabbas för hårt. Dessa avvägningar testar jag under realistisk belastning med verktyg som hping3 eller tcp_syn_flooder i ett isolerat nätverk.
#-kandidater för belastningstoppar
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
Jämförelse av driftslägen: Effekter och användningsområden
Till vardags väljer jag Lägen medvetet, eftersom de påverkar diagnos, mätvärden och beteende under press. Permanenta cookies (2) undviker all tidig tillståndsinställning, men förändrar mätvärden för omförsök och kan påverka sällsynta gränsfall med TCP-alternativ. Det adaptiva läget (1) låter stacken köras normalt och ingriper vid risk för överbelastning. Läget ”av” (0) är endast meningsfullt i laboratoriesituationer eller slutna nätverk. Följande tabell sammanfattar detta kortfattat:
| Läge | Beskrivning av | Fördel | Möjlig biverkning | Exempel |
|---|---|---|---|---|
| 0 | Inaktiverad, inga cookies | Tydligt beteende vid baslinjen | Angriparen fyller Syn-köen | Isolerat testnät |
| 1 | Adaptiv, endast vid överflöd | Vanlig TCP vid inaktivitet | Kalibrera omkopplingspunkten | Offentliga tjänster |
| 2 | Tvingad, alltid aktiv | Tidigt avlastning | Analysvärdena förändras | Svår anfallsposition |
Mätbara effekter: fördröjningar och framgångsgrad
Under tryck sjunker Krav på minne Detta märks tydligt vid varje anslutning, eftersom det inte uppstår något halvöppet tillstånd. Därmed håller SYN-cookies godtagandegraden hög, och korta dataströmmar orsakar färre avbrott. Jag observerar en snabbare återhämtning vid hög trafik så snart källan sinar. Riktlinjerna från Ubuntu och Tenable rekommenderar en adaptiv användning så att vanliga klienter fortsätter att fungera som vanligt. För regressionstester kontrollerar jag återutsändningar, bortfallsfrekvenser och serverns latens vid övergången till cookie-läge.
Ytterligare skyddslager: brandvägg och begränsningar
Jag löser syncookies med Filterregler och sätter gränser för överföringshastigheten så att belastningen inte ens når TCP-stacken. På Linux använder jag helst nftables-regler för att strypa eller tidigt avvisa störande trafik utifrån anslutningshastigheten. En kortfattad översikt över moderna paketfilter finns i handledningen nftables jämfört med Netfilter. Som komplement används SYNPROXY-scenarier på edge-brandväggar, som avbryter handskakningen och endast släpper igenom giltiga anslutningar. För utsatta portar definierar jag strikta öppningar, loggningströsklar och maximalt antal anslutningsförsök per källadress.
Högpresterande metoder: XDP och liknande.
När volymattacker PPS-frekvens För att öka prestandan flyttar jag filterlogiken via XDP till nätverksgränsen på nätverkskortet. På så sätt avvisar jag misstänkta SYN-paket redan före socket-lagret, vilket minskar CPU-belastningen och avlastar mottagningskön. En introduktion till denna teknik underlättar insteg i XDP-paketbehandling. I kombination med SYN-cookies skapas ett tvåstegssystem: först en grov gallring på kortet, sedan en tillförlitlig handskakningskontroll i kärnan. Denna kedja minskar attackytan märkbart och håller tjänsterna tillgängliga.
Diagnos: Att tolka mätvärden och loggmeddelanden på rätt sätt
Vid påfallande Tidsfrister kontrollerar jag netstat/ss-statistiken, dmesg-meddelanden och Grafana-paneler med anslutningshastigheter. En ökande andel SYN-RECV, höga siffror för återutsändningar och bortfall indikerar övergången till skyddsläget. Jag håller utkik efter meddelanden om SYN-backlog-överflöd och korrelerar dem med CPU- och IRQ-belastningen. Paketavlyssningar med tcpdump bekräftar logiken bakom sekvensnumren och hjälper till att identifiera falska positiva resultat. Med iptables/nftables-räknare mäter jag dessutom träfffrekvensen för hastighetsbegränsningsreglerna.
Kompatibilitet: TCP-alternativ och gränsfall
Programmera moderna kärnor Alternativ som MSS, SACK eller Timestamp, så att cookies överförs på ett sätt som gör det möjligt att rekonstruera dem. Äldre eller ovanliga stackar kan uppvisa särdrag, därför kontrollerar jag kritiska vägar innan lanseringen. Särskilt när det gäller proxyservrar, NAT och anycast-topologier observerar jag beteendet noggrant. LWN.net diskuterar designdetaljer som förklarar varför dagens implementeringar fungerar tillförlitligt. I mycket speciella scenarier förblir den tvingade driftsläget (2) ett verktyg som jag endast använder i specifika fall.
Vanliga missuppfattningar: Vad jag ofta rättar till
Syncookies ersätter inte DDoS-försvar i periferin; de skyddar framför allt handskakningsfasen. Ett högt somaxconn-värde i sig förhindrar inte överflöd om SYN/ACK aldrig besvaras. Likaså är det en felaktig antagande att permanenta cookies (2) alltid är det bästa valet; diagnostik och specialfall drabbas av detta. Utan övervakning saknar jag signaler för att justera omkopplingspunkter och gränsvärden. Belastningstester förblir oumbärliga för att konfigurationen och hårdvaran ska passa den verkliga åtkomstdynamiken.
Praktisk genomgång: Steg mot en hållbar antagning
Jag börjar med Läge 1 för tcp_syncookies och verifierar ingångspunkten under belastning. Därefter höjer jag tcp_max_syn_backlog och somaxconn måttligt, samtidigt som jag sänker tcp_synack_retries och mäter framgångsgraden. Brandväggens hastighetsbegränsningar och geo-/ASN-filter filtrerar bort brus före stacken. Jag sparar XDP- eller SmartNIC-filter till situationer med höga PPS-nivåer, så att jag kan använda resurserna på ett målinriktat sätt. Avslutningsvis dokumenterar jag mätvärdena så att senare justeringar kan baseras på data.
IPv6 och dual-stack: samma switch, samma logik
I dual-stack-miljöer beter sig IPv4 och IPv6 är konsekvent i samband med cookies. Knappen net.ipv4.tcp_syncookies styr skyddet globalt för TCP, alltså även för v6-socklar. Jag testar därför övergången till cookie-läget på båda protokollen – särskilt när uppströmsenheter i IPv6 använder andra filtervägar. Viktigt: SYN-cookies skyddar endast TCP. UDP-tjänster eller QUIC kräver egna hastighetsbegränsningar och edge-policyer för att volymmässig trafik inte ska överbelasta CPU:n.
Mätvärden i kärnan: tillförlitliga indikatorer
För en tillförlitlig övervakning använder jag kärnräknare som uttryckligen redovisar cookies. Förutom ss -s När det gäller tillståndsfördelningar övervakar jag räknarna för skickade, mottagna och misslyckade cookies. På så sätt kan jag se om skyddet fungerar, om legitima klienter kommer igenom och om det finns felkonfigurationer.
# Översikt
ss -s
ss -ant state syn-recv | wc -l
# Cookie-räknare (Kärnan: /proc/net/netstat)
grep -E 'Syncookies|ListenOverflows|ListenDrops' /proc/net/netstat
# Live-vy
watch -n1 'grep -E "Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)" /proc/net/netstat'
# Loggmeddelanden (exempel)
# dmesg visar bland annat:
# TCP: Möjlig SYN-översvämning på port 443. Skickar cookies. Kontrollera SNMP-räknare.
Stiga Lista överflöden och ListenDrops parallellt med SyncookiesSent justerar jag backloggar, omförsök och uppströmsfilter. Kvarstår SyncookiesRecv ... tyder det på rena bot-översvämningar; om det däremot blir allt vanligare Syncookies misslyckades, kontrollerar jag NAT-/proxyrutter och eventuella manipulationer längs vägen.
Proxyservrar, lastbalanserare och Kubernetes
På Proxy- och lastbalanseringskedjor avgör placeringen av cookieskyddet. Om en L4-/L7-lastbalanserare avbryter TCP-handskakningen når en SYN-flod inte alls backend-noderna; i så fall aktiverar jag cookies vid kanten. Om lastbalanseraren endast arbetar passivt (DSR, ECMP) måste backend-noderna skydda sig själva. I Kubernetes anpassar jag sysctl-inställningarna på arbetarnoderna, särskilt för arbetsbelastningar via NodePort eller HostNetwork. För Ingress-kontroller med eget SYN-skydd (SYNPROXY, eBPF) justerar jag policyerna så att de inte hämmar varandra. Jag tar hänsyn till lastbalanserarens hälsokontroller i testerna, eftersom korta testfönster med få omförsök annars felaktigt ger intryck av instabilitet.
Gränsfall i detalj: optioner, tidsintervall, NAT
Cookies kodar endast begränsade parametrar. Moderna Linux-implementeringar återger vanligtvis MSS, SACK och Window Scaling på ett tillförlitligt sätt; tidsstämplar och sällsynta alternativ kan dock ha begränsningar beroende på kärnversion. Jag föredrar därför driftsläge (1), så att standardvägen dominerar och cookies endast träder i kraft vid överflöd. En cookies giltighet är bunden till tidsintervall – vid starkt asymmetriska förlopp eller fördröjningstoppar kan en legitim ACK hamna precis utanför fönstret. I WAN- och satellitscenarier mäter jag därför rundresans varians innan jag sänker antalet omförsök. NAT och mellanliggande enheter som manipulerar sekvensnummer eller alternativ är ytterligare kandidater för gränsfall; med riktade avlyssningar bevisar jag var bitar går förlorade.
ACK-/RST-översvämningar och varianter bortom SYN-stormen
Inte alla Transportattack är en ren SYN-översvämning. ACK- eller RST-översvämningar riktar sig mot CPU:n och paketvägarna utan att utlösa handskakningen – cookies hjälper knappt här. Jag använder då tidiga filter (nftables/XDP) med tillståndslogik eller minimal begränsning av ACK-hastigheten. Särskilt RST-vågor mot etablerade anslutningar avbryter jag med hjälp av ett regelverk som avvisar oväntade RST:er utan passande fönster. Även halvöppna upprepningar (SYN med spoofing plus sena ACK:ar) hanterar jag genom hastighetsbegränsningar per källnätverksområde.
Ytterligare finjustering: Lista-/godkännandeköer och snabba fel
Förutom de klassiska parametrarna använder jag kompletterande reglage som påverkar beteendet i gränsområdet:
- Backlog jämfört med somaxconn: Värdet i listor (backlog) per process bestäms av net.core.somaxconn begränsad. Jag ser till att serverprogramvaran och kärnan fungerar i samklang, annars går optimeringarna till spillo.
- tcp_abort_on_overflow: Om förfrågningar tyst avvisas när Accept-kön är full eller om man aktivt svarar med RST. I API:er med hög trafik kan ett snabbt fel göra det möjligt för klienten att snabbt göra ett nytt försök; när det gäller TLS- eller äldre klienter föredrar jag oftast standardavvisningen.
- Hantering av portar och TIME-WAIT: Cookies förhindrar inte Flaskhals i efemära portar. Jag planerar ip_lokal_port_intervall Var generös och använd TIME-WAIT-optimeringar med omdöme, så att återanvändning inte leder till Heisenbugs.
- SO_REUSEPORT: Flera Accept-köer per port fördelar belastningen jämnt över arbetsprocesserna och minskar överbelastningen på enskilda CPU:er.
Testmetoder: reproducerbara och tillförlitliga
Jag simulerar belastning som efterliknar verkliga scenarier och mäter övergångspunkten till cookie-läge, andelen lyckade giltiga anslutningar samt återhämtningstiden efter belastningstoppen. I detta sammanhang kombinerar jag syntetiska SYN-flöden med verkliga applikationsförfrågningar.
Skapa #-flod (laboratorium!)
sudo hping3 -S -p 443 --flood --rand-source
Variera nätverksförhållandena för #
sudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%
# Blanda in legitim trafik
wrk -t8 -c512 -d60s https:///
# Parallell övervakning
watch -n1 'ss -s; echo; grep -E "Syncookies|Listen(Overflows|Drops)" /proc/net/netstat'
Med dessa steg kan jag avgöra om antalet försök minskar för kraftigt, om uppströmsbrandväggar felaktigt filtrerar bort tidsstämplar eller om acceptköerna hos enskilda arbetare överbelastas oproportionerligt. Jag dokumenterar nyckeltalen (närma sig 100%-framgångsfrekvens för legitima anslutningar, träfffrekvens för cookies, latensbeteende) för att senare kunna göra justeringar baserade på data.
Drift och underhåll: Säkerställa stabilitet under hela driftsperioden
Vid kontinuerlig drift planerar jag Hemlig rotation (Automatiskt på kernelnivå) och observerar om byten av tidsluckor har märkbara effekter på sträckor med mycket lång RTT. Jag håller kärnan och drivrutinerna uppdaterade så att förbättringar i cookie-implementeringen (bättre kodning av alternativ, robusta tidsluckor) får effekt. Vid granskningar noterar jag när skyddsläget aktiverades, hur många anslutningar det släppte igenom och om ytterligare filter aktiverades. Vid ändringar av MTU, avlastning eller NF-stackar (t.ex. nya nftables-uppsättningar) upprepar jag korttester för att tidigt upptäcka felaktiga interaktioner.
Förkortad version för den som har bråttom
SYN-cookies lagrar Handshake-belastning liten genom att skapa tillstånd först efter en bekräftad ACK och på så sätt skydda Syn-kön mot översvämningar. Jag aktiverar läge 1, finjusterar backlogs och retries försiktigt och mäter effekterna med tydliga mätvärden. Ytterligare lager som nftables-rate-limits, SYNPROXY och XDP bromsar trafiken redan före TCP-stacken. Sammanfattningsvis skyddar jag på detta sätt webb-, e-post-, VPN- och API-tjänster mot SYN-översvämningar utan att vanliga klienter drabbas. Den som konsekvent genomför dessa åtgärder förbättrar tillgängligheten och minskar avbrotten märkbart vid attackbelastning.
