Perché un'università dovrebbe bloccare il traffico UDP in arrivo con la porta di destinazione 53?

20

Dal mio punto di vista, DNS utilizza UDP e la porta 53. Quali cose indesiderabili potrebbero accadere se i pacchetti UDP in arrivo sul numero di porta 53 non fossero bloccati?

AGGIORNAMENTO: I pacchetti hanno origine o sono destinati al server DNS locale gestito dall'università o al server DNS autorevole gestito dall'università sarebbe consentito.

domain-name-system security udp

— Daniel Kobe
fonte

19

Why would a university block incoming UDP traffic with destination port 53?- Perché non dovrebbero? O in altri termini: perché consentirebbero al traffico UDP (o TCP) in entrata con una porta di destinazione di 53 di transitare sulla rete / firewall in entrata, tranne per arrivare ai server dei nomi autorevoli per i nomi di dominio pubblico se quei server dei nomi erano ospitato sulla rete universitaria interna?

— joeqwerty,

2

Tutto il traffico UDP in entrata per la porta 53 è bloccato, ad eccezione dei server DNS dell'università? Questo suona sospettosamente come un tentativo di usare DNS per la censura per me. Anche se uno che non funzionerà affatto su qualsiasi sistema a cui riesco a pensare, dal momento che i client proveranno TCP quando le richieste UDP non torneranno. A meno che non ti sia dimenticato di menzionare che rilasciano anche il traffico TCP per la porta 53.

— Blacklight Shining

5

Come prassi generale, un amministratore di sistema non si chiede mai "c'è una buona ragione per cui dovrei bloccare questa porta". Di solito, hanno tutte le porte bloccate di default nella loro firewall, e si chiedono "c'è una molto buona ragione per cui dovrei aprire questa porta".

— Federico Poloni,

DNS non utilizza solo UDP, ma utilizza anche TCP. se consenti il traffico UDP, dovresti consentire anche TCP, altrimenti le cose si romperanno (e viceversa, se rilasci UDP, elimina anche TCP).

— Edheldil,

2

@FedericoPoloni Non far finta di fornire "accesso a Internet" se lo fai, perché non lo sei.

— David Schwartz,

40

La logica funziona così:

