Seguridad del enrutamiento:

secuestros de BGP y qué resuelve RPKI

Redes y sistemas  |  unfantasmaenelsistema.com

Internet no es una red, son decenas de miles de redes independientes (los sistemas autónomos) que se anuncian rutas entre sí con un único protocolo: BGP. Ese protocolo nació en una época en la que todos los que hablaban BGP se conocían y se fiaban, y esa confianza sigue siendo su modelo de seguridad por defecto. Cuando un operador anuncia «por aquí se llega a este bloque de direcciones», sus vecinos lo aceptan y lo propagan sin una forma sólida de comprobar si es verdad.

De ahí vienen los incidentes en los que «media internet se cae» durante un rato: un secuestro de prefijo, una fuga de rutas, un error de configuración que se propaga en segundos por todo el planeta. Este artículo explica cómo funciona esa confianza implícita, qué formas tiene de romperse, y qué parte del problema resuelve RPKI (y qué parte, importante, deja fuera).

1. BGP y por qué confía por diseño

Cada red grande (un operador, un proveedor de nube, una universidad, un banco) tiene un número de sistema autónomo o ASN, y uno o varios prefijos de direcciones IP asignados por su registro regional (RIPE en Europa). BGP es el protocolo con el que esos sistemas autónomos se dicen unos a otros qué prefijos pueden alcanzar y por qué camino.

• Un router BGP anuncia a sus vecinos: «para llegar a 203.0.113.0/24, el camino es AS64500». El vecino lo acepta, le añade su propio ASN al AS-PATH y lo reenvía a los suyos
• Entre los caminos posibles hacia un mismo destino, cada router elige uno según sus políticas (preferencia local, longitud del AS-PATH, acuerdos comerciales) y descarta el resto
• No hay ninguna autoridad central que diga qué anuncios son legítimos. La red se autoorganiza a base de acuerdos bilaterales y de confianza en el vecino directo

El resultado es un sistema extraordinariamente robusto frente a fallos físicos (un cable cortado se rodea solo) y extraordinariamente frágil frente a información falsa: si alguien anuncia algo que no le corresponde, la mentira se propaga con la misma eficiencia que una ruta buena.

2. Secuestro de prefijo y fuga de rutas

Los dos fallos clásicos del enrutamiento tienen causas distintas y, a menudo, el mismo origen: un error de configuración, no un ataque.

Ha habido casos muy visibles a lo largo de los años: bloques de direcciones de grandes servicios anunciados por error desde el otro lado del mundo, tráfico de pagos redirigido durante horas, y regiones enteras sin acceso a ciertos servicios porque una fuga de rutas hizo pasar todo su tráfico por un operador que no daba abasto. En la mayoría no hubo malicia: hubo un `redistribute` mal puesto o un filtro que faltaba.

3. RPKI: firmar quién puede originar cada prefijo

RPKI (Resource Public Key Infrastructure) es una PKI paralela a la asignación de recursos de internet. Los registros regionales (RIPE, ARIN, APNIC, LACNIC, AFRINIC) actúan como autoridades: emiten certificados que acreditan qué organización tiene asignado cada prefijo y cada ASN.

Sobre esa base, el titular de un prefijo publica una ROA (Route Origin Authorization): un objeto firmado que dice «el prefijo P puede ser originado por el AS N, hasta una longitud máxima L». Por ejemplo: «192.0.2.0/24 lo origina AS64500, maxLength 24».

El router no habla RPKI directamente: se conecta por el protocolo RTR a uno o varios validadores locales, que le entregan la tabla de prefijos autorizados. Con esa tabla, cada anuncio BGP que llega se clasifica en uno de tres estados.

# Consultar el estado RPKI de un prefijo/origen desde un servicio publico (lectura)
# RIPEstat: https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=192.0.2.0/24
 
# Ver las ROAs publicadas para un ASN con la API de rpki-client / consola del RIR
whois -h whois.bgpmux.com ' -M 192.0.2.0/24'   # ejemplo ilustrativo de consulta de rutas
 
# En un router (Cisco IOS-XR, sintaxis ilustrativa):
#   rpki server 10.0.0.2  transport tcp port 3323
#   route-policy DROP-INVALID  ->  if validation-state is invalid then drop

4. Lo que RPKI no cubre

RPKI con validación de origen resuelve un problema concreto y solo ese: que un AS no autorizado aparezca como origen de un prefijo. Deja fuera varias cosas importantes.

• No valida el AS-PATH. Un atacante puede anunciar el prefijo con el ASN de origen correcto pero un camino intermedio inventado. La ROA seguirá diciendo «valid»
• No impide las fugas de rutas. Una fuga propaga anuncios con origen legítimo por relaciones comerciales equivocadas; RPKI no ve el tipo de relación entre ASes
• No cifra ni autentica el tráfico. Es control del plano de rutas, no del plano de datos
• Depende de la cobertura. Mientras una parte del espacio siga sin ROA (estado NotFound), esos prefijos se pueden secuestrar sin que salte nada

5. Qué puede hacer una organización con su ASN

Si tu organización tiene ASN y prefijos propios, hay una lista corta de acciones con muy buena relación esfuerzo/beneficio:

• Publica ROAs para todos tus prefijos desde el portal de tu RIR. Declara el ASN de origen real y un maxLength ajustado (si solo anuncias /24, no pongas maxLength /24 sobre un /22 salvo que vayas a desagregar): un maxLength demasiado laxo reabre la puerta al secuestro por prefijo más específico
• Activa la validación de origen (ROV) en tus routers de borde: monta uno o dos validadores (Routinator o rpki-client son ligeros) y configura la política de descartar los invalid
• Filtra a tus clientes y peers con prefix-lists y límites de número de prefijos; la mayoría de fugas se cortan con un buen filtro de salida y de entrada
• Monitoriza tus prefijos: alertas de RIPEstat / RIPE Atlas, BGPalerter, o servicios de terceros que avisan cuando aparece un origen o un AS-PATH inesperado para tu bloque
• Regístrate en un IRR (RADB, RIPE DB) con objetos route: coherentes; muchos operadores construyen sus filtros a partir de ahí

Conclusión

BGP mueve todo el tráfico de internet sobre una base de confianza que nunca se pensó para un internet hostil. Los secuestros y las fugas de rutas seguirán ocurriendo mientras esa base no cambie, y cambiarla es lento porque exige coordinación entre miles de organizaciones.

RPKI es el primer escalón realista y ya está desplegado a gran escala: firmar quién puede originar cada prefijo y descartar los anuncios que incumplen esa firma corta la mayoría de los secuestros accidentales y muchos de los deliberados. No valida el camino (para eso llega ASPA) ni sustituye a un buen filtrado, pero publicar tus ROAs y validar en tus routers son dos tardes de trabajo que quitan a tu organización de la lista de blancos fáciles.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)