El lunes por la noche del 12 de noviembre de 2018, Google y otros servicios experimentaron una interrupción de 74 minutos. No es la primera vez que esto sucede, aunque no es muy habitual ver a Google caído. Así es como un error de ruta cometido en Nigeria se propagó a través de China y luego a través de Rusia. Dada la cantidad de tráfico involucrado, las redes se vieron abrumadas y Google quedo inalcanzable (inaccesible). El ISP nigeriano cometió un error de enrutamiento que fue aceptado por un gran ISP chino (China Telecom), causando así inadvertidamente la interrupción: en términos

BGP

El tráfico de Internet depende en gran medida de un sistema llamado BGP, la abreviatura de Border Gateway Protocol, que los ISP utilizan para decirse qué tráfico pueden enrutar y qué tan eficientemente pueden llegar a su destino.

Al comunicarse de forma regular y automática entre ellos sobre la mejor manera de ir de X a Y, de Y a Z, etc., los proveedores de Internet no solo se ayudan mutuamente a encontrar las mejores rutas, sino que también se adaptan rápidamente para evitar los cortes en la red.

Desafortunadamente, BGP no es particularmente robusto, y la simplicidad que lo hace rápido y efectivo puede causar problemas si un ISP comete un error de enrutamiento, o, en este caso, si un ISP se desvía y anuncia deliberadamente rutas falsas para desviar o descarrilar el tráfico de otras personas.

En pocas palabras, las buenas noticias sobre rutas confiables viajan rápido a través de BGP, pero las noticias falsas sobre rutas incorrectas o infames viajan igual de rápido, hasta que alguien se da cuenta y la mayoría competente de la comunidad reacciona para corregir el error.

¿Pero fue un error, o deberíamos asumir algún tipo de conspiración?

Después de todo, Nigeria está conectada popularmente con el fraude en línea; China es frecuentemente acusada de espionaje en internet; y un artículo recientemente publicado afirmó explícitamente que China ha estado usando sistemáticamente el secuestro de BGP como una técnica de ataque cibernético.

Reúna todo esto y es fácil llegar a la conclusión de que aquí ocurrió algo deliberado y nefasto, en lugar de simplemente culpar a un lapso momentáneo.

Pero, como ya lo han señalado los operadores de redes con experiencia, si esto fue un secuestro deliberado, fue un hecho espectacularmente inefectivo y obvio que no funcionó, porque la comunidad de ISP en general se dio cuenta rápidamente y lo solucionó.

Proveedor de Servicios Internet Nigeria - MainOne

Un ISP nigeriano, llamado MainOne,configuró incorrectamente y accidentalmente parte de su red causando una "fuga de ruta". Esto provocó que Google y otras redes se enrutaran a través de rutas de red inusuales. Los incidentes como este ocurren con bastante frecuencia, pero en este caso, los flujos de tráfico generados por los usuarios de Google fueron tan grandes que abrumaron las redes intermediarias, lo que resultó en numerosos servicios (pero predominantemente en Google) quedaran inalcanzables.

Es posible que te sorprenda al saber que un error de un ISP en algún lugar del mundo podría hacer que Google y otros servicios queden sin conexión.



¿Qué es una fuga en la ruta y cómo sucede?

Cuando el tráfico se enruta fuera de las rutas de enrutamiento regulares y óptimas, esto se conoce como una "fuga de ruta". Una explicación de cómo suceden requiere un poco más de contexto.

Cada red y proveedor de red en Internet tiene su propio número de Sistema Autónomo (AS). Este número es único e indica la parte de Internet que controla esa organización. Es importante tener en cuenta la siguiente explicación El número AS principal de Google es 15169. Ese es el rincón de Internet de Google y donde el tráfico de Google debería terminar ... por el camino más rápido.

 TransTelecom (AS 20485) en Rusia, China Telecom (AS 4809) en China y MainOne (AS 37282)

