SYN Flood e SYN Cookies - Connection Table Exhaustion

Un SYN flood sfrutta il three-way handshake TCP inviando moltissimi pacchetti SYN con indirizzi IP sorgente spoofati. Il server alloca una entry nella SYN queue per ogni connessione in attesa dell'ACK finale, che non arriva mai. Quando la coda si esaurisce, le connessioni legittime vengono rifiutate. Non e' un attacco per ottenere accesso: e' puro DoS.

Mappa globale

#

Three-Way Handshake TCP

#

Il three-way handshake e' il meccanismo che TCP usa per stabilire una connessione. Il SYN flood lo sfrutta deliberatamente lasciando il server in attesa di un ACK che non arrivera' mai. Prima di capire l'attacco, e' utile vedere il flusso normale.

Una connessione TCP normale richiede tre passi: il client manda SYN, il server risponde con SYN-ACK allocando risorse per quella connessione, il client chiude con ACK. Dopo questi tre passi la sessione e' stabilita.

sequenceDiagram
    participant C as Client
    participant S as Server

    C->>S: SYN (apre connessione)
    S->>C: SYN-ACK (alloca risorse, attende ACK)
    C->>S: ACK (conferma)
    Note over C,S: Sessione stabilita - scambio dati

Il problema e' che dopo il SYN-ACK il server alloca una entry nella SYN queue (backlog) per quella connessione in stato SYN_RECEIVED, in attesa dell'ACK finale. Questa entry occupa memoria per 30-120 secondi (il timeout). Il SYN flood satura questa queue.

SYN Flood - Connection Table Exhaustion

#

Il SYN flood mira a esaurire la SYN queue del server inondandola con half-open connections che non verranno mai completate. L'attaccante usa indirizzi IP sorgente spoofati, cioe' falsificati e inesistenti, per impedire che il server riceva mai il vero ACK.

sequenceDiagram
    participant A as Attaccante
    participant X as IP spoofato (inesistente)
    participant S as Server vittima

    A->>S: SYN [src = IP spoofato 1]
    S->>X: SYN-ACK - nessuno risponde
    Note over S: half-open connection 1 - attende ACK
    A->>S: SYN [src = IP spoofato 2]
    S->>X: SYN-ACK - nessuno risponde
    Note over S: half-open connection 2 - attende ACK
    A->>S: SYN [src = IP spoofato 3]
    Note over S: ... migliaia di half-open connections
    Note over S: SYN queue esaurita
    Note over S: client legittimi - connessione rifiutata

Perche' l'IP spoofato e' necessario: se l'attaccante usasse il suo IP reale, il suo kernel riceverebbe il SYN-ACK e manderebbe automaticamente un RST, chiudendo immediatamente la half-open connection. Il kernel manda RST perche' vede un SYN-ACK per una connessione che non ha mai aperto. L'IP spoofato impedisce al kernel dell'attaccante di ricevere il SYN-ACK e annullare il flood.

Questo e' lo stesso meccanismo di nmap -sS (SYN stealth scan): nmap usa raw socket per mandare SYN, il kernel riceve il SYN-ACK e manda RST automaticamente, la porta viene rilevata come aperta senza completare la connessione.

Conseguenze sul server:

Indicatori:

# Spike di connessioni in stato SYN_RECEIVED - visibile con ss o netstat
ss -s
netstat -an | grep SYN_RECV | wc -l

SYN Cookies - la difesa principale

#

SYN Cookies sono la difesa principale contro il SYN flood: il server codifica le informazioni della connessione nel sequence number del SYN-ACK, invece di allocare memoria. La memoria viene allocata solo all'arrivo del vero ACK finale.

Il meccanismo elimina la SYN queue: invece di tenere in memoria ogni half-open connection, il server codifica i parametri necessari (IP, porta, timestamp) in un hash crittografico e lo inserisce come sequence number nel SYN-ACK. Se arriva un ACK legittimo, il server decodifica il numero di sequenza e ricostruisce la connessione. Se l'ACK non arriva, non c'e' nulla in memoria da esaurire.

sequenceDiagram
    participant C as Client legittimo
    participant S as Server (SYN Cookies attivi)
    participant A as Attaccante

    C->>S: SYN
    S->>C: SYN-ACK [seq = hash(IP, porta, timestamp)]
    Note over S: NESSUNA MEMORIA ALLOCATA
    C->>S: ACK [ack = hash + 1]
    Note over S: ACK valido - decodifica hash - alloca memoria
    Note over S: Connessione stabilita

    A->>S: SYN [src = IP spoofato]
    S->>A: SYN-ACK [seq = hash]
    Note over S: NESSUNA MEMORIA ALLOCATA
    Note over A: ACK non arriva mai - nessun impatto

Abilitare SYN Cookies su Linux:

# Verifica stato attuale
sysctl net.ipv4.tcp_syncookies

# Abilitare SYN cookies (1 = abilitato)
sysctl -w net.ipv4.tcp_syncookies=1

# Rendere permanente in /etc/sysctl.conf
net.ipv4.tcp_syncookies = 1

Dev parallel: Node.js e Symfony non vedono il SYN flood: il kernel Linux esaurisce la connection table prima che la richiesta raggiunga l'applicazione. Un SYN flood contro un server Node blocca tutte le nuove connessioni TCP a livello kernel, ma i processi Node non consumano piu' CPU del normale. La difesa si configura a livello sistema (net.ipv4.tcp_syncookies=1) o si delega a Cloudflare/AWS Shield che fa SYN proxy trasparente: il cloud risponde al SYN al posto del server, verifica la legittimita' della connessione, e inoltrata solo le connessioni complete.

DoS vs DDoS e il ruolo del SYN flood

#

Il SYN flood puo' essere lanciato sia come DoS (singola sorgente) che come DDoS (botnet). La distinzione cambia la strategia di difesa.

BCP38 - Ingress Filtering: il principio Best Current Practice 38 chiede agli ISP di filtrare in uscita i pacchetti con IP sorgente che non appartengono alla loro rete. Se tutti gli ISP applicassero BCP38, il SYN flood con IP spoofati sarebbe impossibile perche' i pacchetti verrebbero eliminati prima di raggiungere internet. In pratica BCP38 non e' universalmente applicato, rendendo l'IP spoofing ancora possibile.

Mappa figlia - Confronto difese

#

Note correlate: tcp-handshake | tcp-udp | ids-ips