Il contesto è bilanciamento del carico basato sulla rete. Sarebbe bello se qualcuno potesse spiegare come vengono generati i temporali TCP ACK nella vita reale e le strategie di mitigazione pratiche per loro.
Modifica: chiarimento su "strategie di mitigazione". La piattaforma è composta da nginx server web / load balancer in esecuzione su Linux. Quindi apprezzerebbe l'interruttore pertinente da attivare (se esiste) per contrastarlo.
Quando un client e un server si connettono, conoscono la connessione tramite l'indirizzo IP di origine e indirizzo e i numeri di porta (sul client e sul server). Esistono due numeri di sequenza per entrambe le direzioni del flusso di connessione; i loro valori iniziali sono scelti casualmente. Ogni volta che una delle parti invia un pacchetto, quel pacchetto può parlare di entrambi numeri di sequenza: un pacchetto dal client può includere informazioni sul numero di sequenza per il flusso da client a server (ad esempio un "PUSH" ") ma anche informazioni sul numero di sequenza per il flusso da server a client (un" ACK ").
Se l'attaccante può fare in modo che il client e il server non siano d'accordo con un ampio margine su entrambi i numeri di sequenza, allora potrebbe verificarsi una tempesta ACK. Fondamentalmente, il client invia un pacchetto al server con un valore da server a client che il server trova ridicolmente off-the-mark. Il server risponde con un pacchetto che dice "caro cliente, sei gravemente in errore sul numero di sequenza corrente da server a client, prega di essere così gentile da modificare i tuoi modi". Comunque (questo è il punto nifty), quel pacchetto includerà anche un ACK dal server che documenta la nozione del server del numero di sequenza corrente da client a server ... che il client troverà assurdamente invalido. Questo richiederà al client di rispondere con un pacchetto che dice "caro server, si è gravemente sbagliando sull'attuale numero di sequenza da client a server, prega di essere così gentile da modificare i tuoi modi". Quel pacchetto conterrà anche un ACK. E il ciclo continua ...
La tempesta infuria finché uno dei pacchetti ACK è perso, ponendo fine alla partita di ping-pong. Tuttavia, ricomincia la prossima volta che il client o il server ha qualcosa da dire, perché sono ancora desincronizzati.
Le tempeste ACK si basano quindi sulla possibilità di desincronizzare il client e il server per i numeri di sequenza entrambi . Questo può essere fatto con le abilità semi-MitM: ad esempio, l'attaccante può osservare i pacchetti tra client e server, e anche iniettare alcuni pacchetti falsi, ma non bloccare i pacchetti esistenti. Questo è il modello di "l'attaccante si trova sulla stessa LAN, e l'interruttore è in realtà un hub (o è stato abbassato di livello a un comportamento simile a un hub dopo essere stato spammato a morte con pacchetti indesiderati casuali dall'attaccante)". Quando l'utente malintenzionato vede una connessione da client a server, invia immediatamente un pacchetto RST falso (come se il client avesse chiuso la connessione) e quindi un nuovo SYN falso proveniente dal client, con gli stessi numeri di porta, ma numeri di sequenza molto diversi .
Vedi questa presentazione per alcuni dettagli.
La difesa è relativamente facile: uno dei sistemi coinvolti in una tempesta ACK può rilevare che riceve e invia quantità eccessive di pacchetti di errore per una determinata connessione e semplicemente lo rilascia. La tempesta ACK può continuare fino a quando entrambi i sistemi sono pronti a rispondere a un ACK per un ACK; al primo pacchetto perso, la tempesta cessa. Se viene rilevata una tempesta, allora: 1. il sistema che rileva la tempesta può fermarla rifiutandosi di parteciparvi ancora e 2. la connessione è inviolabile, può essere eliminata senza cerimonie.