Cloudflare se ha ganado en la última década la reputación de ser uno de los gigantes tecnológicos más temidos por los atacantes de Internet. Su infraestructura global actúa como un escudo anti-DDoS capaz de frenar oleadas de tráfico malicioso que dejarían de rodillas a cualquier otra infraestructura online. Es, de hecho, la compañía que presume de haber contenido ataques de más de 11 terabits por segundo y miles de millones de peticiones por segundo.

Además, para entidades como LaLiga, que ha intentado combatir la difusión no autorizada de retransmisiones deportivas en tiempo real, Cloudflare se ha convertido en una pesadilla que no se aviene a pactar con ellos el bloqueo de dichas emisiones, lo que lo ha convertido en la diana de todos sus dardos legales y mediáticos.

Sin embargo, el pasado día 12 de septiembre, el cazador se convirtió en su propia presa: la empresa especializada en parar ciberataques se auto–DDoSéo por culpa de un error de programación en su panel de control. El resultado: más de una hora de caída de sus APIs internas y de su dashboard, herramienta clave para millones de clientes en todo el mundo.

¿Cómo se puede "auto-atacar" una empresa como Cloudflare?

La ironía del suceso no ha pasado desapercibida: Cloudflare explicó en un informe pormenorizado que el incidente comenzó con el despliegue de una nueva versión de su Dashboard (el panel de gestión que usan los clientes). Y dentro del código React de esa interfaz había un error en el uso del hook useEffect.

Así, en lugar de ejecutar una petición a la Tenant Service API (el servicio encargado de autorizar solicitudes) una sola vez por renderizado, el bug hacía que se repitiera en bucle cada vez que cambiaba el estado de la aplicación. En la práctica, esto significaba miles de llamadas redundantes en cuestión de segundos.

El momento no pudo ser peor: casi en paralelo, el equipo de ingeniería había desplegado una nueva versión de la propia Tenant Service API. La combinación de ambos factores desencadenó lo que en la jerga se conoce como un 'thundering herd': una estampida de peticiones legítimas, pero descontroladas que saturó al servicio, incapaz de recuperarse por sí solo.

En Genbeta

El hacker Chema Alonso dimite como asesor de los árbitros de fútbol tras fichar por Cloudflare, la 'bestia negra' de LaLiga

El uso problemático de 'useEffect'

El epicentro de esta tormenta fue un viejo conocido para la comunidad de desarrolladores de React: el hook useEffect. Esta función, pensada para manejar efectos secundarios, puede convertirse en una trampa si se configuran incorrectamente sus dependencias. En este caso, se incluyó un objeto que React trataba como 'nuevo' en cada cambio de estado, lo que provocaba que el efecto se ejecutase repetidamente en un ciclo infinito.

La propia documentación oficial de React advierte de este tipo de errores, y en foros como Reddit el caso de Cloudflare ha reavivado el debate sobre si la industria depende en exceso de useEffect para tareas que deberían resolverse de otra forma.

Cronología de una caída anunciada

El 'auto-DDoS' se desarrolló a lo largo de tres horas de vértigo:

• 16:32 UTC: Se lanza la nueva versión del Dashboard con el bug.
• 17:50 UTC: Despliegue de la nueva Tenant Service API.
• 17:57 UTC: El servicio queda abrumado. El dashboard se vuelve inoperativo y las APIs empiezan a devolver errores 5xx.
• 18:17 UTC: Tras añadir más recursos, la disponibilidad de las APIs sube al 98%, pero el dashboard sigue caído.
• 18:58 UTC: Cloudflare publica un parche para eliminar rutas con errores… pero empeora la situación.
• 19:12 UTC: Se revierten los cambios y todo vuelve a la normalidad.

Eso sí, durante todo el incidente, la red de datos de Cloudflare siguió funcionando: el tráfico de webs y servicios protegidos nunca se vio afectado: solo la plataforma de gestión quedó fuera de combate.

Vía | Cloudflare

