Como resultado de un anuncio BGP erróneo de más de 8800 prefijos de redes extranjeras a través de la red Rostelecom, lo que provocó un colapso a corto plazo del enrutamiento, interrupción de la conectividad de la red y problemas con el acceso a algunos servicios en todo el mundo. Problema más de 200 sistemas autónomos propiedad de las principales empresas de Internet y redes de distribución de contenidos, incluidos Akamai, Cloudflare, Digital Ocean, Amazon AWS, Hetzner, Level3, Facebook, Alibaba y Linode.
El anuncio erróneo lo hizo Rostelecom (AS12389) el 1 de abril a las 22:28 (MSK), luego fue recogido por el proveedor Rascom (AS20764) y más adelante en la cadena se extendió a Cogent (AS174) y Level3 (AS3356). cuyo campo cubría casi todos los proveedores de Internet de primer nivel (). BGP notificó rápidamente a Rostelecom sobre el problema, por lo que el incidente duró unos 10 minutos (según Los efectos se observaron durante aproximadamente una hora).
Este no es el primer incidente relacionado con un error por parte de Rostelecom. En 2017, en 5-7 minutos a través de Rostelecom redes de los mayores bancos y servicios financieros, incluidos Visa y MasterCard. Al parecer, en ambos incidentes, el origen del problema trabajos relacionados con la gestión del tráfico, por ejemplo, podrían ocurrir fugas de rutas al organizar el monitoreo interno, priorizar o reflejar el tráfico de ciertos servicios y CDN que pasan a través de Rostelecom (debido a un aumento en la carga de la red debido al trabajo masivo en casa a fines de marzo la cuestión de reducir la prioridad del tráfico de servicios extranjeros en favor de los recursos nacionales). Por ejemplo, hace unos años en Pakistán, un intento Las subredes de YouTube a la interfaz nula dieron como resultado que estas subredes aparecieran en anuncios de BGP y drenaran todo el tráfico de YouTube a Pakistán.
Es interesante que el día antes del incidente con Rostelecom, un pequeño proveedor de "Nueva Realidad" (AS50048) de la ciudad de St. a través de Transtelecom fue 2658 prefijos que afectan a Orange, Akamai, Rostelecom y redes de más de 300 empresas. La fuga de ruta provocó varias oleadas de desvíos de tráfico que duraron varios minutos. En su punto máximo, el problema abarcó hasta 13.5 millones de direcciones IP. Se evitó una perturbación global notable gracias al uso de restricciones de ruta en Transtelecom para cada cliente.
Incidentes similares ocurren en la web global. y continuará hasta que se implemente universalmente Anuncios BGP basados en RPKI (BGP Origin Validation), que permiten recibir anuncios únicamente de los propietarios de la red. Sin autorización, cualquier operador puede anunciar una subred con información ficticia sobre la longitud de la ruta e iniciar el tránsito por ella misma de parte del tráfico procedente de otros sistemas que no aplican filtrado de publicidad.
Al mismo tiempo, en el incidente que nos ocupa, una verificación utilizando el repositorio RIPE RPKI resultó ser . Por coincidencia, tres horas antes de la filtración de la ruta BGP en Rostelecom, en el proceso de actualización del software RIPE, 4100 registros ROA (Autorización de Origen de Ruta RPKI). La base de datos se restauró recién el 2 de abril y durante todo este tiempo la verificación no funcionó para los clientes de RIPE (el problema no afectó a los repositorios RPKI de otros registradores). Hoy RIPE tiene nuevos problemas y repositorio RPKI en 7 horas .
El filtrado basado en registros también se puede utilizar como solución para bloquear fugas (Registro de enrutamiento de Internet), que define sistemas autónomos a través de los cuales se permite el enrutamiento de prefijos determinados. Al interactuar con operadores pequeños, puede limitar la cantidad máxima de prefijos aceptados para las sesiones EBGP (configuración de prefijo máximo) para reducir las consecuencias de los errores humanos.
En la mayoría de los casos, los incidentes son el resultado de errores aleatorios del personal, pero recientemente también se han producido ataques dirigidos, durante los cuales los atacantes comprometen la infraestructura de los proveedores. и tráfico para sitios específicos a través de la organización de ataques MiTM para reemplazar las respuestas DNS.
Para dificultar la obtención de certificados TLS durante este tipo de ataques, la autoridad de certificación Let's Encrypt a la comprobación de dominios multisitio utilizando diferentes subredes. Para evitar esta verificación, un atacante necesitaría lograr simultáneamente la redirección de rutas para varios sistemas autónomos de proveedores con diferentes enlaces ascendentes, lo cual es mucho más difícil que redirigir una sola ruta.
Fuente: opennet.ru