#60 Estresar un sistema es una forma de provocar errores. Las consolas se piratean así: Se meten glitches en la CPU hasta que haces saltar un error antes de que se bloqueen las zonas seguras.

#67 ok, pero algun ejemplo de stack mas o menos actual para servir web que falle de esa manera?? es que me sorprende mucho.

#60 Normalmente a un ataque DoS se lo conoce por tirar abajo los servicios pero esta acción tambien habilita al atacante a crear una cortina de humo para inflitrarse o forzar el reinicio de los sistemas y aprovechar ese instante para socavar información y/o conocer los recursos compartidos a los que están conectados (bases de datos).

Lo único que está claro es que los admin deberían de hacer una audit para esclarecer sus fallos de seguridad y publicar un report explicando qué ha pasado, cómo pudo ocurrir y los pasos a mejorar el stack.

#91 A mi es que como posible explicación me parece un poco pillada por los pelos. Si metemos 'ataque DoS' pues antes metemos que le han robado el portatil a un dev, que han dejado una copia del repo por ahí, o que un backup de pruebas lo han dejado accesible.
Los ataques de DoS son muy accesibles y fáciles y baratos, me extraña que eso fácilmente sea suficiente para abrir una puerta trasera en un sitio como menéame.
Pero hablo desde el desconocimiento y por eso pregunto, me gustaría conocer ejemplos en los que haya pasado con servicios web, con algun post-mortem más o menos técnico.

#93 Those are two of the key takeaways from a recent Neustar and Harris Interactive report based on a global, independent survey of 1,010 directors, managers, CISOs, CSOs, CTOs, and other C-suite executives. 76% reported that they had experienced multiple DDoS attacks. Even those companies that were attacked only once, a whopping 92% of them reported theft of intellectual property, customer data and/or financial assets and resources.

Igual este artículo te lo explica mejor -> https://www.corero.com/blog/theft-and-ddos-attacks-go-hand-in-hand/

Al inundar con peticiones los servidores, los primeros en sufrir los ataques son los firewalls y load balancers. Una vez los firewalls fallan, se puede atacar puertos específicos que estaban protegidos.

#96 In most cases hackers are looking to steal something, so they use a small DDoS attack as a smokescreen to mask their more nefarious subterfuge
Ok entonces el ataque de DoS es para despistar, pero no quiere decir que con un ataque así te roben la información, lo harán por otros medios. Si tiras abajo un firewall o un load balancer por un ataque no es que queden los puertos abiertos, es que se queda inaccesible la web. Que me dices 'pues el admin quita el firewall de la ecuacion para reestablecer el servicio y por eso luego roban datos', bueno pues es que ese admin es temerario.
No quiero buscarle 3 pies al gato, es que simplemente soy desarrollador web y me gusta estar informado. Gente como yo somos los que por falta de conocimiento dejamos puertas abiertas .
En todo caso yo no desarrollaría o usaria un firewall que dejara pasar trafico de forma selectiva a no ser que haya mucho trafico y entonces haga lo que viene siendo un fail-open,es absurdo.

#102 Normalmente son los devops los que se ocupan por el bienestar de la arquitectura pero si dejas a los desarrolladores web que mantengan el stack, entonces seguramente no haya una sino muchas formas de poder atacar el sistema (yo tambien soy desarrollador web ).

En el caso de meneame, imagino que tienen un monolítico bastante guapo con server side rendering y del rollo no me toques que me rompo. Solo con ver la página, no parece que tengan ni helmet... Vamos que lo raro es que se hayan enterado que les han volvaco parte de la base de datos.

#105 bueno la seguridad es tarea compartida, por ejemplo un ataque de inyección de SQL es por un fallo en el desarrollo, no por un tema de sistemas.

#25 un ataque bastante común es hacer un denial of service DoS y cuando los servicios empiezan a fallar se abren puertas traseras.

Si han entrado hasta la cocina (base de datos) no sería muy raro que no tengan la palabra clave para generar el hash. Seguramente lo tengan hardcoded en el código.

#27 Algun ejemplo de como un ataque de DoS puede acabar provocando que se pueda acceder a base de datos? es que no se me ocurre ahora mismo.
Me imagino un stack de AMP antiguo que si por lo que sea los procesos de PHP no den a basto, al apache le de por renderizar el código PHP en claro, y que la contraseña de la bbdd esté en uno de esos archivos y que la base de datos tenga el puerto públicamente accesible, pero son muchos 'sies' de estár haciendo las cosas mal y realmente no me consta que apache escupa php en claro si no es realmente por que esté mal configurado.