Imagen | Marcos Merino mediante IA

En Genbeta | Las webs saqueadas por empresas de IA les pagarán con su propia medicina: Cloudflare quiere poner a buen recaudo el contenido 'humano' 

Desde su fundación, Cloudflare ha desempeñado un papel fundamental en la protección de sitios web contra los ataques de denegación de servicio distribuido (DDoS). En 2017, la compañía implementó funciones de 'mitigación sin límites', ofreciendo protección contra los DDoS a todos sus clientes, incluso aquellos con planes gratuitos.

Con esta iniciativa buscaba democratizar la seguridad online, permitiendo que cualquier sitio web, independientemente de su tamaño o presupuesto, pudiera estar a salvo de estos ataques.

Cloudflare protege actualmente cerca del 20% de todos los sitios web a nivel mundial

Durante los últimos años, la amenaza de los ataques DDoS se ha intensificado en términos de volumen y sofisticación: en 2024, Cloudflare informó haber mitigado un total de 21,3 millones de ataques DDoS a lo largo del año, lo que representa un aumento del 53% en comparación con el año anterior (y equivale a un promedio de 4.870 ataques bloqueados por hora).

Uno de los eventos más destacados fue la mitigación del mayor ataque DDoS registrado hasta ese momento: uno que alcanzó un pico de 5,6 terabits por segundo (Tbps), lanzado por una variante del botnet Mirai y dirigido a un proveedor de servicios de Internet en Asia Oriental. La plataforma detectó y neutralizó el ataque en segundos, evitando interrupciones en el servicio.

En Xataka

Qué es Cloudflare, cómo funciona y por qué una caída o bloqueo hace que medio Internet falle

Además, la compañía observó un aumento significativo en los ataques "hipervolumétricos", aquellos que superan los 1 Tbps: en el cuarto trimestre de 2024, se registraron más de 420 de estos ataques (lo que representa un incremento del 1.885% con respecto al trimestre anterior).

Un nuevo récord

Sin embargo, el 24 de abril de 2025, Cloudflare volvió a demostrar por qué es uno de los pilares fundamentales de la ciberseguridad global: sus sistemas neutralizaron automáticamente el que ahora ya es el mayor ataque DDoS registrado hasta la fecha, con un pico de 5,8 Tbps.

Lo más impresionante es que la mitigación se produjo sin intervención humana y sin que los servicios protegidos por la plataforma sufrieran interrupciones. Matthew Prince, CEO de Cloudflare, compartió los detalles en su cuenta de X, destacando la capacidad de sus sistemas para absorber el 'golpe' sin siquiera inmutarse.

¿Y aquí en España?

Este evento, por otra parte, se produce en medio de la creciente controversia en nuestro país España por los bloqueos masivos ordenados por LaLiga contra miles de webs alojadas en Cloudflare, perfectamente legítimas pero a las que se mete en el mismo saco (por compartir dirección IP) que a algunas emisiones no autorizadas de eventos deportivos que también se encuentran tras el escudo anti-DDoS de Cloudflare.

En Genbeta

Javier Tebas señala a Cloudflare como cómplice de delitos, pero hasta su propio bufete de abogados lo usa

La retórica de LaLiga, y especialmente de su presidente, Javier Tebas, ha sido especialmente negativa contra Cloudflare (a pesar de que sus bloqueos afectan a muchos proveedores más), acusando a esta plataforma de ser cómplice de

"actividades ilegales como el proxenetismo, prostitución, pornografía, comercialización de falsificaciones, fraude y estafa, entre otras".

Muchas de esas webs, tras ver cómo sus ganancias se desplomaban tras ser bloqueadas una jornada liguera tras otra (la mitad del mes, en el mejor de los casos), han terminado renunciando en muchos casos al servicio de protección anti-DDoS que les brindaba gratuitamente Cloudflare, lo que ahora les obliga a realizar gastos extra para obtener protección anti-DDoS por otras vías o, sencillamente, quedar expuestos a los mismos.

