¿Puedo evitar que BIND envíe un código de respuesta para consultas incorrectas?

¿Puedo evitar que BIND envíe un código de respuesta para consultas incorrectas?

Estoy ejecutando un servidor DNS de enlace autorizado. Estoy siguiendo todas las prácticas recomendadas y mi servidor es solo autorativo (no recursivo) con la limitación de velocidad habilitada.

BIND responde a consultas de zonas no autorizadas con código REFUSE. La limitación de velocidad está haciendo su trabajo impidiendo que mi servidor participe en cualquier ataque de amplificación udp a gran escala; sin embargo, preferiría eliminar todas y cada una de las respuestas de las zonas en las que no tengo autoridad.

¿Existe una opción de configuración para esto?

Respuesta1

Si bien no responder en el escenario exacto que describe en la pregunta (consulta falsificada en un posible ataque de amplificación, alternativamente, probar si su servidor es utilizable en tal ataque) estaría bien ya que ningún solucionador está esperando su respuesta, el problema es que no responder a las consultas puede causar problemas reales y su solución propuesta es más amplia que el escenario exacto que describió primero (considere que alguna zona que en realidad no tiene podría delegarse a su servidor de nombres, ya sea por accidente o intencionalmente).

Por lo general, no responder a las consultas no se considera una buena práctica para los servidores de nombres autorizados. Las razones para esto incluyen:

  • Los servidores de resolución rastrean la capacidad de respuesta/confiabilidad de los servidores autorizados con los que están tratando para mejorar su propia capacidad de respuesta. Esto se hace servidor por servidor, no consulta por consulta. Es decir, puede perjudicar la confiabilidad percibida actual de su servidor de nombres si termina sin responder a consultas (potencialmente mal dirigidas) de fuentes legítimas. Es posible engañar a los resolutores para que consideren que su servidor de nombres está totalmente inactivo (temporalmente, pero posiblemente una y otra vez)
  • Si no responder también puede terminar afectando las consultas "buenas" (¿tal vez basadas en una alta tasa de consultas, por ejemplo?), eso puede causar problemas adicionales que pueden no ser obvios a primera vista, como un mayor riesgo de ataques exitosos de envenenamiento de caché para cualquier zona no firmada a la que atienda (particularmente si un atacante puede inducir que su consulta caiga de manera confiable)

En cambio, generalmente desea limitar el tamaño de las respuestas para no proporcionar realmente la amplificación que buscan los atacantes (lo que parece que ya está haciendo):

  • Las consultas que no coinciden con ninguna zona (como en su ejemplo) deberían recibir una REFUSEDrespuesta vacía (en el pasado era común enviar una respuesta de referencia completa para la raíz)
  • Al implementar la limitación de velocidad, probablemente desee enviar TCrespuestas vacías y truncadas (establecer) en lugar de no responder, donde si un servidor de resolución legítimo real termina con una velocidad limitada, obtiene una respuesta y, si se marca como truncada, simplemente los activa para reenviar su consulta a través de TCP en su lugar
  • ANYEn primer lugar, el tipo de consulta tiene una utilidad real limitada y, a veces, se limita aún más con el fin de evitar formas de generar respuestas grandes. (Comominimal-anyen ENLACE)
  • (Y, por supuesto, no permitir en absoluto la recursividad en Internet en general)

En cuanto a no responder con BIND, la característica que permite no responder es la limitación de la tasa de respuesta (RRL), que tiene un slipparámetro de configuración para controlar la proporción entre truncar y descartar cuando alguien ha alcanzado el límite de velocidad. Sin embargo, tenga en cuenta que la eliminación es más relevante para un servidor de resolución que para un servidor autorizado (según la explicación anterior). Esto también se observa enSección RRL del manual BIND:

(Nota: las respuestas eliminadas de un servidor autorizado pueden reducir la dificultad de que un tercero falsifique con éxito una respuesta a un solucionador recursivo. La mejor seguridad contra respuestas falsificadas es que los operadores autorizados firmen sus zonas usando DNSSEC y que los operadores de resolución validen las respuestas. Cuando esto no es una opción, los operadores que están más preocupados por la integridad de la respuesta que por la mitigación de inundaciones pueden considerar establecer el deslizamiento en 1, lo que hace que todas las respuestas con velocidad limitada se trunquen en lugar de eliminarse. Esto reduce la efectividad de la limitación de velocidad contra la reflexión. ataques.)

Si se encuentra en una situación extrema en la que realmente tiene sentido una compensación diferente, puede considerar la slipperilla mencionada anteriormente de todos modos, o alguna herramienta con un conjunto diferente de perillas limitadoras de velocidad, comodnsdist.
Sin embargo, si se trata sólo de los niveles normales de ruido de fondo, probablemente esté causando nuevos problemas con poca ganancia al intentar solucionarlo.

información relacionada