Il SYN flood è un attacco Denial of Service (DoS) che ha lo scopo di osta­co­la­re l’uso legittimo di un sistema online. Dal punto di vista con­cet­tua­le, possiamo im­ma­gi­na­re 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 rie­la­bo­ra­re la cor­ri­spon­den­za legittima. L'ag­gres­so­re ha raggiunto il suo scopo: il traffico regolare collassa.

Cos’è un SYN flood?

Il SYN Flood fa parte degli attacchi DoS. L’ag­gres­so­re invia a un sistema target un flood di pacchetti dati maligni. Lo scopo è di so­vrac­ca­ri­ca­re l’obiettivo e osta­co­lar­ne di con­se­guen­za l’uso legittimo.

Come il Ping of Death, il SYN Flood è un attacco di pro­to­col­lo. Questo tipo di attacchi mira a sfruttare le falle della con­nes­sio­ne di rete per mettere in ginocchio il sistema target. Il SYN Flood funziona perciò di­ver­sa­men­te rispetto agli attacchi vo­lu­me­tri­ci come il ping flood, l’UDP flood e l’HTTP flood,dove lo scopo dei ma­lin­ten­zio­na­ti è in­ghiot­ti­re quanta più banda possibile dalla rete dell’obiettivo.

Come fun­zio­na­no gli attacchi SYN flood

Il SYN flood è co­no­sciu­to anche come “attacco semi-aperto” ed è un tipo di attacco in­for­ma­ti­co rivolto alla con­nes­sio­ne di rete. L’ag­gres­so­re viola il three-way handshake del Tran­smis­sion Control Protocol (TCP). Invece di negoziare, come d’abitudine, una con­nes­sio­ne tra client e server, vengono lasciate sul server molte con­nes­sio­ni semi-aperte che impegnano le sue risorse che di con­se­guen­za non saranno più di­spo­ni­bi­li per il loro utilizzo di routine.

Vediamo per bene come funziona nor­mal­men­te la con­nes­sio­ne TCP e come, nel corso di un attacco SYN flood, ne viene di­stur­ba­to il principio.

Normale con­nes­sio­ne TCP tramite three-way handshake

Insieme all’Internet Protocol (IP), il Tran­smis­sion Control Protocol (TCP) rap­pre­sen­ta uno dei pilastri fon­da­men­ta­li del­l'In­ter­net. Il TCP è un pro­to­col­lo orientato a una con­nes­sio­ne e perciò il client e il server devono negoziare una con­nes­so­ne prima di potersi scambiare dati tra loro. Il three-way handshake serve a questo:

  1. Il client invia un pacchetto SYN (“syn­chro­ni­ze”) al server.- “Ciao, vorrei con­fi­gu­ra­re una con­nes­sio­ne con voi.”
  2. Il server risponde con un pacchetto SYN/ACK (ACK = “ac­k­no­w­led­ge”) e prepara una struttura di dati chiamata “Tran­smis­sion Control Block” (TCB) per la con­nes­sio­ne nel backlog del SYN.- “OK, con piacere. Ti prego di usare i seguenti parametri di con­nes­sio­ne.”
  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 con­nes­sio­ne è pronta e i dati possono essere inviati in entrambe le direzioni. Da parte del server, il Tra­smis­sion Control Block verrà rimosso dal backlog del SYN.- “Fan­ta­sti­co, grazie. Andiamo!”

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

Mec­ca­ni­smo di attacco del SYN flood

