{"id":20882,"date":"2026-08-22T08:31:38","date_gmt":"2026-08-22T06:31:38","guid":{"rendered":"https:\/\/webhosting.de\/tcp-syn-cookies-schutz-syn-flood-kernel\/"},"modified":"2026-08-22T08:31:38","modified_gmt":"2026-08-22T06:31:38","slug":"tcp-syn-cookies-bescherming-tegen-syn-flood-kernel","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/tcp-syn-cookies-schutz-syn-flood-kernel\/","title":{"rendered":"TCP SYN-cookies in de Linux-kernel: bescherming tegen SYN-floods"},"content":{"rendered":"<p><strong>TCP SYN-cookies<\/strong> 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.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>Functionaliteit<\/strong>: Cookie in het ISN, status pas na ACK<\/li>\n  <li><strong>Linux-besturing<\/strong>: net.ipv4.tcp_syncookies met modi 0\/1\/2<\/li>\n  <li><strong>Voordeel<\/strong>: laag geheugengebruik bij een hoge belasting<\/li>\n  <li><strong>Grenzen<\/strong>: biedt geen bescherming tegen aanvallen op de bandbreedte of op apps<\/li>\n  <li><strong>Afstemmen<\/strong>: Stel de backlog- en retry-waarden zorgvuldig in<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-syn-schutz-8574.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hoe SYN-floods de TCP-handshake vertragen<\/h2>\n\n<p>Een aanvaller overspoelt de server met <strong>SYN-pakketten<\/strong> 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 <strong>Syncookies<\/strong> 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.<\/p>\n\n<h2>Technische werkwijze: cookie in plaats van het vroegere statusmechanisme<\/h2>\n\n<p>De kernel reageert op een <strong>SYN<\/strong> 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.<\/p>\n\n<h2>Activeren en controleren: tcp_syncookies in de praktijk<\/h2>\n\n<p>Over de sysctl-schakelaar <strong>net.ipv4.tcp_syncookies<\/strong> 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 <a href=\"https:\/\/webhosting.de\/nl\/syn-flood-bescherming-socket-afhandeling-server-verdediging\/\">SYN bescherming tegen overstromingen<\/a>. De volgende commando's gebruik ik regelmatig:<\/p>\n\n<pre><code>#-status weergeven\nsysctl net.ipv4.tcp_syncookies\n\n# tijdelijk inschakelen (tot de volgende herstart)\nsudo sysctl -w net.ipv4.tcp_syncookies=1\n\n# permanent instellen\necho \"net.ipv4.tcp_syncookies = 1\" | sudo tee \/etc\/sysctl.d\/60-syncookies.conf\nsudo sysctl --system\n<\/code><\/pre>\n\n<h2>Beperkingen: wat SYN-cookies niet kunnen<\/h2>\n\n<p>SYN-cookies zijn vooral gericht op de <strong>Syn-Queue<\/strong> 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.<\/p>\n\n<h2>Tuning: achterstanden, wachtrijen en herhalingspogingen<\/h2>\n\n<p>Voordat er iets ernstigs gebeurt, stem ik <strong>achterstanden<\/strong> en het aantal herpogingen, zodat legitieme pieken de beschermingsmodus niet onnodig activeren. tcp_max_syn_backlog be\u00efnvloedt 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\u00efsoleerd netwerk.<\/p>\n\n<pre><code>#-kandidaten voor piekbelastingen\nsudo sysctl -w net.core.somaxconn=4096\nsudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192\nsudo sysctl -w net.ipv4.tcp_synack_retries=3\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcpsyncookies_7432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bedrijfsmodi vergelijken: gevolgen en toepassing<\/h2>\n\n<p>Voor het dagelijks leven kies ik de <strong>Modi<\/strong> bewust, omdat ze van invloed zijn op de diagnose, statistieken en het gedrag onder druk. Permanente cookies (2) voorkomen elke vroege statusinstelling, maar be\u00efnvloeden wel de meetwaarden voor herpogingen en kunnen zeldzame randgevallen met TCP-opties be\u00efnvloeden. 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:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Modus<\/th>\n      <th>Beschrijving<\/th>\n      <th>Voordeel<\/th>\n      <th>Mogelijke bijwerking<\/th>\n      <th>Voorbeeld<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>0<\/td>\n      <td><strong>Uitgeschakeld<\/strong>, geen cookies<\/td>\n      <td>Duidelijk basisgedrag<\/td>\n      <td>Aanvaller vult de Syn-wachtrij<\/td>\n      <td>Ge\u00efsoleerd testnetwerk<\/td>\n    <\/tr>\n    <tr>\n      <td>1<\/td>\n      <td><strong>Adaptief<\/strong>, alleen bij overloop<\/td>\n      <td>Normaal TCP in rusttoestand<\/td>\n      <td>Kalibreren van het omschakelpunt<\/td>\n      <td>Openbare diensten<\/td>\n    <\/tr>\n    <tr>\n      <td>2<\/td>\n      <td><strong>Verplicht<\/strong>, altijd actief<\/td>\n      <td>Vroegtijdige ontlasting<\/td>\n      <td>Analysewaarden verschuiven<\/td>\n      <td>Zware aanvalspositie<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Meetbare effecten: vertragingen en slagingspercentage<\/h2>\n\n<p>Onder druk daalt de <strong>Vereist geheugen<\/strong> 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.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-syn-cookies-lnx-protection-4281.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Extra beveiligingslagen: firewall en limieten<\/h2>\n\n<p>Syncookies los ik op met <strong>Filterregels<\/strong> 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 <a href=\"https:\/\/webhosting.de\/nl\/netfilter-versus-nftables-moderne-linux-firewalltechnologieen-shield\/\">nftables versus Netfilter<\/a>. Daarnaast helpen SYNPROXY-scenario's op edge-firewalls, die de handshake be\u00ebindigen 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.<\/p>\n\n<h2>High-performance-benaderingen: XDP en co.<\/h2>\n\n<p>Wanneer volumineuze aanvallen de <strong>PPS-tarief<\/strong> 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\u00f3\u00f3r de socketlaag weg, wat CPU-belasting bespaart en de ontvangstwachtrij ontlast. Een inleiding tot deze techniek maakt de eerste stappen gemakkelijker: <a href=\"https:\/\/webhosting.de\/nl\/xdp-hoogwaardige-pakketverwerking-kernel-snelheid\/\">XDP-pakketverwerking<\/a>. 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.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tech_office_tcp_syn_cookies_4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diagnose: statistieken en logboekmeldingen correct interpreteren<\/h2>\n\n<p>Bij opvallende <strong>Time-outs<\/strong> 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.<\/p>\n\n<h2>Compatibiliteit: TCP-opties en randgevallen<\/h2>\n\n<p>Moderne kernels coderen <strong>Opties<\/strong> 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\u00f3\u00f3r de uitrol. Vooral bij proxyservers, NAT en Anycast-topologie\u00ebn observeer ik het gedrag grondig. LWN.net bespreekt ontwerpdetails die verklaren waarom hedendaagse implementaties betrouwbaar werken. In zeer specifieke scenario\u2019s blijft de geforceerde bedrijfsmodus (2) een hulpmiddel dat ik alleen doelgericht inzet.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/developer_desk_tcp_syn_8793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Typische misvattingen: wat ik vaak moet rechtzetten<\/h2>\n\n<p>Syncookies zijn geen vervanging voor <strong>DDoS-verdediging<\/strong> 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.<\/p>\n\n<h2>Praktijktest: stappen naar een betrouwbare aanname<\/h2>\n\n<p>Ik begin met <strong>Modus 1<\/strong> 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\u00f3\u00f3r 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.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/netzsicherheit-datenzentrum-8173.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>IPv6 en dual-stack: dezelfde switch, dezelfde logica<\/h2>\n\n<p>In dual-stack-omgevingen gedragen <strong>IPv4 en IPv6<\/strong> is consistent in de context van cookies. De schakelaar <em>net.ipv4.tcp_syncookies<\/em> regelt de beveiliging globaal voor TCP, dus ook voor v6-sockets. Ik test de overgang naar de cookie-modus daarom op beide protocollen \u2013 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.<\/p>\n\n<h2>Metrieken in de kernel: betrouwbare indicatoren<\/h2>\n\n<p>Voor betrouwbare monitoring maak ik gebruik van kernel-tellers die cookies expliciet registreren. Naast <em>ss -s<\/em> 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.<\/p>\n\n<pre><code># Overzicht\nss -s\nss -ant state syn-recv | wc -l\n\n# Cookie-teller (kernel: \/proc\/net\/netstat)\ngrep -E 'Syncookies|ListenOverflows|ListenDrops' \/proc\/net\/netstat\n\n# Live-weergave\nwatch -n1 'grep -E \"Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n\n# Logboekmeldingen (voorbeeldbericht)\n# dmesg toont onder andere:\n# TCP: Mogelijke SYN-flooding op poort 443. Cookies verzenden. Controleer SNMP-tellers.\n<\/code><\/pre>\n\n<p>Stijgen <em>Lijstoverschrijdingen<\/em> en <em>ListenDrops<\/em> parallel aan <em>SyncookiesVerzonden<\/em> , pas ik de backlogs, herhalingspogingen en upstream-filters aan. Blijven <em>SyncookiesRecv<\/em> , wijst dat op pure bot-spam; als er daarentegen steeds vaker <em>SyncookiesFailed<\/em>, controleer ik NAT\/proxy-routes en mogelijke manipulaties onderweg.<\/p>\n\n<h2>Proxies, load balancers en Kubernetes<\/h2>\n\n<p>Op <strong>Proxy- en LB-ketens<\/strong> 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.<\/p>\n\n<h2>Grenzgevallen in detail: opties, tijdssegmenten, NAT<\/h2>\n\n<p>Cookies coderen alleen <strong>beperkte parameters<\/strong>. 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 \u2013 bij sterk asymmetrische routes of pieken in de vertraging kan een legitieme ACK net buiten het venster vallen. In WAN- en satellietscenario\u2019s 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.<\/p>\n\n<h2>ACK-\/RST-floods en varianten die verder gaan dan de SYN-storm<\/h2>\n\n<p>Niet elke <strong>Transportaanval<\/strong> is een pure SYN-flood. ACK- of RST-floods richten zich op de CPU en pakketpaden, zonder de handshake te activeren \u2013 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\u00ebindig 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.<\/p>\n\n<h2>Verdere optimalisatie: wachtrijen voor lijsten en acceptatie, en snelle foutmeldingen<\/h2>\n\n<p>Naast de klassieke parameters maak ik gebruik van aanvullende schakelaars die het gedrag in de grensgebieden bepalen:<\/p>\n\n<ul>\n  <li><strong>Backlog versus somaxconn<\/strong>: De waarde in <em>lijsten (achterstand)<\/em> per proces wordt bepaald door <em>net.core.somaxconn<\/em> beperkt. Ik zorg ervoor dat de serversoftware en de kernel goed op elkaar zijn afgestemd, anders gaan optimalisaties verloren.<\/li>\n  <li><strong>tcp_abort_on_overflow<\/strong>: Of er bij een volle Accept-Queue stilzwijgend wordt gedropt of actief met RST wordt geantwoord. Bij API\u2019s 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.<\/li>\n  <li><strong>Beheer van de Port- en TIME-WAIT-status<\/strong>: Cookies voorkomen geen <em>Ephemeral-port-bottleneck<\/em>. Ik ben van plan <em>ip_local_port_range<\/em> Wees ruimhartig en pas TIME-WAIT-optimalisaties zorgvuldig toe, zodat hergebruik niet tot Heisenbugs leidt.<\/li>\n  <li><strong>SO_REUSEPORT<\/strong>: Meerdere Accept-wachtrijen per poort verdelen de belasting over de worker-processen en verminderen overflows op afzonderlijke CPU's.<\/li>\n<\/ul>\n\n<h2>Testmethoden: reproduceerbaar en betrouwbaar<\/h2>\n\n<p>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.<\/p>\n\n<pre><code># Een flood genereren (laboratorium!)\nsudo hping3 -S -p 443 --flood --rand-source \n\n# Netwerkcondities vari\u00ebren\nsudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%\n\n# Legitiem verkeer mengen\nwrk -t8 -c512 -d60s https:\/\/\/\n\n# Parallel toezicht\nwatch -n1 'ss -s; echo; grep -E \"Syncookies|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n<\/code><\/pre>\n\n<p>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.<\/p>\n\n<h2>Bedrijf en onderhoud: stabiliteit gedurende de gehele levensduur waarborgen<\/h2>\n\n<p>Bij continu gebruik ben ik van plan om <strong>Geheime rotatie<\/strong> (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\u2019s 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.<\/p>\n\n<h2>Verkorte versie voor wie haast heeft<\/h2>\n\n<p>SYN-cookies bewaren de <strong>Handshake-belasting<\/strong> 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\u00f3\u00f3r 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.<\/p>","protected":false},"excerpt":{"rendered":"<p>TCP SYN-cookies bieden in de Linux-kernel betrouwbare bescherming tegen SYN-flood-aanvallen. Ontdek hoe dit mechanisme werkt en hoe u het kunt configureren.<\/p>","protected":false},"author":1,"featured_media":20875,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-20882","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"129","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"TCP SYN Cookies","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20875","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20882","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=20882"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20882\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/20875"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=20882"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=20882"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=20882"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}