Queste voci di access.log hanno successo con i tentativi di login di wordpress?

Question

Queste voci di access.log hanno successo con i tentativi di login di wordpress?

#1 da (4 voti)

6

Sto ospitando alcuni siti wordpress su un server web Apache 2.4, e ho scoperto migliaia di voci nei registri del mio server in questo modo:

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"

e decine di migliaia di voci come questa:

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

In questi casi il server sta dando una risposta di 302 , che mi sembra come se wordpress li stesse reindirizzando alla pagina di accesso, il che indica un tentativo di accesso fallito.

poi ho visto voci come questa

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"

dove la risposta HTTP è un 200 .

I tentativi di accesso della forza bruta hanno ottenuto le password e sono questi accessi effettivi?

wordpress brute-force

posta the_velour_fog 30.04.2015 - 05:51

fonte

1 risposta

Leggi altre domande sui tag wordpress brute-force

Perché gli honeypot non vengono distribuiti su larga scala? Cosa viene memorizzato su una carta bancaria e in che modo è protetta?

score 4 · Accepted Answer

Prima di tutto, ecco come viene gestito per impostazione predefinita quando visiti la pagina di accesso e prova ad accedere:

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

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

Quindi è il contrario di ciò che hai assunto. 302 significa credenziali valide (reindirizzamento all'area di amministrazione), mentre le credenziali non valide risultano in 200 (resta nella pagina di accesso).

Esistono comunque vari modi per ottenere un 302 senza passare credenziali valide. Ad esempio, è possibile aggiungere un campo POST contenente action=postpass , che determinerebbe l'impostazione di un cookie e la chiamata di wp_safe_redirect (che per impostazione predefinita utilizza 302) al referer passato.

Ci sono molte altre azioni che comporterebbero un 302, ad esempio action=register .

Quindi, mentre non posso dire con certezza che non ci siano stati tentativi bruteforce di successo, potrebbe benissimo essere che quei 302 malintenzionati stiano semplicemente scansionando il tuo sito web per verificare se la tua registrazione è aperta (possibilmente per registrarti e poi provare ad aumentare) i loro privilegi). Potrebbe anche essere che il loro strumento bruteforce non sia configurato correttamente.