¿Por qué una universidad bloquearía el tráfico UDP entrante con el puerto de destino 53?

20

Según tengo entendido, DNS utiliza UDP y el puerto 53. ¿Qué cosas indeseables podrían suceder si los paquetes UDP entrantes al puerto número 53 no estuvieran bloqueados?

ACTUALIZACIÓN: Los paquetes se originan o están destinados al servidor DNS local operado por la universidad o se permitiría un servidor DNS autorizado operado por la universidad.

domain-name-system security udp

— Daniel Kobe
fuente

19

Why would a university block incoming UDP traffic with destination port 53?- ¿Por qué no lo harían? O dicho de otra manera: ¿por qué permitirían que el tráfico UDP (o TCP) entrante con un puerto de destino de 53 transite la red / firewall entrante, excepto para llegar a los servidores de nombres autorizados para los nombres de dominio público si esos servidores de nombres fueran alojado en la red interna de la universidad?

— joeqwerty

2

¿Todo el tráfico UDP entrante para el puerto 53 está bloqueado, excepto a los propios servidores DNS de la universidad? Eso suena sospechosamente como un intento de usar DNS para censurarme. Aunque uno que no funcionará en absoluto en ningún sistema que se me ocurra, ya que los clientes simplemente intentarán TCP cuando las solicitudes UDP no vuelvan. A menos que haya olvidado mencionar que también eliminan el tráfico TCP para el puerto 53.

— Blacklight Shining

55

Como práctica general, un administrador del sistema nunca se pregunta "¿hay alguna buena razón por la que deba bloquear este puerto?". Por lo general, tienen todos los puertos bloqueados por defecto en su firewall, y se preguntan "¿hay una muy buena razón por la que debería abrir este puerto".

— Federico Poloni

DNS no usa solo UDP, también usa TCP. si permite el tráfico UDP, también debe permitir TCP, o las cosas se romperán (y viceversa, si deja caer UDP, también deje caer TCP).

— Edheldil

2

@FedericoPoloni Simplemente no finjas que estás proporcionando "acceso a Internet" si haces esto, porque no lo estás haciendo.

— David Schwartz

40

La lógica funciona así:

Solo los servidores DNS autorizados que proporcionan registros a Internet deben estar expuestos.
Los servidores recursivos abiertos que están expuestos a Internet inevitablemente se encontrarán en escaneos de red y se abusarán de ellos. (Ver la respuesta del usuario 1700494)
La probabilidad de que alguien detenga accidentalmente un servidor recursivo expuesto es mayor que la de un servidor DNS autorizado expuesto. Esto se debe a que muchos dispositivos y configuraciones "listas para usar" predeterminadas permiten una recursión sin restricciones. Las configuraciones autoritativas son mucho más personalizadas y se encuentran con poca frecuencia.
Dado 1-3, descartar todo el tráfico entrante no solicitado con un puerto de destino de 53 protege la red. En el raro caso de que sea necesario agregar otro servidor DNS autorizado a la red (un evento planificado), las excepciones se pueden definir según sea necesario.

— Andrew B
fuente

24

Por ejemplo, los atacantes podrían usar el servidor DNS de la universidad como host de tránsito para el ataque DDoS de amplificación de DNS

— usuario1700494
fuente

En el enlace que publicó, bajo amplificación dns, menciona cómo podría usar una consulta de excavación para recibir una respuesta 50 veces mayor que la consulta. Pero si el tráfico UDP entrante en el puerto 53 está bloqueado, ¿cómo es que todavía puedo hacer una consulta de excavación a la dirección de una universidad?

— Daniel Kobe

1

@DanielKobe La zona DNS que posee el registro de host en cuestión no está destinada a existir solo en el servidor DNS al que actualmente no puede enviar paquetes UDP / 53. También podría ser una indicación de una configuración de DNS de horizonte dividido.

— Mathias R. Jessen

11

La respuesta de Andrew B es excelente. Lo que dijo.

