Attacco SYN flood: varianti e misure difensive

Il SYN flood è un attacco Denial of Service (DoS) che ha lo scopo di ostacolare l’uso legittimo di un sistema online. Dal punto di vista concettuale, possiamo immaginare un attacco DoS come un invio massivo di lettere inutili a un ente pubblico. Quando le caselle di posta sono sature, l’ente non riesce più a ricevere né a rielaborare la corrispondenza legittima. L'aggressore ha raggiunto il suo scopo: il traffico regolare collassa.

Il SYN Flood fa parte degli attacchi DoS. L’aggressore invia a un sistema target un flood di pacchetti dati maligni. Lo scopo è di sovraccaricare l’obiettivo e ostacolarne di conseguenza l’uso legittimo.

Come il Ping of Death, il SYN Flood è un attacco di protocollo. Questo tipo di attacchi mira a sfruttare le falle della connessione di rete per mettere in ginocchio il sistema target. Il SYN Flood funziona perciò diversamente rispetto agli attacchi volumetrici come il ping flood, l’UDP flood e l’HTTP flood,dove lo scopo dei malintenzionati è inghiottire quanta più banda possibile dalla rete dell’obiettivo.

Il SYN flood è conosciuto anche come “attacco semi-aperto” ed è un tipo di attacco informatico rivolto alla connessione di rete. L’aggressore viola il three-way handshake del Transmission Control Protocol (TCP). Invece di negoziare, come d’abitudine, una connessione tra client e server, vengono lasciate sul server molte connessioni semi-aperte che impegnano le sue risorse che di conseguenza non saranno più disponibili per il loro utilizzo di routine.

Vediamo per bene come funziona normalmente la connessione TCP e come, nel corso di un attacco SYN flood, ne viene disturbato il principio.

Insieme all’Internet Protocol (IP), il Transmission Control Protocol (TCP) rappresenta uno dei pilastri fondamentali dell'Internet. Il TCP è un protocollo orientato a una connessione e perciò il client e il server devono negoziare una connessone prima di potersi scambiare dati tra loro. Il three-way handshake serve a questo:

1. Il client invia un pacchetto SYN (“synchronize”) al server.- “Ciao, vorrei configurare una connessione con voi.”
2. Il server risponde con un pacchetto SYN/ACK (ACK = “acknowledge”) e prepara una struttura di dati chiamata “Transmission Control Block” (TCB) per la connessione nel backlog del SYN.- “OK, con piacere. Ti prego di usare i seguenti parametri di connessione.”
3. Il client risponde al pacchetto SYN/ACK con un pacchetto ACK e finisce in questo modo l’handshake. Da questo momento in poi la connessione è pronta e i dati possono essere inviati in entrambe le direzioni. Da parte del server, il Trasmission Control Block verrà rimosso dal backlog del SYN.- “Fantastico, grazie. Andiamo!”

Questo processo si svolge ogni volta in background quando vi collegate a un server, visitate un sito o aprite le vostre e-mail.

Per innescare un SYN flood, l’aggressore si serve di un software speciale. Per esempio, il tool hping è tra i più amati e utilizzati per i penetration test e permette di simulare la banda negli attacchi alla rete. Per motivi di sicurezza, qui vi rappresenteremo solo un modello approssimativo di codice hping per un SYN flood con indirizzo IP mascherato:

Sono interessanti le opzioni del comando:

• L’opzione '--syn' indica allo strumento di utilizzare il protocollo TCP e inviare pacchetti SYN.
• Svolge un ruolo fondamentale l’opzione '--flood' che secondo la documentazione del comando hping permette di inviare pacchetti nel modo più veloce possibile.
• Con l'opzione '--rand-source' l’aggressore maschera il suo indirizzo IP. Al posto del vero indirizzo IP del mittente, inserisce un indirizzo IP casuale.

