Rilevamento
L'obiettivo di un attacco DNS riflesso è quello di inviare grandi volumi di traffico di rete su un host al fine di far cadere il traffico legittimo. Viene scelto quando l'attaccante non controlla abbastanza larghezza di banda per superare la larghezza di banda del bersaglio. È in gran parte irrilevante che la destinazione stia eseguendo o meno un server DNS poiché il danno è in genere già fatto quando i pacchetti raggiungono il server.
Il primo sintomo che vedrai è che il tuo server non risponde sulla rete. Se si dispone di una connessione fuori banda (ad esempio, fisicamente seduti davanti alla tastiera o utilizzando un iLOM, ALOM, iDrac, qualunque) il server avrà probabilmente un carico basso.
Se sospetti un attacco DNS riflesso, puoi utilizzare tcpdump
per cercare un numero elevato di risposte DNS che non hai richiesto. Tenere traccia delle richieste e delle risposte può essere difficile, ma se non stai facendo richieste nessuna , tutte le risposte fanno parte dell'attacco.
tcpdump -A -n dst port 53 and not host <local IP address>
L'opzione -n
è importante qui perché dice a tcpdump
di non fare ricerche DNS, che in questo tipo di attacco scadranno. Ovviamente <local IP address>
dovrebbe essere sostituito con il tuo indirizzo IP in uscita.
Sopravvivenza
Se stai effettivamente eseguendo un name server, la randomizzazione della porta sorgente può aiutare a ridurre il carico causato da queste risposte fasulle. Dan Kaminsky ha diretto una collaborazione alcuni anni fa che ha reso questa parte standard di ogni moderno name server.
Alcuni firewall stateful possono tracciare "sessioni" UDP. La configurazione del firewall per eliminare qualsiasi elemento in ingresso sulla porta 53 che non fa parte di una sessione stabilita potrebbe impedire alle risposte fasulle di raggiungere un servizio valido sulla macchina, il che significa che i pacchetti non devono essere elaborati. Una regola DROP
è migliore di una regola REJECT
qui perché una regola REJECT
invia effettivamente una risposta ICMP al server dei nomi inviandoti la risposta DNS fasulla (che utilizza una maggiore larghezza di banda) mentre la regola DROP
si ferma appena tutto proprio lì e non spreca ulteriore larghezza di banda.
Sempre supponendo che tu stia utilizzando un server dei nomi, assicurati che la memorizzazione nella cache sia attiva e funzionante. (In realtà, fallo ora comunque. I server upstream ti ringrazieranno.)
Purtroppo, queste tre cose sono praticamente una goccia nell'oceano se la larghezza di banda del provider di hosting è stata esaurita, il che è spesso il caso.
Le due strategie di maggior successo per sopravvivere su un DoS basato su larghezza di banda sono
- Maggiore larghezza di banda rispetto all'attaccante.
- Assumere qualcuno che lo faccia.
Se il collo di bottiglia si trova all'interno della rete del tuo server di hosting, potrebbero essere in grado di filtrare ulteriormente il traffico finché puoi dare loro qualcosa di concreto e preciso come "eliminare tutti i pacchetti UDP in arrivo con la porta di destinazione 53".
Se è all'esterno o ai margini della loro rete o se non riescono a filtrare così tanto traffico, il passo successivo è una società specializzata nella mitigazione degli attacchi DoS. Ci sono numerose scelte in questi giorni e non posso davvero raccomandare nessuno di loro senza esperienza personale. C'è un elenco rapido su ServerFault . Il consenso generale è che sono costosi, ma spesso meno del tempo di inattività o della richiesta di estorsione che segue immediatamente l'attacco.
Anche se tieni sotto attacco un po 'di attenzione, ho sentito che a volte il DoS è semplicemente una diversione prima / dopo / mentre gli aggressori si intrufolano e rubano i dati.