Cosa mi impedisce di avviare un flood SYN-ACK usando i server HTTP?

Questo è un attacco noto da lungo tempo chiamato "DoS riflesso". Il motivo per cui in genere non causa un grosso problema per i difensori è che la ricezione di un SYN + ACK inaspettato non occupa nessuno stato sul server di destinazione; al massimo può inviare un pacchetto per dire "uh, mi dispiace, non mi aspettavo che" che possa causare una certa saturazione della loro connessione di rete in uno scenario in cui l'attaccante ha molta larghezza di banda smaltimento, ma soprattutto questo non è molto utile agli aggressori. La maggior parte delle volte, il firewall di fronte al servizio vedrà che non c'è una connessione aperta e basta rilasciare il pacchetto in silenzio. In generale, i pacchetti SYN e SYN + ACK sono molto piccoli, quindi è necessario un numero enorme di questi per causare problemi a un difensore in termini di inondazioni.

Al contrario, il motivo per cui l'inondazione SYN a volte è efficace non è che il collegamento di rete si satura, ma che lo stack TCP del server si aspetta che i nuovi client inviino un ACK e deve mantenere lo stato fino a quando il tempo di attesa scade, causando il limite di connessione semiaperto da raggiungere e nuove connessioni da utenti legittimi da negare. Ciò, tuttavia, è per lo più mitigato in scenari più sensati utilizzando le moderne implementazioni di stack TCP / IP e le misure difensive come i cookie TCP e le regole firewall / IPS.

Il tipo di attacchi di riflesso flooding più comunemente visti sono quelli che amplificano l'attacco nel processo , in cui piccoli pacchetti inviati da un utente malintenzionato generano pacchetti di risposta di grandi dimensioni dal server, consentendo all'aggressore di amplificare in modo significativo il volume del traffico. Questo è stato inizialmente inizialmente sfruttato contro i server DNS, ma più recentemente gli aggressori hanno identificato molti altri servizi che producono coefficienti di amplificazione ancora più elevati, in particolare NTP.

Nella maggior parte degli ISP o organizzazioni il tuo attacco potrebbe non funzionare per l'esterno, semplicemente perché è considerato una best practice del settore e un buon etiquetto per fare quello che il linguaggio di Cisco chiama filtraggio in uscita.

Con alcuni marchi di firewall, ovvero CheckPoint, se le misure anti-spoofing sono abilitate, dovrai solo collegare macchine sulla stessa rete con pacchetti contraffatti.

Semplicemente qualsiasi organizzazione, e in pratica molti ISP, filtrano nei loro firewall o gateway di confine, qualsiasi pacchetto che va su Internet che non ha come sorgente un proprio indirizzo IP.

Negli ISP e nelle grandi organizzazioni che ho gestito ho sempre implementato il filtro di ingresso ed uscita.

I filtri di entrata / uscita sono stati una pratica standard dalla fine degli anni '90, per mitigare i pacchetti contraffatti e gli attacchi DDOS. Molti non applicano ancora le misure.

Suggerimento tecnico: utilizza il filtro Ingress ed Egress per proteggere il bordo della rete

Come racconto aneddotico: ho gestito l'IP / comunicazione / sistemi in uno dei più grandi ISP di un paese del terzo mondo; eravamo ancora in gran parte legati al satellite, e specialmente la larghezza di banda dell'upstream era scarsa e scarsa. Una volta ho inoltrato un ticket all'helpdesk in cui un concorrente aveva acquistato un nostro modem e loro si sono lamentati il nostro servizio non stava inoltrando il loro spazio indirizzo IP .

Come racconto più serio: una volta ho disattivato per un paio di minuti il mio filtraggio delle entrate per i test, ed ero piuttosto in ginocchio a causa dell'errore del mio fornitore a monte di non filtrare correttamente il traffico video multicast.

Potrebbe funzionare, ma sembra doloroso.

Se ti ho capito bene, i SYN nudi sulla tua macchina "reflector" sarebbero stati identificati da qualsiasi IPS o firewall moderno come un tentativo di inondazione e sarebbero stati eliminati.

Un SYN-ACK non richiesto sulla vittima verrebbe eliminato dal firewall. Non andrebbe nemmeno su una porta di servizio.

[source] -ephermal:TCP(SYN):80-> [reflector] -80:TCP(SYN-ACK):ephermal-> [victim]

Ci vorrebbe un lotto di server Web senza la protezione Synflood che invii SYN-ACK per saturare una pipe da 1 Gbps.