Durante un attacco SYN flood si verifica un errore massivo della con­nes­sio­ne TCP:

  1. L’ag­gres­so­re invia al server un pacchetto SYN e maschera il suo indirizzo IP.
  2. Il server crea una struttura di dati Tran­smis­sion Control Block nel backlog del SYN per la con­nes­sio­ne semi-aperta. Il TBC occupa memoria nel server .Per di più, le di­men­sio­ni del backlog del SYN sono limitate.
  3. Il server invia un pacchetto SYN/ACK all’indirizzo IP ma­sche­ra­to dell’ag­gres­so­re.
  4. Poiché dal server dell’ag­gres­so­re non entra alcun pacchetto ACK, per con­fer­ma­re la con­nes­sio­ne, il server continua a inviare altri pacchetti SYN/ACK al presunto client man­te­nen­do la con­nes­sio­ne semi-aperta.
  5. Mentre il server continua ad attendere una risposta, entrano nuovi pacchetti SYN dell’ag­gres­so­re che devono essere inseriti nel backlog del SYN.
  6. Da un momento preciso, non ci sarà più spazio di­spo­ni­bi­le nel backlog del SYN per altre con­nes­sio­ni semi-aperte. Il server re­spin­ge­rà altri pacchetti SYN in entrata e non sarà più rag­giun­gi­bi­le dal­l'e­ster­no.

Per innescare un SYN flood, l’ag­gres­so­re si serve di un software speciale. Per esempio, il tool hping è tra i più amati e uti­liz­za­ti per i pe­ne­tra­tion test e permette di simulare la banda negli attacchi alla rete. Per motivi di sicurezza, qui vi rap­pre­sen­te­re­mo solo un modello ap­pros­si­ma­ti­vo di codice hping per un SYN flood con indirizzo IP ma­sche­ra­to:

hping --syn --flood --rand-source -p <Port><indirizzo IP>

Sono in­te­res­san­ti le opzioni del comando:

  • L’opzione '--syn' indica allo strumento di uti­liz­za­re il pro­to­col­lo TCP e inviare pacchetti SYN.
  • Svolge un ruolo fon­da­men­ta­le l’opzione '--flood' che secondo la do­cu­men­ta­zio­ne del comando hping permette di inviare pacchetti nel modo più veloce possibile.
  • Con l'opzione '--rand-source' l’ag­gres­so­re maschera il suo indirizzo IP. Al posto del vero indirizzo IP del mittente, inserisce un indirizzo IP casuale.

Varianti degli attacchi SYN flood

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’ag­gres­so­re deve as­si­cu­rar­si che i pacchetti SYN/ACK inviati dal server non ricevano risposta. Se il di­spo­si­ti­vo dell’ag­gres­so­re ri­spon­des­se con un pacchetto ACK, questo eli­mi­ne­reb­be la voce cor­ri­spon­den­te sul server dal backlog del SYN.

Quando l’ag­gres­so­re maschera il suo indirizzo IP, allora i pacchetti SYN/ACK vengono in­di­riz­za­ti a estranei. Se un di­spo­si­ti­vo riceve un pacchetto SYN/ACK pro­ve­nien­te da un server senza aver prima inviato un pacchetto SYN, allora il di­spo­si­ti­vo invierà un pacchetto RST (RST = “reset”) ter­mi­nan­do in questo modo la con­nes­sio­ne. Un cyber criminale astuto vuole impedire anche questo per mantenere quante più con­nes­sio­ni possibili semi-aperte sul server.

Attacchi SYN flood diretti

Con un attacco diretto, l’ag­gres­so­re fa partire l'attacco SYN flood con il proprio indirizzo IP. Per essere sicuro che i pacchetti SYN/ACK in entrata siano respinti, l'ag­gres­so­re configura il firewall del suo di­spo­si­ti­vo. Un altro metodo è limitare i pacchetti SYN in uscita.

Nel caso di un attacco diretto, l'ag­gres­so­re agisce con il proprio indirizzo IP e perciò può essere re­la­ti­va­men­te semplice da rin­trac­cia­re. Per questo motivo si tratta di una variante uti­liz­za­ta di rado.

Attacchi SYN flood con indirizzo IP ma­sche­ra­to

