Conferencia DEFCON 19. Tres generaciones de ataques DoS (involucrando a la audiencia como víctimas). Parte 1Pero aún peor ... Traté de desarrollar un proyecto para mis alumnos, y resultó divertido, pero el problema era que era imposible ver las direcciones "asesinadas", ya que había que ver esta configuración de IP. Pero si llevo a cabo el ataque realmente muy rápido, el sistema responderá de inmediato y nadie verá lo que le sucedió.
Lo hice para que pueda ver toda la red, todas las direcciones de esta red página por página. Esta lista podría hacerse aún más grande, ya que se le agregaron 5 direcciones IP por segundo. Cuando comencé este proyecto por primera vez, me pareció que no pasaba nada, ya que mi máquina Windows no parecía reaccionar en absoluto a lo que había sucedido.
Los estudiantes no estarían interesados, porque no aprenderán nada si no pueden ver el daño causado por el ataque. Pensé "ok, este es un mal proyecto, ¿qué debo hacer?", Pero luego me di cuenta: esto mata un controlador de dominio, un servidor de correo y todo eso, es muy malo. Esto es tan malo que no puedo contarles nada a mis alumnos, ¡es mejor que se lo cuente a Microsoft en voz baja!
Entonces envié un tweet que Windows 7 contiene una vulnerabilidad peligrosa, que, sin embargo, no es nada sorprendente. Dije que en relación con esto, necesito contactos del servicio de seguridad de Windows, y las personas en Twitter me ayudaron a encontrar a las personas adecuadas en Microsoft. Después de 2 días, recibí una respuesta oficial de Microsoft, en la que se informó que Mark Hughes les contó sobre esto hace un año. Pero no importa, porque no tienen la intención de hacer correcciones a las versiones actuales de Windows, porque Vista, Windows 7, Windows Server 2003, Windows Server 2008, Windows XP están muriendo gradualmente y dejan de admitirlos. En cambio, corregirán esta vulnerabilidad en Windows 8 o Windows 9 si aún no se les ocurre algo.
Pensé: está bien, si vas a actuar de esta manera, se lo contaré a todo el mundo y dejaré que mis estudiantes prueben este proyecto como tarea, advirtiéndoles que lo usen en una red aislada, porque de lo contrario puedes matar todas las computadoras en la universidad , incluidos nuestros servidores. Hicieron exactamente eso, así que todavía enseño allí, en lugar de estar de pie en la calle con una taza de limosna.
En cualquier caso, este es un ataque muy poderoso, y me gustaría hablar un poco sobre cómo puede defenderse contra él. Pero antes de comenzar, entregaré este asunto a Matthew, y lo único que quiero es que ahora pruebes el impacto de este ataque en ti mismo.
Todas las máquinas y computadoras Windows con una de las versiones de Free BSD Unix son susceptibles al ataque de RA Flood, pero las máquinas con MAC OS y Open BSD son invulnerables. Si observa la configuración de mi MacBook, verá que también es un host y se ha unido a algunas de las redes existentes aquí, verá aquí la red inet6 con una dirección a partir de 2001.
Se conectó a algunas de estas redes inútiles, pero no a todas las redes. Creo que podrían ser redes DefCon. Pero en cualquier caso, verá que mi "MacBook" durante algún tiempo se conectó a las 10 primeras redes encontradas y ya no presta atención a RA. Esta es una muy buena defensa, y creo que Microsoft también debería haber venido de Windows, pero no les interesa mi opinión. Cisco lanzó un parche diseñado para proteger su equipo de ataques de este tipo, y Juniper aún no lo ha hecho.
Entonces, si tiene dispositivos para probar, Ryan configurará su red aislada y matará a alguien allí. Si desea participar en esto, puede unirse a la red SSID llamada "No usar", que usa el cifrado WPA2, por lo que debe ingresar la contraseña "No usar". Si te unes a esta red, Ryan verá cuántas personas hay en la red y te matará. Esta eliminación es bastante interesante, ya que ayuda a descubrir qué otros dispositivos son vulnerables, excepto Windows y Free BSD.
Algunas personas dijeron que iban a traer dispositivos interesantes aquí, y me gustaría saberlo, así que después de la demostración, le preguntaré si quiere ir a la sala de preguntas y respuestas y hablar sobre eso. Entonces podríamos informar al fabricante para alentarlo a lanzar un parche por la vulnerabilidad revelada de su dispositivo. Creo que muchas personas son vulnerables a ataques de este tipo, pero no lo saben.
Ahora le daré la palabra a Matthew para que cuente la historia de LulzSec, y luego continuaré la conversación sobre la defensa, si tenemos tiempo. Por ahora, cerraré todas las ventanas para borrar el escritorio. Lo siento, el nombre de la red es "No conectar" y la contraseña también es "No conectar".
Matthew Prince: Sam es la única persona que conozco que puede llevar a cabo un ataque DDoS con tanto encanto. Mi nombre es Matthew Prince, conozco a Sam, ambos vivimos en San Francisco y ambos estamos involucrados en la historia de LulzSec.
Por lo tanto, te contaré una historia sobre cómo me arrastraron a esto, sobre algunos ataques DDoS que observamos durante 23 días y sobre lo que hicimos para detenerlos.
El 2 de junio de 2011, alrededor de las 4:54 pm GMT, LulzSec anunció en su cuenta de Twitter que habían creado la página de seguridad de Lulz en
lulzsecurity.com . Lo sorprendente fue que esta página estuvo fuera de línea durante 15 minutos debido a un poderoso ataque DDoS. No conozco los detalles de este ataque en particular, porque aún no estábamos involucrados en esto.
Aproximadamente una hora después de que se publicó la publicación sobre la creación de la página, LulzSec tuiteó que pudieron resolver el problema de la denegación de servicio. Lo único que ha cambiado durante este tiempo, como me informaron más tarde, es que se inscribieron en nuestro servicio CloudFlare 9 minutos antes de este mensaje. Hacemos sitios web más rápidos y los protegemos de algunos tipos de ataques, pero no nos consideramos un servicio para prevenir ataques DDoS, por lo que algunos de nosotros nos sorprendió esta acción de LulzSec.
Otra gran sorpresa fue cuando, una hora después, los piratas informáticos publicaron un mensaje dirigido a mí en el que me confesaron su amor por CloudFlare y me preguntaron si podían contar con una cuenta premium gratuita a cambio de ron.
No tenía idea de quiénes eran esos LulzSec en ese momento, así que escribí un mensaje en Twitter, que mi abogado luego dijo que eliminara: "Depende de qué tan bueno sea el ron". Debo decir de inmediato que nunca nos enviaron ron, y nunca les proporcionamos una cuenta pro. Pero CloudFlare es un servicio gratuito, todos los días tenemos miles de sitios registrados y, por lo general, no tenemos problemas con ellos.
Entonces, durante los siguientes 23 días, estos tipos causaron estragos en una variedad de formas. Finalmente, el 25 de junio, publicaron un tweet que marcó el final del ataque.
Fue interesante que CloudFlare funciona como un proxy inverso, por lo que todo el tráfico que se dirigió a Lulz Security primero pasó a través de nuestra red, lo que tiene dos efectos significativos. El primero, cualquiera que atacó a Lulz Security nos atacó, el segundo, gracias a nosotros, Lulz Security pudo ocultar la ubicación de la fuente de su ataque, es decir, el lugar donde se encontraba realmente su alojamiento. Estos son los efectos secundarios de la arquitectura de nuestro sistema, pero los hackers los han usado para su ventaja.
Sam me contactó hace un tiempo y me dijo que iba a hablar sobre DDoS. Hablamos sobre nuestra experiencia y él me preguntó si podía compartir información sobre esto. Tenemos un asesor legal, somos una empresa real con nuestra propia política de privacidad, e incluso si usted está en la lista internacional de buscados por cibercrimen, tratamos de respetar su privacidad. Por lo tanto, escribí una carta a LulzSec y la envié a la dirección de correo electrónico indicada por ellos en mi cuenta.
Les dije que me invitaron a DefCon como orador, así que hablé sobre los ataques en CloudFlare relacionados con las actividades de su comunidad. Escribí que parte de la información que quiero comunicar durante mi presentación está protegida por nuestra política de privacidad, por lo que le pido a LulzSec su consentimiento para su divulgación. Después de 11 días, alguien llamado Jack Sparrow me respondió con el texto: "Tienes mi consentimiento".
Y aquí estoy, para hablar sobre algunas cosas de las que no podría hablar sin este permiso. Puedo hablar sobre cómo nos influenciaron, pero no les revelaré los hosts que solían atacar o las direcciones IP reales.
Permítanme contarles un poco más sobre lo que sucedió en estos 23 días y mostrarles un análisis del tráfico real al sitio web de Lulz Security durante este tiempo.
Durante este tiempo, se realizaron más de 18 millones de visitas a la página cuando las personas visitaron este sitio. Puede ver que casi desde el comienzo del ataque del 22 de junio al 5 de julio se observó un pico de tráfico normal, y luego el sitio dejó de funcionar, aunque todavía usaba CloudFlare. Si intenta visitar este sitio hoy, verá solo la página de configuración de Apache allí, y no sé qué planean hacer a continuación.
Es interesante observar el tráfico del ataque que derribó el sitio.
Diría que todo el tráfico hacia el pico en el medio es solo ruido de fondo normal, en el que no había nada especial y que no presagiaba nada de lo que mostraré en la diapositiva en un par de segundos. De hecho, las tres semanas durante las cuales LulzSec utilizó el servicio CloudFlare fueron bastante tranquilas con respecto a los ataques DoS. Esto es extraño porque muchas personas dijeron que atacaron LulzSec en ese momento.
El pico en el medio del gráfico fue causado por un par de eventos muy obvios, que discutiremos más adelante. También hablaremos sobre los tipos de ataques que se usaron contra LulzSec y lo que hicimos para protegernos.
Un evento particularmente interesante ocurrió el 25 de junio. Se asoció con Jester. No sabía quién era, así que Sam me proporcionó material sobre él.
Parece que Jester pasó mucho tiempo averiguando la ubicación del sitio web de LulzSec y publicó con orgullo en su página las direcciones IP de sus recursos:
www.lulzsecurity.com : 204.197.240.133 y lulzsecurity.com: 111.90.139.55.
Sé qué host era el sitio web de LulzSec el 25 de junio y puedo decirles que estas direcciones no tienen nada que ver con eso. Durante estos 23 días, utilizaron 7 hosts diferentes, inicialmente el host se encontraba en Montreal, Canadá. Durante algún tiempo, a principios de junio, el alojamiento de Malasia se utilizó con una dirección IP de 111.90.139.55. La mayoría de los hosts que utilizaron estaban ubicados en los Estados Unidos, incluido un gran host especializado en mitigar las consecuencias de los ataques DoS, y al final cambiaron al hosting alemán, donde se encuentra el sitio hoy.
Curiosamente, muchas personas afirmaron que fueron ellos quienes derribaron el sitio web LulzSec y publicaron fotos relevantes en Internet. De hecho, esto simplemente demuestra el servicio que ofrecemos en CloudFlare: si su servidor de fondo está desconectado, mostramos su versión en caché, como lo demuestra la barra naranja en la parte superior de la página. Le dice al usuario que está navegando por el caché, tal como sucede con el caché de la página en Google.
Creo que cuando la gente afirmó que habían derribado el sitio LulzSec, lo que realmente sucedió fue que los muchachos de LulzSec simplemente fueron expulsados de sus anfitriones. Entonces, durante un corto período de 36 horas, en realidad indicaron la dirección IP inválida 2.2.2.2 como su dirección, porque no hay un host o servidor web activo bajo esta dirección. Creo que simplemente eligieron una dirección IP aleatoria para que nuestro sistema simplemente los "pusiera" en línea constantemente, porque la versión de caché existe por un período de tiempo limitado hasta que caduca. En este punto, regresaron brevemente al host e indicaron una dirección falsa solo para aparecer en nuestro caché.
No conozco a una sola persona que indique que el sitio web de LulzSec funcionó sin conexión durante al menos un corto tiempo, a pesar del hecho de que muchas personas trataron de dejarlo fuera del modo en línea. De hecho, al mismo tiempo fue LulzSec el que derribó los sitios de otras personas, por ejemplo, el sitio web de la CIA, y fue interesante observar estos ataques. La diapositiva enumera exactamente qué ataques observamos.
Nos sorprendió mucho y literalmente "pusimos a todos en alerta" durante el ataque DDoS, que trató de derribar el sitio durante tres semanas, ya que generalmente observamos ataques que duraron un período de tiempo significativamente más corto. No es tan peligroso burlarse de los piratas informáticos que pastan en Twitter como burlarse de la ciber mafia china o de Europa del Este o de las personas que participan en la extorsión de Internet, porque son los que son capaces de un poderoso ataque DDoS. Sí, estos tipos también son lo suficientemente inteligentes, pero aún así, tales ataques no están a su nivel.
Hemos observado varios ataques relativamente inofensivos en el nivel 7 de OSI utilizando herramientas como Slowloris. Pero el servidor web interno de CloudFlare está especialmente diseñado para no solo "matar" los ataques al nivel 7, sino también para reparar todas las direcciones IP desde las que se realizaron estos ataques. Quiero decir, de hecho, solo estamos contentos cuando los piratas informáticos atacan nuestro séptimo nivel, porque los ataques DDoS en el nivel 3 o 4 nos causan muchos más problemas.
En este caso, mitigamos sus consecuencias, ya que utilizamos la red Anycast. Esto significa que tenemos un montón de máquinas, cientos y cientos de computadoras trabajando en 14 centros de datos diferentes en todo el mundo y vinculadas a la misma dirección IP.
Esto le permite "rociar" un DoS distribuido - ataque o ataque con una gran cantidad de tráfico a una gran superficie de red, lo que hace que sea muy difícil usar tales ataques contra nosotros.
Muchos más problemas nos trajeron ataques de otro tipo. El primero fue producido usando algo así como una red muy grande con una gran cantidad de tráfico que los atacantes nos enviaron directamente. Esta red estaba ubicada geográficamente cerca de nuestro centro de datos en San José, y usaban casi todo su ancho de banda. Tuvimos que transferir a nuestros clientes a otros centros de datos menos ocupados, por lo que esto no los afectó. Pero el centro de datos en San José en ese momento solo podía dar servicio a Lulz Security, mientras continuaba manteniéndolos en línea.
Un ataque aún más interesante, que amenazó a la mayoría de las personas conectadas con nosotros, utilizó a Google como un "reflector" del tráfico. Nos adherimos a reglas específicas con respecto a las direcciones IP de Google para garantizar que nunca bloqueemos el tráfico legítimo que nos llega desde allí. Alguien realmente inteligente descubrió que si envía muchas solicitudes SYN a Google con encabezados falsos que apuntan a nuestra dirección IP, Google nos las devolverá. La solución a este problema fue bastante simple y tomó solo unos minutos: bloqueamos los ACK a los que no estaban conectados los SYN, y luego llamamos a nuestros amigos en Google y les dijimos que nunca recibirían tráfico de estas fuentes, así que solo usen un firewall contra ellos. . Fue un ataque realmente inteligente que tuvo en cuenta la naturaleza de nuestra infraestructura y aprovechó las características de su trabajo.
El último ataque, que nos causó muchos problemas, se basó en el hecho de que alguien escaneó cuidadosamente los rangos de nuestras direcciones IP y descubrió las interfaces del enrutador que estaban sujetas a influencias externas. Con esto, un atacante lanzó un ataque tipo diccionario y deshabilitó varios de nuestros enrutadores, ya que logró evitar Anycast.
La solución al problema nuevamente resultó ser bastante simple: bloqueamos estas direcciones IP que están fuera de nuestra red, pero el ataque sin embargo nos causó daños, porque durante varios minutos nuestros enrutadores quedaron fuera de línea.
Sabes, cuando comparé los ataques más grandes que presenciamos, incluso lo vi cuando nuestro cliente recibió un correo electrónico con el texto: "Hola, somos una agencia del gobierno chino que descubrió que alguien en la red te atacará". "y si nos envía $ 10,000, entonces probablemente podamos resolver este problema". Obviamente, esto no es una agencia, pero realmente son capaces de resolver este problema, porque ellos mismos lo crean. Sin embargo, hubo relativamente pocos ataques de este tipo.
Hablaré sobre algunas cosas más interesantes. El aumento en el contexto del tráfico normal de fondo coincide en el tiempo con la declaración de LulzSec de que bloquearon los servidores de Minecraft. Después de que terminó el ataque, el tráfico disminuyó ligeramente.
Los empleados de nuestra oficina, que son fanáticos de Minecraft, comenzaron un gran debate sobre si LulzSec no debería abandonar nuestra red después de eso, porque ellos mismos causaron mucho daño y, en general, esto no es nada bueno. Para que pueda aprender una lección de que si va a organizar un ataque DDoS contra alguien, es mejor no tocar Minecraft.
Tengo muy poca información sobre quiénes son realmente estos tipos de Lulz Security, para nosotros es solo uno de los nombres de usuario que crean cuentas en Cloudflare. Es muy similar al nombre de la persona que fue arrestada, y no sé si esto es solo una coincidencia o si estas personas realmente derribaron estos sitios. No notamos tanta actividad detrás de ellos para mover a sus anfitriones, además, su sitio ahora está caído.
Sin embargo, fue interesante para nosotros observar cómo el mundo entero intentó "matarlos" durante 23 días, y de todos modos, los ayudamos a mantenerse a flote. ¡Gracias por invitarme aquí!
Sam Bone: Gracias, Matthew, por decidir venir. Ahora volveré a mi presentación. Escuché mucho sobre cómo atacar es más fácil que defender, por lo que te mostraré un ataque que lo sacará de quicio. , , Microsoft , . . , RA Flood.
, IPv6, , , . Router Discovery , , IPv6, , , .
RA Windows, . , . Cisco RA Guard, Windows, . , Cisco . RA Guard , RA-, .
, : , . — , — , .
, , . , Mod Security, , DDoS 7- . , — IP- , , Tor , .
, Akamai, , . Load Balancer, , , . , , 4 , .
. , - HT More , DNS- C&C , . , . Flood- , Anonymous Low Orbit Ion Canon.
CloudFlare, , — , , , , . , , , . , CloudFlare, .
, . , , , . , – , , . , , .
, , ? - ? - ? ? , , . , . , !
Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes?
Apóyenos haciendo un pedido o recomendándolo a sus amigos, un
descuento del 30% para los usuarios de Habr en un análogo único de servidores de nivel de entrada que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de $ 20 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato? ¡Solo tenemos
2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre
Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?