¿Estas entradas de access.log tienen éxito con el inicio de sesión de wordpress?

6

Estoy alojando algunos sitios de wordpress en un servidor web apache 2.4, y he descubierto miles de entradas en los registros de mi servidor de esta manera:

221.219.219.248 - - [09/Mar/2015:03:29:25 +1300] "GET /example.com/wp-login.php HTTP/1.1" 200 6656 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"
221.219.219.248 - - [09/Mar/2015:03:29:26 +1300] "POST /wp-login.php HTTP/1.1" 302 644 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"

y decenas de miles de entradas como esta:

162.144.120.185 - - [13/Mar/2015:07:19:18 +1300] "POST /wp-login.php HTTP/1.0" 302 608 "-" "-"

En estos casos, el servidor está dando una respuesta 302 , que me parece que wordpress los está redirigiendo de nuevo a la página de inicio de sesión, lo que indica un intento de inicio de sesión fallido.

luego vi entradas como esta

78.7.148.218 - - [14/Mar/2015:06:42:31 +1300] "POST /wp-login.php HTTP/1.1" 200 1695 "http://example.com/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0"

donde la respuesta HTTP es un 200 .

¿Los intentos de inicio de sesión de fuerza bruta obtuvieron contraseñas y son estos inicios de sesión exitosos?

    
pregunta the_velour_fog 30.04.2015 - 05:51
fuente

1 respuesta

4

En primer lugar, aquí se explica cómo se maneja de forma predeterminada cuando visita la página de inicio de sesión e intenta iniciar sesión:

POST /wp-login.php
[invalid credentials]
-> 200

POST /wp-login.php
[valid credentials]
-> 302

Así que es al revés de lo que asumiste. 302 significa credenciales válidas (redirigir al área de administración), mientras que las credenciales no válidas dan como resultado 200 (permanecer en la página de inicio de sesión).

Sin embargo, hay varias formas en las que puedes lograr un 302 sin pasar credenciales válidas. Por ejemplo, podría agregar un campo POST que contenga action=postpass , lo que daría como resultado la configuración de una cookie, y wp_safe_redirect (que de manera predeterminada usa 302) se llama con el referente que se aprobó.

Hay muchas otras acciones que darían como resultado un 302, por ejemplo, action=register .

Entonces, aunque no puedo decir con seguridad que no hubo intentos exitosos de fuerza bruta, podría ser que esos 302 atacantes estén escaneando su sitio web para verificar si su registro está abierto (posiblemente para registrarse y luego intentar escalar) sus privilegios). También podría ser que su herramienta de fuerza bruta esté mal configurada.

    
respondido por el tim 30.04.2015 - 15:42
fuente

Lea otras preguntas en las etiquetas