Servidores DNS recursivos orientados al público - reglas de iptables

Ejecutamos servidores DNS recursivos orientados al público en máquinas Linux. Hemos sido utilizados para ataques de amplificación de DNS. ¿Existen iptablesreglas recomendadas que ayuden a mitigar estos ataques?

La solución obvia es limitar los paquetes DNS salientes a un cierto nivel de tráfico. Pero esperaba encontrar algo un poco más inteligente para que un ataque simplemente bloquee el tráfico a la dirección IP de la víctima.

He buscado consejos y sugerencias, pero todos parecen ser "no ejecute servidores de nombres recursivos públicos". Desafortunadamente, estamos respaldados en una situación en la que las cosas que no son fáciles de cambiar se romperán si no lo hacemos, y esto se debe a las decisiones tomadas hace más de una década antes de que estos ataques fueran un problema.

Todo el tipo de apesta a un escenario de "no es mi problema" que no es realmente tu culpa y debería / podría resolverse al 100% tomando las medidas apropiadas, independientemente de cuán "difícil" o "difícil" sea, y eso está terminando tu Servidor recursivo abierto .

Elimínelo gradualmente: informe a los clientes que este servidor desaparecerá a partir de la fecha X. Después de ese tiempo, necesitan instalar un parche (suponiendo que tenga uno) para evitar que use su servidor DNS. Esto se hace todo el tiempo. ¿Administradores de redes, administradores de red, técnicos de soporte, programadores? Lo entendemos ; Esto ocurre al final de la vida útil todo el tiempo, porque es un procedimiento operativo estándar para que un proveedor / proveedor de servicios / socio nos diga que dejemos de usar algo después de la fecha X. No siempre nos gusta, pero es un hecho de la vida en TI.

Dice que no tiene este problema en los dispositivos actuales, por lo que supongo que ha resuelto este problema con una actualización de firmware o parche. Sé que dijiste que no puedes tocar el dispositivo, pero seguramente ellos sí. Quiero decir, si están permitiendo que estas cajas te llamen a casa, no pueden ser tan analistas sobre quién está haciendo qué en sus dispositivos; podría tener una configuración de proxy inverso para todo lo que saben, así que, ¿por qué no hacer que instalen un parche que solucione esto o les digan que usen sus propios servidores DNS ? Seguramente su dispositivo es compatible con DHCP; No puedo pensar en un dispositivo de red (no importa qué tan viejo / frágil / extraño) que no .

Si no puede hacer eso, lo siguiente que debe hacer es controlar quién puede acceder a su servidor recursivo : usted dice que es "difícil saber" quién lo está usando y cómo, pero es hora de averiguarlo con certeza y comenzar a soltar el tráfico que es no legítimo

Estas son organizaciones "cuasi militares / gubernamentales", ¿verdad? Bueno, probablemente son parte de un netblock legítimo que poseen; Estos dispositivos no son enrutadores domésticos detrás de IP dinámicas. Descubrir. Comuníquese con ellos, explique el problema y cómo les está ahorrando mucho dinero al no forzar un reemplazo de firmware o producto si solo pueden confirmar la red / IP de bloqueo de red que el dispositivo utilizará para acceder a su servidor DNS.

Esto se hace todo el tiempo: tengo varios clientes que restringen el acceso a la extranet o los oyentes HL7 a los socios de atención médica de esta manera; no es tan dificilpara que completen un formulario y proporcionen la IP y / o el bloqueo de red de los que debería esperar tráfico: si quieren acceder a la extranet, tienen que darme una IP o subred. Y esto rara vez es un objetivo móvil, por lo que no es como si se vieran inundados con cientos de solicitudes de cambio de IP todos los días: las grandes redes de hospitales del campus que poseen sus propios bloques de red con cientos de subredes y miles y miles de IP de host me dan rutinariamente un puñado de direcciones IP o una subred que debería esperar; Una vez más, estos no son usuarios de computadoras portátiles que deambulan por todo el campus todo el tiempo, entonces, ¿por qué esperaría ver los paquetes fuente UDP desde una dirección IP en constante cambio? Claramente estoy haciendo una suposición aquí, pero apuesto a que no es tanto como piensas para <100s de dispositivos. Sí, será una ACL larga y sí,

