Si en las últimas horas has intentado abrir ubuntu.com, leer el blog de Canonical o entrar al portal de desarrolladores y la página se quedaba cargando, el problema no estaba en tu conexión. Un ataque DDoS a Canonical, una denegación de servicio distribuida en la que una multitud de equipos lanza peticiones a la vez hasta saturar los servidores, dejó caídos o intermitentes sus principales portales durante más de cuatro horas. Lo llamativo no es solo que ocurriera, sino qué se vio afectado y qué siguió funcionando con normalidad.
Qué dominios se quedaron sin respuesta
Según los informes, el ataque se dirigió contra los servidores públicos de la compañía, los que sirven documentación, noticias y herramientas en línea. Cayeron los dominios más visibles, canonical.com y ubuntu.com, pero también el blog oficial, el portal de desarrolladores, assets.ubuntu.com, academy.canonical.com y sitios ligados a tecnologías empresariales como jaas.ai y maas.io. Hasta que los equipos de operaciones de red lograron mitigar el tráfico anómalo y estabilizar la plataforma, buena parte de ese escaparate fue inaccesible.
El equipo de ingeniería reconoció la degradación del servicio a través de la página de estado oficial y de los canales técnicos de Ubuntu Discourse, mientras aplicaba contramedidas urgentes. Y aquí está el detalle que más pesa para quien administra sistemas: la API de seguridad de Ubuntu y los servicios de Livepatch quedaron inaccesibles de forma temporal. Livepatch, para quien no lo use, permite aplicar parches al kernel sin reiniciar la máquina, y tanto esa herramienta como la API de avisos de seguridad suelen consultarse de forma automática, sin que nadie las abra en un navegador.
Por qué instalar y actualizar siguió siendo posible
Aquí es donde el diseño de la infraestructura demostró su utilidad. Los repositorios de paquetes que gestiona APT siguieron funcionando gracias a la red global de servidores espejo, así que las instalaciones y actualizaciones rutinarias no se detuvieron. Si lo tuyo era un apt upgrade de un día cualquiera, probablemente ni te enteraste. Lo mismo vale para el resto de piezas que sostienen el día a día. Launchpad, el centro de compilación y empaquetado, la Snap Store, los servidores de imágenes de disco y Ubuntu Single Sign-On, el sistema de autenticación unificada, mantuvieron su operatividad. Lo que se bloqueó fue la parte de cara al público, mientras la capa esencial de despliegue y mantenimiento de servidores quedaba aislada de la interrupción. Vista desde fuera parece una separación obvia, pero no se improvisa: exige haber replicado y distribuido bien lo importante antes de que llegue el ataque.
El segundo ataque grande del año y un historial que conviene recordar
No es un hecho aislado. Este es el segundo DDoS de gran escala que Canonical afronta en 2026, después de una ofensiva similar a inicios de mayo que también comprometió la infraestructura web y que se atribuyó al colectivo hacktivista conocido como 313 Team. En esta ocasión la compañía no ha señalado a los responsables ni ha publicado un informe forense detallado sobre el origen del tráfico malicioso, así que conviene ser cauto con cualquier atribución que circule por ahí: de momento no hay nada confirmado.
Tampoco es la primera vez que Canonical aparece en estas noticias, aunque los episodios anteriores fueron de otra naturaleza. En julio de 2019 la empresa confirmó una intrusión en sus herramientas de desarrollo, después de que una cuenta suya en GitHub quedara comprometida por una filtración de credenciales. Los atacantes crearon repositorios e informes falsos, pero las auditorías concluyeron que el código de Ubuntu y sus repositorios principales se mantuvieron intactos. Los foros oficiales sufrieron además dos brechas de datos. En julio de 2013, un atacante aprovechó una vulnerabilidad XSS y una cuenta de moderador comprometida en el software vBulletin para exponer los datos de más de 1,8 millones de usuarios, y Canonical respondió apostando por Ubuntu Single Sign-On. En julio de 2016, una inyección SQL en un complemento de los foros dejó al descubierto nombres de usuario, direcciones IP y correos de dos millones de registros. Gracias a ese sistema de autenticación unificado, las contraseñas no resultaron comprometidas.
Cuando el aviso de seguridad también es infraestructura
Este episodio deja una pregunta incómoda que va más allá de Canonical. Solemos pensar en la seguridad como el parche en sí, el código corregido, y damos por hecho que el aviso que nos dice que hay que aplicarlo estará siempre ahí, a una consulta de distancia. Pero ese aviso vive en un servidor, y los servidores se pueden saturar. Cuando los puntos de enlace de avisos de seguridad y metadatos de vulnerabilidades se interrumpen, las cadenas de integración y auditoría automatizada de miles de organizaciones se quedan un rato sin una fuente oficial con la que evaluar sus cargas de trabajo. No se rompió ningún paquete ni se tocó una línea de código, y sin embargo, durante unas horas, mucha gente trabajó a ciegas.
Quizá la lección no sea que las infraestructuras abiertas sean frágiles, porque la capa esencial aguantó, sino que la información de seguridad merece la misma redundancia que reparten los espejos de paquetes. Si nadie debiese depender de un único servidor para instalar software, ¿por qué aceptamos depender de uno solo para saber qué hay que actualizar?
Fuente: Ubuntulog
Añadir comentario
Comentarios