Tuit reciente del responsable de la empresa de diseño web Nexo Virtual

José Ángel Martínez, fundador de NinjaLabs, explicaba a los compañeros de Xataka la situación de muchos clientes tras haber dado este paso:

"Sus servidores consumen entonces muchos  más recursos, porque tienen que con peticiones de bots que llegan de  todos lados y que normalmente quedarían frenados por el servicio de  Cloudflare. De repente, las necesidades de infraestructura suben, y  encima los intentos por gestionar bots pueden acabar bloqueando tráfico  legítimo. Una verdadera pesadilla".

Recientemente, una nueva decisión judicial ha vuelto a respaldar a LaLiga en su enfrentamiento contra Cloudflare, al rechazar las peticiones de nulidad presentadas por la compañía tecnológica (y por RootedCON) contra la legalidad de los bloqueos masivos. En su decisión, el juez declaró 'no probado' que se haya causado daños directos a terceros, y señaló a las operadoras (y no a los bloqueados) como 'afectados' por la sentencia original.

Hace ocho años, en una entrevista a Vice, el CEO de Cloudflare vaticinaba que los ataques DDOS terminarían siendo "algo sobre lo que solo leerás en los libros de historia", y hablaba de la desigualdad que los usuarios experimentaban ante los mismos:

"No debemos crear un sistema de justicia paralela en el que un único individuo, sólo porque está molesto con alguien, puede cerrar sitios web. Lo que estamos tratando de hacer es decir 'independientemente de cuáles sean tus recursos, vamos a mantenerte online".

Imagen | Marcos Merino mediante IA

En Genbeta | "Esto no va de quedarte offline, sino de derechos fundamentales". RootedCON proseguirá la lucha legal contra los bloqueos de LaLiga

Los archivos de registro (o 'logs') de un servidor web son ficheros de texto almacenados en el mismo en el que se registran las solicitudes de acceso HTTP a cualquier recurso del servidor (páginas, imágenes, scripts, etc.): en definitiva, son un registro de todo el tráfico del mismo.

Cada una de sus líneas puede tener un aspecto similar al siguiente, con información del 'user agent' del usuario, IP de origen, URL de destino y fecha del acceso:

11.222.333.44 - - [11/Dec/2023:11:02:33 –0600] "GET /blog/presentacion.html HTTP/1.1" 200 182 "-" "Mozilla/5.0 Chrome/60.0.3112.113"

Pero cuando lo que nos interesa no es cada línea individual, sino los patrones de tráfico y/o los flujos de visitas que el servidor está recibiendo en directo, necesitamos una buena herramienta de visualización de logs. Y aquí es donde entra una de las más interesantes de esta categoría: Logstalgia.

En Xataka

Internet explicada para que cualquier persona pueda entender cómo funciona (y por qué a veces una parte queda KO)

Una forma distinta de visualizar registros de solicitudes HTTP

Logstalgia es una herramienta de visualización de logs de sitios web que presenta (reproduciendo a posteriori o 'retransmitiendo' en tiempo real) los accesos al mismo de un modo tan informativo como visualmente estimulante: como si fuera un videojuego vintage de Pong o matamarcianos.

Las solicitudes de acceso se nos muestran como bolas de colores (del mismo color que el anfitrión) que cruzan la pantalla hasta llegar a la ubicación solicitada: las que llegan a su destino (que puede ser una URL o una etiqueta global, como 'imágenes') terminan impactando, mientras que las fallidas (como los errores 404) se pierden por el borde contrario de la pantalla.

Por ejemplo, un ataque de denegación de servicio (DDoS) contra nuestro servidor, ejecutado mediante una botnet, se vería muy similar a esto (los datos muestran un ataque DDoS a la web del famoso reproductor multimedia VLC):

Logstalgia es compatible con los principales formatos estandarizados de logs usados por los dos softwares para servidores web más usados de Internet (Nginx y Apache), pero, según advierte su web, necesitaremos contar con un servidor web bastante transitado (a partir de las 100 solicitudes por minuto) para lograr resultados interesantes cuando lo usemos en tiempo real.