Esistono diverse varianti di attacchi SYN flood che hanno tutte in comune un unico obiettivo: occupare il server più a lungo possibile. Per farlo, l’aggressore deve assicurarsi che i pacchetti SYN/ACK inviati dal server non ricevano risposta. Se il dispositivo dell’aggressore rispondesse con un pacchetto ACK, questo eliminerebbe la voce corrispondente sul server dal backlog del SYN.

Quando l’aggressore maschera il suo indirizzo IP, allora i pacchetti SYN/ACK vengono indirizzati a estranei. Se un dispositivo riceve un pacchetto SYN/ACK proveniente da un server senza aver prima inviato un pacchetto SYN, allora il dispositivo invierà un pacchetto RST (RST = “reset”) terminando in questo modo la connessione. Un cyber criminale astuto vuole impedire anche questo per mantenere quante più connessioni possibili semi-aperte sul server.

Con un attacco diretto, l’aggressore fa partire l'attacco SYN flood con il proprio indirizzo IP. Per essere sicuro che i pacchetti SYN/ACK in entrata siano respinti, l'aggressore configura il firewall del suo dispositivo. Un altro metodo è limitare i pacchetti SYN in uscita.

Nel caso di un attacco diretto, l'aggressore agisce con il proprio indirizzo IP e perciò può essere relativamente semplice da rintracciare. Per questo motivo si tratta di una variante utilizzata di rado.

Gli attacchi con gli indirizzi IP mascherati sono molto più diffusi. Qui, l'aggressore inserisce un indirizzo IP falsificato nel campo del mittente dei pacchetti SYN occultandone così la reale origine. Di solito gli aggressori preferiscono indirizzi IP che risultano liberi al momento dell'attacco per assicurarsi che i sistemi scelti a caso non rispondano con un pacchetto RST alle risposte SYN/ACK dei server attaccati terminando in questo modo la connessione.

In questa variante “distribuita” di attacco, il SYN flood parte contemporaneamente da molti computer. Di solito si tratta di una rete di computer hackerati, una cosiddetta botnet. I computer zombie della botnet si trovano sotto il controllo dell’aggressore e inviano sotto il suo comando pacchetti SYN alla vittima.

Di solito un server risponde a un singolo pacchetto SYN con più pacchetti SYN/ACK. Questa condizione può essere sfruttata dai cyber criminali per innescare un attacco SYN Flood Reflection. L'aggressore maschera l’indirizzo IP della vittima e fa partire un SYN Flood DDoS contro uno o più server estranei. Ciascuno dei server risponderà a ogni pacchetto SYN in entrata con più pacchetti SYN/ACK che saranno inviati alla vittima provocando una moltiplicazione del traffico di rete. La macchina della vittima sarà bombardata da un flood di pacchetti SYN/ACK con conseguente crash causato dal carico.

Il principio generale del SYN flood è già noto dal 1994 circa. Perciò oggi esistono numerose ed efficaci misure difensive per proteggersi. Alcune presentano anche aspetti negativi o funzionano soltanto secondo condizioni precise .In linea di massima non è così scontato distinguere pacchetti SYN maligni da quelli legittimi. La maggior parte delle misure difensive conosciute si applica sul server ma sono disponibili anche soluzioni di cloud computing.

Abbiamo già menzionato il backlog del SYN, che è parte del sistema operativo. Dal punto di vista concettuale potete immaginare il backlog del SYN come se fosse una tabella. Ciascuna casella contiene le informazioni per creare la singola connessione TCP. Il sistema operativo si occupa di gestire le connessioni. Solo dopo aver stabilito la connessione tramite il three-way handshake, viene inoltrato alle applicazioni in ascolto sulle porte e rimosso dal backlog del SYN.

