DDoS: un protocollo in cui la vittima dice "Non inviarmi traffico per N ms"?

Anche se in teoria sembra un'idea carina, penso che ci siano alcuni motivi per cui questo non è ancora stato implementato e non verrà implementato. Hanno principalmente a che fare con la complessità e la scalabilità:

Se ogni router su Internet ha bisogno di tenere traccia delle richieste da ogni host al traffico di accelerazione, ciò si tradurrebbe in un database molto grande che ogni router deve aggiornare e controllare per ogni pacchetto che viene instradato. Questo ha un enorme impatto sulle prestazioni del router.

Una seconda cosa da considerare è che cose come questa funzionano solo se ampiamente supportate. Le soluzioni come te proposte sono complesse, e prima che il consenso possa essere trovato nella IETF per definire gli standard su come implementare questo (se lo si trova), molto tempo sarà passato. Dopodiché, passa ancora più tempo prima che una grande quantità di router su internet sia passata al software che ha implementato tale funzione. Tutto sommato, può facilmente richiedere un certo numero di anni prima che tale idea venga convertita in uno standard implementato.

Un altro problema è la fiducia. Dovrai fornire un meccanismo per assicurarti che l'host o il router che richiede di richiedere la limitazione sia effettivamente responsabile dell'hosting di quell'IP. Senza questo, il meccanismo potrebbe effettivamente essere usato come uno strumento per eseguire un attacco DDoS, spoofando le richieste di limitazione per il target, interrompendo quindi tutto il traffico verso l'host. Il routing e la fiducia sono ancora una combinazione molto complessa. BGP, il protocollo di routing dinamico su cui è costruita Internet, è ancora basato principalmente sulla fiducia, e sempre più è chiaro che ci sono molte persone che gestiscono reti su Internet di cui semplicemente non ci si può fidare. Soluzioni come RPKI e BGPsec non sono ancora ampiamente implementate. L'aggiunta di un altro meccanismo basato sulla fiducia renderà le cose solo più complicate.

E ultimo ma non meno importante: non tutti beneficiano di non che inviano pacchetti. Se i pacchetti vengono accodati, questo potrebbe essere un onere per le reti lungo il percorso. Ma anche se questo non è il caso: molte reti fanno soldi trasportando pacchetti, e trasportare meno pacchetti significa guadagnare meno soldi. Se una rete ha una relazione diretta con la rete sotto attacco, può considerarlo un servizio (eventualmente pagato), altrimenti potrebbe ridurre il proprio reddito tramite limitazione. Certo, un sacco di reti si concentrano anche su Internet, ma potrebbero non farlo, e questo significherebbe che l'idea non funzionerà molto bene.

ICMP ha già un codice per "Comunicazione con host di destinazione è vietato in modo amministrativo" consulta questo documento come riferimento il router upstream dovrà accettare questo e i tuoi requisiti sono (per lo più) soddisfatti.

Ci sono una serie di ragioni per cui questa soluzione non è sufficiente, alcune già trattate nelle risposte. Tuttavia, il problema principale, in particolare con i moderni attacchi DoS, è la larghezza di banda.

Inizialmente, gli attacchi DoS riguardavano principalmente l'invio di un numero sufficiente di richieste a un server per inondare la capacità dei server di elaborare le richieste. Spesso si trattava di un problema di risorse sul server, ovvero non abbastanza risorse di CPU o di memoria. In molti casi, sarebbe interessato solo un singolo servizio. Ad esempio, il server Web potrebbe non rispondere a causa di troppe richieste, ma altri potrebbero ancora funzionare.

I moderni Dos, in particolare gli attacchi di tipo DDoS, ora parlano di flooding della rete. Hai così tanti dati in arrivo, il tuo firewall, il router e la rete interna diventano allagati. Parte del motivo per cui è così devastante è che non è possibile comunicare in modo efficace con qualcos'altro. Non è possibile inviare un messaggio a un router upstream perché la connessione è inondata: switch, firewall e router non rispondono. Anche se sai cosa vuoi dire al dispositivo / router upstream, non puoi far passare il messaggio.

Ecco perché la soluzione spesso coinvolge il fornitore di servizi a monte. O avete bisogno di un canale di comunicazione separato, che potrebbe anche essere una telefonata, per convincere il vostro fornitore a prendere qualche iniziativa, come la creazione di un "buco nero" BGP per l'indirizzo IP nella vostra rete che viene preso di mira. Questo "buco nero" invierà tutti i dati indirizzati al tuo indirizzo IP interno a un buco nero, in modo che la quantità di traffico proveniente dalla tubazione verso la rete cali e che tu possa ora inviare / ricevere altri dati. Il problema è che se si utilizza NAT o simili, in modo che si abbia realmente solo un indirizzo pubblico, il buco nero indica che la rete è effettivamente fuori servizio e il DoS ha avuto successo. D'altra parte, se disponi di più indirizzi IP pubblici, potresti essere fortunato e subire solo una parziale perdita di servizio.

L'altro problema con il tuo suggerimento è che per funzionare, deve essere veloce e leggero. Tuttavia, deve anche essere sicuro altrimenti rischieresti di creare un nuovo vettore DoS. ad esempio, se si utilizza un protocollo veloce senza connessione, potrebbe essere troppo facile falsificare l'indirizzo IP. Questo mi permetterebbe di inviare richieste al tuo router upstream facendo finta di essere tu a chiedere che non vengano inviati dati. Quindi, qualsiasi comando che possa influenzare i dati inviati deve essere sicuro e verificabile - ora avete un comando che richiede più potenza di elaborazione per elaborarli - moltiplicare quello per il numero di macchine e ora dovete avere router più potenti - più veloce con più memoria e questo si moltiplica quando ci si sposta dal router locale, al router ISP al router di segmento ecc.

Un segnale che proponi dovrebbe raggiungere un router upstream.

Il tuo server non può semplicemente segnalare all'ISP "non inviarmi pacchetti", perché allora nessuno può accedere al tuo servizio. (Riuscito con successo)

Devi tagliare l'attacco il più vicino possibile alla fonte per limitare il numero di utenti legittimi bloccati insieme all'attaccante.

Posso immaginare uno scenario in cui l'operatore del data center utilizza l'intervento umano o script per determinare quali router segnalare.

Mi concentrerò per un attimo sugli attacchi DDoS di esaurimento della larghezza di banda. Questi possono probabilmente essere risolti solo bloccando l'attacco a monte.

Sfortunatamente è comune che l'indirizzo di origine sia falsificato. Quindi non puoi usare traceroute ...

Affinché questo funzioni, ogni pacchetto dovrebbe avere un traceroute a sé stante. Questo è piuttosto un sovraccarico e avrebbe barriere di implementazione.

_{Potrei modificarlo più tardi quando avrò più tempo.}