#60 Estresar un sistema es una forma de provocar errores. Las consolas se piratean así: Se meten glitches en la CPU hasta que haces saltar un error antes de que se bloqueen las zonas seguras.

#67 ok, pero algun ejemplo de stack mas o menos actual para servir web que falle de esa manera?? es que me sorprende mucho.

#60 Normalmente a un ataque DoS se lo conoce por tirar abajo los servicios pero esta acción tambien habilita al atacante a crear una cortina de humo para inflitrarse o forzar el reinicio de los sistemas y aprovechar ese instante para socavar información y/o conocer los recursos compartidos a los que están conectados (bases de datos).

Lo único que está claro es que los admin deberían de hacer una audit para esclarecer sus fallos de seguridad y publicar un report explicando qué ha pasado, cómo pudo ocurrir y los pasos a mejorar el stack.

#91 A mi es que como posible explicación me parece un poco pillada por los pelos. Si metemos 'ataque DoS' pues antes metemos que le han robado el portatil a un dev, que han dejado una copia del repo por ahí, o que un backup de pruebas lo han dejado accesible.
Los ataques de DoS son muy accesibles y fáciles y baratos, me extraña que eso fácilmente sea suficiente para abrir una puerta trasera en un sitio como menéame.
Pero hablo desde el desconocimiento y por eso pregunto, me gustaría conocer ejemplos en los que haya pasado con servicios web, con algun post-mortem más o menos técnico.

#93 Those are two of the key takeaways from a recent Neustar and Harris Interactive report based on a global, independent survey of 1,010 directors, managers, CISOs, CSOs, CTOs, and other C-suite executives. 76% reported that they had experienced multiple DDoS attacks. Even those companies that were attacked only once, a whopping 92% of them reported theft of intellectual property, customer data and/or financial assets and resources.

Igual este artículo te lo explica mejor -> https://www.corero.com/blog/theft-and-ddos-attacks-go-hand-in-hand/

Al inundar con peticiones los servidores, los primeros en sufrir los ataques son los firewalls y load balancers. Una vez los firewalls fallan, se puede atacar puertos específicos que estaban protegidos.

#96 In most cases hackers are looking to steal something, so they use a small DDoS attack as a smokescreen to mask their more nefarious subterfuge
Ok entonces el ataque de DoS es para despistar, pero no quiere decir que con un ataque así te roben la información, lo harán por otros medios. Si tiras abajo un firewall o un load balancer por un ataque no es que queden los puertos abiertos, es que se queda inaccesible la web. Que me dices 'pues el admin quita el firewall de la ecuacion para reestablecer el servicio y por eso luego roban datos', bueno pues es que ese admin es temerario.
No quiero buscarle 3 pies al gato, es que simplemente soy desarrollador web y me gusta estar informado. Gente como yo somos los que por falta de conocimiento dejamos puertas abiertas .
En todo caso yo no desarrollaría o usaria un firewall que dejara pasar trafico de forma selectiva a no ser que haya mucho trafico y entonces haga lo que viene siendo un fail-open,es absurdo.

#105 De la Torre Eiffel, están diciendo que tienen que cambiarle todas sus vigas por lo deterioradas que están después de algo más de un siglo al aire. También es verdad que son de hierro.

#52 Pues también es verdad, pero supongo que como todo material expuesto a la intemperie tendrá sus tratamientos. Sea metal o madera.

#53 recuerdo ver de pasada un documental en el que decían que el puente de san francisco no se si cuando acaban de pintarlo vuelven a empezar, para mantenerlo en buenas condiciones

#105 De la Torre Eiffel, están diciendo que tienen que cambiarle todas sus vigas por lo deterioradas que están después de algo más de un siglo al aire. También es verdad que son de hierro.

#52 El hotel Arts de Barcelona Ah. ¿pero esos andamios no son decorativos?

#54 No sé si son decorativos, pero delgados no son.

#208 No se trata de escalar en equipos de personas, sino de escalar en usuarios. Hay organizaciones pequeñas que pueden usar microservicios si el volumen de datos o usuarios es muy alto y muy variable. Y usar microservicios no es la única solución, pero ya te digo que el monolito de toda la vida escala hasta cierto punto y muy mal. Por supuesto en muchos casos es un modelo que funciona, pero no hace milagros.

Y no voy a entrar en los problemas de Menéame porque ni los conozco ni me importan. Sólo te digo que fallaste en tu diagnóstico, no hay "visionarios" de los que hablas. Más bien son de los de "no creemos en las modas de visionarios"