Así, para reproducir un log basta un comando tan sencillo como éste:

logstalgia data/example.log

…mientras que para visualizar los resultados del log en tiempo real tendremos que utilizar (en el caso de los sistemas Unix) un comando similar a éste:

tail -f /var/log/apache2/access.log | logstalgia --sync

Logstalgia es un software de código abierto, y está disponible (en su web y/o en repositorios de distribuciones) para ser instalado en Windows, Mac OS, Linux y sistemas BSD.

Imagen | Marcos Merino mediante IA + Captura de pantalla

En Genbeta | Una vulnerabilidad del protocolo HTTP/2 ha provocado los mayores ciberataques DDoS de la historia

El pasado mes de septiembre, gigantes tecnológicos como Google, Amazon y Cloudflare detectaron los mayores ataques distribuidos de denegación de servicio (o 'ataques DDoS') registrados hasta la fecha.

Según Google, en agosto de este mismo año logró mitigar un ataque DDoS que, en su mayor pico de tráfico, alcanzó un volumen de 398 millones de solicitudes por segundo. El anterior ataque récord, ejecutado en agosto de 2022, sólo llegó a alcanzar los 46 millones de solicitudes/segundo…

…y aquello ya resultaba equivalente a "recibir todas las solicitudes diarias a Wikipedia (uno de los 10 sitios web más visitados del mundo) en tan sólo 10 segundos", según explicaron los expertos de la compañía.

Google explicó que, pese a la magnitud de estos ataques, logró frenarlos gracias a su infraestructura global de equilibrio de carga. Sin embargo, el Equipo de Respuesta a DDoS de Google ha agregado protecciones adicionales para mitigar en el futuro ataques similares.

Amazon, por su parte, informó que durante el 28 y 29 de agosto de 2023, presenció un ataque con un pico de más de 155 millones de solicitudes por segundo.

En Genbeta

El tercer ataque DDoS en Andorra sugiere que es mejor evitar irte a un lugar con un solo proveedor de Internet si eres streamer

Cloudflare, una empresa especializada en seguridad de infraestructura en Internet, descubrió la vulnerabilidad HTTP/S de día cero en agosto y observó un ataque que alcanzó un pico de 201 millones de solicitudes por segundo.

¿Dónde radica el problema?

Las tres compañías llegaron a la conclusión de que dichos ataques habían sido provocados por una vulnerabilidad recién descubierta en el protocolo HTTP/2 —una pieza fundamental de la infraestructura de Internet, base del 60% de las aplicaciones web—.

Esta vulnerabilidad, conocida como CVE-2023-44487, permite a los atacantes apostar por un nuevo enfoque en su misión de sobrecargar sitios web con un flujo repentino de tráfico, dejándolos temporalmente inaccesibles para los usuarios.

Este tipo de ataque se conoce como 'Ataque de Reset Rápido de HTTP/2' y, hasta el momento, no ha podido ser atribuido a ningún grupo de hackers conocido.

Esta técnica, que permite multiplexar de múltiples solicitudes en una sola conexión, se basa en automatizar la creación masiva de solicitudes de conexión y en su cancelación inmediata, creando un patrón de "solicitud, cancelación, solicitud, cancelación" a gran escala…

El problema radica en que los servidores necesitan procesar estas solicitudes y, si no pueden hacerlo a un ritmo suficientemente rápido, se acumulan en una especie de cola, consumiendo recursos del servidor y ralentizando o incluso bloqueando el acceso a otros usuarios legítimos.

Vía | The Record

Imagen | Marcos Merino mediante IA

En Genbeta | El plan de las operadoras para acabar con las listas IPTV: hacer uso de ataques DDoS