Para responder a la pregunta "¿Qué cosas indeseables podrían suceder si los paquetes UDP entrantes al puerto número 53 no estuvieran bloqueados?" más específicamente, busqué en Google "ataques basados en DNS" y obtuve este útil artículo . Parafrasear:

Ataque DoS reflejado distribuido
Envenenamiento de caché
TCP SYN inundaciones
Túnel de DNS
Secuestro de DNS
Ataque básico de NXDOMAIN
Ataque de dominio fantasma
Ataque de subdominio aleatorio
Ataque de bloqueo de dominio
Ataques basados en botnet desde dispositivos CPE

Esa no es una lista concluyente de posibles ataques basados en DNS, solo diez que un artículo encontró lo suficientemente notables como para mencionarlos.

Realmente, la respuesta corta es "Si no tienes que exponerlo, no lo hagas".

— Katherine Villyard
fuente

3

"If you don't have to expose it, don't."lo cual es cierto para muchas cosas en la vida.

— user9517 es compatible con GoFundMonica

3

Lo están bloqueando, porque pueden y es una política de seguridad sensata.

El problema suele ser más grave que tener posibles solucionadores abiertos: al final del día, no importa configurar servidores DNS de forma segura, sin ser solucionadores abiertos, con medidas anti-DDOS cuando cualquier servidor o máquina con un servicio DNS instalado por error y realizar solicitudes de reenvío de DNS al servidor DNS principal permitirá que cualquier atacante evite las limitaciones de tráfico y las restricciones de seguridad implementadas en sus servidores DNS.

Las solicitudes también parecerán provenir de la infraestructura interna y pueden exponer nombres internos de DNS y detalles no deseados de la organización interna / red / direccionamiento IP.

Además, según las reglas de seguridad de la red, cuanto menor sea el número de servicios y servicios que exponga al exterior, menos probabilidades de que se vean comprometidos y se utilicen como punto de entrada para aprovechar un ataque a su infraestructura desde el interior.

— Rui F Ribeiro
fuente

2

Por lo general, cuando se trata del tráfico UDP, desea ser restrictivo porque:

a) En comparación con TCP, es más difícil para un filtro de paquetes determinar de manera confiable si un paquete entrante es una respuesta a una solicitud desde dentro de la red ... o una solicitud no solicitada. Hacer cumplir los roles de cliente / servidor a través de un firewall de filtrado de paquetes se vuelve más difícil.

b) Cualquier proceso que se una a un puerto UDP en un servidor o computadora cliente, incluso si solo se une a ese puerto porque quiere hacer una solicitud, también estará expuesto a paquetes no solicitados, lo que hace que la seguridad del sistema dependa de que no haya defectos en el proceso que permitirían explotarlo o confundirlo. Ha habido problemas con, por ejemplo, clientes NTP en el pasado. Con un cliente TCP, los datos no solicitados enviados a ese cliente serán, en la mayoría de los casos, descartados por el sistema operativo.

c) Si está ejecutando NAT, el tráfico UDP pesado puede crear mucha carga de trabajo para el equipo NATing debido a razones similares a las de a)

— rackandboneman
fuente

0

Existen herramientas que crean un túnel VPN utilizando el protocolo y el puerto DNS.

El yodo es uno de ellos. Permite evitar los firewalls al hacer un túnel del tráfico por completo a través de un servidor que ejecuta este software. Como dice la descripción, utiliza el protocolo DNS.

Esta y otras herramientas similares podrían ser la razón de esta limitación.

— Gerhard
fuente

2

Puede hacer un túnel IP sobre casi cualquiera de los protocolos de aplicación comunes, sin mencionar TLS, por lo que esa no es una buena razón para dejar caer el tráfico. Además, pensaría que un esquema de IP sobre DNS se uniría a un puerto efímero del lado del cliente (como lo hacen los clientes DNS normales), en lugar del puerto 53.

— Blacklight Shining