Use BGP para defenderse contra un ataque DDoS que se origina desde un AS remoto

16

Tengo una pregunta sobre BGP y cómo lograr esta configuración.

El enrutador central de mi empresa está conectado a un ISP (conexión única). Este enrutador ya ha intercambiado los prefijos específicos de IP pública al ISP en las actualizaciones de BGP. Ahora digamos que hay un AS a varios saltos que está inundando mi AS local con un ataque DDoS. Hay múltiples redes en ese AS dirigidas a los servidores web en mi AS local.

¿Cómo podemos detener este tráfico en nuestro enrutador utilizando BGP?

Agradezco tu respuesta !! :)

Harish Reddy
fuente
2
¿Cómo estableciste la fuente de este tráfico? Si solo estuviera mirando las direcciones IP de origen, esas podrían ser falsificadas. Una inundación de paquetes de todas las direcciones de origen de suplantación de identidad dentro de un único AS es lo que vería si ocurriera un ataque de reflexión.
kasperd
¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.
Ron Maupin

Respuestas:

14

Hay dos cosas que podrías hacer con BGP:

RTBH - Agujero negro activado remotamente

La primera opción es la radical: Blackhole (detener el tráfico) para que la IP sea atacada. Desventaja: ya no se puede acceder a la IP que se está buscando. Beneficio: el resto de su red permanece activa. Packetlife tiene una buena explicación sobre cómo funciona y cómo hacerlo. La segunda opción se basa en la primera:

RTBH basado en fuente

RTBH también se puede usar (en ciertas configuraciones) para bloquear el tráfico proveniente de IP específicas (en un DDoS real que no ayudaría mucho ya que el tráfico entraría desde miles de IP). Nuevamente, Packetlife tiene una explicación.

En su caso, puede obtener todos los prefijos para el AS de una base de datos de enrutamiento como RADB y bloquearlos con RTBH basado en fuente. Sin embargo, el tráfico aún afectaría a su red en la frontera.

Cuando utiliza RTBH "simple", la ventaja es que puede enviar estas rutas RTBH a su ISP Upstream (si lo admiten), que ya podría bloquear el tráfico en su red para que no tenga que manejarlo.

Sebastian Wiesinger
fuente
El método descrito por Packetlife es útil, pero no será de ninguna utilidad en un escenario donde sus enlaces ascendentes estén saturados por el tráfico de ataque. Escribí una respuesta sobre el uso de comunidades de agujeros negros aguas arriba para abordar este problema.
Elliot B.
2
Está en mi última oración: "Cuando usa RTBH" simple ", la ventaja es que puede enviar estas rutas RTBH a su ISP Upstream (si lo admiten), que ya podría bloquear el tráfico en su red para que no tenga para manejarlo ".
Sebastian Wiesinger
Vi eso, pero quería detallar el método del agujero negro activado por el cliente y señalar que "[no tener] que manejarlo" significa que el agujero negro no sería efectivo de otra manera. No pretende ser un golpe en su respuesta, solo proporciona más información :)
Elliot B.
7

El método RTBH descrito por @Sebastian a través de Packetlife es útil, pero ese método solo funcionará si su enlace ascendente no está saturado por el tráfico de ataque. Si su enlace ascendente está saturado, entonces el agujero negro debe implementarse en un punto antes de que el tráfico de ataque llegue a su red.

Puede lograr esto con comunidades de agujeros negros aguas arriba.

Hurricane Electric ofrece una explicación / ejemplo simple de blackholing provocado por el cliente con una comunidad BGP:

  1. El ataque comienza
  2. El cliente identifica el rango de ip o ip bajo ataque
  3. La estática del cliente enruta la ip o el rango de ip a Null0 y agrega un anuncio del prefijo correspondiente con un mapa de ruta que lo etiqueta con 6939: 666.

Ejemplo de configuración de Cisco (donde XXXX es la ip que está siendo atacada):

conf t
ip route X.X.X.X 255.255.255.255 Null0
router bgp YourAS
network X.X.X.X mask 255.255.255.255 route-map blackhole
route-map blackhole permit 10
set community 6939:666
end