El día de ayer fue realmente importante para nuestro país debido a la celebración de las Elecciones Generales del 23J donde se renovaba el poder legislativo pero también el ejecutivo. Durante toda la noche electoral se pudieron ir consultando los resultados provisionales fruto de la recopilación de datos que hacía el Ministerio del Interior de todas las mesas y que se publicitaba en su web.

Pero cuando hablamos de medios digitales y en una fecha tan importante como esta hay que destacar que los ciberdelincuentes van a querer también colaborar pero de una manera no deseada. Y esto precisamente es lo que ocurrió en el día de ayer cuando la web del Ministerio del Interior se cayó durante varios minutos así como la de la JEC. Y todo esto fruto de un ciberataque.

El Ministerio del Interior sufre un ciberataque en plenas elecciones

En las últimas horas el ya conocido grupo Noname057 ha reivindicado la autoría del ataque a las web de la administración pública en un momento que es clave como son unas elecciones en todo el estado. Para poder llevar a cabo este ataque usaron una técnica que es clásica como es el ataque DDoS para provocar una denegación de servicio.

La consecuencia principal del ataque es precisamente que nadie pueda entrar en el sitio web al provocar que  termine totalmente colapsado a raíz de la cantidad de peticiones que recibe el servidor. Todo esto llevado a cabo a través de diferentes botnets, que básicamente son ordenadores infectados de malware y que son dirigidos a realizar numerosas peticiones contra la IP a atacar.

Es por ello que no estamos ante un ataque  grave en el hecho de que pueda suponer una filtración de datos de las bases de datos del ministerio. Pero lo que sí supone es una gran molestia para todas aquellas personas que querían consultar la información actualizada. Aunque por suerte esta fue una caída que duró pocos minutos y los técnicos del ministerio pudieron rescatar la web rápidamente tras la caída. 

En Genbeta

Esta película de 1915 ya incluía las principales técnicas actuales de ciberestafa. Está todo inventado

Lo alarmante es que este no es el primer ataque de este grupo de ciberdelincuentes llamados Noname057 que presuntamente tienen un pensamiento prorruso. Y es por ello que en el pasado han protagonizado otros ataques a instituciones de España como el propio INE, pero también ha atacado a otros países de la Unión Europea y también Estados Unidos. Esto hace que debamos tener como país una infraestructura actualizada y segura que pueda hacer frente a este tipo de peligros.

Vía | VozPopuli

En Genbeta |  Hay escasez de expertos en ciberseguridad, así que puedes hacer este curso gratis de INCIBE: esto es lo que incluye

Los archivos de registro (o 'logs') de un servidor web son ficheros de texto almacenados en el mismo en el que se registran las solicitudes de acceso HTTP a cualquier recurso del servidor (páginas, imágenes, scripts, etc.): en definitiva, son un registro de todo el tráfico del mismo.

Cada una de sus líneas puede tener un aspecto similar al siguiente, con información del 'user agent', IP de origen, URL de destino y fecha del acceso:

11.222.333.44 - - [11/Dec/2021:11:02:33 –0600] "GET /blog/presentacion.html HTTP/1.1" 200 182 "-" "Mozilla/5.0 Chrome/60.0.3112.113"

Pero cuando lo que nos interesa no es cada línea individual, sino los patrones de tráfico y/o los flujos de visitas que el servidor está recibiendo en directo, necesitamos una buena herramienta de visualización de logs. Y aquí es donde entra una de las más interesantes de esta categoría: Logstalgia.

En Xataka

Internet explicada para que cualquier persona pueda entender cómo funciona (y por qué a veces una parte queda KO)

Una forma distinta de visualizar registros de solicitudes HTTP

Logstalgia es una herramienta de visualización de logs de sitios web que presenta (reproduciendo a posteriori o 'retransmitiendo' en tiempo real) los accesos al mismo de un modo tan informativo como visualmente estimulante: como si fuera un videojuego vintage de Pong o matamarcianos.

