Questa è una domanda canonica sulla protezione dei resolver DNS pubblici

I server DNS aperti sembrano piuttosto ordinati e convenienti, in quanto forniscono indirizzi IP che possiamo utilizzare in modo coerente in tutta la nostra azienda indipendentemente da dove si trovano. Google e OpenDNS forniscono questa funzionalità, ma non sono sicuro di volere che queste aziende abbiano accesso alle nostre query DNS.

Voglio creare qualcosa del genere per l'utilizzo da parte della nostra azienda, ma sento molto parlare di questa pratica pericolosa (in particolare per quanto riguarda gli attacchi di amplificazione ) e voglio assicurarmi che lo facciamo nel modo giusto. Quali cose devo tenere a mente quando costruisco questo tipo di ambiente?

Ci sono alcune cose che devi capire andando in questo:

Questo è un problema di ingegneria della rete.

La maggior parte delle persone che stanno cercando di impostare questo tipo di ambiente sono amministratori di sistema. Fantastico, sono anche un amministratore di sistema! Parte del lavoro è capire dove finiscono le tue responsabilità e quelle di qualcun altro, e credimi, questo non è un problema che gli amministratori di sistema possono risolvere da soli. Ecco perché:

• UDP è un protocollo senza stato. Nessuna stretta di mano del client.
• Le query su un server DNS sono transazioni in due passaggi non autenticate (query, risposta). Non è possibile per il server sapere se l'IP di origine è stato falsificato prima che risponda.
• Quando una query ha raggiunto il server, è già troppo tardi per impedire un pacchetto UDP contraffatto. Lo spoofing può essere prevenuto solo da una pratica nota come filtro di ingresso , argomento trattato dai documenti BCP 38 e BCP 84 . Questi sono implementati dai dispositivi di rete posti di fronte al tuo server DNS.
• Non possiamo darti una panoramica su come impostare il tuo datacenter da un capo all'altro o su come implementare queste migliori pratiche. Queste cose sono molto specifiche per le tue esigenze. Il formato di domande e risposte non funziona proprio per questo, e questo sito non è inteso come sostituto dell'assunzione di professionisti per svolgere attività professionali.
• Non dare per scontato che la tua azienda troppo grande per fallire abbia implementato correttamente il filtro degli ingressi.

Questa non è una buona pratica. La migliore pratica non è fare questo.

È molto semplice configurare un resolver DNS con connessione Internet. Ci vuole molta meno ricerca per crearne una che per capire i rischi che comporta. Questo è uno di quei casi in cui le buone intenzioni abilitano inavvertitamente i misfatti (e la sofferenza) degli altri.

• Se il tuo server DNS risponderà a qualsiasi indirizzo IP di origine che vede, stai eseguendo un risolutore aperto. Questi vengono costantemente sfruttati negli attacchi di amplificazione contro parti innocenti. I nuovi amministratori di sistema stanno schierando risolutori aperti ogni giorno , il che rende redditizio per le persone maligne scansionarli costantemente. Non c'è davvero dubbio se il tuo risolutore aperto verrà o meno utilizzato in un attacco: dal 2015 è praticamente scontato. Potrebbe non essere immediato, ma accadrà di sicuro.
• Anche se applichi un ACL usando il tuo software DNS (es. BIND), tutto ciò limita i pacchetti DNS contraffatti a cui il tuo server risponderà. È importante capire che la tua infrastruttura DNS può essere utilizzata non solo per attaccare i dispositivi nell'ACL, ma anche qualsiasi dispositivo di rete tra il tuo server DNS e i dispositivi per cui risponderà. Se non possiedi il datacenter, questo è un problema per più di te.

Google e OpenDNS fanno questo, quindi perché non posso?

A volte è necessario soppesare l'entusiasmo contro la realtà. Ecco alcune domande difficili da porsi:

• È qualcosa che vuoi creare per capriccio o è qualcosa che hai qualche milione di dollari da investire per farlo nel modo giusto?

• Hai un team di sicurezza dedicato? Team dedicato agli abusi? Entrambi hanno i cicli per gestire l'abuso della tua nuova infrastruttura e i reclami che riceverai da soggetti esterni?

• Hai una squadra legale ?

• Quando tutto ciò viene detto e fatto, tutti questi sforzi inizieranno anche in remoto a pagare per se stesso, a generare profitti per l'azienda o a superare il valore monetario di affrontare l'inconveniente che ti ha portato in questa direzione?

In conclusione, so che questa discussione è che le domande e risposte sono una specie di delusione per la maggior parte di voi che vi sono collegate. Serverfault è qui per fornire risposte e una risposta di "questa è una cattiva idea, non farlo" di solito non è percepita come molto utile. Alcuni problemi sono molto più complicati di quanto sembri essere all'inizio, e questo è uno di questi.

