Esta es una pregunta canónica sobre la seguridad de los servidores de resolución de DNS públicos

Los servidores DNS abiertos parecen bastante limpios y convenientes, ya que proporcionan direcciones IP que podemos usar de manera consistente en toda nuestra empresa, independientemente de dónde se encuentren. Google y OpenDNS proporcionan esta funcionalidad, pero no estoy seguro de querer que estas compañías tengan acceso a nuestras consultas DNS.

Quiero configurar algo como esto para que lo use nuestra empresa, pero escucho mucho acerca de que esto es una práctica peligrosa (particularmente en lo que respecta a los ataques de amplificación ) y quiero asegurarme de que lo hagamos bien. ¿Qué cosas debo tener en cuenta al construir este tipo de entorno?

Hay algunas cosas que debes entender al respecto:

Este es un problema de ingeniería de red.

La mayoría de las personas que buscan configurar este tipo de entorno son administradores del sistema. ¡Eso es genial, yo también soy administrador del sistema! Parte del trabajo es comprender dónde terminan sus responsabilidades y comienza la de otra persona, y créanme, este no es un problema que los administradores del sistema puedan resolver por sí mismos. Este es el por qué:

• UDP es un protocolo sin estado. No hay apretón de manos del cliente.
• Las consultas contra un servidor DNS son una transacción de dos pasos no autenticada (consulta, respuesta). No hay forma de que el servidor sepa si la IP de origen está falsificada antes de responder.
• Cuando una consulta llega al servidor, ya es demasiado tarde para evitar un paquete UDP falso. La suplantación de identidad solo puede evitarse mediante una práctica conocida como filtrado de ingreso , un tema que está cubierto por los documentos BCP 38 y BCP 84 . Estos son implementados por los dispositivos de red ubicados frente a su servidor DNS.
• No podemos darle un tutorial sobre cómo configurar su centro de datos de principio a fin, o cómo implementar estas mejores prácticas. Estas cosas son muy específicas para sus propias necesidades. El formato de preguntas y respuestas simplemente no funciona para esto, y este sitio no pretende ser un sustituto de la contratación de personas profesionales para realizar un trabajo profesional.
• No asuma que su empresa de mil millones de dólares demasiado grande para fallar implementa correctamente el filtrado de ingreso.

Esta no es una mejor práctica. La mejor práctica es no hacer esto.

Es muy fácil configurar una resolución de DNS con conexión a Internet. Se necesita mucha menos investigación para configurar uno que para comprender los riesgos involucrados al hacerlo. Este es uno de esos casos donde las buenas intenciones sin darse cuenta permiten las fechorías (y el sufrimiento) de los demás.

• Si su servidor DNS responderá a cualquier dirección IP de origen que vea, está ejecutando un solucionador abierto. Estos se aprovechan constantemente en ataques de amplificación contra partes inocentes. Todos los días , los nuevos administradores de sistemas están trabajando para resolver los problemas abiertos , lo que hace que sea lucrativo que las personas malintencionadas las busquen constantemente. Realmente no hay duda de si su resolutor abierto se usará o no en un ataque: a partir de 2015, es casi un hecho. Puede que no sea inmediato, pero seguramente sucederá.
• Incluso si aplica una ACL usando su software DNS (es decir, BIND), todo lo que hace es limitar a qué paquetes DNS falsificados responderá su servidor. Es importante comprender que su infraestructura DNS se puede usar no solo para atacar los dispositivos en la ACL, sino también cualquier dispositivo de red entre su servidor DNS y los dispositivos por los que responderá. Si no posee el centro de datos, eso es un problema para algo más que usted.

Google y OpenDNS hacen esto, entonces ¿por qué no puedo?

A veces es necesario comparar el entusiasmo con la realidad. Aquí hay algunas preguntas difíciles de hacerse:

• ¿Es esto algo que desea configurar por capricho, o es algo que tiene unos pocos millones de dólares para invertir en hacerlo bien?

• ¿Tienes un equipo de seguridad dedicado? Equipo de abuso dedicado? ¿Ambos tienen los ciclos para lidiar con el abuso de su nueva infraestructura y las quejas que recibirán de terceros?

• ¿Tienes un equipo legal ?

• Cuando todo esto esté dicho y hecho, ¿todo este esfuerzo comenzará a pagarse de forma remota, generará ganancias para la compañía o excederá el valor monetario de lidiar con los inconvenientes que lo llevaron en esta dirección?

Para terminar, sé que este hilo es Q&A es una especie de decepción para la mayoría de ustedes que están vinculados a él. Serverfault está aquí para proporcionar respuestas, y una respuesta de "esta es una mala idea, no lo hagas" generalmente no se percibe como muy útil. Algunos problemas son mucho más complicados de lo que parecen ser al principio, y este es uno de ellos.

