Il termine Amplified reflected attackè nuovo per me e ho alcune domande a riguardo.
Ho sentito che succede principalmente con i server DNS - è vero?
Come proteggerlo?
Come fai a sapere se i tuoi server possono essere utilizzati in un simile attacco? È un problema di configurazione?
Risposte:
Innanzitutto, questo tipo di attacco non sta (principalmente) prendendo di mira il DNS stesso come suggerisce il titolo. Naturalmente creerà un carico aggiuntivo sui server DNS, ma lo scopo principale è DDoS qualcun altro. Una cattiva configurazione del server potrebbe peggiorare le cose, ma alla fine questo problema è inerente alla progettazione di DNS e UDP e, di fatto, a qualsiasi protocollo di comunicazione senza stato.
In pratica funziona così: un utente malintenzionato invia query ordinarie (DNS) a un server (DNS). Queste query vengono forgiate per apparire come se provenissero dal sistema di destinazione. Il server DNS ora risponde alla query, rinviando la risposta alla sua presunta origine: la vittima. Questo è il motivo per cui si chiama attacco di riflessione .
Ciò è possibile perché è possibile verificare l'origine della comunicazione senza stato (come DNS su UDP), in quanto è possibile fidarsi dell'indirizzo del mittente su una cartolina. Il server non ha proprio modo di decidere se una query è legittima o fa parte di un simile attacco. Il DNS è solo il protocollo più popolare qui perché ci sono un sacco di server per esso in giro e non hai bisogno di molte conoscenze tecniche o attrezzature speciali per (mis) utilizzarlo.
A peggiorare le cose (e in ogni caso efficiente in attacco), guarda la parte di amplificazione . Non sarebbe molto dannoso se il traffico dell'attaccante fosse di dimensioni uguali al traffico risultante. L'unico vantaggio per l'attaccante sarebbe che il suo indirizzo viene nascosto dietro il server DNS. Potrebbe falsificare direttamente l'indirizzo del mittente, non ci sarebbe assolutamente bisogno di reindirizzare su DNS. Ma il DNS risponde, e questo è un altro punto per cui il DNS è così popolare qui, può essere molto più grande della domanda. Puoi trovare numeri diversi su questo a seconda delle esatte query utilizzate, ma può arrivare fino a 1:60 se il server è abbastanza amichevole da eseguire query ricorsiveper te. Quindi l'attaccante non ha bisogno di molte macchine sotto il suo controllo per produrre molto traffico dannoso.
Dato che puoi facilmente trovare centinaia e migliaia di server DNS "aperti" su Internet pubblico, puoi fare rapidamente la matematica su quanto poco lavoro deve fare un attaccante se ogni server DNS aperto che conosce rifletterà le sue query amplificate di sessanta volte rispetto al bersaglio. Come ho detto all'inizio, non c'è davvero un buon modo per contromisure. Naturalmente molti server DNS sono aperti a tutti mentre non dovrebbero esserlo, a causa di un'errata configurazione. Ma ci sono tanti server aperti che devono essere aperti, perché esattamente quello è il loro scopo.
Sebbene non sia possibile stabilire se una richiesta fa parte di un attacco o meno, l'unica opzione è non eseguire più il server. Puoi giocherellare con la limitazione della frequenza e altri giocattoli, ma non puoi liberartene completamente. Se stai fornendo DNS per divertimento, puoi inserire nella lista nera l'IP di origine delle richieste. Ma se sei su una scala più ampia, ciò danneggerebbe ancora di più la vittima. Ricorda, tutto ciò che puoi vedere sul server DNS è l'indirizzo della vittima. Immagina che la tua azienda sia sotto attacco tramite il DNS del tuo provider e che il tuo provider decida di tagliare il servizio DNS per la tua azienda. L'attaccante potrebbe segnare questo come un bazillion di punti bonus per quanto riguarda la negazione del servizio .
Ad ogni modo, quegli attacchi si verificano tutto il giorno e la notte e sono considerati "rumori di fondo" di Internet. Se imposti un server DNS pubblico (ricorsivo) non ci vorrà molto prima che tu partecipi ad attacchi casuali. Ovviamente a volte le cose peggiorano quando le grandi infrastrutture (come anche i server root DNS) vengono utilizzate in modo improprio per amplificare, ma in quei casi le contromisure proattive vengono prese da personell fino a quando l'attacco non scende a livelli "normali".
Finora l'insegnamento. Per rispondere alla tua domanda, finalmente:
Sai che il tuo server è vulnerabile se risponde alle domande senza restrizioni. Periodo. Se stai eseguendo query ricorsive, il tuo server può generare il rapporto 1:60 menzionato per l'attaccante. Se serve solo non ricorsivo non è così male, ma comunque ...
Così...
allow-recursione alle allow-querydirettiveallow-recursionsu "none;".
iptables -A INPUT -p udp --dport 53 --set --name dnslimit
iptables -A INPUT -p udp --dport 53 -m recent --update --seconds 60 --hitcount 11 --name dnslimit -j DROP
Ora, con questi punti in mente, dovresti essere bravo ad andare. Di tanto in tanto potrebbe esserci ancora traffico dannoso sul tuo server, ma non in quantità tali da farti dormire bene la notte.