Tenga en cuenta que 6939:666es la comunidad de agujeros negros específica para Hurricane Electric. Modificaría este valor para que se corresponda con la comunidad de agujeros negros de su proveedor ascendente.

Por supuesto, hay varias formas de configurar esto. En mi equipo Brocade, uso la siguiente configuración:

router bgp
!
redistribute static route-map blackhole
!
!
route-map blackhole permit  5
 match tag  66
 set community  55555:666

¿Dónde 55555:666está la comunidad de agujeros negros de su proveedor de aguas arriba? Un agujero negro aguas arriba puede aplicarse con un simple comando:

ip route 123.123.123.123 255.255.255.255 null0 tag 66
Elliot B.
fuente
4

Desde una perspectiva BGP, no hay mucho que pueda hacer. Podría dejar de anunciar su prefijo, pero luego está completando el ataque DoS porque nadie podrá acceder a su servicio.

Si tiene múltiples prefijos, puede volver a numerarlos, pero es probable que el ataque también se mueva al nuevo prefijo.

Lo que debe hacer es trabajar con su flujo ascendente. ¿Tienen un servicio de fregado? Si tienen un sistema como Arbor Peakflow, podrían eliminar el tráfico y limpiarlo antes de que ingrese a su red. Tales servicios son a menudo muy caros.

También hay otras opciones como Cloudflare y compañías similares donde configura BGP a través de un túnel GRE para esa compañía y su tráfico es manejado por su "nube" que puede manejar mucho más tráfico que sus dispositivos locales.

Daniel Dib
fuente
0

Trabajo para CloudFlare, me gustaría compartir algunos de los conocimientos que he desarrollado sobre la mitigación de los ataques DDOS en los últimos meses que he estado aquí.

En primer lugar; Mucha gente recurre a medidas de nivel de red para mitigar los ataques DDOS de la capa de aplicación. Antes de sumergirse en BGP Blackholing, considere si se trata de algo que limita la velocidad o si la protección de la capa de aplicación podría lidiar. Dicho eso ahora es muy barato lanzar ataques DDOS de gran capacidad (dada la cantidad de Recursores DNS abiertos y cómo pueden amplificar los ataques).

Como Elliot describió en su respuesta, usar BGP Communities para bloquear el tráfico puede funcionar bien si su red es pequeña; Este mecanismo está documentado en RFC 3882 . Sin embargo, como nosotros, si en cambio desea absorber el tráfico de ataque en lugar del agujero negro (es decir, desea recopilar datos de ataque DDOS ), tenga cuidado con el daño colateral por el cual los proveedores de redes intermedias terminan congestionados. Puede mitigar el daño colateral al mirar directamente con los ISP de las redes que están lanzando los ataques. Al hacerlo, tiene el camino más corto desde el atacante hasta el destino. Además, puede implementar un diseño de red Anycast , esto significará efectivamente que una dirección IP llegue a varios centros de datos (dependiendo de cuál sea el más cercano).

Obviamente, no es posible que todas las empresas tengan la infraestructura para hacer Anycast y peering; Es por eso que las empresas recurren cada vez más a los servicios en la nube para eliminar el mal tráfico antes de que llegue a sus centros de datos. Naturalmente CloudFlare es uno de esos servicios.

mjsa
fuente
-1

Si toda la evidencia que ha reunido es una avalancha de paquetes con direcciones IP de origen de un AS en particular, es probable que haya llegado a una conclusión errónea. Una explicación más probable sería que esas IP de origen son falsificadas.

Un ataque de reflexión / amplificación implica enviar muchos paquetes falsificando la dirección IP de origen de una víctima. Si esto es realmente lo que está sucediendo, y tiene servidores en su red, que pueden amplificar un ataque, entonces la red que está acusando de un ataque es en realidad la víctima, y ​​usted está ayudando al atacante.

En tal situación, la solución no es aplicar ningún tipo de ingeniería de tráfico, sino configurar sus servidores de modo que no puedan usarse en un ataque de amplificación. Cómo hacer esto no es realmente una pregunta de ingeniería de redes.