Solo i server DNS autorevoli che forniscono record a Internet devono essere esposti.
I server ricorsivi aperti esposti a Internet saranno inevitabilmente individuati da scansioni della rete e abusati. (Vedi la risposta dell'utente1700494)
La probabilità che qualcuno si alzi accidentalmente in piedi su un server ricorsivo esposto è maggiore di quella di un server DNS autorevole esposto. Questo perché molte appliance e configurazioni "out of the box" sono predefinite per consentire la ricorsione senza restrizioni. Le configurazioni autorevoli sono molto più personalizzate e si incontrano raramente.
Dato 1-3, l'eliminazione di tutto il traffico in ingresso non richiesto con una porta di destinazione di 53 protegge la rete. Nel raro caso in cui un altro server DNS autorevole debba essere aggiunto alla rete (un evento pianificato), le eccezioni possono essere definite in base alle necessità.

— Andrew B
fonte

24

Ad esempio, gli aggressori potrebbero utilizzare il server DNS dell'università come host di transito per l' attacco DDoS di amplificazione DNS

— user1700494
fonte

Nel link che hai pubblicato, sotto l'amplificazione DNS, menziona come potresti utilizzare una query di scavo per ricevere una risposta 50 volte maggiore di quella della query. Ma se il traffico UDP in arrivo sulla porta 53 è bloccato, come mai posso ancora fare una query di ricerca a un indirizzo universitario.

— Daniel Kobe,

1

@DanielKobe La zona DNS che possiede il record host in questione non è destinata a esistere solo sul server DNS a cui non è attualmente possibile inviare pacchetti UDP / 53. Potrebbe anche essere un'indicazione di una configurazione DNS split-horizon.

— Mathias R. Jessen,

11

La risposta di Andrew B è eccellente. Cosa ha detto.

Per rispondere alla domanda "Quali cose indesiderabili potrebbero accadere se i pacchetti UDP in arrivo sul numero di porta 53 non fossero bloccati?" più specificamente, ho cercato su Google "attacchi basati su DNS" e ho ottenuto questo utile articolo . Per parafrasare:

Attacco DoS a riflessione riflessa
Avvelenamento da cache
Inondazioni TCP SYN
Tunneling DNS
Dirottamento DNS
Attacco di base NXDOMAIN
Attacco al dominio fantasma
Attacco casuale al sottodominio
Attacco con blocco del dominio
Attacchi basati su botnet da dispositivi CPE

Non è un elenco conclusivo di possibili attacchi basati su DNS, solo dieci che un articolo ha trovato abbastanza degno di nota da menzionare.

In realtà, la risposta breve è: "Se non si dispone di esporla, non lo fanno."

— Katherine Villyard
fonte

3

"If you don't have to expose it, don't."che è vero per molte cose nella vita.

— user9517 supporta GoFundMonica l'

3

Lo stanno bloccando, perché possono ed è una ragionevole politica di sicurezza.

Il problema è spesso più grave che avere potenziali risolutori aperti - alla fine della giornata non importa configurare i server DNS in modo sicuro, senza essere risolutori aperti, con misure anti-DDOS quando qualsiasi server o macchina con un servizio DNS installato per errore e l'inoltro di richieste di inoltro DNS al server DNS principale consentirà a qualsiasi utente malintenzionato di ignorare la limitazione del traffico e le restrizioni di sicurezza implementate sui server DNS.

Le richieste appariranno anche dall'infrastruttura interna e potrebbero esporre nomi interni DNS e dettagli indesiderati dell'organizzazione interna / rete / indirizzamento IP.

Inoltre, secondo le regole di sicurezza della rete, minore è il numero di servizi e servizi che esponi all'esterno, minori sono le probabilità che vengano compromessi e utilizzati come punto di accesso per sfruttare un attacco alla tua infrastruttura dall'interno.

— Rui F Ribeiro
fonte

2

Di solito, quando si tratta di traffico UDP, si desidera essere restrittivi perché:

a) Rispetto a TCP, è più difficile per un filtro pacchetti determinare in modo affidabile se un pacchetto in arrivo è una risposta a una richiesta dall'interno della rete ... o una richiesta non richiesta. L'applicazione di ruoli client / server tramite un firewall di filtraggio dei pacchetti diventa quindi più difficile.

b) Qualsiasi processo che si lega a una porta UDP su un server o un computer client, anche se si lega solo a quella porta perché vuole effettuare una richiesta stessa, sarà esposto anche a pacchetti non richiesti, rendendo la sicurezza del sistema dipendente dal fatto che difetti nel processo che consentirebbero di sfruttarlo o confonderlo. In passato si sono verificati problemi di questo tipo, ad esempio con i client NTP. Con un client TCP, i dati non richiesti inviati a quel client verranno, nella maggior parte dei casi, eliminati dal sistema operativo.

c) Se si esegue NAT, un intenso traffico UDP può creare molto carico di lavoro per l'apparecchiatura NATing a causa di motivi simili a quelli di a)

— rackandboneman
fonte

0

Esistono strumenti che creano tunnel VPN utilizzando il protocollo DNS e la porta.

lo iodio è uno di questi. Permette di bypassare i firewall effettuando il tunneling completo del traffico attraverso un server che esegue questo software. Come indicato nella descrizione, utilizza il protocollo DNS.

Questo e strumenti simili potrebbero essere la ragione di questa limitazione.

— Gerhard
fonte

2

È possibile eseguire il tunneling dell'IP su quasi tutti i protocolli applicativi comuni, per non parlare di TLS, quindi non è certo un buon motivo per eliminare il traffico. Inoltre, potresti pensare che uno schema IP-over-DNS si leghi a una porta effimera lato client (come fanno i normali client DNS), piuttosto che alla porta 53.

— Blacklight Shining