Se vuoi provare a farlo funzionare, puoi comunque chiederci aiuto mentre cerchi di implementare questo tipo di soluzione. La cosa principale da capire è che il problema è di per sé troppo grande perché la risposta sia fornita in un comodo formato di domande e risposte. Devi aver già investito molto tempo nella ricerca dell'argomento e affrontarci con problemi logici specifici che hai riscontrato durante l'implementazione. Lo scopo di queste domande e risposte è darti una migliore comprensione del quadro più ampio e aiutarti a capire perché non possiamo rispondere a una domanda così ampia come questa.

Aiutaci a proteggere Internet! :)

Sia che si stia eseguendo un ricursore DNS aperto o un server DNS autorevole, il problema è lo stesso e la maggior parte delle possibili soluzioni sono uguali.

La migliore soluzione

I cookie DNS sono uno standard proposto che offre ai server DNS un modo per richiedere ai client di inviare un cookie al fine di dimostrare che l'indirizzo IP del client non è stato falsificato. Questo costerà un ulteriore andata e ritorno per la prima ricerca, che è il costo minimo più basso che una soluzione possa offrire.

Fallback per i clienti più anziani

Poiché i cookie DNS non sono ancora standardizzati, sarà ovviamente necessario supportare i clienti più vecchi ora e per gli anni a venire.

È possibile valutare le richieste di limite dai client senza il supporto dei cookie DNS. Ma i limiti di velocità rendono più facile per un utente malintenzionato eseguire il tuo server DNS. Attenzione che alcuni server DNS hanno una funzione di limite di velocità progettata solo per server DNS autorevoli. Dato che stai chiedendo un risolutore ricorsivo, tali implementazioni di limitazione della frequenza potrebbero non essere applicabili a te. Il limite di velocità in base alla progettazione diventerà il collo di bottiglia per il tuo server e quindi un utente malintenzionato dovrà inviarti meno traffico per causare la caduta delle richieste legittime rispetto a quelle che avrebbe se non ci fosse un limite di velocità.

Un vantaggio dei limiti di velocità è che nel caso in cui un utente malintenzionato inonda il server DNS con richieste DNS, è più probabile che rimanga una capacità che ti consentirà di accedere al server e indagare sulla situazione. Inoltre, è possibile progettare limiti di velocità per eliminare principalmente le richieste dagli IP dei client che inviano molte richieste, il che potrebbe essere sufficiente per proteggerti dal DoS dagli aggressori che non hanno accesso agli IP client di spoofing.

Per questi motivi, un limite di velocità leggermente inferiore alla tua effettiva capacità può essere una buona idea, anche se in realtà non protegge dall'amplificazione.

Usando TCP

È possibile forzare un client a utilizzare TCP inviando un codice di errore che indica che la risposta è troppo grande per UDP. Questo ha un paio di inconvenienti. Costa due viaggi di andata e ritorno aggiuntivi. E alcuni client difettosi non lo supportano.

Il costo di due roundtrip aggiuntivi può essere limitato alla sola prima richiesta utilizzando questo approccio:

Quando l'IP client non è stato confermato, il server DNS può inviare una risposta troncata per forzare il client a passare a TCP. La risposta troncata può essere breve quanto la richiesta (o più breve se il client utilizza EDNS0 e la risposta no) che elimina l'amplificazione.

Qualsiasi IP client che completa un handshake TCP e invia una richiesta DNS sulla connessione può essere temporaneamente autorizzato. Una volta autorizzato, l'IP può inviare query UDP e ricevere risposte UDP fino a 512 byte (4096 byte se si utilizza EDNS0). Se una risposta UDP attiva un messaggio di errore ICMP, l'IP viene nuovamente rimosso dalla whitelist.

Il metodo può anche essere invertito usando una lista nera, il che significa che gli IP client possono eseguire query su UDP per impostazione predefinita, ma qualsiasi messaggio di errore ICMP fa sì che l'IP venga inserito nella lista nera che richiede una query TCP per uscire dalla lista nera.

Una bitmap che copre tutti gli indirizzi IPv4 rilevanti potrebbe essere memorizzata in 444 MB di memoria. Gli indirizzi IPv6 dovrebbero essere memorizzati in qualche altro modo.

Non so se qualche server DNS abbia implementato questo approccio.

È stato anche riferito che alcuni stack TCP possono essere sfruttati negli attacchi di amplificazione. Ciò vale tuttavia per qualsiasi servizio basato su TCP e non solo per il DNS. Tali vulnerabilità dovrebbero essere mitigate aggiornando una versione del kernel in cui lo stack TCP è stato corretto in modo da non inviare più di un pacchetto in risposta a un pacchetto SYN.