Por supuesto, es posible que todos los paquetes se originen en un AS. Con la cooperación del AS infractor, puede obtener la confirmación de que los paquetes se originan en su AS. Sin embargo, con ese nivel de cooperación, también podría bloquear el ataque en la fuente.

Si suponemos que a través de algún método, no he pensado en obtener la confirmación de que los paquetes realmente se originan del AS que cree, y que no puede bloquearlo en la fuente y, en cambio, desea bloquearlo a través de BGP, entonces yo He leído sobre un método algo arriesgado para lograr esto. La idea es que anteponga una ruta AS a la ruta que está anunciando. En esta ruta AS antepuesta, incluye el número AS de la fuente de esos paquetes.

Cuando el anuncio llegue a los enrutadores BGP en el AS infractor, detectarán un bucle y descartarán el anuncio. Mientras tanto, el resto del mundo no verá un bucle y aceptará el anuncio.

Esa es la teoria. Si realmente funcionará en la práctica depende de algunos factores diferentes. Por ejemplo, depende de usar realmente el número AS del que se originan los paquetes, que podría ser diferente del número AS que anuncia esas direcciones IP. (Dicha diferencia podría ser legítima o debido a la suplantación de identidad).

También depende de que su flujo ascendente no filtre la ruta si encuentra la ruta AS sospechosa. Además, las redes más alejadas de usted también pueden abandonar su ruta, por ejemplo, si también han tenido malas experiencias con el AS infractor y han decidido abandonar todas las rutas desde allí.

Es su decisión si este enfoque vale la pena el riesgo.

(Me hubiera vinculado a la fuente de este enfoque, si pudiera encontrarlo nuevamente).

kasperd
fuente
2
Eso es algo muy peligroso de hacer. Estás falsificando otro AS en tu camino que no te pertenece. Además, si otras personas eliminan rutas de ese AS, también eliminarán sus rutas.
Sebastian Wiesinger
1
@Sebastian True, ese riesgo también existe. Pero si la alternativa es una red que es inalcanzable debido a que está inundada de tráfico, puede valer la pena el riesgo.
kasperd
Esto suena como una muy mala idea, nunca antes había oído hablar de ella. Rompe la conectividad para un ASN completo cuando hay un nodo de botnet, que no es lo que desea, por ejemplo, grandes proveedores de nube. Además, se escala mal con DDoS'es donde miles de nodos de botnet están atacando algo en su red.
Teun Vink
1
@TeunVink Definitivamente no es aplicable a un ataque DDoS típico. Pero el OP no pregunta sobre un ataque típico de DDoS. Pregunta sobre un ataque en el que todo el tráfico se origina en un AS. Romper la conectividad a un AS sería aceptable, si la alternativa fuera un ataque que rompiera la conectividad a todo Internet.
kasperd
-2

Puede bloquear su AS desde su red local, por lo que su enrutador BGP crea rutas nulas para cualquier prefijo que anuncien.

Pro:

  • su AS les parecerá muerto, que es su objetivo, mientras que normalmente intercambian datos con todos los demás normalmente.
  • su filtrado de ingreso local eliminará automáticamente los paquetes entrantes de ese AS

Contra:

  • pueden crear rutas de agujeros negros en su enrutador, así que asegúrese de tener reglas apropiadas para mantener intactas sus rutas más vitales
Simon Richter
fuente
1
Blackholing un AS completo significa que terminas DOSing tu mismo. Nadie más en ese AS puede contactarte. Sus clientes también podrían estar en ese AS.
Ron Trunk
1
Supongo que aquí hay un AS hostil, es decir, se pierde valor si se bloquean por completo. Hay algunos servicios de "hosting a prueba de balas" que presentaría en esta categoría.
Simon Richter
1
La mayoría de los ASN no son completamente hostiles o amigables, solo contienen algunos hosts que son parte de una botnet. Además, este enfoque no evita que sus enlaces ascendentes se inunden, por lo que no le ayudará a detener los ataques DDoS basados ​​en el volumen.
Teun Vink