Soy un desarrollador web de operaciones de desarrollo con un sitio que ejecuta dos ec2.smalls detrás de un equilibrador de carga en AWS.
Recientemente, vimos que entre 3 y 4 solicitudes por segundo desactivaban el sitio de nuestros clientes.
El sitio estaba inactivo y no volvió a funcionar después de varios reinicios del servidor y escaneos de registros de errores en busca de scripts que pudieran estar causando el problema, a pesar de que no se realizaron cambios recientemente.
Después de activar el registro del balanceador de carga, vi que miles de solicitudes a una sola página provenían de una dirección IP.
Reenviamos la solicitud desde el balanceador de carga al servidor que maneja la solicitud usando X-forwarded-for y bloqueamos la IP usando una regla .htaccess.
Mientras se comunicaban con el departamento de TI de los clientes, se les notificó que la dirección IP responsable de la avalancha de solicitudes era en realidad una de las máquinas internas de la empresa.
La máquina responsable se reinició de forma remota y se detuvieron todas las solicitudes. El sitio volvió a estar en línea.
La explicación oficial para esto fue que "la computadora se estaba volviendo loca".
¿Es posible que un navegador web o una máquina con Windows realice de 3 a 4 solicitudes por segundo a una página web con carga equilibrada y la elimine durante más de 5 horas?
Así es como se veían las solicitudes:
2017-01-14T01:00:46.170447Z west-ssl XX.XXX.XX.XXX:33370 - -1 -1 -1 503 0 0 0 "GET https://www.example.com:443/example/12 HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" ECDHE-RSA-AES128-SHA256 TLSv1.2
Respuesta1
Claro que es posible, aunque depende de varios factores:
1) Parece que la aplicación del lado del servidor tiene problemas de simultaneidad. Podría valer la pena analizar si fueron los servidores de aplicaciones los que constituyeron el cuello de botella, o si fueron aguas arriba, como las bases de datos, y los servidores de aplicaciones se quedaron sin memoria debido a que la configuración de Apache no vaciaba los subprocesos lo suficientemente rápido. Si se tratara de los servidores de aplicaciones, podría valer la pena hacer algunos ajustes: encienda una máquina idéntica fuera del ELB y use JMeter para cargarla y descubrir los cuellos de botella.
Si fuera la base de datos, es posible que pueda usar Memcache/elasticache (ya que parece que está recuperando un objeto específico) para almacenar en caché las consultas reales. De esa manera, las conexiones de base de datos responden rápidamente, Apache puede responder rápidamente y eliminar subprocesos en lugar de llenar el grupo de memoria de la máquina de la aplicación.
Si realmente se siente vulnerable, puede colocar Varnish en sentido ascendente para almacenar en caché las solicitudes en un TTL de 1 a 5 segundos para evitar una inundación importante de solicitudes. Pero tenga cuidado, ya que VCL es implacable y puede provocar problemas importantes y dolores (intoxicación/fuga de caché).
2) En cuanto a la propia máquina "sujeta". Obviamente podría haber sido comprometido; definitivamente debería ser investigado. Te dejaré decidir si el encargado de TI es honesto o no; eso está fuera del ámbito de la falla del servidor.
Suponiendo que no estuviera comprometido, podría haber sido algún código JavaScript incorrecto: si realiza actualizaciones de sondeo y de alguna manera se modificó un parámetro de tiempo, es muy posible que comience a enviar muchas solicitudes por segundo. Del mismo modo, es posible que el JS se haya portado bien, pero es posible que la persona haya tenido 25 pestañas abiertas y se haya ido a casa por la noche; si cada uno envía 1 solicitud cada 5 segundos, eso es 5 solicitudes por segundo.