Las solicitudes de acceso se nos muestran como bolas de colores (del mismo color que el anfitrión) que cruzan la pantalla hasta llegar a la ubicación solicitada: las que llegan a su destino (que puede ser una URL o una etiqueta global, como 'imágenes') terminan impactando, mientras que las fallidas (como los errores 404) se pierden por el borde contrario de la pantalla.

Por ejemplo, un ataque de denegación de servicio (DDoS) contra nuestro servidor, ejecutado mediante una botnet, se vería muy similar a esto (los datos muestran un ataque DDoS a la web del famoso reproductor multimedia VLC):

Logstalgia es compatible con los principales formatos estandarizados de logs usados por los dos softwares para servidores web más usados de Internet (Nginx y Apache), pero, según advierte su web, necesitaremos contar con un servidor web bastante transitado (a partir de las 100 solicitudes por minuto) para lograr resultados interesantes cuando lo usemos en tiempo real.

Así, para reproducir un log basta un comando tan sencillo como éste:

logstalgia data/example.log

…mientras que para visualizar los resultados del log en tiempo real tendremos que utilizar (en el caso de los sistemas Unix) un comando similar a éste:

tail -f /var/log/apache2/access.log | logstalgia --sync

Logstalgia es un software de código abierto, y está disponible (en su web y/o en repositorios de distribuciones) para ser instalado en Windows, mac OS, Linux y sistemas *BSD.

Una versión anterior de este artículo se publicó en 2022.

Ayer día 4 de octubre tuvo lugar el lanzamiento de Overwatch 2, el título de Blizzard que podemos jugar totalmente gratis en PC y consolas. Bueno, o al menos la intención es que podamos jugar gratis, ya que desde que se lanzó para todas sus plataformas, los usuarios han tenido problemas para conectarse a los servidores debido a un ataque DDoS.

El incidente fue tal, que se formaron colas de más de 40.000 personas sin poder acceder al juego. De hecho, hoy 5 de octubre tuvo lugar otro ataque DDoS, haciendo que los problemas persistan y manchando el lanzamiento del título.

Un ataque DDoS ensucia el lanzamiento de Overwatch 2

Overwatch 2 se lanzó en Battle.net y demás plataformas sobre las 20:00 (hora española), y en ese momento, los servidores funcionaban correctamente, pudiendo probar el juego con normalidad. Sin embargo, una hora después empezaron los problemas. Y es que los servidores se saturaron hasta el punto en el que más de 40.000 jugadores permanecieron a la espera de poder jugar. La razón fue un ataque DDoS con el objetivo de darle más quebraderos de cabeza a Blizzard con el lanzamiento de Overwatch 2.

Los fans del juego sufrían desconexiones constantes y largas colas, haciéndose imposible probar el juego durante ese momento. A modo de broma, los usuarios en Reddit alegaban que Overwatch 2 poseía un subtítulo desconocido hasta ahora 'Unexpected Server Error Occurred'.

En Vida Extra

Overwatch 2: estos son sus requisitos mínimos y recomendados para saltar a la acción en PC

Los problemas no solamente afectaron a la conexión del juego, sino que muchos jugadores tampoco pudieron disfrutar de todos los cosméticos de Overwatch 1, ya que la tienda tampoco funcionaba correctamente. Todos los errores del juego se están recopilando en un hilo del foro oficial de Blizzard.

La última actualización de la situación la teníamos esta misma mañana a las 6:30 del 5 de octubre, donde Aaron Keller, director del juego y sucesor de Jeff Kaplan, comentaba que están haciendo progresos en los servidores y que se encuentran trabajando en solventar los problemas ocasionados con un segundo ataque DDoS.

En este momento, el ataque sigue dificultando el acceso a los jugadores, aunque se ha mejorado notablemente la estabilidad de los servidores. Las colas continúan, y los usuarios se desesperan, algo totalmente inesperado para Blizzard, y que tras toda la polémica con Overwatch 2, era lo último que necesitaban.

