{"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-protezione-syn-flood-kernel","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/tcp-syn-cookies-schutz-syn-flood-kernel\/","title":{"rendered":"Cookie TCP SYN nel kernel Linux: protezione contro gli attacchi SYN flood"},"content":{"rendered":"<p><strong>Cookie TCP SYN<\/strong> Nel kernel Linux, il carico dell'handshake viene mantenuto basso codificando crittograficamente le informazioni di stato nel numero di sequenza iniziale (Initial Sequence Number) e stabilendo una connessione completa solo in presenza di un ACK valido. In questo modo impedisco che gli attacchi SYN-flood intasino la coda delle connessioni semiaperte e blocchino i client legittimi.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Funzionalit\u00e0<\/strong>: Cookie nell'ISN, stato disponibile solo dopo l'ACK<\/li>\n  <li><strong>Controllo Linux<\/strong>: net.ipv4.tcp_syncookies con modalit\u00e0 0\/1\/2<\/li>\n  <li><strong>Benefici<\/strong>: basso consumo di memoria durante il carico di attacco<\/li>\n  <li><strong>Confini<\/strong>: non \u00e8 efficace contro gli attacchi alla larghezza di banda o alle app<\/li>\n  <li><strong>Sintonizzazione<\/strong>: Impostare con attenzione i valori di backlog e retry<\/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>Come gli attacchi SYN-Flood rallentano l'handshake TCP<\/h2>\n\n<p>Un hacker inonda il server con <strong>Pacchetti SYN<\/strong> e ignora le successive risposte SYN\/ACK, con il risultato che le voci semi-aperte occupano la coda SYN. Mi capita quindi che le nuove richieste legittime non trovino spazio e che si accumulino i timeout. \u00c8 proprio qui che entrano in gioco <strong>Syncookies<\/strong> A: Il kernel non memorizza inizialmente alcuno stato di connessione e trasferisce i dati necessari nel numero di sequenza. Solo un ACK corretto conferma l\u2019esistenza di un vero terminale remoto, consentendo cos\u00ec il regolare proseguimento della fase di instaurazione della connessione. LWN.net e la documentazione della TUM descrivono questo principio come una protezione consolidata ed efficace contro gli handshake, senza un elevato consumo di memoria. Questa architettura mantiene il server in grado di gestire il traffico anche in caso di picchi, poich\u00e9 crea gli stati pi\u00f9 costosi solo in una fase molto avanzata.<\/p>\n\n<h2>Procedura tecnica: cookie al posto del precedente sistema di gestione dello stato<\/h2>\n\n<p>Il kernel risponde a un <strong>SYN<\/strong> con un SYN\/ACK appositamente codificato, il cui ISN \u00e8 ricavato da una chiave segreta, dalle opzioni TCP e da intervalli di tempo. Se arriva un ACK con il numero corretto, ricostruisco i parametri di sessione a partire dall\u2019ISN e apro il socket normalmente. Se la risposta non arriva, non si crea alcuno stato semi-aperto occupato, il che consente di risparmiare memoria e risorse della CPU. Questo approccio riduce drasticamente la vulnerabilit\u00e0 della fase di accettazione, senza modificare in modo permanente il percorso regolare. Secondo la documentazione di Ubuntu e Red Hat, questa tecnica funziona in modo affidabile da molte generazioni di kernel e interviene solo quando la coda rischia di andare in tilt.<\/p>\n\n<h2>Attivazione e verifica: tcp_syncookies nella pratica<\/h2>\n\n<p>Informazioni sull'opzione sysctl <strong>net.ipv4.tcp_syncookies<\/strong> Controllo il comportamento: 0 = disattivato, 1 = solo in caso di sovraccarico, 2 = permanente. Negli ambienti di produzione imposta solitamente la modalit\u00e0 1, in modo che l\u2019handshake standard rimanga intatto e la protezione si attivi solo quando necessario. Posso verificare rapidamente lo stato nella shell e applicare le modifiche tramite sysctl o in modo permanente in \/etc\/sysctl.d\/. Un articolo di approfondimento sul comportamento dei socket e sui modelli di attacco \u00e8 utile per pianificare il tutto; approfondisco i dettagli nel post <a href=\"https:\/\/webhosting.de\/it\/syn-flood-protection-gestione-dei-socket-difesa-dei-server\/\">Protezione dalle inondazioni SYN<\/a>. Utilizzo regolarmente i seguenti comandi:<\/p>\n\n<pre><code>Visualizza lo stato di #\nsysctl net.ipv4.tcp_syncookies\n\nAttiva temporaneamente # (fino al riavvio)\nsudo sysctl -w net.ipv4.tcp_syncookies=1\n\nImpostare # in modo permanente\necho \"net.ipv4.tcp_syncookies = 1\" | sudo tee \/etc\/sysctl.d\/60-syncookies.conf\nsudo sysctl --system\n<\/code><\/pre>\n\n<h2>Limiti: cosa non fanno i cookie SYN<\/h2>\n\n<p>I cookie SYN si rivolgono principalmente ai <strong>Syn-Queue<\/strong> e impediscono che gli stati semi-aperti occupino memoria. Tuttavia, non sono efficaci contro una linea sovraccarica, una logica applicativa sovraccaricata o la saturazione della CPU. In caso di attacchi volumetrici, ho bisogno di filtri a monte, QoS e, se necessario, scrubbing. Anche gli attacchi a livello di applicazione, come le inondazioni di richieste HTTP-GET, richiedono controlli aggiuntivi, limiti e cache. Pertanto, integro sempre i syncookie in una difesa a pi\u00f9 livelli che riunisce rete, kernel e livello di servizio.<\/p>\n\n<h2>Ottimizzazione: arretrati, code e tentativi di ripetizione<\/h2>\n\n<p>Prima che si verifichi un'emergenza, io... <strong>arretrati<\/strong> e i tentativi di ripetizione, affinch\u00e9 i picchi legittimi non attivino inutilmente la modalit\u00e0 di protezione. tcp_max_syn_backlog influenza la coda delle connessioni semiaperte, mentre somaxconn determina la lunghezza massima della coda di accettazione per le connessioni in attesa di accept(). Con tcp_synack_retries stabilisco quante volte il kernel tenta di ripetere un SYN\/ACK prima di rinunciare. Backlog pi\u00f9 elevati assorbono i brevi picchi di carico, ma consumano memoria; un numero inferiore di tentativi di ripetizione libera prima gli slot, ma comporta il rischio di penalizzare eccessivamente i client remoti. Testo questi compromessi sotto carico realistico con strumenti come hping3 o tcp_syn_flooder in una rete isolata.<\/p>\n\n<pre><code>#: candidati per i picchi di carico\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>Confronto tra le modalit\u00e0 operative: effetti e impiego<\/h2>\n\n<p>Per la vita di tutti i giorni scelgo il <strong>Modalit\u00e0<\/strong> consapevolmente, poich\u00e9 influenzano la diagnosi, le metriche e il comportamento sotto pressione. I cookie permanenti (2) evitano qualsiasi inizializzazione precoce dello stato, ma modificano i valori di misurazione per i tentativi di riconnessione e possono influenzare rari casi limite con le opzioni TCP. La modalit\u00e0 adattiva (1) lascia che lo stack funzioni normalmente e interviene in caso di rischio di overrun. La modalit\u00e0 disattivata (0) \u00e8 utile al massimo in contesti di laboratorio o su reti chiuse. La tabella seguente riassume il tutto in modo sintetico:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Modalit\u00e0<\/th>\n      <th>Descrizione<\/th>\n      <th>Vantaggio<\/th>\n      <th>Possibili effetti collaterali<\/th>\n      <th>Esempio<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>0<\/td>\n      <td><strong>Disattivato<\/strong>, nessun cookie<\/td>\n      <td>Comportamento di base ben definito<\/td>\n      <td>L'autore dell'attacco riempie la coda Syn<\/td>\n      <td>Rete di prova isolata<\/td>\n    <\/tr>\n    <tr>\n      <td>1<\/td>\n      <td><strong>Adattivo<\/strong>, solo in caso di trabocco<\/td>\n      <td>TCP normale in condizioni di inattivit\u00e0<\/td>\n      <td>Calibrare il punto di commutazione<\/td>\n      <td>Servizi pubblici<\/td>\n    <\/tr>\n    <tr>\n      <td>2<\/td>\n      <td><strong>Obbligatorio<\/strong>, sempre attivo<\/td>\n      <td>Sgravio precoce<\/td>\n      <td>I valori analitici subiscono variazioni<\/td>\n      <td>Situazione di attacco difficile<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Effetti misurabili: latenze e percentuale di successo<\/h2>\n\n<p>Sotto pressione, il <strong>Requisiti di memoria<\/strong> evidente all\u2019inizio di ogni connessione, poich\u00e9 non si verifica alcuno stato semi-aperto. Di conseguenza, i cookie SYN mantengono alto il tasso di accettazione e i brevi picchi causano meno interruzioni. In condizioni di traffico intenso, osservo un recupero pi\u00f9 rapido non appena la fonte si esaurisce. Le linee guida di Ubuntu e Tenable consigliano un utilizzo adattivo, in modo che i client normali continuino a funzionare senza modifiche. Per i test di regressione, verifico le ritrasmissioni, i tassi di perdita e la latenza del server durante il passaggio alla modalit\u00e0 cookie.<\/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>Livelli di protezione aggiuntivi: firewall e limiti<\/h2>\n\n<p>Risolvo i syncookies con <strong>Regole di filtraggio<\/strong> e i limiti di velocit\u00e0, in modo che il carico non gravi nemmeno sullo stack TCP. Su Linux preferisco utilizzare le regole di nftables per limitare o respingere tempestivamente i soggetti che superano i limiti di velocit\u00e0 di connessione. La guida offre una panoramica sintetica sui moderni filtri di pacchetti <a href=\"https:\/\/webhosting.de\/it\/netfilter-vs-nftables-moderne-tecnologie-di-firewall-per-linux-shield\/\">nftables vs. Netfilter<\/a>. Inoltre, gli scenari SYNPROXY sui firewall perimetrali contribuiscono a terminare l\u2019handshake e a far passare solo le connessioni valide. Per le porte esposte definisco impostazioni rigorose relative alle aperture, alle soglie di registrazione e al numero massimo di tentativi di connessione per indirizzo di origine.<\/p>\n\n<h2>Approcci ad alte prestazioni: XDP e simili.<\/h2>\n\n<p>Quando gli attacchi di volume colpiscono il <strong>Tasso PPS<\/strong> Per ottimizzare le prestazioni, trasferisco la logica di filtraggio tramite XDP al perimetro di rete della scheda di rete (NIC). In questo modo, scarto i pacchetti SYN sospetti prima ancora che raggiungano il livello socket, riducendo cos\u00ec il carico sulla CPU e alleggerendo la coda di accettazione. Per familiarizzare con questa tecnica, \u00e8 utile consultare una guida introduttiva su <a href=\"https:\/\/webhosting.de\/it\/xdp-elaborazione-dei-pacchetti-ad-alte-prestazioni-velocita-del-kernel\/\">Elaborazione dei pacchetti XDP<\/a>. In combinazione con i cookie SYN, si crea un sistema a due livelli: prima una selezione approssimativa a livello di scheda, poi una verifica affidabile tramite handshake nel kernel. Questa catena riduce sensibilmente la superficie di attacco e mantiene accessibili i servizi.<\/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>Diagnosi: come interpretare correttamente le metriche e i messaggi di log<\/h2>\n\n<p>In caso di anomalie <strong>Timeout<\/strong> Controllo le statistiche di netstat\/ss, i messaggi di dmesg e i pannelli di Grafana relativi alle velocit\u00e0 di connessione. Una percentuale crescente di SYN-RECV, un numero elevato di ritrasmissioni e di pacchetti persi indicano il passaggio alla modalit\u00e0 di protezione. Presto attenzione ai messaggi di overflow del backlog SYN e li metto in correlazione con il carico della CPU e degli IRQ. Le acquisizioni di pacchetti con tcpdump confermano la logica dei numeri di sequenza e aiutano a individuare i falsi positivi. Con i contatori di iptables\/nftables misuro inoltre il numero di conteggi relativi alle regole di limitazione della velocit\u00e0.<\/p>\n\n<h2>Compatibilit\u00e0: opzioni TCP e casi limite<\/h2>\n\n<p>Programmazione dei kernel moderni <strong>Opzioni<\/strong> come MSS, SACK o Timestamp, in modo che i cookie vengano trasportati in modo da poter essere ricostruiti. Gli stack pi\u00f9 datati o meno comuni possono presentare delle peculiarit\u00e0, pertanto verifico i percorsi critici prima del lancio. In particolare, in presenza di proxy, NAT e topologie anycast, osservo attentamente il comportamento. LWN.net discute i dettagli di progettazione che spiegano perch\u00e9 le implementazioni odierne funzionano in modo affidabile. In scenari molto specifici, la modalit\u00e0 operativa forzata (2) rimane uno strumento che utilizzo solo in modo mirato.<\/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>Idee sbagliate comuni: ci\u00f2 che correggo spesso<\/h2>\n\n<p>I syncookies non sostituiscono <strong>Difesa DDoS<\/strong> alla periferia, proteggono soprattutto la fase di handshake. Un valore elevato di somaxconn da solo non impedisce gli overflow se SYN\/ACK non riceve mai risposta. Allo stesso modo, \u00e8 fuorviante ritenere che i cookie permanenti (2) siano sempre la scelta migliore; la diagnostica e i casi particolari ne risentono. Senza monitoraggio, mi mancano i segnali necessari per regolare i punti di commutazione e i limiti. I test di carico rimangono indispensabili affinch\u00e9 la configurazione e l\u2019hardware si adattino alle dinamiche di accesso reali.<\/p>\n\n<h2>Verifica pratica: passaggi per formulare un'ipotesi valida<\/h2>\n\n<p>Inizio con <strong>Modalit\u00e0 1<\/strong> per tcp_syncookies e verifico il punto di intervento sotto carico. Successivamente aumento moderatamente tcp_max_syn_backlog e somaxconn, mentre riduco tcp_synack_retries e misuro i tassi di successo. I limiti di velocit\u00e0 del firewall e i filtri geografici\/ASN eliminano il rumore prima dello stack. Riservo i filtri XDP o SmartNIC per situazioni con PPS elevati, in modo da impiegare le risorse in modo mirato. Infine, documento le metriche in modo che eventuali adeguamenti successivi si basino sui dati.<\/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 e dual-stack: stesso switch, stessa logica<\/h2>\n\n<p>Negli ambienti dual-stack, il comportamento \u00e8 il seguente: <strong>IPv4 e IPv6<\/strong> \u00e8 coerente nel contesto dei cookie. L'interruttore <em>net.ipv4.tcp_syncookies<\/em> gestisce la protezione a livello globale per il protocollo TCP, quindi anche per i socket v6. Per questo motivo verifico il passaggio alla modalit\u00e0 cookie su entrambi i protocolli, specialmente quando i dispositivi a monte in IPv6 utilizzano percorsi di filtraggio diversi. Importante: i cookie SYN proteggono esclusivamente il protocollo TCP. I servizi UDP o QUIC richiedono limiti di velocit\u00e0 e politiche di edge specifici, affinch\u00e9 il traffico volumetrico non sovraccarichi la CPU.<\/p>\n\n<h2>Metriche nel kernel: indicatori affidabili<\/h2>\n\n<p>Per un monitoraggio affidabile, utilizzo i contatori del kernel che registrano esplicitamente i cookie. Oltre a <em>ss -s<\/em> Per monitorare le distribuzioni di stato, tengo d\u2019occhio i contatori relativi ai cookie inviati, accettati e non riusciti. In questo modo riesco a capire se la protezione funziona, se i client legittimi riescono a passare e se ci sono errori di configurazione.<\/p>\n\n<pre><code>Panoramica #\nss -s\nss -ant state syn-recv | wc -l\n\nContatore dei cookie # (kernel: \/proc\/net\/netstat)\ngrep -E 'Syncookies|ListenOverflows|ListenDrops' \/proc\/net\/netstat\n\n# Visualizzazione in tempo reale\nwatch -n1 'grep -E \"Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n\n# Messaggi di log (esempio)\n# dmesg mostra, tra l'altro:\n# TCP: Possibile SYN flooding sulla porta 443. Invio di cookie. Controllare i contatori SNMP.\n<\/code><\/pre>\n\n<p>Salire <em>ListOverflow<\/em> e <em>ListenDrops<\/em> parallelamente a <em>SyncookiesSent<\/em> regolo i backlog, i tentativi di riconnessione e i filtri a monte. Rimangono <em>SyncookiesRecv<\/em> , ci\u00f2 indica una vera e propria ondata di bot; se invece si verificano con maggiore frequenza <em>SyncookiesFailed<\/em>, verifico i percorsi NAT\/proxy e le possibili manipolazioni lungo il percorso.<\/p>\n\n<h2>Proxy, bilanciatori di carico e Kubernetes<\/h2>\n\n<p>All'indirizzo <strong>Catene di proxy e di bilanciamento del carico<\/strong> Determina la posizione della protezione dei cookie. Se un bilanciatore di carico L4\/L7 interrompe l'handshake TCP, un attacco SYN flood non raggiunge affatto i backend; in tal caso, attivo i cookie a livello di edge. Se il bilanciatore di carico opera solo in modo passivo (DSR, ECMP), i nodi backend devono proteggersi autonomamente. In Kubernetes configuro i sysctl sui nodi worker, in particolare per i carichi di lavoro su NodePort o HostNetwork. Per i controller Ingress con difesa SYN integrata (SYNPROXY, eBPF) regolo le policy in modo che non si ostacolino a vicenda. Nei test tengo conto degli health check del bilanciatore di carico, poich\u00e9 altrimenti finestre di prova brevi con un numero ridotto di tentativi potrebbero erroneamente indicare instabilit\u00e0.<\/p>\n\n<h2>Casi limite in dettaglio: opzioni, intervalli di tempo, NAT<\/h2>\n\n<p>I cookie codificano solo <strong>parametri limitati<\/strong>. Le moderne implementazioni Linux ricostruiscono di norma in modo affidabile MSS, SACK e il window scaling; tuttavia, i timestamp e alcune opzioni meno comuni possono presentare delle limitazioni a seconda della versione del kernel. Ritengo quindi preferibile la modalit\u00e0 operativa (1), in modo che prevalga il percorso standard e i cookie entrino in gioco solo in caso di overflow. La validit\u00e0 di un cookie \u00e8 legata a intervalli di tempo: in caso di percorsi fortemente asimmetrici o picchi di ritardo, un ACK legittimo pu\u00f2 trovarsi appena al di fuori della finestra. Negli scenari WAN e satellitari misuro quindi la varianza del round-trip prima di ridurre il numero di tentativi. NAT e middlebox che modificano i numeri di sequenza o le opzioni sono ulteriori candidati per casi limite; con acquisizioni mirate dimostro dove si perdono i bit.<\/p>\n\n<h2>Flood di ACK\/RST e varianti oltre la tempesta di SYN<\/h2>\n\n<p>Non tutti <strong>Attacco durante il trasporto<\/strong> Si tratta di un vero e proprio flood di SYN. I flood di ACK o RST prendono di mira la CPU e i percorsi dei pacchetti senza innescare l\u2019handshake: in questo caso i cookie sono di scarsa utilit\u00e0. In questi casi utilizzo filtri a livello precoce (nftables\/XDP) con logica a stato o con una limitazione minima della frequenza degli ACK. In particolare, interrompo le ondate di RST contro connessioni gi\u00e0 stabilite tramite un insieme di regole che scarta gli RST inattesi privi di una finestra appropriata. Copro anche i ripetitori semi-aperti (SYN con spoofing pi\u00f9 ACK tardivi) tramite limiti di velocit\u00e0 per ogni spazio di rete di origine.<\/p>\n\n<h2>Ulteriori ottimizzazioni: code di lista\/accettazione ed errori rapidi<\/h2>\n\n<p>Oltre ai parametri classici, utilizzo degli interruttori aggiuntivi che ne determinano il comportamento in condizioni limite:<\/p>\n\n<ul>\n  <li><strong>Backlog contro somaxconn<\/strong>: Il valore in <em>elenchi (backlog)<\/em> per ogni processo viene determinato da <em>net.core.somaxconn<\/em> limitato. Mi assicuro che il software del server e il kernel funzionino in sintonia, altrimenti le ottimizzazioni vanno a finire nel nulla.<\/li>\n  <li><strong>tcp_abort_on_overflow<\/strong>: Se, in caso di coda di accettazione piena, la richiesta venga scartata silenziosamente o se venga data una risposta attiva con RST. Nelle API ad alto volume, un errore rapido pu\u00f2 consentire al client di effettuare rapidamente un nuovo tentativo; nel caso di client TLS o legacy, di solito preferisco lo scarto predefinito.<\/li>\n  <li><strong>Gestione delle porte e dello stato TIME-WAIT<\/strong>: I biscotti non prevengono <em>Colli di bottiglia delle porte effimere<\/em>. Ho in programma <em>intervallo_porta_locale<\/em> Sii generoso e utilizza con prudenza le ottimizzazioni TIME-WAIT, affinch\u00e9 il riutilizzo non causi bug imprevisti.<\/li>\n  <li><strong>SO_REUSEPORT<\/strong>: La presenza di pi\u00f9 code di accettazione per ogni porta distribuisce il carico tra i processi worker e riduce gli overflow sulle singole CPU.<\/li>\n<\/ul>\n\n<h2>Metodi di prova: riproducibili e significativi<\/h2>\n\n<p>Simulo carichi realistici e misuro il punto di passaggio alla modalit\u00e0 \"cookie\", la percentuale di successo delle connessioni legittime e il tempo di recupero dopo il picco di carico. A tal fine, combino flussi SYN sintetici con richieste applicative reali.<\/p>\n\n<pre><code>Generare un flusso # (in laboratorio!)\nsudo hping3 -S -p 443 --flood --rand-source \n\nVariare le condizioni di rete #\nsudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%\n\n# Mescolare il traffico legittimo\nwrk -t8 -c512 -d60s https:\/\/\/\n\n# Monitoraggio in parallelo\nwatch -n1 'ss -s; echo; grep -E \"Syncookies|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n<\/code><\/pre>\n\n<p>Con questi passaggi riesco a capire se i ritentativi diminuiscono in modo troppo aggressivo, se i firewall a monte filtrano erroneamente i timestamp o se le code di accettazione dei singoli worker vanno in overflow in modo sproporzionato. Documento gli indicatori chiave (tasso di successo delle connessioni legittime vicino a 100%, tasso di corrispondenza dei cookie, andamento della latenza) per poter effettuare successivamente adeguamenti basati sui dati.<\/p>\n\n<h2>Funzionamento e manutenzione: garantire la stabilit\u00e0 per tutta la durata di vita<\/h2>\n\n<p>In funzionamento continuo, pianifico <strong>Rotazione segreta<\/strong> (automaticamente a livello di kernel) e osservo se i cambiamenti delle fasce temporali hanno effetti visibili su tratte con RTT molto lunghe. Mantengo aggiornati il kernel e i driver affinch\u00e9 i miglioramenti nell\u2019implementazione dei cookie (migliore codifica delle opzioni, fasce temporali robuste) abbiano effetto. Ai fini degli audit, annoto quando \u00e8 entrata in funzione la modalit\u00e0 di protezione, quante connessioni ha lasciato passare e se sono stati attivati filtri aggiuntivi. In caso di modifiche a MTU, offloading o stack NF (ad es. nuovi set nftables), ripeto dei test rapidi per individuare tempestivamente eventuali interazioni errate.<\/p>\n\n<h2>Versione abbreviata per chi va di fretta<\/h2>\n\n<p>I cookie SYN mantengono la <strong>Carico di stretta di mano<\/strong> riducendo il carico, creando gli stati solo dopo un ACK confermato e proteggendo cos\u00ec la coda SYN da un sovraccarico. Attivo la modalit\u00e0 1, ottimizzo con cautela i backlog e i tentativi di riconnessione e misuro gli effetti con metriche chiare. Livelli aggiuntivi come i limiti di velocit\u00e0 nftables, SYNPROXY e XDP frenano il traffico ancora prima dello stack TCP. In sintesi, in questo modo proteggo i servizi web, di posta elettronica, VPN e API dagli attacchi SYN-Flood, senza penalizzare i client regolari. Chi attua questi passaggi in modo rigoroso rafforza la disponibilit\u00e0 e riduce sensibilmente i tempi di inattivit\u00e0 in caso di carico di attacchi.<\/p>","protected":false},"excerpt":{"rendered":"<p>I cookie TCP SYN nel kernel Linux offrono una protezione affidabile dagli attacchi SYN flood. Scoprite come funziona questo meccanismo e come configurarlo.<\/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\/it\/wp-json\/wp\/v2\/posts\/20882","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=20882"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20882\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20875"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20882"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20882"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20882"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}