Hablaremos del BGP Hijacking o secuestro de rutas BGP y como evitarlo con un RPKI Server. Ya hemos visto como funcionan los operadores y como establecen sesiones BGP de Peering con otros operadores.
Pero a la hora de realizar ataques, hay redes que son más jugosas que otras. Por ejemplo si quisiéramos hackear a Visa, posiblemente te sea difícil, porque tendrá muchas medidas de seguridad, pero ¿ y si me hago pasar por Visa ?
BGP Hijacking
El BGP Hijacking es apropiarte o secuestrar una red que no te pertenece. Esto es posible porque el falso Origen dicen que tiene la red X.X.X.X/X y la anuncia a sus peers.
Si estos últimos no hacen ningún tipo de comprobación, se creerán que para ir a la red X.X.X.X/X la mejor opción es pasar por ese operador en vez de por el real. Una vez estemos en esa red, estaremos entregando datos a quien no corresponde.
Esto se conoce como Secuestro de rutas BGP o BGP Hijack.
Antecedentes
Esto fue lo que ocurrió en 2017 cuando una operadora rusa anunció por error rutas que no le correspondían y el tráfico que iba dirigido a Visa, Mastercard o Symantec. Podéis ver más información en este enlace.
Pero se ve que esta operadora controlada por el gobierno Ruso, no es segura o no implementa los filtros que debería porque el pasado 5 de Abril de este año ha vuelto a pasar con Google, Cloudflare y AWS entre otros como detallan en ZDNet.
O el BGP Hijacking que sufrió Whatsapp y por el que el tráfico europeo fue derivado durante 2 horas a un servidor alojado en China que no tenía nada que ver:
Notificaciones en Twitter
Puede parecernos algo extremadamente raro, pero es todo lo contrario. Como curiosidad mientras he escrito este post, han habido 2 secuestros de prefijos, y en el día de hoy 14. Muchas veces estos secuestros no tienen maldad en el fondo y pueden ser una simple mala configuración o un número que a un operario le ha bailado y ha coincidido con tu red.
Existe un servicio que publica los eventos de BGP Hijack que detectan
¿Cómo securizamos nuestra red?
Ya hemos visto lo que nos puede pasar, y lógicamente no queremos que eso nos suceda en nuestra red o en nuestros prefijos.
Protegiendo nuestros prefijos
Lo primero es proteger nuestros prefijos para que otros no puedan anunciarlos como suyos.
Registro ROA
Es registro ROA es un registro que damos de alta en Ripe (o donde nos corresponda por nuestra región) en el que asignamos a nuestra Red asignada, quién será el AS que puede anunciar nuestra red y con que prefijo máximo puede hacerlo.
Por ejemplo si tenemos el rango 10.0.0.0/16 asignado por Ripe, podemos crear un registro en el que asignemos el rango entero al AS65050, con lo que cualquier forma distinga o más precisa de anunciar el 10.0.0.0/16 indicamos que no es válido.
Otra opción es anunciar ese mismo rango, pero indicamos que el valor más preciso que podemos anunciar es un /22 de esta manera, si alguien anuncia el 10.0.1.0/24 no lo consideramos válidos.
Tenemos que tener en cuenta que el receptor deberá verificar estos registro, si no los verifica, no servirá para nada.
Verificando las rutas recibidas
Como hemos visto anteriormente, es importante securizar nuestras redes, pero ¿qué pasa con las que recibidos de los operadores?
Lógicamente debemos partir de no fiarnos de ellas, ya que hoy operadores que no validan, por lo que debemos implementar nuestros propios filtros en los routers que establecen sesiones BGP con otros.
RPKI Servers
Existen distintos servidores que podemos usar para nuestra validación:
- Routinator ( de NLnetLabs )
- The RPKI Validator ( de Ripe )
- OctoRPKI / goRTR ( de Cloudflare )
- FORT ( de NIC México)
La función de los Validation Servers son obtener de los distintos RIRs las listas que cada uno tiene y con esas listas generar una única en común. Su misión no es la de hablar con los routers finales para certificar las rutas.
RTR Server
El Servidor RTR es el encargado de hablar con los routers mediante el protocolo RTR, el cual fue definido en la RFC 8210.
Su función si es establecer una comunicación con los routers finales mediante el protocolo RTR para validar las rutas obtenidas.
Las rutas pueden tener 3 valores:
- Valid: Todo es correcto.
- Invalid: Existe algún problema y la ruta, el origen o el registro ROA no coinciden.
- Unknown: Para esa ruta no existe un registro ROA que indique que hacer con ella.
Lógicamente con estos valores son los que tenemos que jugar en nuestros routers para aceptar o descartar las rutas. Si son Validas o Desconocidas, debemos dejarlas pasar y descartar las Inválidas porque algo no cuadra con lo que el propietario de ese prefijo ha indicado.
Descubre si tu proveedor te protege
Ya hemos visto como proteger nuestra red para no vernos afectados, pero al final dependemos de que todos los proveedores por los que pasa nuestra red hasta llegar al usuario final, se hayan protegido para evitar que un tercero inyecte sus redes haciéndose pasar por ti.
Existen dos test que te servirán para comprobar si tu ISP se protege del BGP Hijacking y no permite que esas rutas sean usadas.
- Rpki webtest de ripe
- Is BGP safe yet? de Cloudflare
Curiosidades
Cloudflare nos da una herramienta con la que poder jugar y ver que proveedores validan sus rangos.
Y por ejemplo Google no valida su famoso registro DNS 8.8.8.0/24 por lo que cualquiera puede hacerse pasar por él y secuestrar las llamadas al DNS que indican, lo cual es otra forma de ataque bastante común (DNS Hijacking)
