La razón del fracaso fue que CenturyLink, al ser un proveedor de Nivel 3, formuló incorrectamente la regla BGPFlowspec en el protocolo de seguridad. BGP Flowspec se utiliza para redirigir el tráfico, por lo que este error provocó graves problemas de enrutamiento dentro de la red del proveedor, que también afectaron la estabilidad de Internet global. Por supuesto, los usuarios de EE. UU. Fueron los más afectados, pero los ecos de los problemas se sintieron en todo el mundo.
Es importante señalar que CenturyLink es la tercera compañía de telecomunicaciones más grande de Estados Unidos, solo detrás de AT&T y Verizon.
BGP Flowspec de IETF es RFC 5575 y se describe como una extensión multiprotocolo de BGP MP-BGP que contiene información de accesibilidad de capa de red (NLRI) . BGP FlowSpec es un método alternativo para descargar el tráfico DDoS atacante desde una ruta, que se considera una forma más sutil de evadir un ataque que RTBH (filtrado de agujero negro activado por control remoto) , cuando todo el tráfico de la dirección del ataque está bloqueado o el tráfico a la dirección de destino. En general, RTBH es un "arma del fin del mundo" y es un último recurso para detener un ataque, ya que su uso muchas veces permite al atacante lograr lo que quiere, es decir, aislar una de las direcciones.
BGP FlowSpec es más sutil y es esencialmente un filtro de firewall que se inserta en BGP para filtrar puertos y protocolos específicos y determina qué tráfico pasar por qué ruta. Por lo tanto, el tráfico "blanco" va a la dirección de destino y, definido como DDoS, se elimina de la ruta. El tráfico se analiza mediante al menos 12 parámetros NLRI:
- Prefijo de destino. Especifica el prefijo de destino para la coincidencia.
- Prefijo de fuente. Especifica el prefijo original.
- Protocolo IP. Contiene un conjunto de pares {operador, valor} que se utilizan para mapear el byte de valor IP en paquetes IP.
- Puerto. Determina si los paquetes serán procesados por TCP, UDP o ambos.
- . , FlowSpec.
- . , FlowSpec.
- ICMP.
- ICMP.
- TCP.
- . IP- ( 2, IP-).
- DSCP. Class Of Service flag.
- Fragment Encoding
No hay informes de fallas completos de CenturyLink, solo mencionan su centro de datos cerca de Ontario. Sin embargo, la falla de enrutamiento fue lo suficientemente grave como para ser notada no solo por los usuarios comunes, sino también por los ingenieros de CloudFlare, quienes también utilizan los servicios de CenturyLink como un gran proveedor. Todo comenzó con un aumento en los errores 522 a las 10:03 am GMT del 30 de agosto,
según un informe de CloudFlare .
Por ejemplo, el sistema de redireccionamiento automático de fallas pudo reducir la cantidad de errores y reducirlos al 25% del valor máximo, pero los problemas con la conectividad de la red y la disponibilidad de recursos aún persisten y son de naturaleza global. Todo esto se hizo en una ventana entre las 10:03 am al comienzo del accidente y hasta las 10:11 am UTC. Durante estos ocho minutos, la automatización y los ingenieros desconectaron su infraestructura de CenturyLink en 48 (!) Ciudades de América del Norte y redirigieron el tráfico a los canales de respaldo de otros proveedores.
Obviamente, esto no solo se hizo en CloudFlare. Sin embargo, esto no solucionó completamente el problema. Para mayor claridad, qué influencia tiene el proveedor problemático en el mercado de telecomunicaciones de Estados Unidos y Canadá, los ingenieros de la compañía proporcionaron un mapa oficial de la disponibilidad de los servicios de CenturyLink:
En los EE. UU., 49 millones de personas utilizan el proveedor, lo que significa que para algunos clientes, si hablamos del informe CloudFlare, e incluso de centros de datos completos, CenturyLink es el único proveedor disponible.
Como resultado, debido a la caída casi total de CenturyLink, los especialistas de CloudFlare registraron una reducción del 3.5% en el tráfico global de Internet. Así es como se veía en un gráfico para los seis proveedores principales con los que trabaja la empresa. CenturyLink está en rojo.
El hecho de que la falla fue global, y no solo "un problema en el centro de datos fuera de Ontario", como dijo el propio proveedor, se evidencia por el tamaño de las actualizaciones de las reglas de Flowspec. Normalmente, las actualizaciones de configuración de BGP Flowspec tienen un tamaño de aproximadamente 2 megabytes, pero los expertos de CloudFlare registraron actualizaciones de configuración de BGP de hasta 26 Mb (!).
Estas actualizaciones, que se distribuyen cada 15 minutos, comparten información con los hosts sobre los cambios en el estado de la ruta. Esto le permite responder de manera flexible a algunos problemas locales. Las actualizaciones de 10 a 15 veces más grandes de lo habitual indican que casi toda la red del proveedor está inactiva o que hay problemas de conectividad extremadamente graves.
CloudFlare cree que la falla fue causada por una regla BGP Flowspec global incorrecta, que fue recibida por la gran mayoría de enrutadores, que luego se reinició en sentido inverso en un intento de restaurar la conexión. Esto encaja en la imagen de un accidente que duró más de 4 horas. Fue cuando la sobrecarga de la memoria y la CPU de los enrutadores podría hacer que los ingenieros perdieran el acceso remoto a varios nodos e interfaces de control.
Por cierto, esta historia está lejos de ser única. Hace poco más de un año, Internet en todo el mundo se "colapsó" por culpa de los propios CloudFlare y la falla de su DNS , además la misma empresa menciona honestamente problemas similares con Flowspec hace siete años , luego de lo cual dejaron de usarlo.