Google está directamente conectado a la mayoría de las redes Tier-1 (las redes más grandes conectan grandes franjas de Internet). Cuando todo funciona como debería ser, la ruta AS de Google, que los paquetes de ruta toman de una red a otra para llegar a su destino, es realmente muy simple. Por ejemplo, en el diagrama anterior, si era cliente de Cogent e intentaba acceder a Google, la ruta AS que vería es "174 6453 15169". Esa cadena de números es como una secuencia de puntos de ruta: comience en AS 174 (Cogent), vaya a Tata (AS 6453), luego vaya a Google (AS 15169). Entonces, los suscriptores de Cogent llegan a Google a través de Tata, un gran proveedor de Nivel 1.




Durante el incidente, MainOne m configuró incorrecetamente su ruta como se refleja en la ruta AS: "20485 4809 37282 15169". Como resultado de esta mala configuración, cualquier red con la que MainOne se asomó (es decir, estaba directamente conectada a) tenía sus rutas filtradas a través de esta ruta errónea. Por ejemplo, el cliente de Cogent en el párrafo anterior (AS 174) no habría ido a través de Tata (AS 6453) como deberían haberlo hecho. En su lugar, fueron enviados primero a través de TransTelecom (una aerolínea rusa, AS 20485), luego a China Telecom CN2 (una aerolínea china transfronteriza, AS 4809), luego a MainOne (el ISP nigeriano que configuró mal todo, AS 37282), y solo entonces fueron finalmente entregados a Google (AS 15169). En otras palabras, un usuario en Londres podría haber tenido su tráfico de Rusia a China y Nigeria, y solo así llegar a Google.





La causa principal de esto fue que MainOne configuró mal su enrutamiento. Como se mencionó anteriormente, incidentes como este en realidad ocurren con bastante frecuencia. El impacto de esta mala configuración debería haberse limitado a MainOne y sus clientes.

Sin embargo, lo que lo tomó de relativamente aislado y lo convirtió en uno mucho más amplio se debe a que CN2, el operador transfronterizo premium de China Telecom, no estaba filtrando el enrutamiento que MainOne les brindó. En otras palabras, MainOne le dijo a CN2 que tenía autoridad para enrutar las direcciones IP de Google. La mayoría de las redes lo verifican, y si es incorrecto, lo filtran. CN2 no lo hizo, simplemente confió en MainOne. Como resultado de esto, la mala configuración de MainOne se propagó a una red sustancialmente más grande. Para agravar esto, es probable que la red rusa TransTelecom se comportara de manera similar hacia CN2 como CN2 se había comportado hacia MainOne: confiaban sin ninguna verificación de las rutas de enrutamiento que CN2 les daba.

Esto demuestra cuánta confianza hay en las conexiones subyacentes que conforman Internet. Es una red de redes. Que funciona mediante la cooperación entre diferentes entidades (países y empresas).


Vale la pena declarar explícitamente: el hecho de que el tráfico de Google se enrutó a través de Rusia y China antes de ir a Nigeria y solo al llegar al destino correcto hizo que a algunas personas les pareciera que la mala configuración. Había demasiada confianza y no había suficiente verificación en varias redes: este es un problema sistémico que hace que Internet sea más vulnerable a los errores de lo que debería ser.

Cómo mitigar las fugas de ruta

Junto con los sistemas internos de Cloudflare, BGPMon.net y ThousandEyes detectaron el incidente. BGPMon tiene varios métodos para detectar anomalías; en este caso, pudieron detectar que los proveedores en las rutas para llegar a Google eran irregulares.


Esperamos que todas las redes que brindan servicios de tránsito puedan garantizar el filtrado adecuado de sus clientes, eliminar los secuestros y las filtraciones de ruta e implementar las mejores prácticas como BCP-38.

Los paquetes falsos deberían prohibirse en el origen (BCP38) Network Ingress Filtering: Defeating Denial of Service Attacks que emplea "IP Source Address Spoofing"

Implementar (para evitar IP Spoofing)

• BCP38 (RFC2827)
• BCP84 (RFC3704)

La idea es simpple. Dropear (drop, descartar) los paquetes que entran la red (border router) cuya dirección de origen no es la misma que la dirección de red asignada de la red de origen

Implementar filtros ingress/egress filter en el border router del ISP:

Fuentes:
https://blog.cloudflare.com/how-a-nigerian-isp-knocked-google-offline/
https://nakedsecurity.sophos.com/2018/11/13/google-and-cloudfare-traffic-diverted-to-china-do-we-need-to-panic/