Gli attacchi con gli indirizzi IP ma­sche­ra­ti sono molto più diffusi. Qui, l'ag­gres­so­re inserisce un indirizzo IP fal­si­fi­ca­to nel campo del mittente dei pacchetti SYN oc­cul­tan­do­ne così la reale origine. Di solito gli ag­gres­so­ri pre­fe­ri­sco­no indirizzi IP che risultano liberi al momento del­l'at­tac­co per as­si­cu­rar­si che i sistemi scelti a caso non ri­spon­da­no con un pacchetto RST alle risposte SYN/ACK dei server attaccati ter­mi­nan­do in questo modo la con­nes­sio­ne.

Attacchi SYN flood di tipo Di­stri­bu­ted Denial of service (DDoS)

In questa variante “di­stri­bui­ta” di attacco, il SYN flood parte con­tem­po­ra­nea­men­te da molti computer. Di solito si tratta di una rete di computer hackerati, una co­sid­det­ta botnet. I computer zombie della botnet si trovano sotto il controllo dell’ag­gres­so­re e inviano sotto il suo comando pacchetti SYN alla vittima.

Attacchi SYN flood re­flec­tion

Di solito un server risponde a un singolo pacchetto SYN con più pacchetti SYN/ACK. Questa con­di­zio­ne può essere sfruttata dai cyber criminali per innescare un attacco SYN Flood Re­flec­tion. L'ag­gres­so­re maschera l’indirizzo IP della vittima e fa partire un SYN Flood DDoS contro uno o più server estranei. Ciascuno dei server ri­spon­de­rà a ogni pacchetto SYN in entrata con più pacchetti SYN/ACK che saranno inviati alla vittima pro­vo­can­do una mol­ti­pli­ca­zio­ne del traffico di rete. La macchina della vittima sarà bom­bar­da­ta da un flood di pacchetti SYN/ACK con con­se­guen­te crash causato dal carico.

Misure difensive per pro­teg­ger­si dagli attacchi SYN Flood

Il principio generale del SYN flood è già noto dal 1994 circa. Perciò oggi esistono numerose ed efficaci misure difensive per pro­teg­ger­si. Alcune pre­sen­ta­no anche aspetti negativi o fun­zio­na­no soltanto secondo con­di­zio­ni precise .In linea di massima non è così scontato di­stin­gue­re pacchetti SYN maligni da quelli legittimi. La maggior parte delle misure difensive co­no­sciu­te si applica sul server ma sono di­spo­ni­bi­li anche soluzioni di cloud computing.

Aumentare la capacità del backlog del SYN

Abbiamo già men­zio­na­to il backlog del SYN, che è parte del sistema operativo. Dal punto di vista con­cet­tua­le potete im­ma­gi­na­re il backlog del SYN come se fosse una tabella. Ciascuna casella contiene le in­for­ma­zio­ni per creare la singola con­nes­sio­ne TCP. Il sistema operativo si occupa di gestire le con­nes­sio­ni. Solo dopo aver stabilito la con­nes­sio­ne tramite il three-way handshake, viene inoltrato alle ap­pli­ca­zio­ni in ascolto sulle porte e rimosso dal backlog del SYN.

Uno dei metodi più semplici per raf­for­za­re 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 per­met­ten­do­vi di re­spin­ge­re gli attacchi SYN flood più piccoli.

Riciclare le con­nes­sio­ni TCP semi-aperte più vecchie

Un altro metodo simile consiste nel can­cel­la­re le con­nes­sio­ni semi-aperte più vecchie dal backlog del SYN, dove possibile. In questo modo si libera lo spazio per una nuova con­nes­sio­ne semi-aperta. Questo metodo, in com­bi­na­zio­ne con uno spazio maggiore sul backlog del SYN, permette di mantenere rag­giun­gi­bi­le un sistema durante un attacco SYN flood. Questo metodo si è rivelato inef­fi­ca­ce nel caso di un attacco vo­lu­me­tri­co.

SYN cache e SYN cookies

