Vai al contenuto 
Cookie TCP SYN 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.
Punti centrali
- Funzionalità: Cookie nell'ISN, stato disponibile solo dopo l'ACK
- Controllo Linux: net.ipv4.tcp_syncookies con modalità 0/1/2
- Benefici: basso consumo di memoria durante il carico di attacco
- Confini: non è efficace contro gli attacchi alla larghezza di banda o alle app
- Sintonizzazione: Impostare con attenzione i valori di backlog e retry
Come gli attacchi SYN-Flood rallentano l'handshake TCP
Un hacker inonda il server con Pacchetti SYN 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. È proprio qui che entrano in gioco Syncookies 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’esistenza di un vero terminale remoto, consentendo così 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é crea gli stati più costosi solo in una fase molto avanzata.
Procedura tecnica: cookie al posto del precedente sistema di gestione dello stato
Il kernel risponde a un SYN con un SYN/ACK appositamente codificato, il cui ISN è 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’ISN 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à 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.
Attivazione e verifica: tcp_syncookies nella pratica
Informazioni sull'opzione sysctl net.ipv4.tcp_syncookies Controllo il comportamento: 0 = disattivato, 1 = solo in caso di sovraccarico, 2 = permanente. Negli ambienti di produzione imposta solitamente la modalità 1, in modo che l’handshake 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 è utile per pianificare il tutto; approfondisco i dettagli nel post Protezione dalle inondazioni SYN. Utilizzo regolarmente i seguenti comandi:
Visualizza lo stato di #
sysctl net.ipv4.tcp_syncookies
Attiva temporaneamente # (fino al riavvio)
sudo sysctl -w net.ipv4.tcp_syncookies=1
Impostare # in modo permanente
echo "net.ipv4.tcp_syncookies = 1" | sudo tee /etc/sysctl.d/60-syncookies.conf
sudo sysctl --system
Limiti: cosa non fanno i cookie SYN
I cookie SYN si rivolgono principalmente ai Syn-Queue 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ù livelli che riunisce rete, kernel e livello di servizio.
Ottimizzazione: arretrati, code e tentativi di ripetizione
Prima che si verifichi un'emergenza, io... arretrati e i tentativi di ripetizione, affinché i picchi legittimi non attivino inutilmente la modalità 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ù 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.
#: candidati per i picchi di carico
sudo sysctl -w net.core.somaxconn=4096
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sudo sysctl -w net.ipv4.tcp_synack_retries=3
Confronto tra le modalità operative: effetti e impiego
Per la vita di tutti i giorni scelgo il Modalità consapevolmente, poiché 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à adattiva (1) lascia che lo stack funzioni normalmente e interviene in caso di rischio di overrun. La modalità disattivata (0) è utile al massimo in contesti di laboratorio o su reti chiuse. La tabella seguente riassume il tutto in modo sintetico:
| Modalità | Descrizione | Vantaggio | Possibili effetti collaterali | Esempio |
|---|---|---|---|---|
| 0 | Disattivato, nessun cookie | Comportamento di base ben definito | L'autore dell'attacco riempie la coda Syn | Rete di prova isolata |
| 1 | Adattivo, solo in caso di trabocco | TCP normale in condizioni di inattività | Calibrare il punto di commutazione | Servizi pubblici |
| 2 | Obbligatorio, sempre attivo | Sgravio precoce | I valori analitici subiscono variazioni | Situazione di attacco difficile |
Effetti misurabili: latenze e percentuale di successo
Sotto pressione, il Requisiti di memoria evidente all’inizio di ogni connessione, poiché 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ù 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à cookie.
Livelli di protezione aggiuntivi: firewall e limiti
Risolvo i syncookies con Regole di filtraggio e i limiti di velocità, 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à di connessione. La guida offre una panoramica sintetica sui moderni filtri di pacchetti nftables vs. Netfilter. Inoltre, gli scenari SYNPROXY sui firewall perimetrali contribuiscono a terminare l’handshake 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.
Approcci ad alte prestazioni: XDP e simili.
Quando gli attacchi di volume colpiscono il Tasso PPS 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ì il carico sulla CPU e alleggerendo la coda di accettazione. Per familiarizzare con questa tecnica, è utile consultare una guida introduttiva su Elaborazione dei pacchetti XDP. 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.
Diagnosi: come interpretare correttamente le metriche e i messaggi di log
In caso di anomalie Timeout Controllo le statistiche di netstat/ss, i messaggi di dmesg e i pannelli di Grafana relativi alle velocità di connessione. Una percentuale crescente di SYN-RECV, un numero elevato di ritrasmissioni e di pacchetti persi indicano il passaggio alla modalità 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à.
Compatibilità: opzioni TCP e casi limite
Programmazione dei kernel moderni Opzioni come MSS, SACK o Timestamp, in modo che i cookie vengano trasportati in modo da poter essere ricostruiti. Gli stack più datati o meno comuni possono presentare delle peculiarità, 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é le implementazioni odierne funzionano in modo affidabile. In scenari molto specifici, la modalità operativa forzata (2) rimane uno strumento che utilizzo solo in modo mirato.
Idee sbagliate comuni: ciò che correggo spesso
I syncookies non sostituiscono Difesa DDoS 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, è 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é la configurazione e l’hardware si adattino alle dinamiche di accesso reali.
Verifica pratica: passaggi per formulare un'ipotesi valida
Inizio con Modalità 1 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à 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.
IPv6 e dual-stack: stesso switch, stessa logica
Negli ambienti dual-stack, il comportamento è il seguente: IPv4 e IPv6 è coerente nel contesto dei cookie. L'interruttore net.ipv4.tcp_syncookies gestisce la protezione a livello globale per il protocollo TCP, quindi anche per i socket v6. Per questo motivo verifico il passaggio alla modalità 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à e politiche di edge specifici, affinché il traffico volumetrico non sovraccarichi la CPU.
Metriche nel kernel: indicatori affidabili
Per un monitoraggio affidabile, utilizzo i contatori del kernel che registrano esplicitamente i cookie. Oltre a ss -s Per monitorare le distribuzioni di stato, tengo d’occhio 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.
Panoramica #
ss -s
ss -ant state syn-recv | wc -l
Contatore dei cookie # (kernel: /proc/net/netstat)
grep -E 'Syncookies|ListenOverflows|ListenDrops' /proc/net/netstat
# Visualizzazione in tempo reale
watch -n1 'grep -E "Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)" /proc/net/netstat'
# Messaggi di log (esempio)
# dmesg mostra, tra l'altro:
# TCP: Possibile SYN flooding sulla porta 443. Invio di cookie. Controllare i contatori SNMP.
Salire ListOverflow e ListenDrops parallelamente a SyncookiesSent regolo i backlog, i tentativi di riconnessione e i filtri a monte. Rimangono SyncookiesRecv , ciò indica una vera e propria ondata di bot; se invece si verificano con maggiore frequenza SyncookiesFailed, verifico i percorsi NAT/proxy e le possibili manipolazioni lungo il percorso.
Proxy, bilanciatori di carico e Kubernetes
All'indirizzo Catene di proxy e di bilanciamento del carico 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é altrimenti finestre di prova brevi con un numero ridotto di tentativi potrebbero erroneamente indicare instabilità.
Casi limite in dettaglio: opzioni, intervalli di tempo, NAT
I cookie codificano solo parametri limitati. 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à operativa (1), in modo che prevalga il percorso standard e i cookie entrino in gioco solo in caso di overflow. La validità di un cookie è legata a intervalli di tempo: in caso di percorsi fortemente asimmetrici o picchi di ritardo, un ACK legittimo può 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.
Flood di ACK/RST e varianti oltre la tempesta di SYN
Non tutti Attacco durante il trasporto 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’handshake: in questo caso i cookie sono di scarsa utilità. 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à 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ù ACK tardivi) tramite limiti di velocità per ogni spazio di rete di origine.
Ulteriori ottimizzazioni: code di lista/accettazione ed errori rapidi
Oltre ai parametri classici, utilizzo degli interruttori aggiuntivi che ne determinano il comportamento in condizioni limite:
- Backlog contro somaxconn: Il valore in elenchi (backlog) per ogni processo viene determinato da net.core.somaxconn limitato. Mi assicuro che il software del server e il kernel funzionino in sintonia, altrimenti le ottimizzazioni vanno a finire nel nulla.
- tcp_abort_on_overflow: 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ò consentire al client di effettuare rapidamente un nuovo tentativo; nel caso di client TLS o legacy, di solito preferisco lo scarto predefinito.
- Gestione delle porte e dello stato TIME-WAIT: I biscotti non prevengono Colli di bottiglia delle porte effimere. Ho in programma intervallo_porta_locale Sii generoso e utilizza con prudenza le ottimizzazioni TIME-WAIT, affinché il riutilizzo non causi bug imprevisti.
- SO_REUSEPORT: La presenza di più code di accettazione per ogni porta distribuisce il carico tra i processi worker e riduce gli overflow sulle singole CPU.
Metodi di prova: riproducibili e significativi
Simulo carichi realistici e misuro il punto di passaggio alla modalità "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.
Generare un flusso # (in laboratorio!)
sudo hping3 -S -p 443 --flood --rand-source
Variare le condizioni di rete #
sudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%
# Mescolare il traffico legittimo
wrk -t8 -c512 -d60s https:///
# Monitoraggio in parallelo
watch -n1 'ss -s; echo; grep -E "Syncookies|Listen(Overflows|Drops)" /proc/net/netstat'
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.
Funzionamento e manutenzione: garantire la stabilità per tutta la durata di vita
In funzionamento continuo, pianifico Rotazione segreta (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é i miglioramenti nell’implementazione dei cookie (migliore codifica delle opzioni, fasce temporali robuste) abbiano effetto. Ai fini degli audit, annoto quando è entrata in funzione la modalità 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.
Versione abbreviata per chi va di fretta
I cookie SYN mantengono la Carico di stretta di mano riducendo il carico, creando gli stati solo dopo un ACK confermato e proteggendo così la coda SYN da un sovraccarico. Attivo la modalità 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à 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à e riduce sensibilmente i tempi di inattività in caso di carico di attacchi.
