Tutoriales y Manuales
Entradas Mensuales
-
►
2023
(Total:
710
)
- ► septiembre (Total: 65 )
-
►
2022
(Total:
967
)
- ► septiembre (Total: 72 )
-
►
2021
(Total:
730
)
- ► septiembre (Total: 56 )
-
►
2020
(Total:
212
)
- ► septiembre (Total: 21 )
-
►
2019
(Total:
102
)
- ► septiembre (Total: 14 )
-
▼
2017
(Total:
231
)
- ► septiembre (Total: 16 )
-
▼
febrero
(Total:
36
)
-
Quitando a los usuarios de Windows los derechos de...
-
Un fallo en CloudFlare expone datos privados de su...
-
AMD presenta oficialmente Ryzen R7 y alcanza en re...
-
Un fan de NVIDIA asesina en Rusia un fan de AMD
-
Google anuncia la primera colisión de SHA1
-
RootedCON 2017 se celebra durante los días 2, 3 y ...
-
Microsoft retrasa sus actualizaciones de seguridad...
-
Con sólo 15 años hackeó ordenadores de la NASA
-
Presentan como prodigio en informática a joven que...
-
DEFT Zero presenta su edición 2017 para el análisi...
-
El 0-Day de WordPress permite el hackeo de 1,5 mil...
-
8 tarjetas gráficas GTX 1080 conectadas para crack...
-
Un nuevo fallo grave provoca DoS al software BIND DNS
-
Universidad sufre un ataque DDoS de sus propios di...
-
El 75% de todo el Ransomware es desarrollado por r...
-
WhatsApp incorpora verificación en dos pasos
-
Vulnerabilidades en las cerraduras inteligentes Bl...
-
Solucionada vulnerabilidad XSS en Steam de Valve
-
La Policía interviene en Málaga una operadora por ...
-
Un sofisticado malware en memoria está infectando ...
-
De nuevo hackean impresoras vulnerables imprimiend...
-
El vendedor de Smart TV Vizio multado con 2.2$ mil...
-
Un hacker tumba más de 10 mil páginas de la dark w...
-
Ransomware Charger secuestra tu teléfono a cambio ...
-
Una multa de tráfico falsa de la DGT infecta tu or...
-
Cómo Google manejó el mayor ataque DDoS de la Botn...
-
Documental: Big Data, conviviendo con el algoritmo
-
Rusia detiene a varios expertos en ciberseguridad ...
-
Nuevas vulnerabilidades críticas en routers Netgear
-
Dos arrestados en Londres por infectar la red CCTV...
-
0-day en SMB afecta a múltipes versiones de Window...
-
Windows Defender ATP te protegerá del Ransomware
-
Gobierno holandés contará todas las papeletas a ma...
-
Backblaze publica su ranking de fiabilidad de disc...
-
Apple elimina iCloud Activation Lock Page por un f...
-
Nueva actualización de seguridad para WordPress
-
-
►
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
seguridad
(
391
)
privacidad
(
351
)
google
(
323
)
ransomware
(
321
)
vulnerabilidad
(
269
)
Malware
(
251
)
android
(
232
)
Windows
(
225
)
tutorial
(
216
)
cve
(
211
)
manual
(
201
)
software
(
199
)
hardware
(
184
)
linux
(
121
)
twitter
(
109
)
ddos
(
86
)
Wifi
(
81
)
WhatsApp
(
77
)
herramientas
(
75
)
cifrado
(
74
)
hacking
(
72
)
app
(
63
)
sysadmin
(
60
)
nvidia
(
50
)
Networking
(
49
)
ssd
(
49
)
youtube
(
42
)
firmware
(
39
)
hack
(
39
)
office
(
39
)
adobe
(
38
)
firefox
(
35
)
contraseñas
(
32
)
eventos
(
32
)
antivirus
(
31
)
cms
(
30
)
flash
(
28
)
anonymous
(
27
)
juegos
(
26
)
programación
(
25
)
MAC
(
24
)
multimedia
(
22
)
apache
(
21
)
exploit
(
21
)
javascript
(
21
)
Kernel
(
19
)
ssl
(
18
)
SeguridadWireless
(
17
)
documental
(
16
)
conferencia
(
15
)
Forense
(
14
)
lizard squad
(
14
)
Debugger
(
13
)
técnicas hacking
(
13
)
auditoría
(
12
)
delitos
(
11
)
metasploit
(
11
)
Virtualización
(
10
)
adamo
(
9
)
reversing
(
9
)
Rootkit
(
8
)
Ehn-Dev
(
7
)
MAC Adress
(
6
)
antimalware
(
6
)
oclHashcat
(
5
)
Entradas populares
-
Nueva filtración masiva de datos. Esta vez no afecta a una empresa del Ibex, como ha ocurrido en las dos últimas semanas, pero sí a uno de l...
-
ShinyHunters, asegura haber abierto una brecha de seguridad en los servidores de la empresa de venta de entradas Ticketmaster , encargada d...
-
El Departamento de Justicia de Estados Unidos, en colaboración con el FBI y agencias internacionales, desmanteló la botnet 911 S5 , conside...
Cómo Google manejó el mayor ataque DDoS de la Botnet Mirai
martes, 7 de febrero de 2017
|
Publicado por
el-brujo
|
Editar entrada
En septiembre, KrebsOnSecurity estaba recibiendo algunos de los mayores
ataques de denegación de servicio distribuidos jamás registrados. El
sitio pronto se oscureció después de que Akamai dijera que ya no
proporcionaría el sitio con protección gratuita, y ningún otro servicio
de mitigación de DDoS se presentó para ofrecer sus servicios. Un
servicio de Google llamado Project Shield, en última instancia, trajo
KrebsOnSecurity de nuevo en línea y ha estado protegiendo el sitio desde
entonces.
En la conferencia de seguridad de Enigma el miércoles, un ingeniero de seguridad de Google describió algunos de los eventos detrás de escena que ocurrieron poco después de que Krebs pidiera ayuda al servicio y en los meses posteriores,
"¿Qué sucede si esta botnet derriba realmente google.com y perdemos todos nuestros ingresos?" El ingeniero de seguridad de Google Damian Menscher recuerda a la gente que preguntaba. "Pero consideramos que si la botnet puede llegar a tirarnos probablemente ya estamos en riesgo de todos modos, no hay nada que los detenga de atacarnos en ningún momento, así que realmente no teníamos nada que perder aquí".
La tercera semana de septiembre de 2016 el blog de KrebsOnSecurity sufrió enormesataques de denegación de servicio, oblignado a bloquear el blog . El sitio resurgió tres días más tarde bajo la égida de Google Project Shield, una iniciativa que busca proteger a los periodistas y sitios de noticias de ser censuradso por estos asedios digitales paralizantes.
Damian Menscher, un ingeniero de seguridad de Google quién trabajo muy de cerca en la migración a Project Shield, habló esta semana sobre los desafíos únicos que implica proteger un pequeño sitio de ataques muy grandes, sostenidos y en constante transformación.
Al referirse a la conferencia de seguridad Enigma 2017 en Oakland, California, Menscher dijo que su equipo sólo consideró brevemente si era una buena idea invitar a un sitio de noticias que toma frecuentes oscilaciones en la industria de DDoS por contrato.
Una vez que el escudo del proyecto consiguió en última instancia KrebsOnSecurity en línea, tomó apenas 14 minutos para que los ataques reasumieran.
El primer ataque se produjo en forma de una inundación de 130 millones de paquetes de syn por segundo, un volumen que es lo suficientemente grande como para derribar muchos sitios, pero una pequeña disminución cuando se mide con los recursos de Google. Alrededor de un minuto después, el ataque cambió a una inundación ligeramente más poderosa de unas 250.000 consultas HTTP por segundo. Provenía de unas 145.000 direcciones IP diferentes, dejando claro que Mirai, una aplicación de código fuente de código abierto que esclaviza cámaras y otros dispositivos de Internet de las cosas, era la responsable. Los atacantes lo siguieron con más variaciones, incluyendo un ataque de 140 gigabits por segundo, hecho posible mediante una técnica conocida como amplificación de DNS y una inundación de syn-ack de 4 millones de paquetes por segundo
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhm1hOsW6E54G1XGJJQa09EmPuA32v0kaUQZMXVWuo-vBwhAD7D1xGC0neuAKSZ6l8LUNQbbHks4dZdZlzwCWmISJiVy-M1YlPtPCih4UNwPoAo69zy333SR26iTL1u1vX_dG0NB4QLFuO/s640/krebs_attacks.png)
En la marca de cuatro horas, KrebsOnSecurity experimentó uno de los mayores ataques vistos por los ingenieros de Project Shield. Entregó más de 450.000 consultas por segundo (QPS) de aproximadamente 175.000 direcciones IP diferentes. Al igual que los ataques que lo precedieron, no representó una amenaza inmediata a KrebsOnSecurity o a los recursos de Google que la estaban protegiendo.
Los ataques fueron los más poderosos en las primeras dos semanas, pero al continuar, incorporaron una variedad de nuevas técnicas. Uno, llamado un ataque de pingback de WordPress, abusó de una característica en la plataforma de blogs ampliamente utilizada que automatiza el proceso de dos sitios que se enlazan entre sí. Esto provocó que un gran número de servidores recuperaran simultáneamente el contenido de KrebsOnSecurity en un intento por sobrecargar los recursos del sitio. Google fue capaz de bloquearlo, ya que cada máquina de consulta emitió un agente de usuario que contenía las palabras "WordPress pingback", que los ingenieros de Google rápidamente bloquearon. Otra técnica denominada "cache-busting ataques" también se detuvo.
Defender un pequeño sitio es muy difícil. Toda mi experiencia en Google durante años fue defender un sitio muy grande. Si tuvimos un millar de consultas adicionales a través de uno de nuestros servicios, no fue un gran problema. Pero el servidor de origen de Brian podría manejar alrededor de 20 consultas por segundo. Vimos ataques de hasta 450.000 consultas por segundo. ¿Cómo lidiar con eso? Es un poco desafiante. Una cosa que usted puede hacer es que puede limitar la tasa de mal tráfico. Así que tienes que identificar el mal tráfico y tratar de descartarlo. Otra cosa que ayuda mucho es que puede servir buen tráfico desde caché. Esto requiere mucha carga del servidor de origen. También le ofrece este beneficio, incluso si el servidor de origen no es saludable, todavía tiene su contenido en caché para que pueda seguir sirviendo a los usuarios y no hay realmente una interrupción visible. Cuando se le preguntó por qué un servicio tan extenso como Google es capaz de defender a Krebs de forma gratuita cuando los funcionarios de Prolexic -un servicio propiedad de Akamai con una competencia básica en la mitigación de DDoS- dijeron que ya no era viable continuar su arreglo pro bono, :
Hay mucho que decir por economía de escala. En el caso de Google, ya estamos sirviendo un montón de propiedades. Al tener todo eso, es más rentable para nosotros tener un terabit de capacidad libre. Yo esperaría que Prolexic también quisiera tener un terabit de capacidad libre, pero luego comienza a comer en su capacidad libre si ... hay dos dos ataques que vienen al mismo tiempo.
Fuentes:
https://krebsonsecurity.com/2017/02/how-google-took-on-mirai-krebsonsecurity/
https://arstechnica.com/security/2017/02/how-google-fought-back-against-a-crippling-iot-powered-botnet-and-won/
En la conferencia de seguridad de Enigma el miércoles, un ingeniero de seguridad de Google describió algunos de los eventos detrás de escena que ocurrieron poco después de que Krebs pidiera ayuda al servicio y en los meses posteriores,
"¿Qué sucede si esta botnet derriba realmente google.com y perdemos todos nuestros ingresos?" El ingeniero de seguridad de Google Damian Menscher recuerda a la gente que preguntaba. "Pero consideramos que si la botnet puede llegar a tirarnos probablemente ya estamos en riesgo de todos modos, no hay nada que los detenga de atacarnos en ningún momento, así que realmente no teníamos nada que perder aquí".
¿Cómo luchó Google contra una botnet?
La tercera semana de septiembre de 2016 el blog de KrebsOnSecurity sufrió enormesataques de denegación de servicio, oblignado a bloquear el blog . El sitio resurgió tres días más tarde bajo la égida de Google Project Shield, una iniciativa que busca proteger a los periodistas y sitios de noticias de ser censuradso por estos asedios digitales paralizantes.
Damian Menscher, un ingeniero de seguridad de Google quién trabajo muy de cerca en la migración a Project Shield, habló esta semana sobre los desafíos únicos que implica proteger un pequeño sitio de ataques muy grandes, sostenidos y en constante transformación.
Al referirse a la conferencia de seguridad Enigma 2017 en Oakland, California, Menscher dijo que su equipo sólo consideró brevemente si era una buena idea invitar a un sitio de noticias que toma frecuentes oscilaciones en la industria de DDoS por contrato.
Una vez que el escudo del proyecto consiguió en última instancia KrebsOnSecurity en línea, tomó apenas 14 minutos para que los ataques reasumieran.
El primer ataque se produjo en forma de una inundación de 130 millones de paquetes de syn por segundo, un volumen que es lo suficientemente grande como para derribar muchos sitios, pero una pequeña disminución cuando se mide con los recursos de Google. Alrededor de un minuto después, el ataque cambió a una inundación ligeramente más poderosa de unas 250.000 consultas HTTP por segundo. Provenía de unas 145.000 direcciones IP diferentes, dejando claro que Mirai, una aplicación de código fuente de código abierto que esclaviza cámaras y otros dispositivos de Internet de las cosas, era la responsable. Los atacantes lo siguieron con más variaciones, incluyendo un ataque de 140 gigabits por segundo, hecho posible mediante una técnica conocida como amplificación de DNS y una inundación de syn-ack de 4 millones de paquetes por segundo
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhhm1hOsW6E54G1XGJJQa09EmPuA32v0kaUQZMXVWuo-vBwhAD7D1xGC0neuAKSZ6l8LUNQbbHks4dZdZlzwCWmISJiVy-M1YlPtPCih4UNwPoAo69zy333SR26iTL1u1vX_dG0NB4QLFuO/s640/krebs_attacks.png)
En la marca de cuatro horas, KrebsOnSecurity experimentó uno de los mayores ataques vistos por los ingenieros de Project Shield. Entregó más de 450.000 consultas por segundo (QPS) de aproximadamente 175.000 direcciones IP diferentes. Al igual que los ataques que lo precedieron, no representó una amenaza inmediata a KrebsOnSecurity o a los recursos de Google que la estaban protegiendo.
Los ataques fueron los más poderosos en las primeras dos semanas, pero al continuar, incorporaron una variedad de nuevas técnicas. Uno, llamado un ataque de pingback de WordPress, abusó de una característica en la plataforma de blogs ampliamente utilizada que automatiza el proceso de dos sitios que se enlazan entre sí. Esto provocó que un gran número de servidores recuperaran simultáneamente el contenido de KrebsOnSecurity en un intento por sobrecargar los recursos del sitio. Google fue capaz de bloquearlo, ya que cada máquina de consulta emitió un agente de usuario que contenía las palabras "WordPress pingback", que los ingenieros de Google rápidamente bloquearon. Otra técnica denominada "cache-busting ataques" también se detuvo.
Defender un pequeño sitio es muy difícil. Toda mi experiencia en Google durante años fue defender un sitio muy grande. Si tuvimos un millar de consultas adicionales a través de uno de nuestros servicios, no fue un gran problema. Pero el servidor de origen de Brian podría manejar alrededor de 20 consultas por segundo. Vimos ataques de hasta 450.000 consultas por segundo. ¿Cómo lidiar con eso? Es un poco desafiante. Una cosa que usted puede hacer es que puede limitar la tasa de mal tráfico. Así que tienes que identificar el mal tráfico y tratar de descartarlo. Otra cosa que ayuda mucho es que puede servir buen tráfico desde caché. Esto requiere mucha carga del servidor de origen. También le ofrece este beneficio, incluso si el servidor de origen no es saludable, todavía tiene su contenido en caché para que pueda seguir sirviendo a los usuarios y no hay realmente una interrupción visible. Cuando se le preguntó por qué un servicio tan extenso como Google es capaz de defender a Krebs de forma gratuita cuando los funcionarios de Prolexic -un servicio propiedad de Akamai con una competencia básica en la mitigación de DDoS- dijeron que ya no era viable continuar su arreglo pro bono, :
Hay mucho que decir por economía de escala. En el caso de Google, ya estamos sirviendo un montón de propiedades. Al tener todo eso, es más rentable para nosotros tener un terabit de capacidad libre. Yo esperaría que Prolexic también quisiera tener un terabit de capacidad libre, pero luego comienza a comer en su capacidad libre si ... hay dos dos ataques que vienen al mismo tiempo.
Fuentes:
https://krebsonsecurity.com/2017/02/how-google-took-on-mirai-krebsonsecurity/
https://arstechnica.com/security/2017/02/how-google-fought-back-against-a-crippling-iot-powered-botnet-and-won/
Enviar por correo electrónico
Escribe un blog
Compartir con Twitter
Compartir con Facebook
Compartir en Pinterest
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.