Podcast #188: Community de Blackhole

La utilización de la comunity de blackhole en BGP es una técnica que proporciona la capacidad de descartar el tráfico no deseado antes de que entre en la red protegida.

Conceptualmente es algo maravilloso. La idea es proteger nuestra red haciendo que el tráfico que no queremos ni siquiera llegue a nuestra red.

En el audio de hoy voy a contaros las aplicaciones de los blackholes, cómo desplegarlo y cómo puede ayudarnos para mitigar ataques de denegación de servicio DDoS.

Lo primero indicar que cuando hablamos de Blackholes normalmente estamos simplificando muchísimo y realmente nos estamos refiriendo a “Remotely Triggered Black Hole Filtering” que vendría a ser un “filtrado de blackhole disparado a distancia”, esta es una traducción muy libre, pero creo que la idea queda clara y no es otra más que crear un filtro en un dispositivo remoto.

Esta técnica no es algo dependiente de ningún fabricante, sino una forma de proceder basándonos en las posibilidades que nos da BGP para transmitir información mediante Communities y en las capacidades de filtrado de cualquier router de hoy en día.

Además el filtrar el tráfico antes de que entre en nuestra red es una necesidad porque los ataques distribuidos pueden llegar a tener un tamaño mayor que la capacidad de nuestros tránsitos. Es decir, podemos llenar todo el ancho de banda disponible con el tráfico del DDoS dejanto toda la red fuera, así que es muy importante que ese tráfico no llegue a entrar.

Pensad que si hubiera un DDoS que llenara el ancho de banda completo de la red podría incluso llegar a dejar fuera a las personas encargadas de trabajar con la red para mitigar el problema.

El procedimiento para crear un blackhole sería el siguiente:

Generar un anuncio de iBGP con una community dada, podría ser la 666 por ejemplo y anunciar el prefijo a bloquear a los routers frontera.
Estos routers frontera recibirían y al comprobar que la community es la de blackhole anunciaría ese mismo prefijo a sus tránsitos. Cada tránsito es posible que use diferentes communities de blackhole, con lo que habrá que hacer adaptaciones.
Cuando llega al proveedor de tránsito este seguirá propagando el blackhole e incluirá una ruta a una IP/32 asignada a null0 para ese prefijo recibido.
Al llegar trafico a nuestros tránsitos al prefijo que está en blackhole el tráfico no será enviado a nosotros sino enviado a esa IP/32 y descartado porque el rango de blackhole será normalmente más pequeño por lo tanto preferido.

Bueno, vamos a tratar de explicar esto un poco más despacio porque aquí hay cosas que pueden sonar un poco raras.

La configuración tiene varias partes y queremos que haga lo siguiente

Match una etiqueta con valor 666.
Cambiamos el next-hop a 192.0.2.1
Cambiamos la local-preference a 200.
Cambiamos el origin a igp.
Marcamos la community no-export.

Y para lanzar el blackhole haríamos lo siguiente:
ip route 198.51.100.1 255.255.255.255 Null0 tag 666
1

ip route 198.51.100.1 255.255.255.255 Null0 tag 666

La configuración que haría esto es la siguiente:
interface loopback0
ip address 192.168.1.1 255.255.255.255
interface Null0
no ip unreachables
router bgp 64555
no synchronization
no bgp client-to-client reflection
bgp log-neighbor-changes
redistribute static route-map black-hole-trigger
neighbor black-hole peer-group
neighbor black-hole remote-as 64555
neighbor black-hole update-source loopback0
neighbor black-hole route-reflector-client
neighbor x.x.x.x peer-group black-hole
route-map black-hole-trigger
permit 10 match tag 666
set ip next-hop 192.0.2.1
set local-preference 200
set origin igp
set community no-export
route-map black-hole-trigger deny 20
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

interface loopback0
ip address 192.168.1.1 255.255.255.255
interface Null0
no ip unreachables
router bgp 64555
no synchronization
no bgp client-to-client reflection
bgp log-neighbor-changes
redistribute static route-map black-hole-trigger
neighbor black-hole peer-group
neighbor black-hole remote-as 64555
neighbor black-hole update-source loopback0
neighbor black-hole route-reflector-client
neighbor x.x.x.x peer-group black-hole
route-map black-hole-trigger
permit 10 match tag 666
set ip next-hop 192.0.2.1
set local-preference 200
set origin igp
set community no-export
route-map black-hole-trigger deny 20

Tener en cuenta si buscáis por ahí ejemplos para copiar y pegar, como el que os pongo en las notas del programa, que los ejemplos se suelen hacer con los rangos 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), y 203.0.113.0/24 (TEST-NET-3) que son bloques reservados para documentación y no pueden ser usados en Internet.

Con esto ya podemos anunciar a nuestros peers.

Ya tenemos un sistema para meter en blackhole rutas que metamos a mano, pero el problema es que tenemos que ser muy rápidos. Como ya he dicho es importante que tengamos en cuenta que si tenemos un DDoS muy grande puede llegar a llenarse los tránsitos y eso ¿sabéis lo que significará?

Que nuestras actualizaciones de BGP con los prefijos blackholeados no llegarán a nuestros tránsitos y el blackhole no será efectivo.

Para solucioar eso hay algún operador de tránsito, Cogent para ser más concretos que te da una sesión multihop y podrías anunciar el blackhole aunque su sesión BGP esté caída. Es decir, tendremos una sesión BGP sólo para el blackhole.

Para implementar blackhole podemos hacerlo a mano (y ser muy ra?idos) o bien automatizarlo, pero claro, eso requiere que tengamos cuidado cuando lanzar el blackhole, si lo hacemos demasiado pronto podremos dejar a clientes sin conectividad sólo por un pico de tráfico legitimo y si es demasiado tarde a lo mejor el blackhole ya no vale para nada, así que para ello lo mejor es que esto os lo monte alguien con la suficiente experiencia en este tipo de soluciones.

En Tecnocrática damos este servicio a nuestros clientes de gestión de red, es decir, a los clientes que les gestionamos la red les montamos varias cosas y una de ellas es esto, la automatización de blackholes en función de su perfil de tráfico y necesitadas específicas, porque cada red es un Mundo.

También deciros que aquí os he puesto un ejemplo en Cisco porque creo que es lo más extendido y común, pero obviamente esto se podrá hacer con cualquier otra fabricante, lo que pasa es que en algunos tendremos que innovar un poco porque por ejemplo con Mikrotik en BGP no podemos hacer un set next-hop, así que bueno, hay que ser más imaginativo.

Al final lo que importa es encontrar una solución para este tipo de problemas y enviar una actualización de BGP a nuestros tránsitos, cada uno con su community de blackhole.