Si por alguna razón los canales de comunicación no están abiertos (o alguien tiene demasiado miedo o no puede molestarse en ponerse en contacto con estos propietarios de dispositivos heredados y hacer esto correctamente), debe establecer una línea base de uso / actividad normal para que pueda formular alguna otra estrategia que ayudará (pero no evitará) su participación en los ataques de amplificación de DNS.

Un funcionamiento prolongado tcpdumpdebería funcionar filtrando en UDP 53 entrante y el registro detallado en la aplicación del servidor DNS. También me gustaría comenzar a recopilar direcciones IP / bloques de red / información geoIP de origen (¿son todos sus clientes en los EE. UU.? Bloquee todo lo demás) porque, como usted dice, no está agregando ningún dispositivo nuevo, simplemente está proporcionando un legado servicio a instalaciones existentes.

Esto también lo ayudará a comprender qué tipos de registros se solicitan y para qué dominios, por quién y con qué frecuencia : para que la amplificación de DNS funcione según lo previsto, el atacante debe poder solicitar un tipo de registro grande (1) a un dominio funcional (2).

1. "tipo de registro grande": ¿sus dispositivos incluso necesitan registros TXT o SOA para poder ser resueltos por su servidor DNS recursivo? Es posible que pueda especificar qué tipos de registros son válidos en su servidor DNS; Creo que es posible con BIND y quizás con DNS de Windows, pero tendrías que investigar un poco. Si su servidor DNS responde SERVFAILa cualquier registro TXT o SOA, y al menos esa respuesta es un orden de magnitud (o dos) menor que la carga útil prevista. Obviamente, usted sigue siendo "parte del problema" porque la víctima falsificada aún recibiría esas SERVFAILrespuestas de su servidor, pero al menos no las está criticando y tal vez su servidor DNS sea "excluido" de la (s) lista (s) recolectada (s) los bots usan con el tiempo por no "cooperar".

2. "dominio funcional": puede incluir en la lista blanca solo dominios que sean válidos. Hago esto en mis configuraciones de centro de datos reforzadas donde los servidores solo necesitan Windows Update, Symantec, etc. para funcionar. Sin embargo, solo está mitigando el daño que está causando en este punto: la víctima aún sería bombardeada NXDOMAINo SERVFAILrespondería desde su servidor porque su servidor aún respondería a la IP de origen falsificada. Una vez más, el script Bot también puede actualizar automáticamente su lista de servidores abiertos en función de los resultados, por lo que esto podría eliminar su servidor.

También usaría alguna forma de limitación de velocidad, como han sugerido otros, ya sea a nivel de aplicación (es decir, tamaño del mensaje, limitaciones de solicitudes por cliente) o al nivel de firewall (ver las otras respuestas), pero nuevamente, tienes que hacer un análisis para asegurarte de que no estás matando el tráfico legítimo.

Un sistema de detección de intrusiones que se haya sintonizado y / o entrenado (nuevamente, necesita una línea de base aquí) también debería ser capaz de detectar el tráfico anormal a lo largo del tiempo por fuente o volumen, pero es probable que tenga que cuidar / ajustar / monitorear regularmente para evitar falsos positivos y / o ver si realmente está evitando ataques.

Al final del día, debe preguntarse si todo este esfuerzo vale la pena o si simplemente debe insistir en que se haga lo correcto y eso elimina el problema en primer lugar.

Depende del tipo de limitación de velocidad que desea hacer.

La limitación de velocidad con iptablesestá realmente más destinada a limitar los paquetes entrantes, ya que los paquetes hasta el límite coincidirán con el filtro y se aplicará el objetivo especificado (por ejemplo, ACCEPT). Probablemente tendría un objetivo posterior para los DROPpaquetes que no coinciden con el filtro. Y aunque iptablestiene un QUEUEobjetivo, simplemente pasa el paquete al espacio de usuario donde necesita suministrar su propia aplicación de cola. También puede calificar los paquetes salientes con límite, pero pocas personas realmente quieren comenzar a descartar el tráfico saliente.

