Durante los ataques de amplificación de DNS en un servidor DNS, observé que algunas solicitudes de DNS tienen para una pareja IP/puerto algo así como 104.49.96.196:80. Entiendo que se trata de una IP falsificada, pero ¿está bien considerar filtrar el puerto de la solicitud de DNS? Creo que no deberíamos esperar un puerto > 1023. ¿Es una suposición segura? En ese caso, creo que es una victoria fácil de detectar y no responder al ataque de amplificación de DNS (si el paquete llega al servidor DNS y el WAF no lo descarta).
Respuesta1
No, no es una suposición segura. No intente filtrar por puertos, esto no producirá consecuencias útiles. La forma en que un cliente maneja sus puertos locales es asunto suyo y, por lo tanto, como servidor, puede esperar recibir tráfico de todos los puertos. La división de Unix en 1024 es un legado arcaico del pasado que básicamente ya no significa nada hoy.
Si desea combatir la amplificación de DNS, además de las medidas "estándar" (como asegurarse de que realmente necesita manejar todo el tráfico que recibe, es decir, que no está completamente abierto), una de las formas más utilizadas hoy en día es RRL o básicamente limitación de velocidad.
Mira ahttps://www.infoblox.com/dns-security-resource-center/dns-security-solutions/dns-security-solutions-response-rate-limiting-rrl/para una introducción sobre el tema y enhttps://www.isc.org/docs/DNS-RRL-LISA14.pdfpara una presentación más técnica.
Respuesta2
Los clientes DNS deben tener un puerto de origen > 1023.
Si es <1024, solo debería ser el puerto de origen 53 si proviene de algún otro servidor DNS, pero eso es poco probable.
Verificar contcpdump port 53
Al mirarRFC6056ysimplificación con algunas muestrasPodríamos ir más allá y decir que cualquier pila de IP que se comporte bien no debería tener (tenía) un puerto de origen inferior a 49152 (primer puerto efímero). Sin embargo, la sección 3.2 contradice esto, al igual que las muestras.
Pero hasta que alguien pueda proporcionar una referencia al RFC que redefina el RFC6056, es seguro decir que el deporte <= 1023 no es válido.
Si por alguna razón hay una solicitud que falla, el cliente debe volver a intentarlo y, con suerte, obtener una solicitud exitosa. (Incluso si esto fallara, ignoraría esas implementaciones)