Lidiando con los ataques de reflexión NTP en IPTables


16

Estamos lidiando con un ataque de reflexión / amplificación NTP en nuestros servidores ubicados. Esta pregunta es específica para responder a los ataques de reflexión NTP, y no está dirigida a DDoS en general.

Aquí está el tráfico:

gráfico de tráfico de red del enrutador

Está produciendo un poco de CPU en nuestro enrutador:

gráfico de uso de CPU del enrutador

Desafortunadamente, no es lo suficientemente grande como para hacer que nuestro proveedor ascendente bloquee el tráfico, lo que significa que nos está pasando.

Hemos utilizado la siguiente regla para bloquear el tráfico NTP, que se origina en el puerto 123:

-p udp --sport 123 -j DROP

Esta es la primera regla en IPTables.

Busqué mucho y no puedo encontrar mucha información sobre cómo usar IPTables para mitigar un ataque de reflexión NTP. Y parte de la información por ahí parece completamente incorrecta. ¿Es correcta esta regla de IPTables? ¿Hay algo más que podamos agregar o hacer para mitigar un ataque de reflexión / amplificación NTP que no sea contactar a nuestro proveedor de red ascendente?

Además: dado que estos atacantes deben usar redes que

  • permitir la suplantación de direcciones IP en paquetes
  • tienen parcheo, código NTP de alrededor de 2010

¿Hay alguna cámara de compensación global a la que podamos informar estas direcciones IP, para que se arreglen y dejen de permitir paquetes falsificados y parchen sus servidores NTP?


10
Sí, la regla de iptables es correcta, pero ejecutar un filtro de paquetes al final de su tubería, en su servidor, no evitará que la tubería se llene, para obtener más información, consulte: serverfault.com/questions/531941/i-am- under-ddos-what-can-i-do
HBruijn

Respuestas:


20

Esencialmente, no tiene suerte si el ataque DDoS logra llenar cualquier tubería que tenga a Internet (que es el propósito de cualquier ataque de reflexión UDP: llenar la tubería). Si su enlace ascendente puede tomar 1 Gbps de tráfico, y hay (digamos) 2 Gbps de tráfico total para ir por el enlace, entonces la mitad de la misma será soltada por el enrutador o el conmutador que está poniendo los paquetes en el enlace. Al atacante no le importa que se caiga la mitad de su tráfico de ataque, pero sus clientes sí: la pérdida de paquetes del 50% en una conexión TCP va a hacer cosas terribles para el rendimiento y la fiabilidad de esas conexiones.

Solo hay dos formas de detener un ataque DDoS volumétrico:

  1. Tenga una tubería lo suficientemente grande como para que el tráfico de ataque no la llene.
  2. Detenga los paquetes de ataque antes de que caigan por la tubería.
  3. Cambie a una dirección IP diferente que no esté bajo ataque de reflexión NTP.

Bloquearlos en iptables no hará sentadillas, porque para entonces el tráfico de ataque ya ha exprimido el tráfico legítimo y ha provocado que se caiga al suelo, por lo que el atacante ha ganado. Como usted (presumiblemente) no controla el enrutador o conmutador ascendente que reenvía el tráfico de ataque, sí, tendrá que ponerse en contacto con su proveedor de red ascendente y hacer que hagan algo para evitar que el tráfico de ataque llegue a su red enlace, ya sea

  • bloquear todo el tráfico en el puerto de ataque (no es algo que la mayoría de los ISP estén dispuestos a hacer en sus enrutadores de acceso de cliente colo $REASONS)

  • filtrar las direcciones IP de origen del ataque (más plausible, con S / RTBH, pero no es algo que todos los proveedores ya tengan disponible)

  • peor de los casos, bloquear la dirección IP de destino

Tenga en cuenta que bloquear la IP solo funciona si tiene otras direcciones IP que pueden continuar funcionando: si su proveedor bloquea su única dirección IP, el atacante ha tenido éxito porque está fuera de Internet, que es lo que intentaban lograr en primer lugar.


¿Tendrías alguna idea de por qué los ISP no quieren bloquear el tráfico?
André Borie

44
Hay muchas razones 1. A los ISP se les paga para entregar tráfico, no para bloquearlo. 2. Solo los equipos de red de gama alta son capaces de realizar inspecciones de velocidad de línea en grandes volúmenes de tráfico (100G +), lo cual es costoso. 3. No es trivial pasar de la solicitud del cliente a las líneas de configuración en un enrutador central.
womble

5

Asumiré que tiene una tubería a su ISP que termina en su propio enrutador / firewall. Luego, detrás de ese enrutador / firewall, tiene sus propias máquinas. El ISP no bloqueará el tráfico, por lo que debe tratarlo usted mismo. Desea bloquear el tráfico en el enrutador / firewall para evitar que golpee las máquinas detrás de este mientras minimiza la carga en el enrutador / firewall.

Su regla parece correcta para descartar cualquier cosa que provenga de un servidor ntp en el puerto estándar. Recuerde que si realmente usa ntp, es posible que deba hacer agujeros en las reglas de su firewall

Si su cortafuegos usa el seguimiento de la conexión (la mayoría lo hace), entonces puede usar la tabla "sin procesar" para descartar los paquetes antes de que lleguen al dispositivo de seguimiento de la conexión.

iptables -t raw -A PREROUTING -p udp --sport 123 -j DROP


1

Parece que podemos informar las IP por abuso de NTP (y con suerte, parches de NTP) a

http://openntpproject.org/

En cuanto a las redes de informes que permiten IP falsificadas, no puedo encontrar mucho :

Nuestras mediciones muestran que la suplantación de identidad sigue prevaleciendo entre aproximadamente el 25% de los sistemas autónomos y los bloques de red que encuestamos. Más importante aún, un único punto de entrada para el tráfico falsificado proporciona a los atacantes un medio para enviar tráfico falso a todo Internet. Los ISP pueden emplear el filtrado [RFC2827] para garantizar que su tráfico saliente no sea falsificado.

¿Quizás el único método es contactar al ISP directamente?

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.