<< Torna agli Approfondimenti Tematici

Premessa

Uno dei più comuni attacchi di tipo DoS (Denial of Service) è il TCP Syn flooding, che consiste nell’inviare da parte dell’hacker un pacchetto TCP iniziale di SYN (Synchronize) con indirizzo IP sorgente spoofed .

Il server risponderà con SYN ACK a questo indirizzo non esistente e conseguentemente l’ACK finale, necessario per completare il Three Way Handshake del TCP, non arriverà mai. La connessione resterà in uno stato di Half Open (detta anche embryonic connection) e memorizzata in un apposito buffer all’interno del server.

Ovviamente l’Hacker invierà una sequenza di pacchetti di questo tipo, con indirizzi IP source sempre diversi, tale da saturare i buffer disponibili all’interno del server, il quale non potrà accettare ulteriori connessioni. L’attacco è riuscito in quanto utenti legittimi non potranno collegarsi al server durante tutto questo periodo.

Protezione SYN Proxy

Per proteggere i server da attacchi di questo tipo i firewall agiscono normalmente in modalità SYN Proxy:

Come si vede dalla figura 2, il firewall risponde al SYN per conto del server (passo 2) con un SYN ACK e solo quando riceve l’ACK finale valido da parte del Client (passo 3) invia a sua volta il SYN al server (passo 4) e porta a termine l’apertura della connessione con quest’ultimo (passi 5 e 6). A questo punto le 2 semiconnessioni vengono ricongiunte e tutti i pacchetti successivi saranno scambiati direttamente da client a server senza ulteriore intervento da parte del firewall.

Il Firewall svolge quindi il ruolo di proxy solo nella fase di apertura connessione, prima simulando il server nei confronti del client (passi 1-3) e successivamente simulando il client nei confronti del server (passi 4-6). Da notare che questo comportamento è attivato solo al superamento di una soglia (normalmente configurabile) di pacchetti di SYN ricevuti nell’unità di tempo.

La modalità SYN Proxy protegge i server dietro al firewall ma rischia di far diventare quest’ultimo il bersaglio degli attacchi, per due motivi:

1) Alla ricezione di un pacchetto di SYN un firewall esegue un’elaborazione dello stesso (detta First Path Flow): Route Lookup, Zone Lookup, Policy Lookup, opzionalmente NAT...
2) Se il traffico è permesso (come lo è normalmente ad esempio nel caso di richieste http al server aziendale esposto nella DMZ) due nuove righe vengono aggiunte nella Session Table (la seconda per permettere il traffico di ritorno).

Nel caso di attacco TCP SYN Flooding questa elaborazione totalmente inutile ha effetti negativi sulle performances del firewall; si rischia inoltre di saturare completamente la session table con inutili connessioni half-open.

Un metodo per mitigare questo tipo di attacco è abbassare il Timeout: questo parametro è il tempo massimo dopo il quale una connessione Half Open viene rimossa. Il default per firewall Juniper SRX è 20 secondi e può essere ridotto fino ad 1 secondo. Questo però potrebbe creare problemi con applicazioni critiche e delay sensitive. Inoltre l’hacker potrebbe semplicemente aumentare il rate di pacchetti SYN nell’unità di tempo.

Protezione SYN Cookie

I firewall Juniper per risolvere questo problema adottano la modalità operativa SYN Cookie, alternativa a SYN Proxy, che illustro di seguito:

Esaminando più in dettaglio il Three Way Handshake, come si vede in figura 3, in questa fase vengono impostati i valori iniziali dei contatori

Sequence Number: Seq
Acknowledge Number: Ack

i quali sono utilizzati dal TCP per controllare la corretta ricezione sequenziale dei segmenti ed eventualmente riordinare segmenti arrivati fuori sequenza. In particolare Seq di Client ed Ack di server servono per controllare la sequenzialità dei segmenti inviati da Client a Server e viceversa. Questi valori non partono normalmente da 0 ma da un valore casuale che ognuna delle due parti sceglie (per il proprio Seq) e lo comunica all’altra appunto durante il Three Way Handshake iniziale.

L’algoritmo Syn Cookie è stato originariamente inventato da D. J. Bernstein ed Eric Shenk ed è attualmente quanto di meglio esista per mitigare attacchi di tipo TCP Syn Flooding. Nella modalità Syn Cookie il firewall non appena riceve un pacchetto di SYN genera un cookie, un Hash crittografato che utilizza come proprio Seq. Il Cookie viene calcolato a partire da indirizzo IP locale e remoto, Porte locali e remote, ed un contatore noto solo al firewall stesso; la presenza di quest’ultimo rende il cookie impossibile da ricalcolare da parte di altri.

Quando il firewall riceve l’Ack finale estrae il contatore Ack, sottrae 1 e valida il cookie; se è corretto il Three Way Handshake è ritenuto valido e solo in tal caso inizia l’elaborazione First Path Flow.

Come su vede dalla figura 4, il firewall risponde al SYN per conto del server dopo aver calcolato il cookie che inserisce come Seq nel SYN ACK( detto anche ISN, Initial Seq Number passo 2); solo alla ricezione dell’ACK (passo 3) viene effettuata l’elaborazione ed eventualmente permessa la nuova connessione ed inserita nella Session Table.

Il Syn Cookie è stateless, per cui non instaura una sessione alla ricezione del pacchetto di SYN; non invoca azioni “resource intensive” fino alla ricezione di un Syn Cookie valido. E’ quindi evidente che nel caso di TCP SYN Flooding l’unica azione eseguita dal firewall è proprio il calcolo del cookie; i rischi di saturazione della Session Table sono mitigati rispetto al SYN Proxy. Questo metodo permette anche di rilevare ed eliminare pacchetti di ACK con cookie non validi, non associati quindi ad effettive richieste di inizio connessione valide.

[edit security]
user@srx# show
flow {
[sp=6]syn-flow-protection-mode syn-cookie;
}

Nella figura 5 viene indicato come attivare la modalità SYN Cookie nei firewall SRX. SYN Cookie e SYN Proxy sono modalità mutualmente esclusive.