iptables caída del límite de velocidad:

iptables -A INPUT -p udp --port 53 -m hashlimit --hashlimit 1/minute --hashlimit-burst 5 -j ACCEPT
iptables -A INPUT -p udp --port 53 -j DROP

El uso en hashlimitlugar de limitle dará un límite de velocidad por IP de destino. Es decir, cinco paquetes a 8.8.8.8 que alcanzan el límite evitarán que los paquetes se envíen a 8.8.4.4, mientras que hashlimitsi 8.8.8.8 está al máximo, aún puede alcanzar 8.8.4.4, que suena más como lo que desea.

Si no desea que se eliminen los paquetes que superen el límite, entonces lo que realmente desea es tc. tcregulará el flujo para obtener un flujo constante y agradable en lugar de mucho tráfico con ráfagas. En el lado entrante, los paquetes se entregan a la aplicación más lentamente, pero todos llegarán en orden. En los paquetes salientes, su aplicación saldrá lo más rápido posible, pero se colocará en el cable de forma continua.

No he usado tcmucho, pero aquí hay un ejemplo de limitación de velocidad ICMP que probablemente pueda adaptar fácilmente para DNS.

Aquí hay una cosa que puede hacer para mitigar potencialmente las respuestas a consultas falsas, pero requiere algo de trabajo:

Primero, eche un vistazo a su registro del canal de seguridad y encuentre una dirección IP que se está falsificando.

Luego ejecute un tcpdump usando esa fuente IP (10.11.12.13) como esta:

tcpdump -n src 10.11.12.13 and udp dst port 53 -v -X -S

Obtendrás algo como esto:

18: 37: 25.969485 IP (tos 0x0, ttl 52, id 46403, offset 0, flags [none], proto: UDP (17), length: 45) 10.11.12.13.51169> 01.02.03.04.domain: 4215+ ANY ? . (17)
        0x0000: 4500 002d b543 0000 3411 b9d9 0A0B 0C0D E ..-. C..4 .......
        0x0010: 0102 0304 c7e1 0035 0019 0e89 1077 0100 ....... 5 ..... w ..
        0x0020: 0001 0000 0000 0000 0000 ff00 0100 ..............

Ahora la parte divertida! Abra rfc1035 en http://tools.ietf.org/html/rfc1035 y pase a la sección 4.1.1.

Es hora de traducir los resultados de tcpdump y descubrir un patrón que podamos usar para crear un filtro de nivel de paquete.

El ID del encabezado comienza en 0x1C, por lo que tenemos algunos indicadores en 0x1E, el QDCOUNT en 0x20, el ANCOUNT en 0x22, el NSCOUNT en 0x24 y el ARCOUNT en 0x26.

Eso deja la pregunta real en 0x28, que en este caso es nula (ROOT) para NAME, 0xFF para QTYPE = ANY y 0x01 para QCLASS = IN.

Para abreviar una historia larga, descubrí que agregar las siguientes reglas de iptables bloquea más del 95% de las consultas falsificadas que solicitan CUALQUIER registro EN LA RAÍZ:

iptables -A INPUT -p udp --dport domain -m u32 --u32 "0x28=0x0000ff00" -j DROP

Su kilometraje puede variar ... espero que esto ayude.

Uso tcy puesta en cola de disciplinas en Linux para el puerto de salida 53 UDP:

IFACE=eth0    
tc qdisc  add dev ${IFACE} root handle 1: htb default 0
tc class  add dev ${IFACE} parent 1: classid 1:1 htb rate   10mbit burst 20m
tc qdisc  add dev ${IFACE} parent 1:1 handle 10: sfq perturb 1
tc filter add dev ${IFACE} protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:1

