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


20

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é.


19
Why would a university block incoming UDP traffic with destination port 53?- Pourquoi pas? Ou en d'autres termes: pourquoi autoriseraient-ils le trafic UDP (ou TCP) entrant avec un port de destination 53 à transiter par le réseau / pare-feu entrant, sauf pour accéder aux serveurs de noms faisant autorité pour le ou les noms de domaine public si ces serveurs de noms étaient hébergé sur le réseau universitaire interne?
joeqwerty

2
Tout le trafic UDP entrant pour le port 53 est bloqué, sauf vers les propres serveurs DNS de l'université? Cela ressemble étrangement à une tentative d'utiliser DNS pour la censure pour moi. Bien que celui-ci ne fonctionnera pas du tout sur n'importe quel système auquel je peux penser, car les clients essaieront simplement TCP lorsque les demandes UDP ne reviendront pas. À moins que vous n'ayez oublié de mentionner qu'ils abandonnent également le trafic TCP pour le port 53.
Blacklight Shining

5
En règle générale, un administrateur système ne se demande jamais "existe-t-il une bonne raison pour laquelle je dois bloquer ce port". Habituellement, ils ont tous les ports bloqués par défaut dans leur pare-feu, et ils se demandent "y a-t-il une très bonne raison pour laquelle je devrais ouvrir ce port".
Federico Poloni

DNS n'utilise pas seulement UDP, il utilise également TCP. si vous autorisez le trafic UDP, vous devez également autoriser TCP, sinon les choses se briseront (et vice versa, si vous supprimez UDP, supprimez TCP également).
Edheldil

2
@FedericoPoloni Ne prétendez pas que vous fournissez un "accès Internet" si vous le faites, car vous ne l'êtes pas.
David Schwartz

Réponses:


40

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.

24

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


Dans le lien que vous avez publié, sous amplification DNS, il indique comment vous pouvez utiliser une requête Dig pour recevoir une réponse 50 fois supérieure à la requête. Mais si le trafic UDP entrant sur le port 53 est bloqué, comment se fait-il que je puisse toujours faire une requête de fouille vers une adresse universitaire.
Daniel Kobe

1
@DanielKobe La zone DNS propriétaire de l'enregistrement hôte en question ne doit pas exister uniquement sur le serveur DNS auquel vous ne pouvez pas actuellement envoyer de paquets UDP / 53. Cela pourrait également être une indication d'une configuration DNS à horizon divisé.
Mathias R. Jessen

11

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. »


3
"If you don't have to expose it, don't."ce qui est vrai pour beaucoup de choses dans la vie.
user9517 prend en charge GoFundMonica

3

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.


2

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)


0

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.


2
Vous pouvez tunneler IP sur à peu près tous les protocoles d'application courants, sans parler de TLS, ce n'est donc pas une bonne raison de supprimer le trafic. En outre, vous penseriez qu'un schéma IP sur DNS se lierait à un port client éphémère (comme le font les clients DNS ordinaires), plutôt qu'au port 53.
Blacklight Shining
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.