Ga naar de inhoud 
TCP SYN-cookies In de Linux-kernel wordt de handshake-belasting laag gehouden door statusinformatie cryptografisch in het Initial Sequence Number te coderen en pas bij een geldige ACK een verbinding volledig tot stand te brengen. Zo voorkom ik dat SYN-floods de wachtrij met halfopen verbindingen verstoppen en legitieme clients blokkeren.
Centrale punten
- Functionaliteit: Cookie in het ISN, status pas na ACK
- Linux-besturing: net.ipv4.tcp_syncookies met modi 0/1/2
- Voordeel: laag geheugengebruik bij een hoge belasting
- Grenzen: biedt geen bescherming tegen aanvallen op de bandbreedte of op apps
- Afstemmen: Stel de backlog- en retry-waarden zorgvuldig in
Hoe SYN-floods de TCP-handshake vertragen
Een aanvaller overspoelt de server met SYN-pakketten en negeert de volgende SYN/ACK-antwoorden, waardoor halfopen verbindingen de SYN-wachtrij bezetten. Ik merk dan dat nieuwe, legitieme verzoeken geen plaats vinden en dat er steeds vaker time-outs optreden. Precies hier komen Syncookies aan: De kernel slaat in eerste instantie geen verbindingsstatus op en verwerkt de benodigde gegevens in het volgnummer. Pas een correcte ACK bewijst dat er daadwerkelijk een tegenpartij is, zodat het opbouwen van de verbinding normaal verloopt. LWN.net en de TUM-documentatie beschrijven dit principe als een beproefde, effectieve bescherming tegen handshakes zonder hoog geheugenverbruik. Deze architectuur zorgt ervoor dat de server ook bij een verkeersstroom nog in staat is om verbindingen aan te nemen, omdat hij dure statussen pas op een zeer laat moment aanmaakt.
Technische werkwijze: cookie in plaats van het vroegere statusmechanisme
De kernel reageert op een SYN met een speciaal gecodeerde SYN/ACK, waarvan de ISN is afgeleid uit een geheime sleutel, TCP-opties en tijdssegmenten. Als er een ACK met het juiste nummer binnenkomt, reconstrueer ik uit de ISN de sessieparameters en open ik de socket op de gebruikelijke manier. Als er geen antwoord komt, is er ook geen bezette halfopen toestand, wat geheugen en CPU ontziet. Deze aanpak vermindert de kwetsbaarheid van de acceptatiefase drastisch, zonder het reguliere pad permanent te wijzigen. Volgens documentatie van Ubuntu en Red Hat werkt deze techniek al vele kernelgeneraties lang betrouwbaar en treedt deze pas in werking wanneer de wachtrij dreigt te overlopen.
Activeren en controleren: tcp_syncookies in de praktijk
Over de sysctl-schakelaar net.ipv4.tcp_syncookies Hiermee stel ik het gedrag in: 0 = uit, 1 = alleen bij overbelasting, 2 = permanent. In productieomgevingen stel ik meestal modus 1 in, zodat de standaard-handshake intact blijft en de bescherming pas in werking treedt wanneer dat nodig is. Ik kan de status snel in de shell bekijken en wijzigingen doorvoeren via sysctl of permanent in /etc/sysctl.d/. Een relevant achtergrondartikel over socketgedrag en aanvalspatronen helpt bij het plannen van het geheel; ik ga dieper in op de details in het artikel SYN bescherming tegen overstromingen. De volgende commando's gebruik ik regelmatig:
#-status weergeven
sysctl net.ipv4.tcp_syncookies
# tijdelijk inschakelen (tot de volgende herstart)
sudo sysctl -w net.ipv4.tcp_syncookies=1
# permanent instellen
echo "net.ipv4.tcp_syncookies = 1" | sudo tee /etc/sysctl.d/60-syncookies.conf
sudo sysctl --system
Beperkingen: wat SYN-cookies niet kunnen
SYN-cookies zijn vooral gericht op de Syn-Queue en voorkomen dat halfopen statussen geheugen bezetten. Ze bieden echter geen bescherming tegen een overbelaste verbinding, overbelaste applicatielogica of CPU-verzadiging. Bij volumetrische aanvallen heb ik upstream-filters, QoS en eventueel scrubbing nodig. Ook aanvallen op applicatieniveau, zoals HTTP-GET-overstromingen, vereisen extra controles, limieten en caches. Ik pas syncookies daarom altijd toe binnen een meerlaagse verdediging die het netwerk-, kernel- en serviceniveau samenbrengt.
Tuning: achterstanden, wachtrijen en herhalingspogingen
Voordat er iets ernstigs gebeurt, stem ik achterstanden en het aantal herpogingen, zodat legitieme pieken de beschermingsmodus niet onnodig activeren. tcp_max_syn_backlog beïnvloedt de wachtrij van halfopen verbindingen, somaxconn de maximale lengte van de acceptatiewachtrij voor verbindingen die wachten op accept(). Met tcp_synack_retries bepaal ik hoe vaak de kernel een SYN/ACK-herhaling probeert voordat hij het opgeeft. Hogere backlogs vangen korte piekbelastingen op, maar kosten wel geheugen; minder herhalingspogingen maken slots eerder vrij, maar brengen het risico met zich mee dat verwijderde clients te hard worden getroffen. Deze afwegingen test ik onder realistische belasting met tools zoals hping3 of tcp_syn_flooder in een geïsoleerd netwerk.
#-kandidaten voor piekbelastingen
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
Bedrijfsmodi vergelijken: gevolgen en toepassing
Voor het dagelijks leven kies ik de Modi bewust, omdat ze van invloed zijn op de diagnose, statistieken en het gedrag onder druk. Permanente cookies (2) voorkomen elke vroege statusinstelling, maar beïnvloeden wel de meetwaarden voor herpogingen en kunnen zeldzame randgevallen met TCP-opties beïnvloeden. De adaptieve modus (1) laat de stack normaal draaien en grijpt in wanneer er een overrun dreigt. De uit-stand (0) is hooguit zinvol in laboratoriumomgevingen of gesloten netwerken. De volgende tabel vat dit beknopt samen:
| Modus | Beschrijving | Voordeel | Mogelijke bijwerking | Voorbeeld |
|---|---|---|---|---|
| 0 | Uitgeschakeld, geen cookies | Duidelijk basisgedrag | Aanvaller vult de Syn-wachtrij | Geïsoleerd testnetwerk |
| 1 | Adaptief, alleen bij overloop | Normaal TCP in rusttoestand | Kalibreren van het omschakelpunt | Openbare diensten |
| 2 | Verplicht, altijd actief | Vroegtijdige ontlasting | Analysewaarden verschuiven | Zware aanvalspositie |
Meetbare effecten: vertragingen en slagingspercentage
Onder druk daalt de Vereist geheugen Dit is duidelijk bij het tot stand brengen van een verbinding, omdat er geen halfopen toestand ontstaat. Daardoor houden SYN-cookies de acceptatiegraad hoog, en veroorzaken korte pieken minder afbrekingen. Ik zie bij een hoge verkeersstroom een sneller herstel zodra de bron opdroogt. Ubuntu- en Tenable-richtlijnen raden adaptief gebruik aan, zodat normale clients ongewijzigd blijven functioneren. Voor regressietests controleer ik hertransmissies, drop-percentages en de serverlatentie bij de overgang naar de cookiemodus.
Extra beveiligingslagen: firewall en limieten
Syncookies los ik op met Filterregels en limieten voor het aantal verzoeken instellen, zodat de belasting de TCP-stack helemaal niet belast. Op Linux geef ik de voorkeur aan nftables-regels om overtreders op basis van verbindingsfrequenties te beperken of in een vroeg stadium te weigeren. De handleiding biedt een beknopt overzicht van moderne pakketfilters nftables versus Netfilter. Daarnaast helpen SYNPROXY-scenario's op edge-firewalls, die de handshake beëindigen en alleen geldige verbindingen doorlaten. Voor kwetsbare poorten stel ik strikte instellingen vast voor het openen van poorten, logdrempels en het maximale aantal verbindingspogingen per bronadres.
High-performance-benaderingen: XDP en co.
Wanneer volumineuze aanvallen de PPS-tarief Om de belasting te verminderen, verplaats ik de filterlogica via XDP naar de netwerkrand van de NIC. Zo filter ik verdachte SYN-pakketten al vóór de socketlaag weg, wat CPU-belasting bespaart en de ontvangstwachtrij ontlast. Een inleiding tot deze techniek maakt de eerste stappen gemakkelijker: XDP-pakketverwerking. In combinatie met SYN-cookies ontstaat een tweetraps systeem: eerst een grove selectie op de kaart, daarna een betrouwbare handshake-controle in de kernel. Deze keten verkleint het aanvalsoppervlak aanzienlijk en houdt diensten toegankelijk.
Diagnose: statistieken en logboekmeldingen correct interpreteren
Bij opvallende Time-outs Ik controleer de netstat/ss-statistieken, dmesg-meldingen en Grafana-panelen met verbindingssnelheden. Een stijgend aandeel SYN-RECV, veel hertransmissies en drops duiden op de overgang naar de beschermingsmodus. Ik let op meldingen van syn backlog overflow en breng deze in verband met de CPU- en IRQ-belasting. Pakketopnames met tcpdump bevestigen de logica van de volgnummers en helpen bij het herkennen van valse positieven. Met iptables/nftables-tellers meet ik bovendien de treffersituatie bij rate-limit-regels.
Compatibiliteit: TCP-opties en randgevallen
Moderne kernels coderen Opties zoals MSS, SACK of Timestamp, zodat cookies op een manier worden verzonden waarbij ze kunnen worden gereconstrueerd. Oudere of ongebruikelijke stacks kunnen eigenaardigheden vertonen; daarom controleer ik kritieke paden vóór de uitrol. Vooral bij proxyservers, NAT en Anycast-topologieën observeer ik het gedrag grondig. LWN.net bespreekt ontwerpdetails die verklaren waarom hedendaagse implementaties betrouwbaar werken. In zeer specifieke scenario’s blijft de geforceerde bedrijfsmodus (2) een hulpmiddel dat ik alleen doelgericht inzet.
Typische misvattingen: wat ik vaak moet rechtzetten
Syncookies zijn geen vervanging voor DDoS-verdediging aan de rand; ze beschermen vooral de handshake-fase. Een hoog somaxconn-getal alleen voorkomt geen overloop als SYN/ACK nooit wordt beantwoord. Ook is de aanname dat permanente cookies (2) altijd de beste keuze zijn misleidend; diagnoses en speciale gevallen lijden hieronder. Zonder monitoring mis ik signalen om omschakelpunten en limieten aan te passen. Belastingtests blijven onmisbaar, zodat de configuratie en hardware aansluiten bij de werkelijke toegangsdynamiek.
Praktijktest: stappen naar een betrouwbare aanname
Ik begin met Modus 1 voor tcp_syncookies en controleer het ingrijpingspunt onder belasting. Daarna verhoog ik tcp_max_syn_backlog en somaxconn gematigd, terwijl ik tcp_synack_retries verlaag en de slagingspercentages meet. Firewall-rate-limits en geo-/ASN-filters filteren ruis uit vóór de stack. XDP- of SmartNIC-filters bewaar ik voor situaties met hoge PPS-waarden, zodat ik mijn middelen doelgericht kan inzetten. Tot slot documenteer ik de statistieken, zodat latere aanpassingen op gegevens zijn gebaseerd.
IPv6 en dual-stack: dezelfde switch, dezelfde logica
In dual-stack-omgevingen gedragen IPv4 en IPv6 is consistent in de context van cookies. De schakelaar net.ipv4.tcp_syncookies regelt de beveiliging globaal voor TCP, dus ook voor v6-sockets. Ik test de overgang naar de cookie-modus daarom op beide protocollen – vooral wanneer upstream-apparaten in IPv6 andere filterpaden gebruiken. Belangrijk: SYN-cookies beschermen uitsluitend TCP. UDP-diensten of QUIC vereisen eigen snelheidsbeperkingen en edge-beleid, zodat volumetrisch verkeer de CPU niet overbelast.
Metrieken in de kernel: betrouwbare indicatoren
Voor betrouwbare monitoring maak ik gebruik van kernel-tellers die cookies expliciet registreren. Naast ss -s Om de toestandverdelingen te observeren, houd ik de tellers bij voor verzonden, geaccepteerde en mislukte cookies. Zo kan ik zien of de beveiliging werkt, of legitieme clients doorkomen en of er verkeerde configuraties zijn.
# Overzicht
ss -s
ss -ant state syn-recv | wc -l
# Cookie-teller (kernel: /proc/net/netstat)
grep -E 'Syncookies|ListenOverflows|ListenDrops' /proc/net/netstat
# Live-weergave
watch -n1 'grep -E "Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)" /proc/net/netstat'
# Logboekmeldingen (voorbeeldbericht)
# dmesg toont onder andere:
# TCP: Mogelijke SYN-flooding op poort 443. Cookies verzenden. Controleer SNMP-tellers.
Stijgen Lijstoverschrijdingen en ListenDrops parallel aan SyncookiesVerzonden , pas ik de backlogs, herhalingspogingen en upstream-filters aan. Blijven SyncookiesRecv , wijst dat op pure bot-spam; als er daarentegen steeds vaker SyncookiesFailed, controleer ik NAT/proxy-routes en mogelijke manipulaties onderweg.
Proxies, load balancers en Kubernetes
Op Proxy- en LB-ketens bepaalt de plaatsing van de cookie-beveiliging. Als een L4-/L7-loadbalancer de TCP-handshake afbreekt, bereikt een SYN-flood de backends helemaal niet; in dat geval activeer ik de cookies aan de edge. Als de LB alleen passief werkt (DSR, ECMP), moeten backend-knooppunten zichzelf beschermen. In Kubernetes stem ik de sysctls op de workerknooppunten af, met name bij NodePort- of HostNetwork-workloads. Voor Ingress-controllers met eigen SYN-bescherming (SYNPROXY, eBPF) pas ik de beleidsregels zo aan dat ze elkaar niet in de weg zitten. Ik houd in tests rekening met de healthchecks van de load balancer, omdat korte testvensters met een laag aantal herpogingen anders ten onrechte tot instabiliteit leiden.
Grenzgevallen in detail: opties, tijdssegmenten, NAT
Cookies coderen alleen beperkte parameters. Moderne Linux-implementaties reconstrueren MSS, SACK en Window Scaling doorgaans betrouwbaar; tijdstempels en zeldzame opties kunnen echter, afhankelijk van de kernelversie, beperkingen hebben. Ik geef daarom de voorkeur aan de werkingsmodus (1), zodat het standaardpad de overhand heeft en cookies alleen bij een overflow in werking treden. De geldigheid van een cookie is gekoppeld aan tijdsegmenten – bij sterk asymmetrische routes of pieken in de vertraging kan een legitieme ACK net buiten het venster vallen. In WAN- en satellietscenario’s meet ik daarom de round-trip-variantie voordat ik het aantal herpogingen verlaag. NAT en middleboxes die sequentienummers of opties bewerken, zijn andere kandidaten voor randgevallen; met gerichte captures toon ik aan waar bits verloren gaan.
ACK-/RST-floods en varianten die verder gaan dan de SYN-storm
Niet elke Transportaanval is een pure SYN-flood. ACK- of RST-floods richten zich op de CPU en pakketpaden, zonder de handshake te activeren – cookies helpen hier nauwelijks. Ik gebruik dan vroege filters (nftables/XDP) met statuslogica of een minimale ACK-snelheidsbeperking. Met name RST-golven gericht tegen bestaande verbindingen beëindig ik via een set regels die onverwachte RST's zonder passend venster afwijst. Ook half-open herhalingen (SYN met spoofing plus late ACK's) vange ik op via snelheidsbeperkingen per bronnetwerkruimte.
Verdere optimalisatie: wachtrijen voor lijsten en acceptatie, en snelle foutmeldingen
Naast de klassieke parameters maak ik gebruik van aanvullende schakelaars die het gedrag in de grensgebieden bepalen:
- Backlog versus somaxconn: De waarde in lijsten (achterstand) per proces wordt bepaald door net.core.somaxconn beperkt. Ik zorg ervoor dat de serversoftware en de kernel goed op elkaar zijn afgestemd, anders gaan optimalisaties verloren.
- tcp_abort_on_overflow: Of er bij een volle Accept-Queue stilzwijgend wordt gedropt of actief met RST wordt geantwoord. Bij API’s met een hoog verwerkingsvolume kan een snelle fout de client in staat stellen snel een nieuwe poging te doen; bij TLS- of legacy-clients geef ik meestal de voorkeur aan het standaard droppen.
- Beheer van de Port- en TIME-WAIT-status: Cookies voorkomen geen Ephemeral-port-bottleneck. Ik ben van plan ip_local_port_range Wees ruimhartig en pas TIME-WAIT-optimalisaties zorgvuldig toe, zodat hergebruik niet tot Heisenbugs leidt.
- SO_REUSEPORT: Meerdere Accept-wachtrijen per poort verdelen de belasting over de worker-processen en verminderen overflows op afzonderlijke CPU's.
Testmethoden: reproduceerbaar en betrouwbaar
Ik simuleer belasting op basis van realistische scenario's en meet het omschakelpunt naar de cookie-modus, het slagingspercentage van legitieme verbindingen en de hersteltijd na de piekbelasting. Daarbij combineer ik synthetische SYN-overbelastingen met echte applicatieverzoeken.
# Een flood genereren (laboratorium!)
sudo hping3 -S -p 443 --flood --rand-source
# Netwerkcondities variëren
sudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%
# Legitiem verkeer mengen
wrk -t8 -c512 -d60s https:///
# Parallel toezicht
watch -n1 'ss -s; echo; grep -E "Syncookies|Listen(Overflows|Drops)" /proc/net/netstat'
Aan de hand van deze stappen kan ik vaststellen of het aantal herpogingen te sterk afneemt, of upstream-firewalls ten onrechte tijdstempels filteren, of dat de accept-queues van afzonderlijke workers onevenredig vol raken. Ik documenteer de kengetallen (succespercentage van legitieme verbindingen dat in de buurt ligt van 100%, cookie-hitpercentage, latentiegedrag) om later op basis van gegevens aanpassingen te kunnen doorvoeren.
Bedrijf en onderhoud: stabiliteit gedurende de gehele levensduur waarborgen
Bij continu gebruik ben ik van plan om Geheime rotatie (automatisch door de kernel) en kijk of het wisselen van tijdslots zichtbare effecten heeft op trajecten met een zeer lange RTT. Ik houd de kernel en stuurprogramma’s up-to-date, zodat verbeteringen in de cookie-implementatie (betere codering van opties, robuuste tijdslots) effect sorteren. Voor audits noteer ik wanneer de beveiligingsmodus in werking trad, hoeveel verbindingen erdoor werden doorgelaten en of er extra filters werden ingeschakeld. Bij wijzigingen aan MTU, offloading of NF-stacks (bijv. nieuwe nftables-sets) herhaal ik korte tests, zodat ik verkeerde interacties vroegtijdig kan ontdekken.
Verkorte versie voor wie haast heeft
SYN-cookies bewaren de Handshake-belasting klein houden door statussen pas aan te maken na een bevestigde ACK, en zo de Syn-wachtrij te beschermen tegen overstroming. Ik activeer modus 1, stel backlogs en retries zorgvuldig af en meet de effecten met duidelijke statistieken. Extra lagen zoals nftables-rate-limits, SYNPROXY en XDP remmen het verkeer al af vóór de TCP-stack. Al met al beveilig ik op deze manier web-, e-mail-, VPN- en API-diensten tegen SYN-floods, zonder reguliere clients te benadelen. Wie deze stappen strikt implementeert, versterkt de beschikbaarheid en vermindert uitval bij een aanval merkbaar.
