Come funzionano le connessioni TCP/IP
Transmission Control Protocol/Internet Protocol (TCP/IP) è una tecnologia fondamentale per la moderna rete di computer. È il modo in cui (per la maggior parte del tempo) il tuo computer richiede e riceve informazioni attraverso una rete e Internet. È completo di controllo degli errori, ritrasmissione di dati mancanti/corretti, e diverse altre importanti caratteristiche che rendono letteralmente affidabile e funzionale Internet come lo conosciamo. Tuttavia, per capire come viene abusato, dobbiamo prima capire come funziona.
Per brevità, non ci addentreremo nell’intero processo di connessione TCP/IP. Ci concentreremo solo sul processo iniziale di handshake a tre vie del TCP, poiché è tutto ciò che è rilevante per l’argomento di questo scritto.
Gli host di una rete che vogliono scambiare dati usando TCP devono prima negoziare una connessione. È qui che entra in gioco il TCP three-way handshake. Il processo di handshake permette a entrambi gli host di riconoscere il successo dell’invio e della ricezione delle comunicazioni di rete, così come di impostare la loro rispettiva sessione in previsione dello scambio di dati applicativi.
Fig. 1) TCP three-way handshake
Nella figura 1, vediamo un client che stabilisce una connessione TCP con un server. Il primo passo è che il client invii un pacchetto di sincronizzazione o SYN. Questo pacchetto ha due ruoli primari, il primo è quello di testare la capacità di raggiungere la risorsa remota. Se questo pacchetto viene instradato con successo, dice anche al server che un client remoto vuole iniziare il processo di negoziazione della connessione per lo scambio di dati. Il server risponde emettendo un pacchetto di sincronizzazione e conferma, o SYN-ACK, diretto al client che sta iniziando la connessione. La parte finale dell’handshake a tre vie è che il client risponda al SYN-ACK con un pacchetto finale di Acknowledgement, o ACK. Una volta che questo handshake è completo, la connessione è pronta per essere usata dall’applicazione per la trasmissione bidirezionale dei dati.
Il metodo più comune per il trasporto delle comunicazioni TCP è su Internet Protocol o IP. Questo significa che i pacchetti TCP sono comunicati tra il client e il server utilizzando datagrammi IP, indirizzati utilizzando indirizzi IP per ciascuno dei dispositivi.
Come funziona questo attacco
Gli aggressori armano questo processo di handshake, spoofando gli indirizzi IP di origine dei pacchetti SYN. Questo spoofing fa sì che il server invii il pacchetto SYN-ACK all’IP vittima, che il server crede abbia richiesto l’inizializzazione della sessione, agendo come un riflettore.
Fig. 2) Riflesso SYN-ACK
Nella figura 2, si può vedere una visualizzazione molto semplice di questo attacco. Tuttavia, questo non mostra come appare uno scenario di attacco reale. La realtà è che TCP è stato progettato per operare su reti inaffidabili, il che significa che un singolo SYN spoofed può innescare un server per inviare più SYN-ACK in rapida successione se non riceve l’ACK finale dell’handshake. Il numero di SYN-ACK da inviare e quanto velocemente inviarli è una metrica configurabile, quindi è difficile stimare esattamente quanti SYN-ACK una vittima mirata può ricevere in relazione al volume di pacchetti SYN spoofati che sono stati inviati dagli attaccanti.
Bassa larghezza di banda vs alto PPS
Gli attacchi SYN-ACK non sono i tipici attacchi di riflessione. Una delle attrazioni principali degli attacchi di riflessione basati su UDP è il loro fattore di amplificazione, o la dimensione del pacchetto che arriva alla vittima rispetto alla dimensione del pacchetto che un attaccante deve inviare. In molti casi, il fattore di amplificazione è molte volte quello della richiesta originale. Nel caso della riflessione CLDAP, per esempio, il pacchetto risultante è circa 50-70 volte più grande del pacchetto che l’attaccante deve inviare per innescare la riflessione. Gli attacchi di amplificazione sono spesso considerati volumetrici, tipicamente con l’obiettivo di saturare i collegamenti di rete utilizzati dai server e dalle applicazioni prese di mira.
Nel caso delle riflessioni SYN-ACK, la dimensione del pacchetto consegnato alla vittima è quasi la stessa del pacchetto inviato dall’attaccante. Diciamo “quasi la stessa dimensione” perché è possibile, e molto probabile, che mentre l’attaccante invia un pacchetto SYN di lunghezza minima, alcuni router sulla rete tra l’attaccante e la vittima possono anche modificare il pacchetto TCP per aggiungere informazioni di collegamento aggiuntive, come l’opzione Maximum Segment Size (MSS) TCP, aumentando la dimensione assoluta del traffico osservato dalla vittima. Questa opzione rappresenta 4 byte in più per pacchetto rispetto a quello inviato dall’aggressore.
20:56:32.296905 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xfa7c (correct), seq 1000, win 8192, urg 0, length 0
20:56:32.315637 IP (tos 0x0, ttl 124, id 4894, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6e18 (correct), seq 3609252029, ack 1001, win 60720,
options , length 0
Fig. 3) Amplificazione SYN-ACK a 4 byte
Questo non significa che questo attacco non sia una minaccia. Durante diversi attacchi coordinati contro i clienti Akamai, sono state osservate molteplici istanze di flood ad alto numero di pacchetti al secondo (PPS) utilizzando il traffico SYN-ACK riflesso. Mentre il traffico a bassa larghezza di banda ha meno probabilità di saturare i collegamenti, l’alto PPS può causare problemi all’attrezzatura di rete che tenta di elaborare e instradare il diluvio di SYN-ACKS che corre attraverso le reti.
Cosa un attaccante può e non può controllare
Gli attaccanti SYN-ACK dipendono dalle configurazioni TCP dei loro riflettori e da come gestiscono le connessioni TCP. Questo significa che gli attaccanti sono limitati in ciò che possono riflettere alla vittima. I ricercatori di Akamai hanno trascorso del tempo a testare contro diversi servizi abilitati TCP esposti su macchine in tutta Internet per vedere quale combinazione di flag TCP & opzioni potrebbe risultare negli scenari di attacco più impattanti. Tratteremo alcuni scenari di attacco, come differiscono e come gli aggressori potrebbero sfruttare gli attacchi SYN-ACK in futuro.
Opzioni TCP e SYN-ACKS imbottiti
Gli aggressori non possono controllare il contenuto di un pacchetto SYN-ACK. Mentre abbiamo visto SYN floods imbottiti per anni, l’idea di un SYN-ACK imbottito non è qualcosa che ci aspettiamo. Nel mondo reale, quando sono stati lanciati attacchi SYN-ACK, i pacchetti che arrivavano alle reti delle vittime avevano una lunghezza prevedibile di 44 byte. Come discusso in precedenza, questo ci informa che gli aggressori stavano molto probabilmente spingendo fuori pacchetti SYN senza opzioni di 40 byte, con le opzioni MSS molto probabilmente impostate dal dispositivo di rete sul percorso in transito. Questo risulta in un piccolo fattore di amplificazione, ma volevamo testare quanto grande potessimo ottenere SYN-ACK da server reali.
I test sono stati condotti utilizzando diverse variazioni di opzioni TCP. L’obiettivo dei test era quello di essere in grado di identificare le opzioni che potevano essere utilizzate in modo affidabile e risultare in una risposta SYN-ACK più grande da server scelti a caso su Internet. Le opzioni che potrebbero essere utilizzate da un attaccante con conseguente SYN-ACK più grandi sono Maximum Segment Size (MSS), Timestamp (TS), Selective ACK (SAckOK), Window Scale (WScale), & cookie TCP Fast Open (TFO).
Semplicemente utilizzando opzioni valide, un attaccante potrebbe consumare circa il 62% in più di larghezza di banda rispetto ad un pacchetto SYN minimo (72 byte contro 44 byte). Utilizzando queste opzioni, le intestazioni diminuiscono il rapporto di amplificazione (il 10% di amplificazione diventa il 6-7%); tuttavia, è ancora possibile ottenere l’amplificazione semplicemente omettendo l’opzione MSS, in quanto sarà impostata in transito indipendentemente dal fatto che l’attaccante la invii o meno.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options
, length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win
60192, options , length 0
Fig. 4) Imbottitura SYN-ACK con TFO
Durante i test, è stato possibile sfruttare il TS, SAckOK, WSCale, & le opzioni TCP TFO (e il padding NOP) per emettere un pacchetto SYN di 68 byte che ha prodotto una risposta SYN-ACK di 72 byte che è stata consegnata alla vittima, come si vede nella figura 4. Se un host non supporta TFO, un aggressore può ancora spingere un pacchetto SYN da 56 byte che risulta in un SYN-ACK da 60 byte che viene instradato alla rete della vittima, come si vede sotto in figura 5.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options
, length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192,
options , length 0
Fig. 5) SYN-ACK padding meno TFO
Amplificazione SYN-ACK
Una piccola quantità di amplificazione è possibile utilizzando gli attacchi SYN-ACK, ma è possibile aumentare questo fattore di amplificazione prendendo di mira lo spazio IP che è allocato ma non occupato (il che significa che l’IP è instradabile ma nessuna macchina è attualmente distribuita e/o gestisce il traffico di rete). Questo scenario permette agli aggressori di sfruttare appieno gli sforzi di ritrasmissione TCP, che a sua volta aumenta i fattori di amplificazione e il consumo di banda.
Quando una macchina normale riceve un SYN-ACK fuori stato da un riflettore, risponderà con un pacchetto RST come mostrato sotto nella Figura 6. Questo pacchetto RST sarà ricevuto dal riflettore, e la sessione TCP sul riflettore sarà chiusa.
21:33:15.173204 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xfa7b (correct), seq 1000, win 8192, urg 0, length 0
21:33:15.191517 IP (tos 0x0, ttl 124, id 46635, offset 0, flags , proto TCP (6), length 44)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xb751 (correct), seq 1209013908, ack 1001, win
60720, options , length 0
21:33:15.191558 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 6) il SYN-ACK fuori stato innesca una risposta RST
Se questo pacchetto SYN-ACK è destinato ad un indirizzo IP che è allocato ma non occupato, il SYN-ACK sarà instradato (impattando l’attrezzatura di rete lungo il percorso) ma non raggiungerà mai una macchina reale che emetterebbe un RST. Questa mancanza di pacchetti RST farà sì che il riflettore assuma la mancata consegna del SYN-ACK e cominci a tentare la ritrasmissione.
Nei test, il numero di tentativi di ritrasmissione è tipicamente tra 5 e 7 pacchetti SYN-ACK inviati alla vittima per ogni SYN inviato. Se supponiamo che un attaccante invii un SYN di 40 byte, possiamo aspettarci che 5-7 SYN-ACK di 44 byte attraversino la rete delle vittime. In uno scenario peggiore di 7 pacchetti ricevuti, questo risulta in una richiesta di 40 byte che genera 308 byte di pacchetti che arrivano ai confini della vittima, un fattore di amplificazione del 770%. Utilizzando le intestazioni delle opzioni TCP per generare SYN-ACK più grandi, un attaccante potrebbe spingere quei numeri a 56 byte, con conseguente 420 byte di traffico riflesso, un fattore di amplificazione del 750%.
21:12:24.647377 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 56)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0xab5d (correct), seq 1000, win 8192, urg 0, options , length 0
21:12:24.665340 IP (tos 0x0, ttl 124, id 46598, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfec2 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:24.965713 IP (tos 0x0, ttl 124, id 46784, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xfd96 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:26.965689 IP (tos 0x0, ttl 124, id 47738, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf5c6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:30.965750 IP (tos 0x0, ttl 124, id 49898, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xe626 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:38.965701 IP (tos 0x0, ttl 124, id 53757, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xc6e6 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
21:12:54.965710 IP (tos 0x0, ttl 124, id 61887, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x8866 (correct), seq 1309850370, ack 1001, win 60192, options , length 0
Fig. 7) SYN risulta in 6 SYN-ACKS
TFO, padding, e amplificazione
TCP Fast Open (TFO) è stato discusso in maggior dettaglio qui per coprire alcuni interessanti casi limite osservati nei test. Usando i cookie TFO, è possibile innescare risposte più grandi (12 byte in più per SYN-ACK); tuttavia, a causa di sviste nell’implementazione di TFO, queste misure possono alterare i fattori di amplificazione e, in diversi scenari, gli attacchi abilitati TFO possono essere più desiderabili.
Gli aggressori che tentano di sfruttare i riflettori abilitati TFO possono trovare fruttuoso farlo solo in determinate circostanze. Queste circostanze sarebbero i casi in cui non c’è spazio IP che non sia gestito da una macchina viva, se un attaccante deve dirigere i pacchetti SYN-ACK riflessi verso macchine reali che risponderanno con pacchetti RST, l’amplificazione della ritrasmissione TCP è essenzialmente irrilevante poiché il riflettore smetterà di inviare SYN-ACK alla ricezione della risposta RST dalle macchine della vittima.
Per rendere questa proposta ancora meno desiderabile, gli host abilitati TFO non includeranno l’opzione di intestazione di 12 byte per il cookie TFO nei pacchetti SYN-ACK aggiuntivi oltre al primo pacchetto emesso. Ciò significa in breve che l’amplificazione in questo scenario non è una serie di pacchetti da 72 byte che colpiscono la vittima. Nei test del mondo reale, è stato osservato che il primo SYN-ACK sarà di 72 byte, ma i seguenti 5-6 tentativi di ritrasmissione ometteranno questa opzione TCP e risulteranno in un pacchetto di 60 byte. In questo caso, un pacchetto di 72 byte risulta in una riflessione di 432 byte; essenzialmente, l’unico vantaggio sono i 12 byte aggiuntivi del primissimo pacchetto rispetto a una riflessione senza l’opzione cookie TFO.
20:51:46.333671 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34567 > y.y.y.y.443: Flags , cksum 0x1212 (correct), seq 1000, win 8192, urg 0, options , length 0
20:51:46.351665 IP (tos 0x0, ttl 124, id 51260, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x1f6c (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:46.651887 IP (tos 0x0, ttl 124, id 51447, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x6bb0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:48.651862 IP (tos 0x0, ttl 124, id 52323, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x63e0 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:51:52.651854 IP (tos 0x0, ttl 124, id 54181, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x5440 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:00.651876 IP (tos 0x0, ttl 124, id 58527, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0x3500 (correct), seq 3436032873, ack 1001, win 60192, options , length 0
20:52:16.651862 IP (tos 0x0, ttl 124, id 2147, offset 0, flags , proto TCP (6), length 60)
y.y.y.y.443 > x.x.x.x.34567: Flags , cksum 0xf67f (correct), seq 3436032873, ack 1001, win 60192, options , length 0
Fig. 8) Omissione del cookie TFO dopo la prima risposta
Gli host abilitati al TFO resettano le loro misure dei cookie di handshake dopo aver ricevuto un RST dalla macchina (o dalle macchine) vittima presa di mira. Ciò significa che un attaccante che prende di mira macchine reali che utilizzano riflettori abilitati TFO potrebbe causare in modo affidabile una serie di pacchetti SYN-ACK da 72 byte che arrivano agli end-point delle vittime.
Il fattore di amplificazione è solo 4 byte, assumendo che una richiesta di 68 byte dall’attaccante risulti in un SYN-ACK da 72 byte che arriva alla vittima seguito da un pacchetto RST dalla vittima al riflettore. Se questo accade continuamente, allora le sessioni TCP avviate sul riflettore tramite l’attaccante risulteranno sempre in un pacchetto SYN-ACK che include i byte aggiuntivi che sono l’opzione cookie TFO.
20:54:41.611605 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x8762 (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:41.629518 IP (tos 0x0, ttl 124, id 14354, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6ade (correct), seq 3714341928, ack 1001, win 60192, options , length 0
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6ade (correct), seq 3714341928, ack 1001, win 60192, options , length 0
20:54:41.629548 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:42.664171 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0xc1bd (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:42.682391 IP (tos 0x0, ttl 124, id 15171, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0x6d0a (correct), seq 3730789605, ack 1001, win 60192, options , length 0
20:54:42.682440 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
20:54:43.781512 IP (tos 0x0, ttl 64, id 1, offset 0, flags , proto TCP (6), length 68)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x7dde (correct), seq 1000, win 8192, urg 0, options , length 0
20:54:43.800464 IP (tos 0x0, ttl 124, id 15726, offset 0, flags , proto TCP (6), length 72)
y.y.y.y.443 > x.x.x.x.34568: Flags , cksum 0xf5fe (correct), seq 3748251272, ack 1001, win 60192, options , length 0
20:54:43.800534 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto TCP (6), length 40)
x.x.x.x.34568 > y.y.y.y.443: Flags , cksum 0x1aa1 (correct), seq 1001, win 0, length 0
Fig. 9) Inclusione del cookie TFO dopo RST
Preoccupazioni di mitigazione
Mitigare una riflessione SYN-ACK può essere difficile e deve essere fatto con attenzione. È molto facile mitigare eccessivamente questo tipo di attacco e causare danni autoinflitti ai client reali e alle sessioni TCP nelle reti di produzione. Queste sessioni colpite si tradurrebbero in problemi di connettività, prestazioni degradate e blocco di host/utenti legittimi sulle vostre reti. Queste misure di sovramitigazione possono avere effetti più lunghi e più impattanti dell’attacco stesso.
In molti casi, la sovramitigazione degli attacchi con impatto TCP può anche avere risultati inaspettati per le vittime. Durante le inondazioni SYN, per esempio, è comune che quando i servizi reali iniziano ad avere problemi di connettività, un’ondata di attacchi secondari sembra gonfiarsi in tutta la rete. In questi casi, la “seconda ondata” è tutt’altro ed è tipicamente il risultato di client/utenti reali che tentano di stabilire connessioni legittime senza successo; questo si traduce in un’ondata di pacchetti SYN più alti del normale, poiché i client colpiti continuano a tentare la ritrasmissione di pacchetti SYN non riconosciuti.
Una mitigazione eccessiva di un attacco SYN-ACK potrebbe probabilmente causare problemi e risultati simili, specialmente se la mitigazione avviene in un punto della rete in cui i clienti reali stanno facendo richieste legittime in uscita.
La VERA soluzione per gli attacchi di riflessione
Come per la maggior parte degli attacchi di spoofing, la vera soluzione non è qualcosa che rientra nel controllo di una singola organizzazione. Per affrontare realmente questo e altri problemi associati alle capacità di spoofing dobbiamo guardare all’IETF e agli operatori di rete. L’IETF ha pubblicato BCP38, che delinea come gli operatori di rete possono identificare e prevenire l’instradamento del traffico spoofed. Alla fine della giornata, è qualcosa che gli operatori di rete devono implementare e far rispettare se davvero speriamo di vedere questi tipi di attacchi spoofed/riflessi scomparire, o almeno diventare significativamente più difficili da orchestrare.
Riassunto finale
Gli attacchi SYN-ACK riflessi non sono qualcosa di nuovo; sono in realtà qualcosa di vecchio come il TCP stesso. La loro mancanza di popolarità ha più a che fare con altri attacchi riflessi basati su UDP che sono molto più preoccupanti e impattanti e generalmente un migliore set di strumenti per gli attaccanti. Non sono un effetto collaterale di un’implementazione difettosa, non sono un exploit, sono un sintomo dello spoofing IP su Internet che è ancora possibile quasi 20 anni dopo che la soluzione proposta per i proprietari e gli operatori di rete è stata redatta e finalizzata.
Detto questo, i vecchi attacchi possono ancora essere dolorosi, e i SYN-ACK riflessi non fanno eccezione. Le organizzazioni dovrebbero prendere in considerazione la possibilità di esaminare le loro capacità di mitigazione e le opzioni, dato che l’attrezzatura di rete può lottare per gestire alte inondazioni di traffico PPS attraverso i confini e le reti.
È importante sottolineare la reale possibilità di sovramitigazione per attacchi di questa natura e garantire che i tentativi di combattere questi tipi di attacchi non si traducano in interruzioni autoimposte… un compito che è molto più facile a dirsi che a farsi.