Lo configurará con un disclímite de 10mbit para cualquier paquete con la marca de firewall '1'. Las marcas del cortafuegos son solo internas al cortafuegos y no modifican el paquete. Solo el manejo del paquete por la disciplina de colas. A continuación, le mostramos cómo usar iptableslas marcas de firewall:

iptables -A PREROUTING -o eth0 -p udp --sport 53 -t mangle -j MARK --set-mark 1
iptables -A PREROUTING -o eth0 -p udp --dport 53 -t mangle -j MARK --set-mark 1

Modifique a su gusto para excluir subredes y / o destinos confiables. El -o eth0limita la conformación a sólo los paquetes salientes. Espero que esto ayude.

Intentaría componer una lista de todos los clientes que confían en sus resolutivos recursivos que se enfrentan externamente. Comience con un día más o menos de rastreo de paquetes en los cuadros DNS. A partir de ahí, comience a crear reglas de iptables para permitir ese tráfico que reconoce y autoriza. Finalmente, el valor predeterminado será soltar el tráfico a 53 / tcp y 53 / udp. Si eso rompe algo, afina tus reglas.

dependiendo de la "posición" de la red en la que se encuentre [teniendo múltiples fuentes bgp o estando en el "final" de Internet, como una red auxiliar), puede probar algo como uRPF para evitar la suplantación de direcciones de origen.

Otra fuente de información.

¿Estos dispositivos todavía están bajo un contrato de soporte? Si es así, comuníquese con sus clientes. Hágales saber que Internet ha evolucionado un poco en la última década y para continuar proporcionando resolución de nombres para estos dispositivos, deberá conocer la IP de SRC para recibir consultas. Establezca una fecha ~ 6 meses en el futuro, momento en el que ya no podrá atender a clientes desconocidos, y cúmplala. Esto es bastante común en la industria. Si estos dispositivos ya no están bajo un contrato de soporte ... parece una decisión comercial. ¿Cuánto tiempo piensa su empresa gastar recursos en productos antiguos que ya no generan ingresos?

Suenan como dispositivos especializados, ¿son tan especializados que puede predecir razonablemente para qué dominios esperar consultas legítimas? bind admite vistas, crea una vista pública que solo hace recursión para esos dominios.

Use esto como una oportunidad de aprendizaje, si aún no lo ha hecho, deje de lanzar productos donde no tiene la capacidad de corregir errores. Eso es lo que es, un error. Uno que sin duda EOL este dispositivo prematuramente, tarde o temprano.

Desde nanog en alguna parte, esto:

iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP 

Esto no es lo ideal. Sería mejor permitir menos paquetes por segundo y tener una ráfaga más alta.

Aquí hay una solución que he usado un par de veces contra los ataques DDOS, no es perfecta pero me ayudó. La solución consiste en un script que el cron llama a cada N minutos (como 1,2,3, etc. minutos) y bloquea las IP que crean una cantidad de conexiones más grande que la dada en el script:

#!/bin/sh

PORT_TO_CHECK="53"
CONNECTION_LIMIT="20"
IPTABLES="/sbin/iptables"

netstat -an > /tmp/netstat.tmp
Buf_var1=`cat /tmp/netstat.tmp | grep -v "LISTEN"| grep ":$PORT_TO_CHECK\ " | grep -v "0.0.0.0" | awk '{print $5}' | grep -v ":$PORT_TO_CHECK$" | sed -e 's/^::ffff://g' -e 's/:.*$//g' | sort | uniq`
i=0
banned_flag=0
for conn in `for i in $Buf_var1; do echo -n "$i "; cat /tmp/netstat.tmp | grep -c $i;done | grep -v "=\ 0"`;do
[ $i = 0 ] && connip=$conn && i=1
[ $i = 2 ] && {
connum=$conn
[ $connum -ge $CONNECTION_LIMIT ] && {
[ "$var_test" = "" ] && {
$IPTABLES -I INPUT -s $connip -j DROP
banned_flag=1
}
}
}
[ $banned_flag = 1 ] && i=0
[ $i = 1 ] && i=2
done
rm -f /tmp/netstat.tmp