{"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-beskyttelse-mod-syn-flood-kerne","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/tcp-syn-cookies-schutz-syn-flood-kernel\/","title":{"rendered":"TCP SYN-cookies i Linux-kernen: Beskyttelse mod SYN-floods"},"content":{"rendered":"<p><strong>TCP SYN-cookies<\/strong> I Linux-kernen holder de h\u00e5ndtryksbelastningen lav ved at krypteret at indkode tilstandsoplysninger i den indledende sekvensnummer (Initial Sequence Number) og f\u00f8rst oprette en forbindelse fuldt ud, n\u00e5r der modtages en gyldig ACK. P\u00e5 den m\u00e5de forhindrer jeg, at SYN-floods tilstopper k\u00f8en af halv\u00e5bne forbindelser og blokerer legitime klienter.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>Funktionalitet<\/strong>: Cookie i ISN, status f\u00f8rst efter ACK<\/li>\n  <li><strong>Linux-styring<\/strong>: net.ipv4.tcp_syncookies med tilstande 0\/1\/2<\/li>\n  <li><strong>Fordel<\/strong>: lavt hukommelsesforbrug ved angrebsbelastning<\/li>\n  <li><strong>Gr\u00e6nser<\/strong>: hj\u00e6lper ikke mod angreb p\u00e5 b\u00e5ndbredden eller mod apps<\/li>\n  <li><strong>Indstilling<\/strong>: Indstil backlog- og retry-v\u00e6rdier omhyggeligt<\/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>Hvordan SYN-floods bremser TCP-h\u00e5ndtrykket<\/h2>\n\n<p>En hacker oversv\u00f8mmer serveren med <strong>SYN-pakker<\/strong> og ignorerer de efterf\u00f8lgende SYN\/ACK-svar, hvilket medf\u00f8rer, at halv\u00e5bne poster optager plads i SYN-k\u00f8en. Jeg oplever s\u00e5, at nye, legitime anmodninger ikke kan komme igennem, og at der opst\u00e5r en r\u00e6kke tidsoverskridelser. Det er netop her, at <strong>Syncookies<\/strong> an: Kernen gemmer i f\u00f8rste omgang ingen forbindelsesstatus og overf\u00f8rer de n\u00f8dvendige data til sekvensnummeret. F\u00f8rst et korrekt ACK bekr\u00e6fter, at der er tale om en \u00e6gte modpart, hvorp\u00e5 opbygningen forts\u00e6tter 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\u00f8rst opretter ressourcekr\u00e6vende tilstande p\u00e5 et meget sent tidspunkt.<\/p>\n\n<h2>Teknisk fremgangsm\u00e5de: Cookie i stedet for det tidligere tilstandsanl\u00e6g<\/h2>\n\n<p>Kernen svarer p\u00e5 et <strong>SYN<\/strong> med et specielt kodet SYN\/ACK, hvis ISN er afledt af en hemmelig n\u00f8gle, TCP-optioner og tidsintervaller. Hvis der modtages et ACK med det rigtige nummer, rekonstruerer jeg sessionsparametrene ud fra ISN\u2019et og \u00e5bner socketen som normalt. Hvis svaret udebliver, opst\u00e5r der heller ingen optaget halv\u00e5ben tilstand, hvilket sk\u00e5ner hukommelse og CPU. Denne tilgang reducerer s\u00e5rbarheden i modtagelsesfasen drastisk uden at \u00e6ndre den normale proces permanent. If\u00f8lge dokumentation fra Ubuntu og Red Hat har teknikken fungeret p\u00e5lideligt i mange kernelgenerationer og tr\u00e6der f\u00f8rst i kraft, n\u00e5r k\u00f8en truer med at g\u00e5 i st\u00e5.<\/p>\n\n<h2>Aktivering og test: tcp_syncookies i praksis<\/h2>\n\n<p>Om sysctl-parameteren <strong>net.ipv4.tcp_syncookies<\/strong> Jeg styrer adf\u00e6rden: 0 = sl\u00e5et fra, 1 = kun ved overbelastning, 2 = permanent. I produktionsmilj\u00f8er indstiller jeg som regel til tilstand 1, s\u00e5 standard-handshaken forbliver intakt, og beskyttelsen f\u00f8rst tr\u00e6der i kraft, n\u00e5r det er n\u00f8dvendigt. Jeg kan hurtigt se status i shell'en, og \u00e6ndringer foretager jeg via sysctl eller permanent i \/etc\/sysctl.d\/. En relevant baggrundsartikel om socket-adf\u00e6rd og angrebsm\u00f8nstre hj\u00e6lper med at planl\u00e6gge det hele; jeg g\u00e5r n\u00e6rmere ind p\u00e5 detaljerne i indl\u00e6gget <a href=\"https:\/\/webhosting.de\/da\/syn-beskyttelse-mod-oversvommelse-socket-handtering-serverforsvar\/\">SYN-oversv\u00f8mmelsesbeskyttelse<\/a>. Jeg bruger f\u00f8lgende kommandoer regelm\u00e6ssigt:<\/p>\n\n<pre><code>Vis #-status\nsysctl net.ipv4.tcp_syncookies\n\nAktiv\u00e9r # midlertidigt (indtil genstart)\nsudo sysctl -w net.ipv4.tcp_syncookies=1\n\n# Indstil permanent\necho \"net.ipv4.tcp_syncookies = 1\" | sudo tee \/etc\/sysctl.d\/60-syncookies.conf\nsudo sysctl --system\n<\/code><\/pre>\n\n<h2>Begr\u00e6nsninger: Hvad SYN-cookies ikke kan<\/h2>\n\n<p>SYN-cookies er prim\u00e6rt rettet mod <strong>Syn-Queue<\/strong> og forhindrer, at halv\u00e5bne tilstande optager hukommelse. De har dog ingen effekt mod en overbelastet forbindelse, en overbelastet applikationslogik eller CPU-m\u00e6tning. Ved volumetriske angreb har jeg brug for opstr\u00f8msfiltre, QoS og eventuelt scrubbing. Ogs\u00e5 angreb p\u00e5 applikationsniveau, s\u00e5som HTTP-GET-oversv\u00f8mmelser, kr\u00e6ver yderligere kontroller, begr\u00e6nsninger og cacher. Jeg indlemmer derfor altid syncookies i et flerlagsforsvar, der samler netv\u00e6rks-, kerne- og serviceniveauet.<\/p>\n\n<h2>Tuning: Backlogs, k\u00f8er og gentagelser<\/h2>\n\n<p>Inden en n\u00f8dsituation opst\u00e5r, stemmer jeg <strong>Eftersl\u00e6b<\/strong> og antallet af gentagelser, s\u00e5 legitime spidsbelastninger ikke un\u00f8digt udl\u00f8ser beskyttelsestilstanden. tcp_max_syn_backlog p\u00e5virker k\u00f8en af halv\u00e5bne forbindelser, mens somaxconn bestemmer den maksimale l\u00e6ngde af acceptk\u00f8en for forbindelser, der venter p\u00e5 accept(). Med tcp_synack_retries bestemmer jeg, hvor mange gange kernen fors\u00f8ger at gentage SYN\/ACK, f\u00f8r den giver op. H\u00f8jere backlogs opfanger korte belastningsspidser, men koster hukommelse; f\u00e6rre gentagelsesfors\u00f8g frig\u00f8r slots hurtigere, men medf\u00f8rer risikoen for at ramme fjernklienter for h\u00e5rdt. Disse kompromiser tester jeg under realistisk belastning med v\u00e6rkt\u00f8jer som hping3 eller tcp_syn_flooder i et isoleret netv\u00e6rk.<\/p>\n\n<pre><code>#-kandidater til spidsbelastninger\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>Sammenligning af driftsformer: Konsekvenser og anvendelse<\/h2>\n\n<p>Til hverdagen v\u00e6lger jeg den <strong>Tilstande<\/strong> bevidst, da de p\u00e5virker diagnose, m\u00e5linger og adf\u00e6rd under pres. Permanente cookies (2) undg\u00e5r enhver tidlig tilstandsopbygning, \u00e6ndrer dog m\u00e5lev\u00e6rdier for gentagne fors\u00f8g og kan p\u00e5virke sj\u00e6ldne kanttilf\u00e6lde med TCP-indstillinger. Den adaptive tilstand (1) lader stakken k\u00f8re normalt og griber ind, n\u00e5r der er risiko for overrun. Tilstanden \u00bbslukket\u00ab (0) giver kun mening i laboratoriesituationer eller lukkede netv\u00e6rk. F\u00f8lgende tabel opsummerer dette kortfattet:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Tilstand<\/th>\n      <th>Beskrivelse af<\/th>\n      <th>Fordel<\/th>\n      <th>Mulig bivirkning<\/th>\n      <th>Eksempel<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>0<\/td>\n      <td><strong>Deaktiveret<\/strong>, ingen cookies<\/td>\n      <td>Tydelig baseline-adf\u00e6rd<\/td>\n      <td>Angriberen fylder Syn-k\u00f8en<\/td>\n      <td>Isoleret testnet<\/td>\n    <\/tr>\n    <tr>\n      <td>1<\/td>\n      <td><strong>Adaptiv<\/strong>, kun ved overl\u00f8b<\/td>\n      <td>Normalt TCP i hvile<\/td>\n      <td>Kalibrering af omskiftningspunktet<\/td>\n      <td>Offentlige tjenester<\/td>\n    <\/tr>\n    <tr>\n      <td>2<\/td>\n      <td><strong>Tvunget<\/strong>, altid aktiv<\/td>\n      <td>Tidlig aflastning<\/td>\n      <td>Analysev\u00e6rdierne \u00e6ndrer sig<\/td>\n      <td>H\u00e5rd angrebsposition<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>M\u00e5lbare effekter: forsinkelser og succesrate<\/h2>\n\n<p>Under tryk falder den <strong>Krav til hukommelse<\/strong> Dette er tydeligt ved hver forbindelsesoprettelse, da der ikke opst\u00e5r en halv\u00e5ben tilstand. Dermed holder SYN-cookies acceptfrekvensen h\u00f8j, og korte bursts for\u00e5rsager f\u00e6rre afbrydelser. Under h\u00f8j trafik observerer jeg en hurtigere genopretning, s\u00e5 snart kilden t\u00f8rrer ud. Ubuntu- og Tenable-retningslinjer anbefaler adaptiv anvendelse, s\u00e5 normale klienter fungerer u\u00e6ndret. Til regressionstests tester jeg genudsendelser, tabsprocenter og serverlatens ved overgangen til cookie-tilstand.<\/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>Yderligere beskyttelseslag: Firewall og begr\u00e6nsninger<\/h2>\n\n<p>Jeg sletter syncookies med <strong>Filterregler<\/strong> og s\u00e6tter rate limits, s\u00e5 belastningen slet ikke n\u00e5r at tr\u00e6nge ind i TCP-stakken. P\u00e5 Linux foretr\u00e6kker jeg at bruge nftables-regler til at begr\u00e6nse eller tidligt afvise overtr\u00e6dere p\u00e5 baggrund af forbindelseshastigheder. Vejledningen giver et kortfattet overblik over moderne pakkefiltre <a href=\"https:\/\/webhosting.de\/da\/netfilter-vs-nftables-moderne-linux-firewallteknologier-shield\/\">nftables vs. Netfilter<\/a>. Derudover hj\u00e6lper SYNPROXY-scenarier p\u00e5 edge-firewalls, som afbryder handshaken og kun videresender gyldige forbindelser. For udsatte porte definerer jeg strenge \u00e5bninger, logningst\u00e6rskler og et maksimalt antal forbindelsesfors\u00f8g pr. kildeadresse.<\/p>\n\n<h2>H\u00f8jtydende tilgange: XDP og lignende.<\/h2>\n\n<p>N\u00e5r volumenangreb <strong>PPS-hastighed<\/strong> For at \u00f8ge ydeevnen flytter jeg filterlogikken via XDP ud til netv\u00e6rkskanten p\u00e5 NIC\u2019en. P\u00e5 den m\u00e5de frasorterer jeg mist\u00e6nkelige SYN-pakker allerede f\u00f8r socket-laget, hvilket sparer CPU-belastning og aflaster modtagelsesk\u00f8en. En introduktion til denne teknik g\u00f8r det lettere at komme i gang med <a href=\"https:\/\/webhosting.de\/da\/xdp-hojtydende-pakkebehandling-kernehastighed\/\">XDP-pakkeh\u00e5ndtering<\/a>. I kombination med SYN-cookies opst\u00e5r der et to-trins system: f\u00f8rst en grov udv\u00e6lgelse p\u00e5 kortet, derefter en p\u00e5lidelig handshake-kontrol i kernen. Denne k\u00e6de reducerer angrebsfladen m\u00e6rkbart og sikrer, at tjenesterne forbliver tilg\u00e6ngelige.<\/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: S\u00e5dan fortolkes m\u00e5linger og logoplysninger korrekt<\/h2>\n\n<p>Ved p\u00e5faldende <strong>Timeouts<\/strong> 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 \u00f8je med meddelelser om SYN-backlog-overl\u00f8b og sammenholder dem med CPU- og IRQ-belastningen. Pakkefangster med tcpdump dokumenterer sekvensnummerlogikken og hj\u00e6lper med at identificere falske positiver. Med iptables\/nftables-t\u00e6llere m\u00e5ler jeg desuden, hvor ofte rate-limit-reglerne udl\u00f8ses.<\/p>\n\n<h2>Kompatibilitet: TCP-indstillinger og gr\u00e6nsetilf\u00e6lde<\/h2>\n\n<p>Programmering af moderne kerner <strong>Valgmuligheder<\/strong> som MSS, SACK eller Timestamp, s\u00e5 cookies transporteres p\u00e5 en m\u00e5de, der g\u00f8r det muligt at rekonstruere dem. \u00c6ldre eller us\u00e6dvanlige stakke kan udvise s\u00e6rlige egenskaber, derfor tjekker jeg kritiske stier inden implementeringen. Is\u00e6r ved proxyservere, NAT og anycast-topologier observerer jeg adf\u00e6rden grundigt. LWN.net diskuterer designdetaljer, der forklarer, hvorfor nutidige implementeringer fungerer p\u00e5lideligt. I meget specifikke scenarier forbliver den tvungne driftsform (2) et v\u00e6rkt\u00f8j, som jeg kun anvender m\u00e5lrettet.<\/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>Typiske misforst\u00e5elser: Det, jeg ofte retter<\/h2>\n\n<p>Syncookies erstatter ikke <strong>DDoS-forsvar<\/strong> i periferien; de beskytter is\u00e6r h\u00e5ndtryksfasen. Et h\u00f8jt somaxconn-tal i sig selv forhindrer ikke overl\u00f8b, hvis SYN\/ACK aldrig besvares. Ligeledes er det en fejlagtig antagelse, at permanente cookies (2) altid er det bedste valg; det g\u00e5r ud over diagnosticering og s\u00e6rlige tilf\u00e6lde. Uden overv\u00e5gning mangler jeg signaler til at justere skiftpunkter og gr\u00e6nser. Belastningstests er fortsat uundv\u00e6rlige, s\u00e5 konfigurationen og hardwaren passer til den reelle adgangsdyynamik.<\/p>\n\n<h2>Praksistjek: Trin til en holdbar antagelse<\/h2>\n\n<p>Jeg begynder med <strong>Tilstand 1<\/strong> for tcp_syncookies og verificerer indgrebspunktet under belastning. Derefter \u00f8ger jeg tcp_max_syn_backlog og somaxconn moderat, samtidig med at jeg s\u00e6nker tcp_synack_retries og m\u00e5ler succesraterne. Firewall-hastighedsbegr\u00e6nsninger og geo-\/ASN-filtre frasorterer st\u00f8j f\u00f8r stakken. Jeg gemmer XDP- eller SmartNIC-filtre til situationer med h\u00f8je PPS-niveauer, s\u00e5 jeg kan anvende ressourcerne m\u00e5lrettet. Til sidst dokumenterer jeg m\u00e5lingerne, s\u00e5 senere justeringer kan baseres p\u00e5 data.<\/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 og dual-stack: samme switch, samme logik<\/h2>\n\n<p>I dual-stack-milj\u00f8er opf\u00f8rer <strong>IPv4 og IPv6<\/strong> er konsekvent i forbindelse med cookies. Knappen <em>net.ipv4.tcp_syncookies<\/em> styrer beskyttelsen globalt for TCP, alts\u00e5 ogs\u00e5 for v6-sockets. Jeg tester derfor overgangen til cookie-tilstand p\u00e5 begge protokoller \u2013 is\u00e6r hvis upstream-enheder i IPv6 bruger andre filtreringsveje. Vigtigt: SYN-cookies beskytter udelukkende TCP. UDP-tjenester eller QUIC kr\u00e6ver egne hastighedsbegr\u00e6nsninger og edge-politik, s\u00e5 volumetrisk trafik ikke overbelaster CPU\u2019en.<\/p>\n\n<h2>Metrikker i kernen: p\u00e5lidelige indikatorer<\/h2>\n\n<p>For at sikre p\u00e5lidelig overv\u00e5gning bruger jeg kernelt\u00e6llere, der eksplicit registrerer cookies. Ud over <em>ss -s<\/em> Og for at overv\u00e5ge tilstandsfordelingerne holder jeg \u00f8je med t\u00e6llerne for sendte, modtagne og mislykkede cookies. P\u00e5 den m\u00e5de kan jeg se, om beskyttelsen virker, om legitime klienter kommer igennem, og om der er fejlkonfigurationer.<\/p>\n\n<pre><code># Oversigt\nss -s\nss -ant state syn-recv | wc -l\n\n# Cookie-t\u00e6ller (Kernel: \/proc\/net\/netstat)\ngrep -E 'Syncookies|ListenOverflows|ListenDrops' \/proc\/net\/netstat\n\n# Live-visning\nwatch -n1 'grep -E \"Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n\n# Logmeddelelser (eksempel)\n# dmesg viser bl.a.:\n# TCP: Mulig SYN-flooding p\u00e5 port 443. Sender cookies. Tjek SNMP-t\u00e6llere.\n<\/code><\/pre>\n\n<p>Stige <em>ListenOverflows<\/em> og <em>ListenDrops<\/em> sidel\u00f8bende med <em>SyncookiesSent<\/em> justerer jeg backlogs, retries og upstream-filtre. Forbliver <em>SyncookiesRecv<\/em> ... tyder det p\u00e5 rene bot-angreb; hvis derimod <em>SyncookiesFailed<\/em>, tjekker jeg NAT\/proxy-ruter og eventuelle manipulationer undervejs.<\/p>\n\n<h2>Proxyservere, load balancere og Kubernetes<\/h2>\n\n<p>P\u00e5 <strong>Proxy- og LB-k\u00e6der<\/strong> bestemmer placeringen af cookie-beskyttelsen. Hvis en L4-\/L7-load-balancer afbryder TCP-h\u00e5ndtrykket, n\u00e5r en SYN-flod slet ikke frem til backend-serverne; i s\u00e5 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\u00e5 arbejdsknudepunkterne, is\u00e6r ved NodePort- eller HostNetwork-workloads. For Ingress-controllere med eget SYN-forsvar (SYNPROXY, eBPF) tilpasser jeg politikkerne, s\u00e5 de ikke bremser hinanden. Jeg tager load balancerens sundhedstjek med i betragtning i testene, da korte testvinduer med f\u00e5 gentagelser ellers fejlagtigt kan give indtryk af ustabilitet.<\/p>\n\n<h2>Gr\u00e6nsetilf\u00e6lde i detaljer: Optioner, tidsintervaller, NAT<\/h2>\n\n<p>Cookies koder kun <strong>begr\u00e6nsede parametre<\/strong>. Moderne Linux-implementeringer rekonstruerer som regel MSS, SACK og Window Scaling p\u00e5lideligt; tidsstempler og sj\u00e6ldne indstillinger kan dog have begr\u00e6nsninger afh\u00e6ngigt af kernelniveauet. Jeg foretr\u00e6kker derfor driftsform (1), s\u00e5 standardvejen dominerer, og cookies kun tr\u00e6der i kraft ved overl\u00f8b. En cookies gyldighed er bundet til tidsintervaller \u2013 ved st\u00e6rkt asymmetriske ruter eller forsinkelsestoppe kan en legitim ACK ligge lige uden for vinduet. I WAN- og satellitscenarier m\u00e5ler jeg derfor round-trip-variansen, f\u00f8r jeg s\u00e6nker antallet af gentagne fors\u00f8g. NAT og middleboxe, der \u00e6ndrer sekvensnumre eller optioner, er yderligere kandidater til kanttilf\u00e6lde; med m\u00e5lrettede datafangster dokumenterer jeg, hvor bits g\u00e5r tabt.<\/p>\n\n<h2>ACK-\/RST-floods og varianter ud over SYN-stormen<\/h2>\n\n<p>Ikke alle <strong>Transportangreb<\/strong> er en ren SYN-flood. ACK- eller RST-floods er rettet mod CPU\u2019en og pakkeruterne uden at udl\u00f8se handshaken \u2013 cookies hj\u00e6lper n\u00e6sten ikke her. Jeg bruger i s\u00e5 fald tidlige filtre (nftables\/XDP) med tilstandslogik eller minimal begr\u00e6nsning af ACK-frekvensen. Is\u00e6r RST-b\u00f8lger mod etablerede forbindelser afbryder jeg ved hj\u00e6lp af et regels\u00e6t, der afviser uventede RST'er uden et passende vindue. Ogs\u00e5 halvt \u00e5bne gentagelser (SYN med spoofing plus sene ACK'er) d\u00e6kker jeg via hastighedsbegr\u00e6nsninger pr. kildenetv\u00e6rksomr\u00e5de.<\/p>\n\n<h2>Yderligere finjustering: Liste-\/acceptk\u00f8er og hurtige fejl<\/h2>\n\n<p>Ud over de klassiske parametre bruger jeg supplerende kontakter, der pr\u00e6ger adf\u00e6rden i gr\u00e6nseomr\u00e5det:<\/p>\n\n<ul>\n  <li><strong>Backlog vs. somaxconn<\/strong>: V\u00e6rdien i <em>lister (backlog)<\/em> pr. proces bestemmes af <em>net.core.somaxconn<\/em> begr\u00e6nset. Jeg s\u00f8rger for, at serversoftwaren og kernen fungerer i harmoni, ellers g\u00e5r optimeringerne til spilde.<\/li>\n  <li><strong>tcp_abort_on_overflow<\/strong>: Om foresp\u00f8rgslerne, n\u00e5r Accept-k\u00f8en er fuld, enten droppes uden varsel eller besvares aktivt med RST. I API\u2019er med h\u00f8j trafik kan en hurtig fejl give klienten mulighed for hurtigt at fors\u00f8ge igen; for TLS- eller \u00e6ldre klienter foretr\u00e6kker jeg som regel standarddropping.<\/li>\n  <li><strong>H\u00e5ndtering af Port- og TIME-WAIT-tilstande<\/strong>: Cookies forhindrer ikke <em>Ephemeral-port-flaskehals<\/em>. Jeg planl\u00e6gger <em>ip_local_port_range<\/em> V\u00e6r gener\u00f8s, og brug TIME-WAIT-optimeringer med omtanke, s\u00e5 Reuse ikke f\u00f8rer til Heisenbugs.<\/li>\n  <li><strong>SO_REUSEPORT<\/strong>: Flere Accept-k\u00f8er pr. port fordeler belastningen p\u00e5 tv\u00e6rs af worker-processerne og mindsker overbelastning p\u00e5 de enkelte CPU\u2019er.<\/li>\n<\/ul>\n\n<h2>Testmetoder: reproducerbare og p\u00e5lidelige<\/h2>\n\n<p>Jeg simulerer belastning, der ligger t\u00e6t p\u00e5 virkelige scenarier, og m\u00e5ler skiftetidspunktet til cookie-tilstand, succesraten for legitime forbindelser samt genopretningstiden efter belastningstoppen. I den forbindelse kombinerer jeg syntetiske SYN-floder med reelle applikationsanmodninger.<\/p>\n\n<pre><code>Generer #-flood (laboratorium!)\nsudo hping3 -S -p 443 --flood --rand-source \n\nVarier #-netv\u00e6rksforholdene\nsudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%\n\n# Bland legitim trafik\nwrk -t8 -c512 -d60s https:\/\/\/\n\n# Parallel overv\u00e5gning\nwatch -n1 'ss -s; echo; grep -E \"Syncookies|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n<\/code><\/pre>\n\n<p>Ved hj\u00e6lp af disse trin kan jeg se, om antallet af gentagne fors\u00f8g falder for kraftigt, om upstream-firewalls fejlagtigt filtrerer tidsstempler, eller om acceptk\u00f8erne hos enkelte arbejdere l\u00f8ber over i uforholdsm\u00e6ssigt stort omfang. Jeg dokumenterer n\u00f8gletallene (tiln\u00e6rmelse til 100%-succesrate for legitime forbindelser, cookie-hitrate, latenstidsadf\u00e6rd) for senere at kunne foretage justeringer p\u00e5 baggrund af data.<\/p>\n\n<h2>Drift og vedligeholdelse: Sikring af stabilitet gennem hele levetiden<\/h2>\n\n<p>I kontinuerlig drift planl\u00e6gger jeg <strong>Hemmelig rotation<\/strong> (automatisk p\u00e5 kernelsiden) og observerer, om skift mellem tidsslots har synlige effekter p\u00e5 str\u00e6kninger med meget lang RTT. Jeg holder kernelen og driverne opdaterede, s\u00e5 forbedringer i cookie-implementeringen (bedre kodning af indstillinger, robuste tidsslots) kommer til udtryk. Til auditform\u00e5l noterer jeg, hvorn\u00e5r beskyttelsestilstanden tr\u00e5dte i kraft, hvor mange forbindelser den lod passere, og om der blev aktiveret yderligere filtre. Ved \u00e6ndringer af MTU, offloading eller NF-stacks (f.eks. nye nftables-s\u00e6t) gentager jeg kortvarige tests, s\u00e5 jeg tidligt kan opdage eventuelle interaktionsfejl.<\/p>\n\n<h2>Forkortet version til dem, der har travlt<\/h2>\n\n<p>SYN-cookies gemmer <strong>H\u00e5ndtryksbelastning<\/strong> lille ved f\u00f8rst at oprette tilstande efter en bekr\u00e6ftet ACK og dermed beskytte Syn-k\u00f8en mod overbelastning. Jeg aktiverer tilstand 1, finjusterer backlogs og retries omhyggeligt og m\u00e5ler effekterne med klare m\u00e5lepunkter. Yderligere lag som nftables-rate-limits, SYNPROXY og XDP bremser trafikken allerede f\u00f8r TCP-stakken. Alt i alt sikrer jeg p\u00e5 denne m\u00e5de web-, mail-, VPN- og API-tjenester mod SYN-floods uden at ulempe almindelige klienter. Den, der konsekvent implementerer disse trin, styrker tilg\u00e6ngeligheden og reducerer nedbrud m\u00e6rkbart under angrebsbelastning.<\/p>","protected":false},"excerpt":{"rendered":"<p>TCP SYN-cookies yder p\u00e5lidelig beskyttelse mod SYN-flood-angreb i Linux-kernen. L\u00e6r, hvordan mekanismen fungerer, og hvordan du konfigurerer den.<\/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":"121","_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\/da\/wp-json\/wp\/v2\/posts\/20882","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=20882"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20882\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20875"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20882"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20882"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20882"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}