Los servicios IPTV sin duda son una lacra para las operadoras que tratan de hacer negocio con la venta de paquetes de canales de entretenimiento o de deporte. Son muchos los intentos que se hacen prácticamente a diario por cerrarlos, aunque tras el cierre de uno aparecen cinco más. Ahora, los operadores tienen un plan que tratará de cerrar por la fuerza estos servicios: usando ciberataques.

Esta idea ha surgido desde Hungría y su asociación de medios de comunicación que han denunciado en un primer momento que la justicia no actúa contra estos servicios aunque los denuncien. Esto es algo que pasa en la mayoría de países, donde los procesos de investigación se pueden demorar durante años hasta que se termine sacando una sentencia de cierre. Esto hace que se tengan que explorar otras medidas.

Las operadores recurren a una vía rápida para acabar con las listas IPTV

La solución que se está planteando en estos casos de denegación de servicio DDoS contra los sitios web que alojan las IPTV. Hay que tener en cuenta que todos estos servicios utilizan dominios, direcciones IP, servidores y servicios en la nube como si fuera una web normal. De esta manera, estos proveedores pueden contratar al personal necesario para lanzar ataques y directamente tumbarlos.

Obviamente el hecho de que los canales de las diferentes IPTV se vean afectados por un ataque DDoS hará que la experiencia sea totalmente nefasta, haciendo que los usuarios puedan optar por pagar a los teleoperadores para disfrutar sin caídas constantes. Además, todo estaría pensado, ya que aunque el proveedores de servicios cambiara la IP al detectar el ataque, se podría seguir lanzando más ataques con un rastreo de la dirección IP siendo algo difícil de lo que escapar.

El problema que se puede presentar en este caso es que puede tener daños colaterales. Esto quiere decir que termine afectando al resto de dominios que tenga la empresa de hosting bajo su mismo paraguas. Aunque esto puede tener también buenas noticias para las teleoperadoras, ya que esto puede hacer plantearse a las empresas de hosting el alojar este tipo de servicios.

En Genbeta

Las mejores aplicaciones para ver una lista IPTV en Windows 10

De momento es algo que es una simple propuesta que se está poniendo encima de la mesa en Hungría. Aunque si todo va bien, seguramente muchas operadoras de toda Europa se terminen sumando a esta idea. Si bien, se tiene que revisar la legislación de cada país de manera independiente para saber si realizar estos ataques DDoS se pueden llevar a cabo sin acabar en los tribunales.

Vía | TorrentFreak

Hace ahora un año, la compañía Cloudflare —un gigante de Internet, poco conocido entre el gran público pese a ser un actor clave en la gestión de la infraestructura de la Red de redes— anunció que había logrado hacer frente al mayor ataque DDoS de la historia.

Durante dicho ataque, una enorme red de bots bombardeó los servidores de Cloudflare con hasta 17,2 millones de solicitudes por segundo, una cifra ciertamente desmesurada, y muy por encima de un DDoS medio. De hecho, mientras que la mayoría de los DDoS no buscan más que obstruir el ancho de banda del servidor atacado, el de agosto de 2021 fue un DDoS volumétrico, que buscaba consumir la CPU y la RAM del servidor.

10 meses después, el pasado mes de junio, Cloudflare hizo saber al mundo que había tenido éxito frenando otro ataque mucho mayor contra su propia infraestructura: 26 millones de solicitudes por segundo, con la particularidad de que esta vez se trataba de un ataque vía HTTPS (lo que encarece el ataque y dificulta mitigarlo).

En ese momento, Cloudflare volvía a coronarse como receptor y mitigador del mayor ataque DDoS hasta la fecha. Sin embargo, ahora, tan sólo dos meses más tarde, ha perdido ese trono…

En Xataka

Qué es un ataque DDoS y cómo puede afectarte

46 millones de solicitudes por segundo

…Google Cloud, el servicio de alojamiento en la nube de Google, ha informado de que ha logrado hacer frente con éxito a un ataque mucho mayor, que esta vez ha ascendido a los 46 millones de solicitudes por segundo. Para intentar hacernos una idea de la enormidad de este ataque, pensemos en concentrar en sólo 10 segundos todas las solicitudes de conexión que la Wikipedia suele recibir a lo largo de sólo un día.

