Un usuario preguntó 👇
Veo que los ataques de registro se repiten con el error de borde 499. IP diferentes …
Se pone peor y tengo que reiniciar el sitio web porque deja de responder.
¿Cómo puedo detener esto?
2017-08-23 12:00:07 Error 170.150.185.150 499 GET /xmlrpc.php HTTP / 1.1 2017-08-23 12:00:39 Error 170.150.185.150 499 GET /wp-login.php HTTP / 1.1 2017- 08-23 12:01:11 Error 170.150.185.150 499 GET /wp-login.php HTTP / 1.1 2017-08-23 12:01:43 Error 170.150.185.150 499 GET /wp-login.php HTTP / 1.1 2017- 08-23 12:02:15 Error 170.150.185.150 499 GET /wp-login.php HTTP / 1.1
2017-08-23 11:13:20 Error 189.76.233.145 499 GET /wp-login.php HTTP / 1.1 2017-08-23 11:13:51 Error 189.76.233.145 499 GET /wp-login.php HTTP / 1.1 2017-08-23 11:15:14 Error 65.94.86.78 405 GET /xmlrpc.php HTTP / 1.1 2017-08-23 11:15:14 Error 65.94.86.78 499 GET /wp-login.php HTTP / 1.1 2017- 08-23 11:15:14 Error 65.94.86.78 499 GET /wp-login.php HTTP / 1.1 2017-08-23 11:15:14 Error 65.94.86.78 499 GET /wp-login.php HTTP / 1.1 2017- 08-23 11:15:15 Error 65.94.86.78 499 GET /wp-login.php HTTP / 1.1
Lanzador de hilos
(@ jlee2027)
Hace 3 años, 6 meses
Y hacia abajo de nuevo….
(@crudhunter)
Hace 3 años, 6 meses
Está ejecutando bajo el servidor web Nginx. Nginx usa 499 para decirle que el cliente cerró la conexión antes de que el servidor web pudiera responder. Lo cual es inusual en sí mismo.
Podría ser que el cliente realmente se esté cerrando o que tenga una seguridad separada frente a su servidor web que tome los ataques y cierre el enlace final a su sitio. Todo dependiendo de su configuración.
Sin embargo, si la seguridad del front-end está configurada correctamente, su servidor web nunca debería ver una conexión. Yo mismo lo hago de esa manera. NO quiero perder el tiempo “hablando” con estos hacker-bots, así que solo tengo que cerrarles la puerta (cerrar el enlace) sin obtener ninguna otra respuesta. (El mismo método que utilizo en Telemarketers cuando llaman. 🙂)
Por qué NGinx debe reiniciarse / reiniciarse, es probable que algo en su sitio impida que su servidor NGinx cierre la conexión. Procesamiento de back-end en NGinx, un plugin o incluso un registro de WordFence que aún no se ha producido, MemCached no respondió (si se usó), esperando el servidor de base de datos,…,… Una lista interminable de cosas podría ralentizar la respuesta de su servidor. el cierre remoto. Es necesario desinfectar.
Si el ataque de fuerza bruta llega lo suficientemente rápido, el servidor puede usar todas las conexiones TCP disponibles, por lo que ya no puede responder. La posada ya no tiene habitaciones libres (entradas de conexión).
Si hace ‘netstat’ o ‘netstat -a’ desde la línea de comandos, probablemente verá todos estos enlaces abiertos.
Consulte la columna Estado. Si el estado de TCP es ‘CLOSE_WAIT’, eso significa que el control remoto FIN se ha lanzado para cerrar la conexión, pero su sistema operativo está esperando que su proceso local (Nginx acepto ahora) para cerrarlo previamente, los registros pueden ser liberado.
Dependiendo de la cantidad de conexiones disponibles configuradas, puede, como se mencionó, quedarse sin espacio para nuevas conexiones y verá que no habrá respuesta del servidor.
Una de las formas de eliminar un servidor web es si no puede responder y limpiar lo suficientemente rápido. 🙂
(@crudhunter)
Hace 3 años, 6 meses
Por cierto … Veo que estás usando PHP-7.0.22. Se sabe que esa versión es la PHP7 predeterminada y estás actuando como un tonto para colapsar en algunos entornos de alojamiento. Es posible que desee cambiar a una versión posterior. Sin embargo, probablemente no se aplique a sus 499.
(@wfyann)
Hace 3 años, 6 meses
Hola @ jlee2027,
De hecho, el código de error (499) indica que el cliente cerró la conexión antes de que el servidor web pudiera responder.
Ahora bien, hay una serie de posibles razones por las que esto está sucediendo.
Cerrar la conexión podría ser algo ascendente; pero también puede hacer que el servidor sea demasiado lento para responder o algún problema de configuración.
Le recomiendo encarecidamente que en todos los casos se ponga en contacto con su proveedor de alojamiento para que puedan investigar más a fondo e identificar la causa de este comportamiento.
Lanzador de hilos
(@ jlee2027)
Hace 3 años, 6 meses
Bien, resolvió el 499. Era un problema de PHP Pool donde pm.max.children era 5. Lo suficientemente tonto como para que el PHP predeterminado solo estableciera 5 instancias, pero estoy divagando. Cuando alcanzó el requisito 6, esperó 30 segundos, luego NGINX lo cronometró. Aumenté el pm.max.children, reconstruí PHP (el reinicio no funciona, necesitas reconstruir) y el 499 se ha ido.
Gracias a todos por su apoyo Caleb y wfyAnn, ¡definitivamente ayudaron!
Sigo recibiendo 2017-08-26 08:34:47 Error 219.85.235.75 405 GET /xmlrpc.php HTTP / 1.1 2017-08-26 08:34:49 Error 219.85.235.75 503 GET /wp-login.php HTTP / 1.1 2017-08-26 08:34:49 Error 219.85.235.75 503 GET /wp-login.php HTTP / 1.1 2017-08-26 08:34:50 Error 219.85.235.75 503 GET /wp-login.php HTTP / 1.1 2017-08-26 08:34:53 Error 219.85.235.75 503 GET /wp-login.php HTTP / 1.1
Ignore el 405 y el 503. Le estoy diciendo a WordPress qué lanzar. Espero disuadirlos de que accedan a nuestro servidor, pero todavía se están realizando intentos regulares con diferentes IP.
¿Hay alguna forma de frustrar estos esfuerzos? TIA.
Esta respuesta fue modificada hace 3 años, 6 meses por.
(@wfyann)
Hace 3 años, 6 meses
Hola @ jlee2027,
Gracias por la respuesta.
Si aplica, podría «Bloquear direcciones IP que envían solicitudes POST con un agente de usuario y un árbitro en blanco“Característica (Wordfence -> Opciones -> sección Otras opciones).
Además, si identifica un patrón en el Agente de usuario, puede bloquear aplicaciones de dicho Agente de usuario especificándolas en el campo «Agente de usuario coincidente (navegador)» (Wordfence -> Bloqueo -> Bloqueo avanzado).
Déjeme saber si esto ayuda.
¿Solucionó tu problema??
0 / 0