Uno dei metodi più semplici per rafforzare un sistema contro gli attacchi SYN flood è proprio di aumentare la capacità del backlog del SYN. Ogni voce presente nel backlog del SYN occupa una quantità precisa di spazio nella memoria e questo limita il numero di voci possibili. Questo limite standard su Linux, ad esempio, è pari a meno di cento voci. Il valore però si può aumentare. In linea di principio, il backlog del SYN può contenere più di mille voci permettendovi di respingere gli attacchi SYN flood più piccoli.

Un altro metodo simile consiste nel cancellare le connessioni semi-aperte più vecchie dal backlog del SYN, dove possibile. In questo modo si libera lo spazio per una nuova connessione semi-aperta. Questo metodo, in combinazione con uno spazio maggiore sul backlog del SYN, permette di mantenere raggiungibile un sistema durante un attacco SYN flood. Questo metodo si è rivelato inefficace nel caso di un attacco volumetrico.

L’idea alla base di una SYN cache è semplice: invece di salvare un Transmission Control Block (TBC) completo nel backlog del SYN per ogni connessione semi-aperta, si mantiene soltanto un TBC minimo. Questa tecnica utilizza una funzione crittografica di hash per impedire all'aggressore di indovinare le informazioni crittografiche della connessione. La SYN cache si è rivelata una tecnica efficace. Solo in alcuni casi particolari si possono perdere i dati di connessione.

L’invenzione dei SYN cookies nel 1996 ha permesso di sviluppare ulteriormente il concetto di SYN cache. Qui si rinuncia del tutto all’utilizzo del Transmission Control Block come struttura di dati. Al suo posto si codificano i parametri rilevanti di connessione nella sequenza numerica del pacchetto SYN/ACK. La funzione crittografica di hash garantisce che l’aggressore non riesca a indovinare facilmente la sequenza numerica.

Un client legittimo risponde al pacchetto SYN/ACK con un pacchetto ACK e ricorre a una sequenza numerica particolare. Il server utilizza la sequenza numerica dl pacchetto ACK per verificare la crittografa della connessione e stabilire la connessione. L’utilizzo di SYN cookies rappresenta una protezione efficace da attacchi SYN flood. In casi particolari, però, può portare a una riduzione delle prestazioni.

Entrambe le tecniche sono utilizzate anche in combinazione. Normalmente si usa la SYN cache. Se la SYN cache si riempie, si passa ai SYN cookies. In questo modo si combinano gli aspetti positivi delle due tecniche.

La lotta contro gli attacchi DoS è nata quasi insieme a Internet. Con le botnet, gli aggressori moderni hanno a disposizione una potenza ben più elevata. Perciò gli attacchi DDoS relativi con il loro enorme flood di dati possono mettere in ginocchio anche i sistemi più forti. Per questo motivo oggi sono sempre di più i servizi che utilizzano provider di cloud globali.

L’idea alla base: distribuire il flusso di dati DDoS in entrata su tanti sistemi singoli permettendo di disperdere il carico totale dell'attacco e ridurre il picco su ogni singolo sistema. In questo modo la rete riesce a contrastare anche gli attacchi più potenti.

A livello di rete, oltre a quella dei filtri si sta diffondendo la tecnologia Anycast. Le richieste ai sistemi collegati da Anycast vengono inoltrate automaticamente al server più vicino geograficamente. Questo riesce perciò a sventare gli attacchi DDoS globali anche a livello locale. Le reti Anycast come Cloudflare convincono per la loro eleganza e resistenza.

Il blog di Cloudfare offre una panoramica interessante su tutti gli sviluppi correnti per la lotta agli attacchi SYN Flood. Oltre alla strategia di mitigazione basata sulle bot anche i pacchetti SYN Signaturen sembrano promettenti. Questi creano delle impronte leggibili dei pacchetti SYN in entrata. Dall’impronta è possibile risalire a informazioni del sistema operativo della macchina da cui è stato inviato in origine il pacchetto SYN. Durante un attacco SYN flood i pacchetti inviati falliscono all’analisi delle impronte e perciò vengono filtrati.