Según Google Cloud, el ataque fracasó porque su servicio Cloud Armor fue capaz de detectar los primeros signos de la amenaza e inmediatamente recomendó de manera automatizada una regla de protección para el servidor que logró el milagro de esquivar la bala. Ante el fracaso, el ataque —acometido se extinguió una hora y nueve minutos después. Según explica la compañía en su blog corporativo,

"Además de su inesperadamente alto volumen de tráfico, el ataque tenía otras características notables. Estuvieron implicadas 5.256 IPs procedentes de 132 países distintos que contribuyeron al ataque. […] El ataque se basó en solicitudes cifradas (HTTPS) que requirieron hacer uso de recursos tecnológicos adicionales".

"Aproximadamente el 22% de las IPs de origen se correspondían con nodos de salida de la red Tor, aunque el volumen de solicitudes proveniente de esos nodos representó únicamente el 3% del tráfico del ataque"nuestro análisis muestra que los nodos de salida de Tor pueden enviar una cantidad significativa de tráfico no deseado a aplicaciones y servicios web".

Aparentemente, "la distribución geográfica y los tipos de servicios no seguros aprovechados para generar el ataque" coinciden con los detectados en otros lanzados a través de la red de bots Mēris, de la que Xataka nos informaba el pasado septiembre de 2021 que había conseguido batir dos veces el récord del ataque DDoS más grande de la historia.

Investigadores de seguridad de Akamai, Cloudflare, Lumen Black Lotus Labs, Mitel, Netscour, Team Cymru, Telus y The Shadowserver Foundation han descubierto ataques de denegación de servicio (DDoS por sus siglas en inglés) con un rango de amplificación inmenso: supera los 4.000 millones a 1 y se pueden lanzar desde un solo paquete. Este DDoS ha sido bautizado como CVE-2022-26143.

El fallo reside en unos 2.600 sistemas Mitel MiCollab y MiVoice Business Express que están incorrectamente aprovisionados y, por este motivo, actúan como pasarelas de centralita a Internet y tienen un modo de prueba que no debería estar expuesto a Internet. En su blog, la Fundación Shadowserver explica que la instalación de prueba "puede ser usada para lanzar un ataque DDoS de hasta 14 horas de duración por medio de un único paquete, lo que resulta en una relación de amplificación de paquetes que establece un récord de 4.294.967.296:1".

Gran fuerza para impedir el rastreo

Los investigadores han explicado, además, que "hay que señalar que esta capacidad de iniciación de ataques con un solo paquete tiene el efecto de impedir el rastreo por parte de los operadores de red para conocer quién inició los ataques falsos. Esto ayuda a enmascarar la infraestructura de generación de tráfico de ataque, haciendo menos probable que el origen del ataque pueda ser rastreado"

Un controlador en los sistemas de Mitel contiene un comando. Este puede producir teóricamente 4.294.967.294 paquetes a lo largo de 14 horas con un tamaño máximo posible de 1.184 bytes.

Además de actualizar los sistemas, los usuarios de Mitel pueden detectar y bloquear el tráfico entrante inapropiado en el puerto UDP 10074 con herramientas estándar de defensa de la red. Se aconseja a quienes reciban el ataque que utilicen herramientas específicas de defensa para DDoS.

En Genbeta

El tercer ataque DDoS en Andorra sugiere que es mejor evitar irte a un lugar con un solo proveedor de Internet si eres streamer

Mitel ha publicado actualizaciones de software que deshabilitan el acceso público a la función de prueba, al tiempo que describió el problema como una vulnerabilidad de control de acceso que podría ser explotada para obtener información sensible.

Los primeros ataques que utilizaron el exploit comenzaron el 18 de febrero y se dirigieron a instituciones financieras, empresas de logística y de gaming.

Vía | ZDnet