L’idea alla base di una SYN cache è semplice: invece di salvare un Tran­smis­sion Control Block (TBC) completo nel backlog del SYN per ogni con­nes­sio­ne semi-aperta, si mantiene soltanto un TBC minimo. Questa tecnica utilizza una funzione crit­to­gra­fi­ca di hash per impedire al­l'ag­gres­so­re di in­do­vi­na­re le in­for­ma­zio­ni crit­to­gra­fi­che della con­nes­sio­ne. La SYN cache si è rivelata una tecnica efficace. Solo in alcuni casi par­ti­co­la­ri si possono perdere i dati di con­nes­sio­ne.

L’in­ven­zio­ne dei SYN cookies nel 1996 ha permesso di svi­lup­pa­re ul­te­rior­men­te il concetto di SYN cache. Qui si rinuncia del tutto all’utilizzo del Tran­smis­sion Control Block come struttura di dati. Al suo posto si co­di­fi­ca­no i parametri rilevanti di con­nes­sio­ne nella sequenza numerica del pacchetto SYN/ACK. La funzione crit­to­gra­fi­ca di hash ga­ran­ti­sce che l’ag­gres­so­re non riesca a in­do­vi­na­re fa­cil­men­te la sequenza numerica.

Un client legittimo risponde al pacchetto SYN/ACK con un pacchetto ACK e ricorre a una sequenza numerica par­ti­co­la­re. Il server utilizza la sequenza numerica dl pacchetto ACK per ve­ri­fi­ca­re la crit­to­gra­fa della con­nes­sio­ne e stabilire la con­nes­sio­ne. L’utilizzo di SYN cookies rap­pre­sen­ta una pro­te­zio­ne efficace da attacchi SYN flood. In casi par­ti­co­la­ri, però, può portare a una riduzione delle pre­sta­zio­ni.

Entrambe le tecniche sono uti­liz­za­te anche in com­bi­na­zio­ne. Nor­mal­men­te 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.

Mi­ti­ga­tion Service di cloud computing

La lotta contro gli attacchi DoS è nata quasi insieme a Internet. Con le botnet, gli ag­gres­so­ri moderni hanno a di­spo­si­zio­ne 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 uti­liz­za­no provider di cloud globali.

L’idea alla base: di­stri­bui­re il flusso di dati DDoS in entrata su tanti sistemi singoli per­met­ten­do di di­sper­de­re il carico totale del­l'at­tac­co e ridurre il picco su ogni singolo sistema. In questo modo la rete riesce a con­tra­sta­re anche gli attacchi più potenti.

A livello di rete, oltre a quella dei filtri si sta dif­fon­den­do la tec­no­lo­gia Anycast. Le richieste ai sistemi collegati da Anycast vengono inoltrate au­to­ma­ti­ca­men­te al server più vicino geo­gra­fi­ca­men­te. Questo riesce perciò a sventare gli attacchi DDoS globali anche a livello locale. Le reti Anycast come Clou­d­fla­re con­vin­co­no per la loro eleganza e re­si­sten­za.

Il blog di Cloudfare offre una pa­no­ra­mi­ca in­te­res­san­te su tutti gli sviluppi correnti per la lotta agli attacchi SYN Flood. Oltre alla strategia di mi­ti­ga­zio­ne basata sulle bot anche i pacchetti SYN Si­gna­tu­ren sembrano pro­met­ten­ti. Questi creano delle impronte leggibili dei pacchetti SYN in entrata. Dall’impronta è possibile risalire a in­for­ma­zio­ni del sistema operativo della macchina da cui è stato inviato in origine il pacchetto SYN. Durante un attacco SYN flood i pacchetti inviati fal­li­sco­no all’analisi delle impronte e perciò vengono filtrati.

In sintesi
25 anni dopo la loro scoperta come strumento di attacco, il SYN flood rap­pre­sen­ta ancora una minaccia per i provider dei siti. For­tu­na­ta­men­te esistono misure sempre più efficaci per pro­teg­ge­re il Tran­smis­sion Control Protocol più vul­ne­ra­bi­le dagli attacchi SYN flood.
Vai al menu prin­ci­pa­le