Portada
mis comunidades
otras secciones
#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.
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.
#45:
#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
https://www.peeringdb.com/ix/1
http://asnmap.com/asn/36459
https://bgp.he.net/AS36459
Saludos, humanos.
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
https://www.peeringdb.com/ix/1
http://asnmap.com/asn/36459
https://bgp.he.net/AS36459
Saludos, humanos.
#24:
#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.
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.
#3:
"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.
https://blogs.akamai.com/2018/03/memcached-fueled-13-tbps-attacks.html
https://blogs.akamai.com/2018/03/memcached-fueled-13-tbps-attacks.html
Comentarios
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.
#4 Quizás es la competencia...
#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.
#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í.
#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.
#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.
#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.
#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".
#9 “No hay huevos”, dijo alguien.
#4 pues alguien que querrá meter troyanos en las descargas.
#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.
#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.
#4 Buena publicidad par Akamai who knows....
Por cierto el post original:
https://githubengineering.com/ddos-incident-report/
#17 Eso estoy pensando... ¿no estaría preparado para batir un record, además?
#17 buenisimo el link
#4 Monstruos y monstruas. Usa lenguaje inclusivo.
#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.
#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.
#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.
#39 con psnetwork hicieron lo mismo
#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.
#4 China
"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.
https://blogs.akamai.com/2018/03/memcached-fueled-13-tbps-attacks.html
#3 Suerte que fue contra github y no contra stackoverflow, no hubieran sabido cómo arreglarlo sin consultarlo
#27 Si echan abajo stackoverflow, ese día el mundo se queda sin resolver incidencias informáticas y se quedan parados todos los desarrollos.
#3 Alucinante
Ahora empezarán con los ataques TTreS...
#6 sería DTres y DCuatro
#8 a la DTres va la vencida.
http://cuddlebuggery.com/wp-content/uploads/2012/08/Ba-dum-tish.png
#8 DDoS no atacan si uno no quiere
#6 Ddos personas no fueron suficientes para tumbal ggithub
#6 Es aquí donde uno se vanagloria de haber empezado con la informática con el MS-UNO?
Sobrevivir dice ... fue mas bien un ataque de suto o muelte
Aquí en mi ignorancia sobre redes, ¿Cómo se repele un ataque de tan gigante tamaño?
#13 Se desconecta el cable rojo.
#23 go to #45 para mas info
#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.
#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
https://www.peeringdb.com/ix/1
http://asnmap.com/asn/36459
https://bgp.he.net/AS36459
Saludos, humanos.
#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.
#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
#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.
#60 no lo he podido leer, pero creo que aqui responden a eso: https://githubengineering.com/ddos-incident-report/
#13 CDN
Basicamente, hay un montón de replicas repartidas por todo el globo. Ante un ataque, solo afecta al CDN más proximo.
#26 lo de CDN me suena más, gracias por la aclaración.
#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.
#13 sin agacharse a por el jabón.
Joder
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.
#29 hombre, "maldito memcache"... Entiendo que, si tienes una maquina accesible desde internet, como poco mirarás qué servicios tiene corriendo... No?
#34 auditoria de seguridad dices?????
#48 #57 Para un mínimo, no hace falta ni una auditoría (que tambien): "netstat -puta" y a ver qué hay escuchando.
#29 eso es pasar una mala tarde amigo
#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.
Cada vez que leo sobre estos ataques me viene a la cabeza el Travian
Normal que sobreviviera GitHub, seguro que había un hilo para sobrevivir ataques DDoS
Si pero se va la electricidad y jake mate colega
resumiendo, se atacaron ellos mismos...
#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
*- Para los profanos, es una corrección de código que alguien puede enviar al dueño de ese código.
#44 no fallaron... ese ataque puede ocurrir contra cualquier servicio de Internet.
#53 Lo sé, pero intentaron tirar GitHub y no lo consiguieron, ergo fallaron.
#42 que noooooo.... usaron maquinas con mala configuración para atacarles mediante una técnica llamada "reflection attack" https://en.m.wikipedia.org/wiki/Reflection_attack
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.
#36 El memcache vulnerable no era de GitHub...
#40 Cierto lo habia leido mal, gracias.
#36 ein? Te traduzco el articulo: no hay culo que aguante semejante berga.