Read on Twitter
Gente peligrosa con acceso a micrófonos y cámaras, y oídos de gobernantes, vendiendo fruta y ficción barata. Dramatismo para subir la venta de su imagen.
Es importante en estos casos desenmascararlos.
Sobre los hechos de ayer a la web de la marcha virtual por #75Octubres 1/n
Es importante en estos casos desenmascararlos.
Sobre los hechos de ayer a la web de la marcha virtual por #75Octubres 1/n
Se iba a realizar una marcha virtual utilizando una plataforma llamada VirtualMov, q pone a disposición de sus usuarios un sitio web a través del cual se accede al servicio de manifestación virtual que incluye personajes digitales, chat en tiempo real y acceso a recursos online
Desconozco el costo del servicio para quien lo contrata, pero su uso - una vez puesto en marcha el servicio específico p una manifestación virtual - es gratuito.
Ayer ocurrió que alrededor del mediodía el servicio dejó de funcionar y "las voces" denunciaron un ataque informático
Ayer ocurrió que alrededor del mediodía el servicio dejó de funcionar y "las voces" denunciaron un ataque informático
La posibilidad de un ataque es siempre real, en este caso se dijo que se trataba de una Denegación de Servicio Distribuida (DDoS en inglés) que consta en precisamente interrumpir un servicio mediante una sobrecarga de accesos.
Sin embargo, lo más probable es que el servicio se haya saturado por la cantidad de accesos legítimos. De hecho, a primera vista un DDoS es idéntico a una sobrecarga por accesos legítimos. Una investigación posterior puede brindar luz sobre si se trató de lo uno o lo otro.
Para diferenciar los tipos de accesos se analizan las proveniencias de los mismos, el ritmo y los reintentos.
P. e. si para un servicio argentino que espera mayoría de accesos desde Argentina se detectan mayoría de accesos extranjeros, es potencialmente factible hablar de un DDoS
P. e. si para un servicio argentino que espera mayoría de accesos desde Argentina se detectan mayoría de accesos extranjeros, es potencialmente factible hablar de un DDoS
Sin embargo, al no contar con esta información que solo es obtenible por el prestador de servicio y siempre y cuando el mismo pueda contar con un registro de estos accesos (lo que no siempre es así), es IMPOSIBLE determinar lo sucedido y mucho menos AFIRMAR cualquier conclusión
Lo mucho que uno puede hacer es analizar el entorno y proponer hipótesis.
Como se observa en este tuit, el servicio en cuestión se encontraba hosteado en Amazon con sus DNS en Cloudflare
https://mobile.twitter.com/4Dgifts/status/1317540509724921858
Como se observa en este tuit, el servicio en cuestión se encontraba hosteado en Amazon con sus DNS en Cloudflare
https://mobile.twitter.com/4Dgifts/status/1317540509724921858
Amazon es un proveedor de infraestructura altamente escalable y otros servicios. Cloudflare es un proveedor de cache distribuida, DNS y servicios de seguridad, entre otros.
CF ofrece protección contra DDoS. Y cuenta con la arquitectura, los medios y recursos para efectivamente mitigar o paliar un ataque del estilo, o en el peor de los casos, al menos determinar si hubo tal ataque.
SIN EMBARGO, podemos ver que la IP del servicio en cuestión NO pertenece a CF sino a Amazon por lo que los servicios de seguridad de CF no estaban en juego.
Por otro lado, los servicios de Amazon poseen la capacidad de escalar automáticamente con la demanda.
Por otro lado, los servicios de Amazon poseen la capacidad de escalar automáticamente con la demanda.
Escalar implica crecer en capacidad de soportar carga.
PERO para que escale automáticamente debe estar configurado a tal fin, y la aplicación debe ser capaz también capaz de hacerlo (esto no es inmediato ni sencillo). Y además, tiene un costo económico.
Entonces, ¿qué pasó?
PERO para que escale automáticamente debe estar configurado a tal fin, y la aplicación debe ser capaz también capaz de hacerlo (esto no es inmediato ni sencillo). Y además, tiene un costo económico.
Entonces, ¿qué pasó?
Si nos fijamos hoy ya no nos responde una IP de Amazon sino una de OVH, y nos indica amablemente que se trata de una aplicación hecha en PHP servida por Apache.
Esta info nos sirve como indicio de que la aplicación no sería capaz de soportar miles o millones de accesos.
Esta info nos sirve como indicio de que la aplicación no sería capaz de soportar miles o millones de accesos.
Citando a un experto en la materia: "El problema seguramente fue la app que se quedó sin file descriptors", que es totalmente posible dado que PHP requiere de un archivo por cada cliente (un file descriptor) para almacenar la sesión de usuario y esto ocurre por defecto.
Debemos considerar también los accesos a base de datos por parte de la aplicación y todos los servicios que la app pueda llegar a utilizar. Y la capacidad del/los servidor/es en cuestión.
En principio, no resulta disparatado hablar de una sobrecarga por accesos legítimos
En principio, no resulta disparatado hablar de una sobrecarga por accesos legítimos
No es inmediatamente fácil ni económico producir una infraestructura autoescalable y una aplicación acorde.
Y hablar de un ataque informático parece una salida fácil y libre de culpas, como si además no hubiese sido previsible.
Y hablar de un ataque informático parece una salida fácil y libre de culpas, como si además no hubiese sido previsible.
Muches llegarán hasta acá y dirán: ¿y? ¡no me confirmaste nada aún!
Y no, no puedo lamentablemente. Solo el dueño del servicio y sus proveedores pueden brindar luz al suceso, justamente quienes dudo que quieran hacerlo.
Y no, no puedo lamentablemente. Solo el dueño del servicio y sus proveedores pueden brindar luz al suceso, justamente quienes dudo que quieran hacerlo.
Pero decir que fue la NSA, mostrar gráficos de conexiones fechados en agosto que además no dicen nada y tirar una sarta de términos inexistentes y sin sentido no suman absolutamente nada a la cuestión.
Si usamos la navaja d Ockham: "en igualdad de condiciones, la explicación más sencilla suele ser la más probable"
A mi criterio, es muchísimo más factible que se haya tratado d una mala configuración de app e infraestructura que de un ataque informático, aunq no lo descarte
FIN
A mi criterio, es muchísimo más factible que se haya tratado d una mala configuración de app e infraestructura que de un ataque informático, aunq no lo descarte
FIN