#212 Prácticamente desacuerdo en todo lo que dices. Entiendo que te identificas como 'visionario' jeje

#9 La mayoría de errores es porque tienen una parte nueva comunicando con la parte vieja, eso es insostenible y mal planificado por parte de los que trabajan en la web.

Cuando en un Twitch pregunte que arquitectura habían escogido para la nueva aplicación me vi todos estos problemas, ya que no puedes escalar ni horizontal ni verticalmente cosas por separado, esto es que por ejemplo la gestión de usuarios (lectura/escritura) es mas demandada por el frontend que por ejemplo el nótame (no lo se se seguro pero para poner un ejemplo), te podría permitir tener una infraestructura más flexible ante una demanda dinámica.

No tiene nada que ver con el dinero, al contrario, poner más infraestructura es darle una patada al balón de la deuda técnica hacia delante ya que durante un tiempo todo ira bien a base de quemar dinero.

#109 No, han creado otro monolito conectando cosas a través de llamadas HTTP internamente, es que me veo el percal, tienes una fachada bonita y detrás el legacy del legacy.

#109 Quizás están usando cosas serverless que se ejecutan en el aire acondicionado de tu casa, eso si que es puntero

#109 joder te quiero comer los morros, que bien lo has explicado (y no lo digo de coña), los programadores hypster se están cargando la calidad de las cosas en nombre de "la modernidad" y cuando se lo demuestras te cuentan que "con lo barato que es el hardware hoy en día no hace falta código eficiente, subes de recursos y con eso vale" #TrueStory

#109 El el Twitch ya decían que no habían hecho microservicios, más o menos tenían tu discurso. A lo mejor si los usaran podrían escalar. En vez de eso han querido hacer un lavado de cara que, además, nadie quiere.

Por cierto, lo que describes no es un tema de visionarios, es el presente y hasta diría que ya el pasado porque no es un paradigma nuevo para nada. El problema de pasar de monolito a otras arquitecturas que han probado de sobra ser más flexibles y eficientes es saber valorar la relación coste/beneficio porque no sale barato y no tiene sentido en todos los casos.

#143 quieres decir que para escalar, si o si se necesita romper un monolito en microservicios?
Los microservicios permiten escalar equipos de personas cuando una empresa se hace muy grande. Grande del tamaño de google. Estámos hablando de menéame. El que piense que para menéame lo mejor es una arquitectura de microservicios y que es necesaria para escalar es un VISIONARIO.
No es que no tenga sentido en todos los casos. Es que en la GRANDISIMA mayoría de los casos no tiene sentido. Pero como excusa cuando algo falla por no estar bien testeado, desarrollado, por no saber programar modularmente sin meter una peticion HTTP entre dos contextos diferentes... pues es una carta que se usa mucho

#208 No se trata de escalar en equipos de personas, sino de escalar en usuarios. Hay organizaciones pequeñas que pueden usar microservicios si el volumen de datos o usuarios es muy alto y muy variable. Y usar microservicios no es la única solución, pero ya te digo que el monolito de toda la vida escala hasta cierto punto y muy mal. Por supuesto en muchos casos es un modelo que funciona, pero no hace milagros.

Y no voy a entrar en los problemas de Menéame porque ni los conozco ni me importan. Sólo te digo que fallaste en tu diagnóstico, no hay "visionarios" de los que hablas. Más bien son de los de "no creemos en las modas de visionarios"

#212 Prácticamente desacuerdo en todo lo que dices. Entiendo que te identificas como 'visionario' jeje

#109 this

Historia nunca vista en tecnología y que nadie sabe cómo termina.

#83 Puedes decir Londres, Nueva York o Milán, pero no puedes decir La Coruña, Lérida o San Cucufate del Vallés

#113 Ellos dicen Còrdova, Saragossa, Cadis, Lleó o Conca. Pero los demás no pueden traducir sus toponimos (que lo hacen todas las lenguas).

#113 Puedes decir lo que te dé la gana, pero hasta yo me reiré si dices San Cucufate.

#83 https://www.rae.es/dpd/L%C3%A9rida

Lérida. Nombre tradicional en lengua castellana de la provincia y ciudad de Cataluña cuyo nombre en catalán es Lleida. Salvo en textos oficiales, donde es preceptivo usar el topónimo catalán como único nombre oficial aprobado por las Cortes españolas, en textos escritos en castellano debe emplearse el topónimo castellano. El gentilicio, para todo tipo de textos, incluidos los oficiales, es leridano. También existe el gentilicio culto ilerdense, basado en el nombre latino de esta ciudad.