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í".

¿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

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/