Tutoriales y Manuales
Entradas Mensuales
-
►
2024
(Total:
1090
)
- ► septiembre (Total: 50 )
-
►
2023
(Total:
710
)
- ► septiembre (Total: 65 )
-
►
2022
(Total:
967
)
- ► septiembre (Total: 72 )
-
►
2021
(Total:
730
)
- ► septiembre (Total: 56 )
-
▼
2020
(Total:
212
)
-
▼
octubre
(Total:
23
)
- Ataque Intercambio de SIM y Robo de WhatsApp con e...
- Actualización de emergencia para el navegador Goog...
- Hackean por segunda vez la contraseña de Donald Tr...
- Autores del ransomware DarkSide deciden donar dine...
- Los ISP están monitoreando las actividades de los ...
- La NSA publica el top 25 de vulnerabilidades aprov...
- Estados Unidos acusa a 6 oficiales de inteligencia...
- Google recibió el mayor ataque DDoS de la historia...
- Los mejores bots de Telegram
- Investigador de Google encuentra errores de Bleedi...
- Graves vulnerabilidades en productos Cisco, SAP, S...
- Software AG sufre un ataque de ransomware; piden 2...
- Microsoft utiliza la ley de marcas comerciales par...
- Actualizaciones de seguridad productos Microsoft: ...
- Los 10 ataques de Phishing más utilizados en 2020
- Fallo incorregible en el chip T2 de Apple permite ...
- Microsoft alerta de un sofisticado ransomware para...
- Descubren un bootkit en UEFI utilizado para espiar...
- Graves vulnerabilidades en HP Device Manager
- Hospital de Nueva Jersey pagó 670 mil dólares para...
- Más del 61% de los servidores Microsoft Exchange s...
- Empresa suiza relojes Swatch víctima de un ransomware
- Condenado a 7 años de prisión el ruso que hackeó L...
- ► septiembre (Total: 21 )
-
▼
octubre
(Total:
23
)
-
►
2019
(Total:
102
)
- ► septiembre (Total: 14 )
-
►
2017
(Total:
231
)
- ► septiembre (Total: 16 )
-
►
2016
(Total:
266
)
- ► septiembre (Total: 38 )
-
►
2015
(Total:
445
)
- ► septiembre (Total: 47 )
-
►
2014
(Total:
185
)
- ► septiembre (Total: 18 )
-
►
2013
(Total:
100
)
- ► septiembre (Total: 3 )
-
►
2011
(Total:
7
)
- ► septiembre (Total: 1 )
Blogroll
Etiquetas
Entradas populares
-
Después de ver qué es una vCPU y la diferencia entre núcleos (cores) e hilos en los procesadores, pasamos a explicar toda la nomenclatura d...
-
iperf3 es la última versión del popular programa iperf para medir el ancho de banda entre dos o más equipos en red local o Internet . Es...
-
A finales del mes de agosto hablábamos de que los legisladores estadounidense habían solicitado la investigación de TP-Link . Y así, ya ten...
Google recibió el mayor ataque DDoS de la historia en 2017
Google absorbió un DDoS de 2.5 Tbps con 167 Mpps (millions of packets per second), en español 167 millones de paquetes por segundo recibió la red Google sin causar ningún impacto. El ataque fue cuatro veces mayor que el de la botnet Mirai de 2016. Supera, también, al sufrido por Amazon AWS a principios de año 2020. Google cree que el ataque fue perpetrado por algún "actor" patrocinado por un país-nación. Y dice que 3 ASN Chinos fueron de los más involucrados en el ataque. A buen entendedor, pocas palabras bastan.
Google mitigó un ataque DDoS de 2,54 Tbps en 2017, el DDoS más grande jamás visto
El equipo de Google Cloud reveló que en septiembre de 2017 mitigó el ataque DDoS que alcanzó los 2.54 Tbps, el mayor ataque DDoS de la historia.
Este ataque es el ataque de denegación de servicio distribuido más grande registrado hasta la fecha.
A pesar de apuntar simultáneamente a miles de nuestras direcciones IP, presumiblemente con la esperanza de esquivar las defensas automatizadas, el ataque no tuvo ningún impacto
“Nuestra infraestructura absorbió un DDoS de 2.5 Tbps en septiembre de 2017, la culminación de una campaña de seis meses que utilizó múltiples métodos de ataque. A pesar de apuntar simultáneamente a miles de nuestras direcciones IP, presumiblemente con la esperanza de superar las defensas automatizadas, el ataque no tuvo ningún impacto ". lee la publicación publicada por Damian Menscher, ingeniero de confiabilidad de seguridad de Google Cloud.
"El atacante utilizó varias redes para falsificar 167 Mpps (millones de paquetes por segundo) a 180.000 servidores CLDAP, DNS y SMTP expuestos, que luego nos enviarían grandes respuestas".
Los investigadores de Google señalaron que el ataque que mitigaron fue cuatro veces mayor que el ataque de 623 Gbps lanzado desde la botnet Mirai en 2016. Los expertos notaron que este ataque es más grande que el ataque DDoS de 2.3 Tbps mitigado por AWS de Amazon en febrero.
Un informe publicado por Google Threat Threat Analysis Group (TAG) especula que el ataque fue llevado a cabo por un actor de amenazas patrocinado por algún estado-nación.
“Hemos visto a jugadores más grandes aumentar sus capacidades para lanzar ataques a gran escala en los últimos años. Por ejemplo, en 2017, nuestro equipo de Ingeniería de Confiabilidad de Seguridad midió un ataque de amplificación UDP sin precedentes proveniente de varios ISP chinos (ASN 4134, 4837, 58453 y 9394), que sigue siendo el ataque de ancho de banda más grande del que tenemos conocimiento ". lee el informe publicado por Google.
Menscher reveló que el ataque fue parte de una campaña que aprovechó múltiples métodos de amplificación DDoS para afectar los servidores de Google.
Google decidió revelar el ataque DDoS para advertir de una tendencia creciente de actores patrocinados por el estado que abusan de los ataques DDoS para atacar recursos en línea.
Los expertos creen que los ataques DDoS son cada vez más peligrosos y se intensificarían en los próximos años.
Este año se registró otro gran ataque de una botnet de IoT. Apuntó al protocolo de red y acertó con 690 millones de paquetes por segundo (mpps). En un informe a principios de año, Amazon AWS reportó un ataque DDoS volumétrico de 2.3Tb por segundo, registrado en el primer trimestre de 2020. La mayor tasa de paquetes por segundo mitigada por Amazon en ese período fue de 293,1 Mpps, más de dos veces menor que la registrada por Google este año.
La colaboración con socios en la comunidad de Internet (proveedores de red, proveedores, clientes) puede ayudar a mitigar los grandes ataques de manera oportuna. Los proveedores de red pueden rastrear paquetes defectuosos y filtrarlos, los proveedores pueden proporcionar parches y alertar a los clientes para que los apliquen.
Las amenazas a la seguridad, como los ataques distribuidos de denegación de servicio (DDoS), perturban las empresas de todos los tamaños, provocando interrupciones y, lo que es peor, la pérdida de la confianza del usuario. Estas amenazas son una de las principales razones por las que en Google le damos mucha importancia a la confiabilidad del servicio, que se basa en la base de una red robusta.
Para ayudar a garantizar la confiabilidad, hemos ideado algunas formas innovadoras de defenderse contra ataques avanzados. En esta publicación, profundizaremos en las amenazas DDoS, mostraremos las tendencias que estamos viendo y describiremos cómo nos preparamos para los ataques de varios terabits, para que sus sitios se mantengan en funcionamiento.
Taxonomía de las capacidades del atacante
Con un ataque DDoS, un adversario espera interrumpir el servicio de su víctima con una avalancha de tráfico inútil. Si bien este ataque no expone los datos del usuario y no conduce a un compromiso, puede resultar en una interrupción y pérdida de la confianza del usuario si no se mitiga rápidamente.
Los atacantes desarrollan constantemente nuevas técnicas para alterar los sistemas. Dan a sus ataques nombres fantásticos, como Smurf, Tsunami, XMAS tree, HULK, Slowloris, cache bust, amplificación de TCP, inyección de javascript y una docena de variantes de ataques reflejados. Mientras tanto, el defensor debe considerar todos los posibles objetivos de un ataque DDoS, desde la capa de red (enrutadores / conmutadores y capacidad de enlace) hasta la capa de aplicación (web, DNS y servidores de correo). Es posible que algunos ataques ni siquiera se centren en un objetivo específico, sino que atacan todas las direcciones IP de una red. Multiplicar las decenas de tipos de ataques por la diversidad de infraestructura que se debe defender genera infinitas posibilidades.
Entonces, ¿cómo podemos simplificar el problema para hacerlo manejable? En lugar de centrarse en los métodos de ataque, Google agrupa los ataques volumétricos en un puñado de métricas clave:
- bps bits de red por segundo → ataques dirigidos a enlaces de red
- paquetes de red pps por segundo → ataques dirigidos a equipos de red o servidores DNS
- rps HTTP (S) solicitudes por segundo → ataques dirigidos a servidores de aplicaciones (layer7)
De esta manera, podemos enfocar nuestros esfuerzos en asegurar que cada sistema tenga la capacidad suficiente para resistir ataques, según lo midan las métricas relevantes.
Tendencias en los volúmenes de ataques DDoS
Nuestra próxima tarea es determinar la capacidad necesaria para resistir los mayores ataques DDoS para cada métrica clave. Hacer esto correctamente es un paso necesario para operar de manera eficiente una red confiable: el aprovisionamiento excesivo desperdicia recursos costosos, mientras que el aprovisionamiento insuficiente puede provocar una interrupción.
Para hacer esto, analizamos cientos de ataques significativos que recibimos en las métricas enumeradas e incluimos informes creíbles compartidos por otros. Luego, trazamos los ataques más grandes observados durante la última década para identificar tendencias. (Varios años de datos antes de este período informaron nuestra decisión de qué usar para el primer punto de datos de cada métrica).
El crecimiento exponencial en todas las métricas es evidente, y a menudo genera titulares alarmistas a medida que aumentan los volúmenes de ataques. Pero debemos tener en cuenta el crecimiento exponencial de Internet en sí, que también proporciona ancho de banda y procesamiento a los defensores. Después de tener en cuenta el crecimiento esperado, los resultados son menos preocupantes, aunque siguen siendo problemáticos.
Arquitectura de infraestructura defendible
Dados los datos y las tendencias observadas, ahora podemos extrapolar para determinar la capacidad de reserva necesaria para absorber los ataques más grandes que puedan ocurrir.
bps (bits de red por segundo)
Nuestra infraestructura absorbió un DDoS de 2.5 Tbps en septiembre de 2017, la culminación de una campaña de seis meses que utilizó múltiples métodos de ataque. A pesar de apuntar simultáneamente a miles de nuestras direcciones IP, presumiblemente con la esperanza de escapar de las defensas automatizadas, el ataque no tuvo ningún impacto. El atacante utilizó varias redes para falsificar 167 Mpps (millones de paquetes por segundo) a 180.000 servidores CLDAP, DNS y SMTP expuestos, que luego nos enviarían grandes respuestas. Esto demuestra los volúmenes que puede lograr un atacante con buenos recursos: esto fue cuatro veces mayor que el ataque récord de 623 Gbps de la botnet Mirai un año antes. Sigue siendo el ataque de mayor ancho de banda informado hasta la fecha, lo que reduce la confianza en la extrapolación.
pps (paquetes de red por segundo)
Hemos observado una tendencia de crecimiento constante, con un ataque de 690 Mpps generado por una botnet de IoT este año. Un valor atípico notable fue un ataque de 2015 a la máquina virtual de un cliente, en el que una botnet de IoT aumentó a 445 Mpps en 40 segundos, un volumen tan grande que inicialmente pensamos que era una falla de monitoreo.
rps (solicitudes HTTP (S) por segundo)
En marzo de 2014, javascript malicioso inyectado en miles de sitios web a través de un ataque man-in-the-middle de red hizo que cientos de miles de navegadores inundaran YouTube con solicitudes, alcanzando un máximo de 2.7 Mrps (millones de solicitudes por segundo). Ese fue el ataque más grande que conocimos hasta hace poco, cuando un cliente de Google Cloud fue atacado con 6 Mrps. El lento crecimiento es diferente a las otras métricas, lo que sugiere que podemos estar subestimando el volumen de futuros ataques.
0 comentarios :
Publicar un comentario
Los comentarios pueden ser revisados en cualquier momento por los moderadores.
Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.
Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.