Pourquoi une université bloquerait-elle le trafic UDP entrant avec le port de destination 53?

D'après ma compréhension, le DNS utilise UDP et le port 53. Quelles choses indésirables pourraient se produire si les paquets UDP entrants vers le port 53 n'étaient pas bloqués?

MISE À JOUR: Les paquets proviennent ou sont destinés au serveur DNS local exploité par l'université ou au serveur DNS faisant autorité géré par l'université serait autorisé.

La logique fonctionne comme ceci:

1. Seuls les serveurs DNS faisant autorité qui fournissent des enregistrements sur Internet doivent être exposés.
2. Les serveurs récursifs ouverts qui sont exposés à Internet seront inévitablement détectés par les analyses de réseau et abusés. (Voir la réponse de user1700494)
3. La probabilité qu'une personne lève accidentellement un serveur récursif exposé est supérieure à celle d'un serveur DNS faisant autorité exposé. Cela est dû au fait que de nombreux appareils et configurations "prêtes à l'emploi" autorisent par défaut la récursion sans restriction. Les configurations faisant autorité sont beaucoup plus personnalisées et rarement rencontrées.
4. De 1 à 3, la suppression de tout le trafic entrant non sollicité avec un port de destination de 53 protège le réseau. Dans le cas rare où un autre serveur DNS faisant autorité doit être ajouté au réseau (un événement planifié), des exceptions peuvent être définies selon les besoins.

Par exemple, les attaquants pourraient utiliser le serveur DNS de l'université comme hôte de transit pour l' attaque DDoS d'amplification DNS

La réponse d'Andrew B est excellente. Ce qu'il a dit.

Pour répondre à la question "Quelles sont les choses indésirables qui pourraient se produire si les paquets UDP entrants vers le port numéro 53 n'étaient pas bloqués?" plus précisément, j'ai recherché sur Google les «attaques basées sur DNS» et j'ai obtenu cet article pratique . Paraphraser:

1. Attaque DoS par réflexion distribuée
2. Empoisonnement du cache
3. Inondations TCP SYN
4. Tunnellisation DNS
5. Détournement de DNS
6. Attaque de base NXDOMAIN
7. Attaque de domaine fantôme
8. Attaque aléatoire de sous-domaine
9. Attaque de verrouillage de domaine
10. Attaques basées sur le botnet à partir d'appareils CPE

Ce n'est pas une liste concluante d'attaques basées sur DNS possibles, juste dix qu'un article a trouvé assez notable pour mentionner.

Vraiment, la réponse est « Si vous n'avez de l' exposer, non. »

Ils le bloquent, car ils le peuvent et c'est une politique de sécurité sensée.

Le problème est souvent plus grave que d'avoir des résolveurs ouverts potentiels - à la fin de la journée, cela n'a pas d'importance de configurer les serveurs DNS en toute sécurité, sans être des résolveurs ouverts, avec des mesures anti-DDOS lorsqu'un serveur ou une machine avec un service DNS installé par erreur , et faire des demandes de transfert DNS vers le serveur DNS principal permettra à n'importe quel attaquant de contourner votre limitation de trafic et les restrictions de sécurité mises en œuvre sur vos serveurs DNS.

Les demandes sembleront également provenir de l'infrastructure interne et peuvent exposer des noms internes DNS et des détails indésirables de l'organisation interne / du réseau / de l'adressage IP.

De plus, selon les règles de sécurité du réseau, moins vous exposez de services et de services à l'extérieur, moins il y a de chances qu'ils soient compromis et utilisés comme point d'entrée pour tirer parti d'une attaque contre votre infrastructure de l'intérieur.

Habituellement, en ce qui concerne le trafic UDP, vous voulez être restrictif car:

a) Comparé à TCP, il est plus difficile pour un filtre de paquets de déterminer de manière fiable si un paquet entrant est une réponse à une demande de l'intérieur du réseau ... ou une demande non sollicitée. L'application des rôles client / serveur via un pare-feu de filtrage de paquets devient ainsi plus difficile.

b) Tout processus qui se lie à un port UDP sur un serveur ou un ordinateur client, même s'il se lie uniquement à ce port parce qu'il veut faire lui-même une demande, sera également exposé à des paquets non sollicités, ce qui rend la sécurité du système dépendante de l'absence de défauts dans le processus qui permettraient de l'exploiter ou de le confondre. Il y a eu de tels problèmes avec, par exemple, des clients NTP dans le passé. Avec un client TCP, les données non sollicitées envoyées à ce client seront, dans la plupart des cas, rejetées par le système d'exploitation.

c) Si vous exécutez NAT, un trafic UDP lourd peut créer une charge de travail importante pour l'équipement NATing pour des raisons similaires à celles du point a)

Il existe des outils qui créent un tunnel VPN en utilisant le protocole DNS et le port.

l'iode en fait partie. Il permet de contourner les pare-feu en tunnelant complètement le trafic via un serveur exécutant ce logiciel. Comme l'indique la description, il utilise le protocole DNS.

Cet outil et des outils similaires peuvent être à l'origine de cette limitation.