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

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 !! :)

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.

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

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.

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.

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).

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