WordPress Errore Forbidden in Personalizza

Comunemente questo errore e dato quasi sempre da un server non configurato correttamente, il mostro del mod_security e un sistema di protezione del server che stai utilizzando. Fa molto bene il suo lavoro infatti l’errore 403 Forbbiden deriva proprio da lui. Perchè?

I pacchetti hosting standart acquistati dai provider ufficiali questa configurazione viene data in automatico oppure a seconda del pannello di controllo possono cambiare comportamenti della protezione dati.

Osservando la funzione “Inspect” del browser web (es. Google Chrome) possiamo scoprire che il server web sta inviando stati HTTP 403 (Forbidden) come risposta da admin-ajax.php. Questo perchè ormai il server ci ha completamente isolati (bannati) perche abbiamo mandato troppo richieste. E dunque mod_sec si mette all’azione, ci banno e priva dei nostri privilegi da amministrazione del nostro proprio nostro sito web.

Noi abbiamo esperimentato questo comportamento del mod_sec su CWP, con kernel Centos 7. Okey spiegato il problema, veniamo al dunque per come risolverlo…

Analizzando gli errori log:

<div class="wp-block-codemirror-blocks-code-block code-block"><pre>[Thu Mar 09 07:37:02 2017] [error] [client xxx.xxx.196.210] ModSecurity: Access denied with code 403 (phase 2). Pattern match "\\\\b(?i:having)\\\\b\\\\s+(\\\\d{1,10}|'[^=]{1,10}')\\\\s*?[=&lt;&gt;]|(?i:\\\\bexecute(\\\\s{1,5}[\\\\w\\\\.$]{1,5}\\\\s{0,3})?\\\\()|\\\\bhaving\\\\b ?(?:\\\\d{1,10}|[\\\\'\\"][^=]{1,10}[\\\\'\\"]) ?[=&lt;&gt;]+|(?i:\\\\bcreate\\\\s+?table.{0,20}?\\\\()|(?i:\\\\blike\\\\W*?char\\\\W*?\\\\()|(?i:(?:(select(.* ..." at ARGS:customize_changeset_data. [file "/usr/local/apache/modsecurity-crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "130"] [id "959070"] [rev "2"] [msg "SQL Injection Attack"] [data "Matched Data: This is the text which I wanted to change to something else! within ARGS:customize_changeset_data: {\\x22parallax_one_our_story_text\\x22:{\\x22value\\x22:\\x22&lt;p&gt;There were more text which were needed to be changed [hostname "www.domain.com"] [uri "/wordpress/wp-admin/admin-ajax.php"] [unique_id "WMEGHn8AAAEAACWLdyQAAAAE"]
</pre></div>

Scopriamo che l’indirizzo IP, e stato bloccato per msg “SQL Injection Attack ciò vuol dire che noi per il sistema abbiamo avuto dei comportamenti che per il nostro server non li va bene.

L ‘”Accesso negato con codice 403″ è correlato allo stato HTTP 403 (Proibito). Il file di registro ha insultato piacevolmente la causa del problema. I dati o il payload sono stati inviati all’URI “/wordpress/wp-admin/admin-ajax.php” ma sono stati bloccati dalla regola di sicurezza di ModSecurity. È stato riconosciuto come “SQL Injection Attack” anche se la richiesta è stata inviata dal back-end con credenziali di accesso autentiche.

Cosa fare adesso?

A questo punto, concentriamoci sulle regole di ModSecurity e proviamo a capire quale regola è responsabile del problema 403. Prendi questa parte del registro degli errori di Apache ed esaminala:

<div class="wp-block-codemirror-blocks-code-block code-block"><pre>	[file "/usr/local/apache/modsecurity-crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "130"] [id "959070"] [rev "2"] [msg "SQL Injection Attack"]</pre></div>

Il file modsecurity_crs_41_sql_injection_attack.conf alla riga 130 contiene la regola di blocco con ID 959070. L’ID è il nostro obiettivo principale. Questo indica quale regola causa il problema. Se sono presenti più ID con numeri diversi, è necessario gestirli individualmente. Conoscendo il numero ID della regola è possibile aggirarla. Ci sono molti modi per farlo, buoni e cattivi.

IP dinamico

L’host, che viene utilizzato per accedere al back-end di WordPress, ha un indirizzo IP pubblico dinamico. Il modo più semplice e forse il più insicuro è disabilitare la regola stessa, aiuterà ma in caso di un vero attacco siamo nei panni … Quindi per farlo, aggiungi una nuova riga a /usr/local/apache/conf/mod_sec_disable_rules.conf con il seguendo il comando e riavvia il server Apache.

<div class="wp-block-codemirror-blocks-code-block code-block"><pre>$ echo 'SecRuleRemoveById 959070' &gt;&gt; /usr/local/apache/conf/mod_sec_disabled_rules.conf 
$ service httpd restart</pre></div>

Come ho già detto, forse questo non è il modo migliore per farlo, ma se utilizzi un indirizzo IP dinamico quando accedi a WordPress, lo farà. La regola è ora completamente disabilitata. Il seguente comando abiliterà nuovamente la regola:

<div class="wp-block-codemirror-blocks-code-block code-block"><pre>$ cd /usr/local/apache/conf/ 
$ cp mod_sec_disabled_rules.conf mod_sec_disabled_rules.conf.tmp 
$ sed '/959070/d' mod_sec_disabled_rules.conf.tmp &gt; mod_sec_disabled_rules.conf</pre></div>

Con un indirizzo IP statico o un intervallo IP, esiste un modo migliore per aggirare la regola inserendo in una lista bianca l’indirizzo pubblico dell’host.

<div class="wp-block-codemirror-blocks-code-block code-block"><pre>$ cd /usr/local/apache/modsecurity-crs/ 
$ echo 'SecRule REMOTE_ADDR "@ipMatch xxx.xxx.196.208/28"phase:1,nolog,allow,ctl:ruleEngine=Off,id:40' &gt;&gt; modsecurity_crs_10_config.conf 
$ service httpd restart</pre></div>

Sostituisci xxx.xxx.196.208 / 28 con il tuo indirizzo CIDR.

Ciò può impedire ulteriori conflitti con ModSecurity in futuro e la regola continuerà a proteggere da qualsiasi intrusione esterna.

Tutorial Per CWP (Centos Web Panel)

Consideriamo che il nostro IP come nell’immagine di sopra sia 128.199.122.54 come notiamo nel log, questo indirizzo IP e stato bloccato per malintenzione. Spostiamo l’elenco verso destra per vedere bene i dettagli e avere ID di chiamata, poi copia ID della restrizione.

Dopo aver copiato L’ID, diamoli il permesso che vuole perchè ovviamente quel ID e nostro quindi possiamo darli i permessi per qualsiasi chiamata di modifica. Nel riquadro a destra troverai Regole Disabilitate, apri il modulo di configurazione e aggiungi la stringa: SecRuleRemoveById 941100

E salva.

Apri il terminale in modalità semplice copia e ed esegui il comando:

<div class="wp-block-codemirror-blocks-code-block code-block"><pre>grep 128.199.122.54 /usr/local/apache/domlogs/*error.log|grep ModSecurity</pre></div>

(l’indirizzo IP) deve essere quel dei Errore Log dove abbiamo ricavato ID della chiamata.

Fatto, riavvia mod security e ora prova ad andare sul pannello di controllo WordPress, e fai tutto quello che dovevi fare.
Fateci sapere.