edición general
403 meneos
5701 clics
GitHub acaba de sobrevivir el ataque DDoS más grande de la historia

GitHub acaba de sobrevivir el ataque DDoS más grande de la historia

GitHub lidió hace pocas horas con lo que hasta la fecha ha sido el ataque DDoS más grande de la historia que se haya reportado, y lo más notable: fueron capaces de resolver la situación en 10 minutos. Entre las 17:21 y las 17:30 UTC del 28 de febrero de 2018, GitHub fue capaz de identificar y mitigar un ataque DDoS que impactó a la plataforma con una cantidad monumental de tráfico: 1.35 Tbps (terabits por segundo) enviados a través de 126.9 millones de paquetes por segundo.

| etiquetas: github , ddos
175 228 3 K 448 tecnología
65 comentarios
175 228 3 K 448 tecnología
Comentarios destacados:                
#4 Me pregunto que mente retorcida y enferma se le ocurre atacar a GitHub siendo un servicio bastante amable con la comunidad. Es como si atacasen a la Wikipedia.

Claro que visto los monstruos que habitan en este planeta (como la desgraciada que torturó hasta morir un gato en una lavadora) no me sorprende.
  1. #1 --355188--
    Sobrevivir dice ... fue mas bien un ataque de suto o muelte
    1 K 19
  2. #2 titot
    Joder
    0 K 9
  3. ℵiemand #3 ℵiemand
    "Since UDP is easily spoofable, it makes this service vulnerable to use as a reflector. Worse, memcached can have an amplification factor of over 50,000, meaning a 203 byte request results in a 100 megabyte response." - de la empresa que gestionó el DDoS.

    blogs.akamai.com/2018/03/memcached-fueled-13-tbps-attacks.html
    10 K 82
  4. #4 CrudaVerdad
    Me pregunto que mente retorcida y enferma se le ocurre atacar a GitHub siendo un servicio bastante amable con la comunidad. Es como si atacasen a la Wikipedia.

    Claro que visto los monstruos que habitan en este planeta (como la desgraciada que torturó hasta morir un gato en una lavadora) no me sorprende.
    28 K 171
  5. JMorell #5 JMorell
    #4 Quizás es la competencia...
    4 K 33
  6. Inviegno #6 Inviegno
    Ahora empezarán con los ataques TTreS...
    10 K 53
  7. Shotokax #7 Shotokax
    #4 parece que hay corporaciones a las que le jode que el software sea libre, pero lo llevan claro si creen que así van a acabar con él.
    3 K 42
  8. gelatti #8 gelatti
    #6 sería DTres y DCuatro :-D
    1 K 6
  9. #9 joehigashi
    #4 los que hacen cosas asi lo hacen para demostrar que pueden.
    Seguramente se corrió la voz de que era "imposible" tumbar Github y alguien quiso demostrar que no.
    Ahora que no han podido, todavia mas gente querra hacerlo para demostrar que han podido con algo "imposible".
    12 K 80
  12. #12 sagat
    #8 DDoS no atacan si uno no quiere xD
    5 K 24
  13. Merkstw #13 Merkstw
    Aquí en mi ignorancia sobre redes, ¿Cómo se repele un ataque de tan gigante tamaño?
    1 K 14
  14. albandy #14 albandy
    #4 pues alguien que querrá meter troyanos en las descargas.
    1 K 26
  15. crafton #15 crafton
    #4 Seguramente si, lo que no tiene porque ser mal intencionado.

    Tal vez fue simplemente un stress test de ellos mismos o alguna consultora externa, como quien prueba las alarmas de incendios, para precisamente hacerlo más fuerte.
    0 K 9
  16. #16 --501250--
    #7 ¿A qué te refieres? En GitHub alojan mucho código libre (que no software), pero GitHub no es software libre. GitLab sí es software libre pero paradójicamente alojan menos código libre ahí.
    2 K 22
  17. estoyausente #17 estoyausente
    #4 Buena publicidad par Akamai :-P who knows....

    Por cierto el post original:
    githubengineering.com/ddos-incident-report/
    1 K 28
  18. Shotokax #18 Shotokax
    #16 a eso me refiero, que es una forma (torpe) de torpedear desarrollos libres. De todos modos, cuando decía "software" me refería al código; no seamos puntillosos.
    0 K 12
  19. Kleshk #19 Kleshk
    Normal que sobreviviera GitHub, seguro que había un hilo para sobrevivir ataques DDoS xD xD xD
    0 K 8
  20. orangutan #20 orangutan
    #6 Ddos personas no fueron suficientes para tumbal ggithub
    0 K 10
  21. #21 --501250--
    #18 Vale, pero das por hecho demasiadas cosas. Igualmente era por torpedear el código cerrado que alojan en GitHub. Los que tienen cuentas cerradas pierden más. ;)
    2 K 25
  22. #22 --574181-- *
    #17 Eso estoy pensando... ¿no estaría preparado para batir un record, además? :tinfoil:
    0 K 6
  23. Joice #23 Joice
    #13 Se desconecta el cable rojo.
    5 K 40
  24. EauDeMeLancomes #24 EauDeMeLancomes
    #13 con máquinas de hardware especiales y muy caras dedicadas en exclusiva a descartar el tráfico que por ratio, origen o firma no es legítimo/habitual/esperado. Incluso hay marcas que son capaces de dejar pasar el tráfico legítimo mientras paran el ataque, sin que haya caída de servicio. Hablamos de que el hardware para parar ataques de ese calibre, que serán unos cuantos appliances en cascada o en paralelo, pasará de largo el medio millón de euros.

    Este ataque o es publi concertada de akamai o es un simple test. Si preparas algo así de gordo, tienes que probarlo contra algo que sea capaz de aguantar un par de envites y que no sea amazon microsoft que te cae una denuncia que le duele a toda tu progenie.
    12 K 99
  25. atatat #25 atatat
    Si pero se va la electricidad y jake mate colega{troll}
    0 K 7
  26. #26 amchacon
    #13 CDN

    Basicamente, hay un montón de replicas repartidas por todo el globo. Ante un ataque, solo afecta al CDN más proximo.
    0 K 6
  27. #27 --44189--
    #3 Suerte que fue contra github y no contra stackoverflow, no hubieran sabido cómo arreglarlo sin consultarlo
    26 K 150
  28. Merkstw #28 Merkstw
    #26 lo de CDN me suena más, gracias por la aclaración.
    0 K 11
  29. #29 tutte
    Maldito memcache, ayer nos dió la tarde...
    En mi caso, teníamos 3 clústers enviando paquetes a 1Gb/s. Y todo porque por defecto en CentOS está escuchando en la interfaz externa.
    0 K 9
  30. #30 --534741--
    #4 Monstruos y monstruas. Usa lenguaje inclusivo.
    0 K 7
  31. Itsallgoodman #31 Itsallgoodman
    Cada vez que leo sobre estos ataques me viene a la cabeza el Travian
    0 K 8
  32. tamat #32 tamat
    #4 github ademas de hospedar proyectos abiertos contiene miles de repositorios privados de usuarios de pago, y esos repositorios suelen contener las claves de acceso a amazon, passwords, etc. Asi que no es tan mal objetivo.
    2 K 36
  33. saqueador #33 saqueador
    #32 Como si alojan los códigos de acceso a Sión, un ataque DDOS es para denegar un servicio, no para robar información.
    6 K 38
  34. #34 flixter
    #29 hombre, "maldito memcache"... Entiendo que, si tienes una maquina accesible desde internet, como poco mirarás qué servicios tiene corriendo... No?
    1 K 10
  35. #35 bokepacha
    #6 Es aquí donde uno se vanagloria de haber empezado con la informática con el MS-UNO?
    2 K 20
  36. #36 Tasio_
    Preocupante que usen el puerto por defecto de Memcache y que este no sea unicamente accesible desde local o desde la red privada, Github lo ha maquillado muy bien pero aunque el ataque no sea su culpa sus servidores no estaban debidamente protegidos.
    0 K 6
  37. neo1999 #37 neo1999
    #3 Alucinante o_o
    0 K 9
  38. #38 Hopo
    #4 China
    0 K 7
  39. cosmonauta #39 cosmonauta
    #33 A menudo se usa un DDOS como primer ataque, con la esperanza de que los técnicos de sistemas cometan un error que se pueda aprovechar.

    No es la mejor manera, porque dejas claras tus intenciones desde el minuto cero, pero a veces funciona, por ejemplo contra Steam hace algún tiempo.
    1 K 27
  40. cosmonauta #40 cosmonauta
    #36 El memcache vulnerable no era de GitHub...
    1 K 14
  41. #41 --270157--
    #13 sin agacharse a por el jabón.
    0 K 6
  42. #42 --556871--
    resumiendo, se atacaron ellos mismos...
    0 K 7
  43. XrV #43 XrV
    #39 con psnetwork hicieron lo mismo
    0 K 6
  44. daphoene #44 daphoene
    #42 En cualquier caso, el código del ataque seguro que está en GitHub. Igual les pueden mandar un pull request * para que vean dónde fallaron :troll:

    *- Para los profanos, es una corrección de código que alguien puede enviar al dueño de ese código.
    0 K 6
  45. XrV #45 XrV
    #24 un simple fw se te va rapidito a los 100k€, para filtrar 1Tbit no me quiero inaginar la infraestructura.
    Como dicen en el articulo, eso se detiene desde los carriers que conectan el objetivo (github) al resto de internet.

    Ya que estoy vamos a estirar del hilo:
    Github tiene las ips 192.30.255.113 y 192.30.255.112, alojadas en la propia red de github (AS36459). Dicha red conecta a Internet via:

    AS1299-TELIANET
    AS174-COGENT-174
    AS2828-XO-AS15
    AS2914-NTT-COMMUNICATIONS-2914
    AS3356-LEVEL3

    La salida se produce en 6 lugares distintos:

    Dos conexiones de 20G en equinix (un punto de intercambio neutro de datos, IX) y 2 de 10G en SIX (otro punto neutro de intercambio de datos). Luego 2 mas en puntos de intercambio privados que no se las conexiones.

    Por cierto Equinix es el corazón de Internet en USA.

    Bueno, pues akamai conecta dos nodos (y otro antiDDos) en cada uno de los IX de Equinix con 60G cada uno!!! Simplemente demencial. Aunque en SIX Akamai conecta con 80G!! (Amazon conecta 200G ahí, ejemmm)

    Y llegados a este punto me planteo que el ataque ha sido tan gordo que ha hecho temblar Internet, un terremoto de escala 8.5 por lo menos.

    Frikis de las redes, ¿me apuntais más datos?

    Fuentes: bgp.he.net, asnmap.net y peeringdb.com

    www.peeringdb.com/ix/1
    asnmap.com/asn/36459
    bgp.he.net/AS36459

    Saludos, humanos.
    11 K 86
  46. XrV #46 XrV
    #23 go to #45 para mas info
    0 K 6
  47. XrV #47 XrV
    #26 eso no disipa el ataque, y no es el caso de gitHub, aunque me pregunto de que forma detienes tanto caudal por muy cloudflare que seas.
    0 K 6
  48. XrV #48 XrV
    #34 auditoria de seguridad dices????? :shit:
    0 K 6
  49. XrV #49 XrV
    #29 eso es pasar una mala tarde amigo
    0 K 6
  50. XrV #50 XrV
    #36 ein? Te traduzco el articulo: no hay culo que aguante semejante berga.
    0 K 6
  51. #51 Tasio_
    #40 Cierto lo habia leido mal, gracias.
    0 K 6
  52. XrV #52 XrV
    #42 que noooooo.... usaron maquinas con mala configuración para atacarles mediante una técnica llamada "reflection attack" en.m.wikipedia.org/wiki/Reflection_attack
    0 K 6
  53. XrV #53 XrV
    #44 no fallaron... ese ataque puede ocurrir contra cualquier servicio de Internet.
    0 K 6
  54. XrV #54 XrV
    #17 buenisimo el link
    1 K 16
  55. daphoene #55 daphoene
    #53 Lo sé, pero intentaron tirar GitHub y no lo consiguieron, ergo fallaron.
    0 K 6
  56. #56 none
    #45 Akamai funciona como red de proxys distribuidos por cpd's de medio planeta. Cuando pides resolver un dominio akamaizado te dan una ip del proxy inverso mas cercano de akamai. El trafico se para mucho antes de llegar a los nodos de intercambio y a los enlaces finales de github. Y más este tráfico tipo udp.
    2 K 24
  57. frg #57 frg
    #29 ¿Defecto de Centos?, ¿no será un error de configuración del "memcached"?.

    Voy a mirar los míos, no vaya a ser que los tenga igual.
    0 K 10
  58. #58 flixter *
    #48 #57 Para un mínimo, no hace falta ni una auditoría (que tambien): "netstat -puta" y a ver qué hay escuchando.
    0 K 7
  59. XrV #59 XrV
    #56 y eso como se detecta? Es un servicio entre carriers? Con un traceroute se puede ver?
    Por lo que leí en el articulo de github lo que hicieron fué redirigir el trafico a una ip de akamai, osea tras iniciarse el ataque.
    Saludos
    1 K 15
  60. #60 none
    #59 En condiciones normales, vía dns. Se delega la resolución del dominio a Akamai (poniendose como masters del dominio), y estos van resolviendo a ip's de sus proxys en función de donde sea el origen de la petición.

    Pero en el caso de este ataque no estoy seguro como lo han hecho, ya que efectivamente resuelve a ip's de github nativas suyas, por lo que el ddos llegaría hasta las puertas de su carrier.
    0 K 9
  61. squanchy #61 squanchy
    #27 Si echan abajo stackoverflow, ese día el mundo se queda sin resolver incidencias informáticas y se quedan parados todos los desarrollos.
    0 K 9
  62. #62 --26321--
    #15 En la empresa donde trabajo, grande corporación americana, también se hacen este tipo de pruebas: Stress tests, penetration tests y esas cosas.

    Antes de iniciar las pruebas, y si ellos consideran que alguna de estas tareas pueden impactar al usuario o a los beneficios, entonces envían un email para comunicarnoslo. Eso sí, tenemos prohibido tomar medidas extras: Sólo sentarnos y mirar sudando las gráficas de rendimiento.

    Veo difícil que haya sido algo planificado.
    1 K 17
  63. XrV #63 XrV
    #60 no lo he podido leer, pero creo que aqui responden a eso: githubengineering.com/ddos-incident-report/
    0 K 6
  64. tamat #64 tamat
    #33 normalmente tras un DDOS un server puede quedar en un estado vulnerable, ya sea por desbordamientos de memoria o porque el servidor se resetea y es mas facil saber el uptime de la maquina. He visto varias charlas de la DEFCON donde usan ataques DDOS como herramienta para ataques mas elaborados.
    0 K 9
  65. gonas #65 gonas
    #4 #7 Github es un producto comercial. Aunque se uso mayoritariamente su parte gratuita, también tiene una parte de pago. Y como suele pasar con estas cosas, la parte gratuita se usa para promocionar la de pago.
    0 K 12
comentarios cerrados

menéame