Mod Security & Worpress

Come già precedentemente discusso nei miei articoli, mod security è un modulo di Apache che funge da web application firewall (WAF), permette di proteggere la nostra applicazione da attacchi, bot o richieste anomale.

Ogni richiesta web viene confrontata con una serie di regole presenti nel nostro WAF, in caso la chiamata infrangesse una di queste regole, essa verrà bloccata con codice 403.

Mod security inoltre unito a fail2ban permette di impostare dei blocchi temporanei e/o definitivi ad IP in caso continuassero ad infrangere queste regole tramite iptable, in modo da salvaguardare le risorse del nostro server.

Ora il problema è che le regole di default di mod security sono troppo aggressive e in caso non corrette per gestire correttamente WordPress.

Per ovviare a ciò è necessario disabilitare queste regole dove servono. In questo caso è stato necessario verificare i comportamenti dell’applicativo durante la sua normale esecuzione, attraverso i log di mod security, per comprendere quale regole andavano bloccate.

Di seguito il set di regole da disabilitare che attualmente ho verificato aver problemi nella normale esecuzione di WordPress.

Per fare ciò occorre:

1. creare una directory dove inserire la vostra configurazione con il set regole da disabilitare ad esempio in /etc/httpd/custom-conf/ o /etc/apache2/custom-conf/ a seconda della distribuzione Linux.
2. Creare un file ad esempio wp-modsecurity.conf e incollarci il contenuto sottostante

<LocationMatch "/">
   #FrontpageRole
   SecRuleRemoveByID 981173 960024
   #MailChimp
   SecRuleRemoveByID 981172
   #API WordPress.com JetPack
   SecRuleRemoveById 981318 950901 981243 973300 973333 973332 960015 950109
</LocationMatch>

<LocationMatch "/wp-content/themes/">
    SecRuleRemoveByID 960015
</LocationMatch>

<LocationMatch "/wp-login.php">
    SecRuleRemoveById 950120 950901
</LocationMatch>

<LocationMatch "/wp-admin/wp-login.php">
   SecRuleRemoveById 950120 950901
</LocationMatch>

<LocationMatch "/wp-admin/options.php">
    SecRuleRemoveById 950120
</LocationMatch>

<LocationMatch "/wp-admin/admin-ajax.php">
     SecRuleRemoveById 959151 981231 981319 960024 981173 981245 981318 950001 959073 981243 973338 981257 981240 950901 981317 950109
     SecRuleRemoveById 959070 981250 960015
     SecRuleRemoveById phpids-17 # Detects JavaScript object properties and methods
     SecRuleRemoveById phpids-20 # Detects JavaScript language constructs
     SecRuleRemoveById phpids-21 # Detects very basic XSS probings
     SecRuleRemoveById phpids-30 # Detects common XSS concatenation patterns 1/2
     SecRuleRemoveById phpids-61 # Detects url injections and RFE attempts
     #wpforms plugin
     SecRuleRemoveById 981242 981246 973300 973347 973333 973344 973332
</LocationMatch>

<LocationMatch "/wp-admin/admin.php">
     #smart-slider plugin
     SecRuleRemoveByID 981317
     #Smart gallery
     SecRuleRemoveById 960335
</LocationMatch>

<LocationMatch "/wp-admin/nav-menus.php">
        SecRuleRemoveByID 960024 981257 981245 981242 981246 981243 200004 973347 950120 950120 981231 981240
</LocationMatch>

<LocationMatch "/wp-admin/install.php">
    SecRuleRemoveById 950901
</LocationMatch>

<LocationMatch "/wp-json/jetpack/v4/jitm">
    SecRuleRemoveById 950109
</LocationMatch>

3. Includere in ogni Virtual Host (/etc/httpd/site-enabled/virtualhost.conf) ,che gestisce un applicazione WordPress, il file di configurazione:

Include custom-conf/wp-modsecurity.conf

4. Riavviare Apache

Questo set di regole potrebbe essere non ancora completo. Pur avendolo testato con applicativi con diversi plugin molto utilizzati, WooCommerce compreso, potrebbero non bastare e nuove regole potrebbero essere necessarie se nuovi plugin venissero bloccati.

Se è necessario aggiungere nuove regole è sempre meglio farlo con criterio, non disabilitare la regola per l’intera applicazione ma individuare url della richiesta bloccata e inibire solo quella regola per questo url.

Se dovessimo dover sbloccare la richiesta di esempio intercettata da mod security, e presente nei suoi log:

Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 192.0.102.230] ModSecurity: Access denied with code 403 (phase 2). Pattern match "\\\\\\\\%((?!$|\\\\\\\\W)|[0-9a-fA-F]{2}|u[0-9a-fA-F]{4})" at ARGS:#38;page_handle. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_20_protocol_violations.conf"] [line "465"] [id "950109"] [rev "2"] [msg "Multiple URL Encoding Detected"] [severity "WARNING"] [ver "OWASP_CRS/2.2.9"] [maturity "6"] [accuracy "8"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/EVASION"] [hostname "www.manuelroccon.it"] [uri "/admin/ajax.php"] [unique_id "XaMGGuMghUsF943j6QiDNQAAAIk"]

sarà necessario individuare uri di riferimento (/admin/ajax.php) e la regola infranta (950109) in questo caso la corretta regola da implementare sarà la seguente (molto importante è anche verificare hostname che corrisponda effettivamente a un nostro vhost in gestione):

<LocationMatch "/wp-admin/options.php">
    SecRuleRemoveById 950120
</LocationMatch>

Ricordo che queste regole sono testate con Mod Security 2 e WordPress 5.2.3

Una nota extra:

Se avete attivato anche mod_evasive, modulo di apache che protegge da attacchi ddos, richieste continue (ad esempio Ajax di plugin) potrebbero essere rilevate da ModSecurity e sua volta bloccate da fail2ban, vi consiglio di alzare il numero di richieste alla stessa pagina almeno ad 8 per secondo.