Si desea intentar que esto funcione, aún puede pedirnos ayuda mientras intenta implementar este tipo de solución. Lo principal a tener en cuenta es que el problema es demasiado grande por sí solo para que la respuesta se proporcione en un conveniente formato de preguntas y respuestas. Es necesario que haya invertido una cantidad significativa de tiempo investigando el tema y abordarnos con problemas lógicos específicos que haya encontrado durante su implementación. El propósito de estas preguntas y respuestas es brindarle una mejor comprensión del panorama general y ayudarlo a comprender por qué no podemos responder una pregunta tan amplia como esta.

¡Ayúdanos a mantener Internet seguro! :)

Ya sea que esté ejecutando un recursor DNS abierto o un servidor DNS autorizado, el problema es el mismo y la mayoría de las soluciones posibles también son las mismas.

La mejor solucion

Las cookies DNS son un estándar propuesto que brinda a los servidores DNS una manera de exigir a los clientes que envíen una cookie para demostrar que la dirección IP del cliente no ha sido falsificada. Esto costará un viaje de ida y vuelta adicional para la primera búsqueda, que es la sobrecarga más baja que cualquier solución podría ofrecer.

Reserva para clientes mayores

Debido a que las cookies de DNS aún no están estandarizadas, por supuesto será necesario admitir clientes más antiguos ahora y en los años venideros.

Puede calificar las solicitudes de límite de clientes sin soporte de cookies DNS. Pero los límites de velocidad hacen que sea más fácil para un atacante hacer DoS su servidor DNS. Tenga en cuenta que algunos servidores DNS tienen una función de límite de velocidad diseñada solo para servidores DNS autorizados. Como está preguntando acerca de un solucionador recursivo, tales implementaciones de limitación de velocidad pueden no ser aplicables en su caso. El límite de velocidad por diseño se convertirá en el cuello de botella para su servidor y, por lo tanto, un atacante deberá enviarle menos tráfico para que se eliminen las solicitudes legítimas de lo que lo haría si no hubiera un límite de velocidad.

Una ventaja de los límites de velocidad es que en caso de que un atacante inunde su servidor DNS con solicitudes DNS, es más probable que le quede capacidad que le permitirá enviar mensajes al servidor e investigar la situación. Además, los límites de velocidad pueden diseñarse para eliminar principalmente las solicitudes de IP de clientes que envían muchas solicitudes, lo que puede ser suficiente para protegerlo contra DoS de los atacantes que no tienen acceso a IP de clientes falsos.

Por esas razones, un límite de velocidad un poco por debajo de su capacidad real puede ser una buena idea, incluso si en realidad no protege contra la amplificación.

Usando TCP

Es posible forzar a un cliente a utilizar TCP enviando un código de error que indica que la respuesta es demasiado grande para UDP. Esto tiene un par de inconvenientes. Cuesta dos viajes de ida y vuelta adicionales. Y algunos clientes defectuosos no lo admiten.

El costo de dos viajes de ida y vuelta adicionales se puede limitar solo a la primera solicitud con este enfoque:

Cuando la IP del cliente no ha sido confirmada, el servidor DNS puede enviar una respuesta truncada para obligar al cliente a cambiar a TCP. La respuesta truncada puede ser tan corta como la solicitud (o más corta si el cliente usa EDNS0 y la respuesta no), lo que elimina la amplificación.

Cualquier IP de cliente que complete un protocolo de enlace TCP y envíe una solicitud de DNS en la conexión se puede incluir temporalmente en la lista blanca. Una vez en la lista blanca, esa IP puede enviar consultas UDP y recibir respuestas UDP de hasta 512 bytes (4096 bytes si se usa EDNS0). Si una respuesta UDP desencadena un mensaje de error ICMP, la IP se elimina de la lista blanca nuevamente.

El método también se puede revertir usando una lista negra, lo que significa que las direcciones IP de los clientes pueden realizar consultas a través de UDP de forma predeterminada, pero cualquier mensaje de error ICMP hace que la IP se ponga en una lista negra que necesita una consulta TCP para salir de la lista negra.

Un mapa de bits que cubra todas las direcciones IPv4 relevantes podría almacenarse en 444 MB de memoria. Las direcciones IPv6 tendrían que almacenarse de alguna otra manera.

No sé si algún servidor DNS ha implementado este enfoque.

También se ha informado que algunas pilas TCP pueden explotarse en ataques de amplificación. Sin embargo, eso se aplica a cualquier servicio basado en TCP y no solo a DNS. Dichas vulnerabilidades deben mitigarse actualizando a una versión del kernel donde la pila TCP ha sido reparada para no enviar más de un paquete en respuesta a un paquete SYN.