Il SYN cookie è una tecnica per resistere a un attacco informatico Flood SYN (attacco SYN a valanga/allagamento) e viene definita dall'inventore Daniel J. Bernstein come una "scelta particolare di sequenze iniziali TCP da parte dei TCP servers".[1]
In particolare, l'uso dei SYN cookies permette a un server di evitare la caduta della connessione quando la coda SYN è piena comportandosi invece come se la coda SYN fosse stata ampliata.
Quindi il server manda indietro la rispettiva risposta SYN+ACK al client, ma scarta l'entrata in coda del SYN. Se il server poi riceve un conseguente ACK di risposta dal client, è capace di ricostruire l'entrata nella coda SYN, grazie alle informazioni codificate nella sequenza TCP.
Definizione
[modifica | modifica wikitesto]I SYN cookies sono una scelta particolare della sequenza iniziale TCP da parte dei server. La differenza tra la sequenza iniziale del server e quella del client è:
- i primi 5 bit: t mod 32, dove t è un contatore di bit a 32 bits che si incrementa ogni 64 secondi;
- 3 bit successivi: m, ovvero la codifica di un MSS selezionato dal server in risposta all'MSS del client;
- gli ultimi 24 bit: s, ovvero un "segreto" selezionato dal server in funzione dell'indirizzo IP e del numero di porta del client, dell'indirizzo IP e del numero di porta del server, e del valore di t.
Questa scelta di sequenza iniziale è in accordo con il requisito base TCP che la sequenza di numeri cresca lentamente. La scelta del server cresce in modo leggermente più veloce di quella iniziale del client.
Falsificazione cieca di connessione
[modifica | modifica wikitesto]
Se un attaccante indovina una sequenza valida mandata all'host di qualcun altro, può creare una connessione con quell'host.
Gli attaccanti possono provare a decriptare la funzione segreta del server, ispezionando una serie di cookies validi e provando a predirne uno valido nuovo. Per definire una funzione "sicura", la chance di successo dell'attaccante deve essere non troppo diversa dalla probabilità di indovinare in maniera casuale. Gli autenticatori di messaggi a chiave segreta sono progettati proprio per garantire questo tipo di sicurezza. Ad esempio, la funzione che codifica l'input in 16 bytes, cripta il risultato tramite AES (Rijndael) con una chiave segreta ed estrae i primi 24 bit del risultato è estremamente veloce e sembra essere sicura.
Non importa quale sia la funzione usata, l'attaccante in qualche milione di tentativi di pacchetti di ACK casuali riuscirà a creare una connessione. I server possono rendere questi attacchi più costosi in due modi:
- tenendo traccia dei tempi di overflow delle più recenti code SYN (non una variabile globale, ma una per ogni coda) non deve ricostruire gli ingressi SYN mancanti se non ci sono stati overflow recenti.
- aggiungendo un altro numero al cookie: una funzione scelta (lato server) segreta a 32 bit dell'indirizzo del cliente. Questo forza l'attaccante a indovinare 32 bit invece di 24.
L'introduzione di nuovo protocollo a 128 bit potrebbe rendere la creazione cieca della connessione praticamente impossibile.
Critiche
[modifica | modifica wikitesto]L'uso dei SYN cookies non infrange nessun protocollo specifico e di conseguenza è compatibile con ogni implementazione TCP.
Ci sono, comunque, alcune precauzioni da tenere a mente quando si usano i SYN cookies in quanto:
- il server è limitato a solo 8 valori MSS ed è tutto ciò che può essere codificato in 3 bit;
- il server deve rifiutare tutte le opzioni TCP (come il timestamp), perché il server scarta la coda SYN dove quella informazione sarebbe altrimenti archiviata.
Mentre queste limitazioni rendono l'esperienza non ottimale, sono raramente notate lato client, perché sono applicate solo quando sotto attacco. In questa evenienza, la perdita di opzioni TCP per salvare la connessione è considerata un costo accettabile.
Un problema sorge quando il pacchetto con l'ACK finalizzato alla connessione (mandato dal client) viene perso e il protocollo del livello applicativo richiede che il server comunichi per primo. In questo caso, il client assume che la connessione sia stata stabilita correttamente e aspetta dal server il segnale previsto, o che rimandi il pacchetto SYN+ACK. In caso contrario, il server non è avvertito della sessione e non manda il SYN+ACK perché è scartata l'entrata della coda che l'avrebbe attivato.
Eventualmente, il client può chiudere la connessione in base a un timer a livello di applicazione, ma questo può risultare relativamente lungo.
Nel 2008, la versione 2.6.26 del kernel di Linux ha aggiunto un supporto limitato alle opzioni TCP, codificandole nel timestamp.
Il nuovo standard Transazioni Cookie TCP (TCPCT) è pensato per superare questi inconvenienti e migliorare qualche aspetto. Diversamente dai SYN cookies, TCPTC è un'estensione del protocoll TCP e richiede compatibilità da entrambi gli estremi (client e server).
Considerazioni di sicurezza
[modifica | modifica wikitesto]I firewall più semplici che sono configurati in modo da permettere tutte le connessioni in uscita ma per poter restringere le connessioni in entrata (ad esempio permettendo le connessioni sulla porta 80 ma bloccando tutte le altre), funzionano bloccando solo le richieste SYN sulle porte non volute. Se i SYN cookies sono attivi, bisogna fare attenzione ad assicurarsi che l'attaccante non sia capace di bypassare il firewall creando l'ACK, provando per tentativi fino a che uno non è accettato. I SYN cookies dovrebbero essere attivati o disattivati in base alla porta, cosicché i SYN cookies attivati su una porta pubblica non causino un riconoscimento falso su una porta non pubblica.
Note
[modifica | modifica wikitesto]- ^ D. J. Bernstein, SYN COOKIES.
