Un utente ha chiesto informazioni su Fixing WordPress di Wordpress

Problemi con le regole modsec OWASP e WP cron

Un utente ha chiesto 👇

Attiva la regola OWASP quasi ogni volta che qualcuno visita i miei siti WP. Uso WHM / cPanel e OWASP3. Attualmente sto usando wordpress 5.0.2, ma questo è accaduto anche su 4.x.

Fonte: (IP pubblico del mio server)
Stato: 200
ID regola: 920180: Lunghezza intestazione POST applicazione Oggetto mancante.
Richiesta: POST /wp-cron.php?doing_wp_cron=1546253580.8522100448608398437500
Descrizione azione: avviso.
Giustificazione: EQ dell’operatore abbinato a 0 da REQUEST_HEADERS.

Questo non interferisce con alcuna funzionalità per l’utente ma riempie sempre i miei log di modsec. Ho provato a disabilitare wp-cron.php definendo (‘DISABLE_WP_CRON’, ‘true’) in wp-config.php, ma ciò non ha aiutato. La regola è sempre incoraggiante.

Un’altra cosa che ho notato è che le mie regole modsec bruteforce personalizzate non funzionano più, anche se a un certo punto lo hanno fatto.
Ecco le regole personalizzate di ModSec che dovrebbero bloccare gli attacchi bruteforce:

SecStatusEngine on
SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},id:5000134

#SecAction phase:1,nolog,pass,initcol:ip=%{REQUEST_HEADERS.x-forwarded-for},id:5000134

<Locationmatch "/wp-login.php">
SecRule ip:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 10 minutes, more than 10 login attempts in 5 minutes.'"

SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"

SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/300,id:5000137"

SecRule ip:bf_counter "@gt 10" "t:none,setvar:ip.bf_block=1,expirevar:ip.bf_block=600,setvar:ip.bf_counter=0"

</locationmatch>
SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000234

<Locationmatch "/xmlrpc.php">
SecRule user:bf_block "@gt 0" "deny,status:401,log,id:5000235,msg:'ip address blocked for 10 minutes, more than 5 login attempts in 5 minutes.'"

SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/300,id:5000237"

SecRule ip:bf_counter "@gt 5" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=600,setvar:ip.bf_counter=0"

</Locationmatch>

# Default HTTP policy: allowed_request_content_type (rule 900220)
SecRule &TX:allowed_request_content_type "@eq 0" "id:1901162, phase:1, pass, nolog, setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain|text/x-gwt-rpc'"

Lanciatore di thread

(@ivanclab)

2 anni, 2 mesi fa

Ho spostato define (‘DISABLE_WP_CRON’, true); all’inizio di wp-config.php e ora sembra essere disabilitato. Penso ancora che questo dovrebbe essere impostato per non provocare le regole OWASP.

Lanciatore di thread

(@ivanclab)

2 anni, 2 mesi fa

Dopo la semina define(‘DISABLE_WP_CRON’, true); all’inizio di ogni file wp-config.php ho aggiunto cron job ogni volta con il comando wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Nessuna regola ModSec lo chiama se viene chiamato in questo modo.

Ho impostato regole personalizzate WP bruteforce per modsec:

SecUploadDir /tmp
SecTmpDir /tmp
SecDataDir /tmp
SecRequestBodyAccess On

SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000134

<Locationmatch "/wp-login.php">
    # React if block flag has been set.
    SecRule user:bf_block "@gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 5 login attempts in 3 minutes.'"

    # Setup Tracking.  On a successful login, a 302 redirect is performed, a 200 indicates login failed.
    SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"
    SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"
	
    SecRule ip:bf_counter "@gt 5" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=300,setvar:ip.bf_counter=0"
</Locationmatch>

ErrorDocument 401 default

Mancava il reindirizzamento degli ugelli e dei documenti di errore dopo l’attivazione del blocco.

In una nota a margine, dopo uno sguardo più attento alle mie regole precedenti, le regole xmlrpc.php sembrano non necessarie. Mi sembra come fermerebbero anche gli usi legittimi. Nel mio caso sarebbe meglio bloccare xmlrpc poiché non è richiesto.

L’ho aggiunto a .htaccess per bloccarlo:

<Files "xmlrpc.php">
Require all denied
</Files>

Was this helpful?

0 / 0

Lascia un commento 0

Your email address will not be published. Required fields are marked *