{"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-skydd-mot-syn-oeversvaemning-kaernan","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/tcp-syn-cookies-schutz-syn-flood-kernel\/","title":{"rendered":"TCP SYN-cookies i Linux-k\u00e4rnan: Skydd mot SYN-\u00f6versv\u00e4mningar"},"content":{"rendered":"<p><strong>TCP SYN-cookies<\/strong> I Linux-k\u00e4rnan h\u00e5ller handskakningsbelastningen l\u00e5g genom att kryptografiskt koda tillst\u00e5ndsinformation i Initial Sequence Number och f\u00f6rst uppr\u00e4tta en fullst\u00e4ndig anslutning vid ett giltigt ACK. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rhindrar jag att SYN-\u00f6versv\u00e4mningar \u00f6verbelastar k\u00f6n med halv\u00f6ppna anslutningar och blockerar legitima klienter.<\/p>\n\n<h2>Centrala punkter<\/h2>\n\n<ul>\n  <li><strong>Funktionalitet<\/strong>: Cookie i ISN, status f\u00f6rst efter ACK<\/li>\n  <li><strong>Linux-styrning<\/strong>: net.ipv4.tcp_syncookies med l\u00e4gena 0\/1\/2<\/li>\n  <li><strong>F\u00f6rm\u00e5n<\/strong>: l\u00e5gt lagringsbehov vid attackbelastning<\/li>\n  <li><strong>Gr\u00e4nser<\/strong>: hj\u00e4lper inte mot bandbredds- eller app-attacker<\/li>\n  <li><strong>Tuning<\/strong>: St\u00e4ll in v\u00e4rdena f\u00f6r backlog och retry noggrant<\/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>Hur SYN-floods bromsar upp TCP-handskakningen<\/h2>\n\n<p>En angripare \u00f6verbelastar servern med <strong>SYN-paket<\/strong> och ignorerar de efterf\u00f6ljande SYN\/ACK-svaren, vilket leder till att halv\u00f6ppna poster tar upp plats i SYN-k\u00f6n. Jag m\u00e4rker d\u00e5 att nya, legitima f\u00f6rfr\u00e5gningar inte f\u00e5r plats och att tids\u00f6verskridanden blir allt vanligare. Det \u00e4r just h\u00e4r som <strong>Syncookies<\/strong> an: K\u00e4rnan lagrar inledningsvis ingen anslutningsstatus och \u00f6verf\u00f6r n\u00f6dv\u00e4ndiga data till sekvensnumret. F\u00f6rst ett korrekt ACK bekr\u00e4ftar att det finns en verklig motpart, varp\u00e5 uppkopplingen forts\u00e4tter som vanligt. LWN.net och TUM-dokumentationen beskriver denna princip som ett etablerat, effektivt skydd mot handskakningsattacker utan h\u00f6g minnesanv\u00e4ndning. Denna arkitektur g\u00f6r att servern f\u00f6rblir mottaglig \u00e4ven vid h\u00f6g trafikbelastning, eftersom den f\u00f6rst mycket sent skapar resurskr\u00e4vande tillst\u00e5nd.<\/p>\n\n<h2>Teknisk process: Cookie ist\u00e4llet f\u00f6r det tidigare tillst\u00e5ndssystemet<\/h2>\n\n<p>K\u00e4rnan svarar p\u00e5 ett <strong>SYN<\/strong> med ett s\u00e4rskilt kodat SYN\/ACK, vars ISN h\u00e4rleds fr\u00e5n en hemlig nyckel, TCP-alternativ och tidsintervall. Om ett ACK med r\u00e4tt nummer anl\u00e4nder rekonstruerar jag sessionsparametrarna utifr\u00e5n ISN och \u00f6ppnar socketen p\u00e5 vanligt s\u00e4tt. Om svaret uteblir finns det inte heller n\u00e5got upptaget halv\u00f6ppet tillst\u00e5nd, vilket sparar p\u00e5 minne och CPU. Denna metod minskar s\u00e5rbarheten i mottagningsfasen drastiskt utan att permanent \u00e4ndra den vanliga v\u00e4gen. Enligt dokumentation fr\u00e5n Ubuntu och Red Hat har tekniken fungerat tillf\u00f6rlitligt i m\u00e5nga generationer av k\u00e4rnan och tr\u00e4der i kraft f\u00f6rst n\u00e4r k\u00f6n hotar att \u00f6verbelastas.<\/p>\n\n<h2>Aktivera och testa: tcp_syncookies i praktiken<\/h2>\n\n<p>Om sysctl-flaggan <strong>net.ipv4.tcp_syncookies<\/strong> Jag styr beteendet: 0 = av, 1 = endast vid \u00f6verbelastning, 2 = permanent. I produktionsmilj\u00f6er st\u00e4ller jag oftast in l\u00e4ge 1, s\u00e5 att standardhandshaken f\u00f6rblir intakt och skyddet aktiveras f\u00f6rst vid behov. Jag kan snabbt se statusen i shellen och g\u00f6r \u00e4ndringar via sysctl eller permanent i \/etc\/sysctl.d\/. En l\u00e4mplig bakgrundsartikel om socketbeteende och attackm\u00f6nster underl\u00e4ttar planeringen av det hela; jag g\u00e5r in p\u00e5 detaljerna i inl\u00e4gget <a href=\"https:\/\/webhosting.de\/sv\/syn-oeversvaemningsskydd-uttagshantering-serverfoersvar\/\">SYN \u00f6versv\u00e4mningsskydd<\/a>. F\u00f6ljande kommandon anv\u00e4nder jag regelbundet:<\/p>\n\n<pre><code># Visa status\nsysctl net.ipv4.tcp_syncookies\n\n# Aktivera tillf\u00e4lligt (tills omstart)\nsudo sysctl -w net.ipv4.tcp_syncookies=1\n\n# St\u00e4ll in 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\u00e4nsningar: Vad SYN-cookies inte klarar av<\/h2>\n\n<p>SYN-cookies riktar sig fr\u00e4mst till <strong>Syn-Queue<\/strong> och f\u00f6rhindrar att halv\u00f6ppna tillst\u00e5nd tar upp minnesutrymme. De har dock ingen effekt mot en \u00f6verbelastad anslutning, en \u00f6verbelastad applikationslogik eller CPU-m\u00e4ttnad. Vid volymetriska attacker beh\u00f6ver jag uppstr\u00f6msfilter, QoS och vid behov scrubbing. \u00c4ven attacker p\u00e5 applikationsniv\u00e5, s\u00e5som HTTP-GET-\u00f6versv\u00e4mningar, kr\u00e4ver ytterligare kontroller, begr\u00e4nsningar och cacher. Jag integrerar d\u00e4rf\u00f6r alltid syncookies i ett flerstegsf\u00f6rsvar som f\u00f6renar n\u00e4tverks-, k\u00e4rn- och tj\u00e4nsteniv\u00e5erna.<\/p>\n\n<h2>Tuning: Eftersl\u00e4pningar, k\u00f6er och nya f\u00f6rs\u00f6k<\/h2>\n\n<p>Innan en n\u00f6dsituation intr\u00e4ffar, g\u00f6r jag f\u00f6ljande: <strong>Eftersl\u00e4pningar<\/strong> och antalet f\u00f6rs\u00f6k, s\u00e5 att legitima toppar inte utl\u00f6ser skyddsl\u00e4get i on\u00f6dan. tcp_max_syn_backlog p\u00e5verkar k\u00f6n med halv\u00f6ppna anslutningar, medan somaxconn p\u00e5verkar den maximala l\u00e4ngden p\u00e5 k\u00f6n f\u00f6r anslutningar som v\u00e4ntar p\u00e5 accept(). Med tcp_synack_retries best\u00e4mmer jag hur m\u00e5nga g\u00e5nger k\u00e4rnan f\u00f6rs\u00f6ker skicka ett SYN\/ACK innan den ger upp. H\u00f6gre backloggar hanterar korta belastningstoppar, men tar upp minne; f\u00e4rre f\u00f6rs\u00f6k frig\u00f6r platser tidigare, men medf\u00f6r risken att avbrutna klienter drabbas f\u00f6r h\u00e5rt. Dessa avv\u00e4gningar testar jag under realistisk belastning med verktyg som hping3 eller tcp_syn_flooder i ett isolerat n\u00e4tverk.<\/p>\n\n<pre><code>#-kandidater f\u00f6r belastningstoppar\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>J\u00e4mf\u00f6relse av driftsl\u00e4gen: Effekter och anv\u00e4ndningsomr\u00e5den<\/h2>\n\n<p>Till vardags v\u00e4ljer jag <strong>L\u00e4gen<\/strong> medvetet, eftersom de p\u00e5verkar diagnos, m\u00e4tv\u00e4rden och beteende under press. Permanenta cookies (2) undviker all tidig tillst\u00e5ndsinst\u00e4llning, men f\u00f6r\u00e4ndrar m\u00e4tv\u00e4rden f\u00f6r omf\u00f6rs\u00f6k och kan p\u00e5verka s\u00e4llsynta gr\u00e4nsfall med TCP-alternativ. Det adaptiva l\u00e4get (1) l\u00e5ter stacken k\u00f6ras normalt och ingriper vid risk f\u00f6r \u00f6verbelastning. L\u00e4get \u201dav\u201d (0) \u00e4r endast meningsfullt i laboratoriesituationer eller slutna n\u00e4tverk. F\u00f6ljande tabell sammanfattar detta kortfattat:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>L\u00e4ge<\/th>\n      <th>Beskrivning av<\/th>\n      <th>F\u00f6rdel<\/th>\n      <th>M\u00f6jlig biverkning<\/th>\n      <th>Exempel<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>0<\/td>\n      <td><strong>Inaktiverad<\/strong>, inga cookies<\/td>\n      <td>Tydligt beteende vid baslinjen<\/td>\n      <td>Angriparen fyller Syn-k\u00f6en<\/td>\n      <td>Isolerat testn\u00e4t<\/td>\n    <\/tr>\n    <tr>\n      <td>1<\/td>\n      <td><strong>Adaptiv<\/strong>, endast vid \u00f6verfl\u00f6d<\/td>\n      <td>Vanlig TCP vid inaktivitet<\/td>\n      <td>Kalibrera omkopplingspunkten<\/td>\n      <td>Offentliga tj\u00e4nster<\/td>\n    <\/tr>\n    <tr>\n      <td>2<\/td>\n      <td><strong>Tvingad<\/strong>, alltid aktiv<\/td>\n      <td>Tidigt avlastning<\/td>\n      <td>Analysv\u00e4rdena f\u00f6r\u00e4ndras<\/td>\n      <td>Sv\u00e5r anfallsposition<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>M\u00e4tbara effekter: f\u00f6rdr\u00f6jningar och framg\u00e5ngsgrad<\/h2>\n\n<p>Under tryck sjunker <strong>Krav p\u00e5 minne<\/strong> Detta m\u00e4rks tydligt vid varje anslutning, eftersom det inte uppst\u00e5r n\u00e5got halv\u00f6ppet tillst\u00e5nd. D\u00e4rmed h\u00e5ller SYN-cookies godtagandegraden h\u00f6g, och korta datastr\u00f6mmar orsakar f\u00e4rre avbrott. Jag observerar en snabbare \u00e5terh\u00e4mtning vid h\u00f6g trafik s\u00e5 snart k\u00e4llan sinar. Riktlinjerna fr\u00e5n Ubuntu och Tenable rekommenderar en adaptiv anv\u00e4ndning s\u00e5 att vanliga klienter forts\u00e4tter att fungera som vanligt. F\u00f6r regressionstester kontrollerar jag \u00e5teruts\u00e4ndningar, bortfallsfrekvenser och serverns latens vid \u00f6verg\u00e5ngen till cookie-l\u00e4ge.<\/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>Ytterligare skyddslager: brandv\u00e4gg och begr\u00e4nsningar<\/h2>\n\n<p>Jag l\u00f6ser syncookies med <strong>Filterregler<\/strong> och s\u00e4tter gr\u00e4nser f\u00f6r \u00f6verf\u00f6ringshastigheten s\u00e5 att belastningen inte ens n\u00e5r TCP-stacken. P\u00e5 Linux anv\u00e4nder jag helst nftables-regler f\u00f6r att strypa eller tidigt avvisa st\u00f6rande trafik utifr\u00e5n anslutningshastigheten. En kortfattad \u00f6versikt \u00f6ver moderna paketfilter finns i handledningen <a href=\"https:\/\/webhosting.de\/sv\/netfilter-vs-nftables-moderna-brandvaeggstekniker-foer-linux-skydd\/\">nftables j\u00e4mf\u00f6rt med Netfilter<\/a>. Som komplement anv\u00e4nds SYNPROXY-scenarier p\u00e5 edge-brandv\u00e4ggar, som avbryter handskakningen och endast sl\u00e4pper igenom giltiga anslutningar. F\u00f6r utsatta portar definierar jag strikta \u00f6ppningar, loggningstr\u00f6sklar och maximalt antal anslutningsf\u00f6rs\u00f6k per k\u00e4lladress.<\/p>\n\n<h2>H\u00f6gpresterande metoder: XDP och liknande.<\/h2>\n\n<p>N\u00e4r volymattacker <strong>PPS-frekvens<\/strong> F\u00f6r att \u00f6ka prestandan flyttar jag filterlogiken via XDP till n\u00e4tverksgr\u00e4nsen p\u00e5 n\u00e4tverkskortet. P\u00e5 s\u00e5 s\u00e4tt avvisar jag misst\u00e4nkta SYN-paket redan f\u00f6re socket-lagret, vilket minskar CPU-belastningen och avlastar mottagningsk\u00f6n. En introduktion till denna teknik underl\u00e4ttar insteg i <a href=\"https:\/\/webhosting.de\/sv\/xdp-hoegpresterande-paketbehandling-kaernhastighet\/\">XDP-paketbehandling<\/a>. I kombination med SYN-cookies skapas ett tv\u00e5stegssystem: f\u00f6rst en grov gallring p\u00e5 kortet, sedan en tillf\u00f6rlitlig handskakningskontroll i k\u00e4rnan. Denna kedja minskar attackytan m\u00e4rkbart och h\u00e5ller tj\u00e4nsterna tillg\u00e4ngliga.<\/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>Diagnos: Att tolka m\u00e4tv\u00e4rden och loggmeddelanden p\u00e5 r\u00e4tt s\u00e4tt<\/h2>\n\n<p>Vid p\u00e5fallande <strong>Tidsfrister<\/strong> kontrollerar jag netstat\/ss-statistiken, dmesg-meddelanden och Grafana-paneler med anslutningshastigheter. En \u00f6kande andel SYN-RECV, h\u00f6ga siffror f\u00f6r \u00e5teruts\u00e4ndningar och bortfall indikerar \u00f6verg\u00e5ngen till skyddsl\u00e4get. Jag h\u00e5ller utkik efter meddelanden om SYN-backlog-\u00f6verfl\u00f6d och korrelerar dem med CPU- och IRQ-belastningen. Paketavlyssningar med tcpdump bekr\u00e4ftar logiken bakom sekvensnumren och hj\u00e4lper till att identifiera falska positiva resultat. Med iptables\/nftables-r\u00e4knare m\u00e4ter jag dessutom tr\u00e4fffrekvensen f\u00f6r hastighetsbegr\u00e4nsningsreglerna.<\/p>\n\n<h2>Kompatibilitet: TCP-alternativ och gr\u00e4nsfall<\/h2>\n\n<p>Programmera moderna k\u00e4rnor <strong>Alternativ<\/strong> som MSS, SACK eller Timestamp, s\u00e5 att cookies \u00f6verf\u00f6rs p\u00e5 ett s\u00e4tt som g\u00f6r det m\u00f6jligt att rekonstruera dem. \u00c4ldre eller ovanliga stackar kan uppvisa s\u00e4rdrag, d\u00e4rf\u00f6r kontrollerar jag kritiska v\u00e4gar innan lanseringen. S\u00e4rskilt n\u00e4r det g\u00e4ller proxyservrar, NAT och anycast-topologier observerar jag beteendet noggrant. LWN.net diskuterar designdetaljer som f\u00f6rklarar varf\u00f6r dagens implementeringar fungerar tillf\u00f6rlitligt. I mycket speciella scenarier f\u00f6rblir den tvingade driftsl\u00e4get (2) ett verktyg som jag endast anv\u00e4nder i specifika fall.<\/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>Vanliga missuppfattningar: Vad jag ofta r\u00e4ttar till<\/h2>\n\n<p>Syncookies ers\u00e4tter inte <strong>DDoS-f\u00f6rsvar<\/strong> i periferin; de skyddar framf\u00f6r allt handskakningsfasen. Ett h\u00f6gt somaxconn-v\u00e4rde i sig f\u00f6rhindrar inte \u00f6verfl\u00f6d om SYN\/ACK aldrig besvaras. Likas\u00e5 \u00e4r det en felaktig antagande att permanenta cookies (2) alltid \u00e4r det b\u00e4sta valet; diagnostik och specialfall drabbas av detta. Utan \u00f6vervakning saknar jag signaler f\u00f6r att justera omkopplingspunkter och gr\u00e4nsv\u00e4rden. Belastningstester f\u00f6rblir oumb\u00e4rliga f\u00f6r att konfigurationen och h\u00e5rdvaran ska passa den verkliga \u00e5tkomstdynamiken.<\/p>\n\n<h2>Praktisk genomg\u00e5ng: Steg mot en h\u00e5llbar antagning<\/h2>\n\n<p>Jag b\u00f6rjar med <strong>L\u00e4ge 1<\/strong> f\u00f6r tcp_syncookies och verifierar ing\u00e5ngspunkten under belastning. D\u00e4refter h\u00f6jer jag tcp_max_syn_backlog och somaxconn m\u00e5ttligt, samtidigt som jag s\u00e4nker tcp_synack_retries och m\u00e4ter framg\u00e5ngsgraden. Brandv\u00e4ggens hastighetsbegr\u00e4nsningar och geo-\/ASN-filter filtrerar bort brus f\u00f6re stacken. Jag sparar XDP- eller SmartNIC-filter till situationer med h\u00f6ga PPS-niv\u00e5er, s\u00e5 att jag kan anv\u00e4nda resurserna p\u00e5 ett m\u00e5linriktat s\u00e4tt. Avslutningsvis dokumenterar jag m\u00e4tv\u00e4rdena s\u00e5 att senare justeringar kan baseras 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 och dual-stack: samma switch, samma logik<\/h2>\n\n<p>I dual-stack-milj\u00f6er beter sig <strong>IPv4 och IPv6<\/strong> \u00e4r konsekvent i samband med cookies. Knappen <em>net.ipv4.tcp_syncookies<\/em> styr skyddet globalt f\u00f6r TCP, allts\u00e5 \u00e4ven f\u00f6r v6-socklar. Jag testar d\u00e4rf\u00f6r \u00f6verg\u00e5ngen till cookie-l\u00e4get p\u00e5 b\u00e5da protokollen \u2013 s\u00e4rskilt n\u00e4r uppstr\u00f6msenheter i IPv6 anv\u00e4nder andra filterv\u00e4gar. Viktigt: SYN-cookies skyddar endast TCP. UDP-tj\u00e4nster eller QUIC kr\u00e4ver egna hastighetsbegr\u00e4nsningar och edge-policyer f\u00f6r att volymm\u00e4ssig trafik inte ska \u00f6verbelasta CPU:n.<\/p>\n\n<h2>M\u00e4tv\u00e4rden i k\u00e4rnan: tillf\u00f6rlitliga indikatorer<\/h2>\n\n<p>F\u00f6r en tillf\u00f6rlitlig \u00f6vervakning anv\u00e4nder jag k\u00e4rnr\u00e4knare som uttryckligen redovisar cookies. F\u00f6rutom <em>ss -s<\/em> N\u00e4r det g\u00e4ller tillst\u00e5ndsf\u00f6rdelningar \u00f6vervakar jag r\u00e4knarna f\u00f6r skickade, mottagna och misslyckade cookies. P\u00e5 s\u00e5 s\u00e4tt kan jag se om skyddet fungerar, om legitima klienter kommer igenom och om det finns felkonfigurationer.<\/p>\n\n<pre><code># \u00d6versikt\nss -s\nss -ant state syn-recv | wc -l\n\n# Cookie-r\u00e4knare (K\u00e4rnan: \/proc\/net\/netstat)\ngrep -E 'Syncookies|ListenOverflows|ListenDrops' \/proc\/net\/netstat\n\n# Live-vy\nwatch -n1 'grep -E \"Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n\n# Loggmeddelanden (exempel)\n# dmesg visar bland annat:\n# TCP: M\u00f6jlig SYN-\u00f6versv\u00e4mning p\u00e5 port 443. Skickar cookies. Kontrollera SNMP-r\u00e4knare.\n<\/code><\/pre>\n\n<p>Stiga <em>Lista \u00f6verfl\u00f6den<\/em> och <em>ListenDrops<\/em> parallellt med <em>SyncookiesSent<\/em> justerar jag backloggar, omf\u00f6rs\u00f6k och uppstr\u00f6msfilter. Kvarst\u00e5r <em>SyncookiesRecv<\/em> ... tyder det p\u00e5 rena bot-\u00f6versv\u00e4mningar; om det d\u00e4remot blir allt vanligare <em>Syncookies misslyckades<\/em>, kontrollerar jag NAT-\/proxyrutter och eventuella manipulationer l\u00e4ngs v\u00e4gen.<\/p>\n\n<h2>Proxyservrar, lastbalanserare och Kubernetes<\/h2>\n\n<p>P\u00e5 <strong>Proxy- och lastbalanseringskedjor<\/strong> avg\u00f6r placeringen av cookieskyddet. Om en L4-\/L7-lastbalanserare avbryter TCP-handskakningen n\u00e5r en SYN-flod inte alls backend-noderna; i s\u00e5 fall aktiverar jag cookies vid kanten. Om lastbalanseraren endast arbetar passivt (DSR, ECMP) m\u00e5ste backend-noderna skydda sig sj\u00e4lva. I Kubernetes anpassar jag sysctl-inst\u00e4llningarna p\u00e5 arbetarnoderna, s\u00e4rskilt f\u00f6r arbetsbelastningar via NodePort eller HostNetwork. F\u00f6r Ingress-kontroller med eget SYN-skydd (SYNPROXY, eBPF) justerar jag policyerna s\u00e5 att de inte h\u00e4mmar varandra. Jag tar h\u00e4nsyn till lastbalanserarens h\u00e4lsokontroller i testerna, eftersom korta testf\u00f6nster med f\u00e5 omf\u00f6rs\u00f6k annars felaktigt ger intryck av instabilitet.<\/p>\n\n<h2>Gr\u00e4nsfall i detalj: optioner, tidsintervall, NAT<\/h2>\n\n<p>Cookies kodar endast <strong>begr\u00e4nsade parametrar<\/strong>. Moderna Linux-implementeringar \u00e5terger vanligtvis MSS, SACK och Window Scaling p\u00e5 ett tillf\u00f6rlitligt s\u00e4tt; tidsst\u00e4mplar och s\u00e4llsynta alternativ kan dock ha begr\u00e4nsningar beroende p\u00e5 k\u00e4rnversion. Jag f\u00f6redrar d\u00e4rf\u00f6r driftsl\u00e4ge (1), s\u00e5 att standardv\u00e4gen dominerar och cookies endast tr\u00e4der i kraft vid \u00f6verfl\u00f6d. En cookies giltighet \u00e4r bunden till tidsintervall \u2013 vid starkt asymmetriska f\u00f6rlopp eller f\u00f6rdr\u00f6jningstoppar kan en legitim ACK hamna precis utanf\u00f6r f\u00f6nstret. I WAN- och satellitscenarier m\u00e4ter jag d\u00e4rf\u00f6r rundresans varians innan jag s\u00e4nker antalet omf\u00f6rs\u00f6k. NAT och mellanliggande enheter som manipulerar sekvensnummer eller alternativ \u00e4r ytterligare kandidater f\u00f6r gr\u00e4nsfall; med riktade avlyssningar bevisar jag var bitar g\u00e5r f\u00f6rlorade.<\/p>\n\n<h2>ACK-\/RST-\u00f6versv\u00e4mningar och varianter bortom SYN-stormen<\/h2>\n\n<p>Inte alla <strong>Transportattack<\/strong> \u00e4r en ren SYN-\u00f6versv\u00e4mning. ACK- eller RST-\u00f6versv\u00e4mningar riktar sig mot CPU:n och paketv\u00e4garna utan att utl\u00f6sa handskakningen \u2013 cookies hj\u00e4lper knappt h\u00e4r. Jag anv\u00e4nder d\u00e5 tidiga filter (nftables\/XDP) med tillst\u00e5ndslogik eller minimal begr\u00e4nsning av ACK-hastigheten. S\u00e4rskilt RST-v\u00e5gor mot etablerade anslutningar avbryter jag med hj\u00e4lp av ett regelverk som avvisar ov\u00e4ntade RST:er utan passande f\u00f6nster. \u00c4ven halv\u00f6ppna upprepningar (SYN med spoofing plus sena ACK:ar) hanterar jag genom hastighetsbegr\u00e4nsningar per k\u00e4lln\u00e4tverksomr\u00e5de.<\/p>\n\n<h2>Ytterligare finjustering: Lista-\/godk\u00e4nnandek\u00f6er och snabba fel<\/h2>\n\n<p>F\u00f6rutom de klassiska parametrarna anv\u00e4nder jag kompletterande reglage som p\u00e5verkar beteendet i gr\u00e4nsomr\u00e5det:<\/p>\n\n<ul>\n  <li><strong>Backlog j\u00e4mf\u00f6rt med somaxconn<\/strong>: V\u00e4rdet i <em>listor (backlog)<\/em> per process best\u00e4ms av <em>net.core.somaxconn<\/em> begr\u00e4nsad. Jag ser till att serverprogramvaran och k\u00e4rnan fungerar i samklang, annars g\u00e5r optimeringarna till spillo.<\/li>\n  <li><strong>tcp_abort_on_overflow<\/strong>: Om f\u00f6rfr\u00e5gningar tyst avvisas n\u00e4r Accept-k\u00f6n \u00e4r full eller om man aktivt svarar med RST. I API:er med h\u00f6g trafik kan ett snabbt fel g\u00f6ra det m\u00f6jligt f\u00f6r klienten att snabbt g\u00f6ra ett nytt f\u00f6rs\u00f6k; n\u00e4r det g\u00e4ller TLS- eller \u00e4ldre klienter f\u00f6redrar jag oftast standardavvisningen.<\/li>\n  <li><strong>Hantering av portar och TIME-WAIT<\/strong>: Cookies f\u00f6rhindrar inte <em>Flaskhals i efem\u00e4ra portar<\/em>. Jag planerar <em>ip_lokal_port_intervall<\/em> Var gener\u00f6s och anv\u00e4nd TIME-WAIT-optimeringar med omd\u00f6me, s\u00e5 att \u00e5teranv\u00e4ndning inte leder till Heisenbugs.<\/li>\n  <li><strong>SO_REUSEPORT<\/strong>: Flera Accept-k\u00f6er per port f\u00f6rdelar belastningen j\u00e4mnt \u00f6ver arbetsprocesserna och minskar \u00f6verbelastningen p\u00e5 enskilda CPU:er.<\/li>\n<\/ul>\n\n<h2>Testmetoder: reproducerbara och tillf\u00f6rlitliga<\/h2>\n\n<p>Jag simulerar belastning som efterliknar verkliga scenarier och m\u00e4ter \u00f6verg\u00e5ngspunkten till cookie-l\u00e4ge, andelen lyckade giltiga anslutningar samt \u00e5terh\u00e4mtningstiden efter belastningstoppen. I detta sammanhang kombinerar jag syntetiska SYN-fl\u00f6den med verkliga applikationsf\u00f6rfr\u00e5gningar.<\/p>\n\n<pre><code>Skapa #-flod (laboratorium!)\nsudo hping3 -S -p 443 --flood --rand-source \n\nVariera n\u00e4tverksf\u00f6rh\u00e5llandena f\u00f6r #\nsudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%\n\n# Blanda in legitim trafik\nwrk -t8 -c512 -d60s https:\/\/\/\n\n# Parallell \u00f6vervakning\nwatch -n1 'ss -s; echo; grep -E \"Syncookies|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n<\/code><\/pre>\n\n<p>Med dessa steg kan jag avg\u00f6ra om antalet f\u00f6rs\u00f6k minskar f\u00f6r kraftigt, om uppstr\u00f6msbrandv\u00e4ggar felaktigt filtrerar bort tidsst\u00e4mplar eller om acceptk\u00f6erna hos enskilda arbetare \u00f6verbelastas oproportionerligt. Jag dokumenterar nyckeltalen (n\u00e4rma sig 100%-framg\u00e5ngsfrekvens f\u00f6r legitima anslutningar, tr\u00e4fffrekvens f\u00f6r cookies, latensbeteende) f\u00f6r att senare kunna g\u00f6ra justeringar baserade p\u00e5 data.<\/p>\n\n<h2>Drift och underh\u00e5ll: S\u00e4kerst\u00e4lla stabilitet under hela driftsperioden<\/h2>\n\n<p>Vid kontinuerlig drift planerar jag <strong>Hemlig rotation<\/strong> (Automatiskt p\u00e5 kernelniv\u00e5) och observerar om byten av tidsluckor har m\u00e4rkbara effekter p\u00e5 str\u00e4ckor med mycket l\u00e5ng RTT. Jag h\u00e5ller k\u00e4rnan och drivrutinerna uppdaterade s\u00e5 att f\u00f6rb\u00e4ttringar i cookie-implementeringen (b\u00e4ttre kodning av alternativ, robusta tidsluckor) f\u00e5r effekt. Vid granskningar noterar jag n\u00e4r skyddsl\u00e4get aktiverades, hur m\u00e5nga anslutningar det sl\u00e4ppte igenom och om ytterligare filter aktiverades. Vid \u00e4ndringar av MTU, avlastning eller NF-stackar (t.ex. nya nftables-upps\u00e4ttningar) upprepar jag korttester f\u00f6r att tidigt uppt\u00e4cka felaktiga interaktioner.<\/p>\n\n<h2>F\u00f6rkortad version f\u00f6r den som har br\u00e5ttom<\/h2>\n\n<p>SYN-cookies lagrar <strong>Handshake-belastning<\/strong> liten genom att skapa tillst\u00e5nd f\u00f6rst efter en bekr\u00e4ftad ACK och p\u00e5 s\u00e5 s\u00e4tt skydda Syn-k\u00f6n mot \u00f6versv\u00e4mningar. Jag aktiverar l\u00e4ge 1, finjusterar backlogs och retries f\u00f6rsiktigt och m\u00e4ter effekterna med tydliga m\u00e4tv\u00e4rden. Ytterligare lager som nftables-rate-limits, SYNPROXY och XDP bromsar trafiken redan f\u00f6re TCP-stacken. Sammanfattningsvis skyddar jag p\u00e5 detta s\u00e4tt webb-, e-post-, VPN- och API-tj\u00e4nster mot SYN-\u00f6versv\u00e4mningar utan att vanliga klienter drabbas. Den som konsekvent genomf\u00f6r dessa \u00e5tg\u00e4rder f\u00f6rb\u00e4ttrar tillg\u00e4ngligheten och minskar avbrotten m\u00e4rkbart vid attackbelastning.<\/p>","protected":false},"excerpt":{"rendered":"<p>TCP SYN-cookies ger ett p\u00e5litligt skydd mot SYN-flood-attacker i Linux-k\u00e4rnan. L\u00e4s mer om hur mekanismen fungerar och hur du konfigurerar 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":"131","_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\/sv\/wp-json\/wp\/v2\/posts\/20882","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=20882"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/20882\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/20875"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=20882"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=20882"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=20882"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}