Plesk ModSecurity: setup e configurazione regole WAF

Cos'e' ModSecurity

ModSecurity e' un Web Application Firewall (WAF) open source che si integra con Apache, Nginx e IIS per analizzare le richieste HTTP e bloccare attacchi noti come SQL injection, XSS, command injection, scanning automatico e tentativi di sfruttamento di vulnerabilita' delle applicazioni web.

Plesk integra ModSecurity come componente opzionale e fornisce tre rule set ufficiali: OWASP ModSecurity Core Rule Set, Atomic Basic ModSecurity, Comodo WAF Rules.

Installare ModSecurity

Da pannello: Tools & Settings → Web Application Firewall (ModSecurity). Se l'estensione non e' presente, andare in Tools & Settings → Updates e installare il componente "ModSecurity".

Da SSH:

plesk installer --select-product-id panel --select-release-current --install-component modsecurity

Abilitare ModSecurity

Nella pagina di configurazione scegliere il modo operativo:

  • Off: ModSecurity disabilitato
  • Detection only: analizza ma non blocca, utile per testing
  • On: blocca attivamente le richieste sospette

Consigliamo di partire in Detection only per qualche giorno e analizzare i log: se non emergono falsi positivi gravi, passare a On.

Scegliere il rule set

Plesk offre tre rule set:

  • OWASP CRS (gratuito): il set più' usato al mondo, copre OWASP Top 10
  • Atomic Basic (gratuito): regole base di Atomicorp
  • Comodo WAF (gratuito con registrazione): regole aggiornate quotidianamente
  • Atomic Advanced (a pagamento): regole premium, false positive ridotti

Per la maggior parte dei siti, OWASP CRS e' un'ottima scelta di partenza.

Paranoia Level

OWASP CRS supporta diversi livelli di aggressivita' (paranoia level):

  • Level 1: regole base, pochi falsi positivi
  • Level 2: più' regole, possibili falsi positivi su form complessi
  • Level 3: regole stringenti, richiede tuning
  • Level 4: regole massime, solo per applicazioni semplici

Plesk non espone direttamente il paranoia level: si modifica nel file /etc/httpd/modsecurity.d/tortix_waf.conf tramite la variabile tx.paranoia_level.

Configurazione per dominio

ModSecurity puo' essere abilitato/disabilitato singolarmente per dominio:

  1. Andare in Subscriptions → dominio → Web Application Firewall (ModSecurity)
  2. Spuntare "Disable for this site" se serve disattivarlo
  3. Personalizzare le direttive ModSecurity per il singolo sito

Analizzare i log

I blocchi ModSecurity sono registrati in:

/var/log/modsec_audit.log
/var/log/httpd/error_log

Per cercare blocchi su un dominio specifico:

grep "miosito.it" /var/log/modsec_audit.log | grep -i "blocked"

Disabilitare una regola specifica

Se una regola genera falsi positivi su un sito, e' possibile disabilitarla. Trovare l'ID della regola nel log (es. id 949110), poi aggiungere in Subscriptions → dominio → Apache & nginx Settings → Additional Apache directives:

<IfModule mod_security2.c>
    SecRuleRemoveById 949110
</IfModule>

Aggiornare le regole

Le regole vengono aggiornate da Plesk automaticamente. Per forzare l'aggiornamento manuale:

plesk sbin modsecurity_ctl --update

Performance

ModSecurity ha un'impatto sulle prestazioni del web server (mediamente +5-15% di CPU). Su server con molti siti e traffico elevato monitorare il carico dopo l'attivazione.

Tuning paranoia level

I paranoia level di OWASP CRS aumentano progressivamente l'aggressivita' delle regole. Level 1 e' adatto a quasi tutti i siti, Level 2 a siti business con form complessi controllati, Level 3-4 solo a siti molto semplici dove qualsiasi richiesta anomala e' sospetta. Cambiare il level richiede testing approfondito.

Audit log analysis

Il file /var/log/modsec_audit.log registra ogni richiesta bloccata con dettaglio completo: headers, body, regola triggerata. Per analisi avanzata si usano tool come WAF-FLE o ModSecurity Dashboard che aggregano e visualizzano i blocchi in grafici interattivi.

Falsi positivi su WordPress

WordPress e' noto per generare falsi positivi con OWASP CRS, specialmente nell'editor Gutenberg che invia POST con HTML complesso. Plesk include esclusioni predefinite per WordPress che vanno abilitate in Subscription → ModSecurity → Use exclusion rules for WordPress.

Performance impact

ModSecurity aggiunge latenza alle richieste: tipicamente 5-20ms per request, ma puo' salire fino a 100ms per request complesse con paranoia level alto. Su server con SSD veloci e CPU recenti l'impatto e' trascurabile; su VPS limitati puo' essere sensibile.

Aggiornamento manuale del rule set

Per ottenere l'ultima versione di OWASP CRS prima dell'aggiornamento Plesk automatico:

cd /etc/httpd/modsecurity.d/owasp-crs
git pull

Disabilitare per uploads grandi

I file upload molto grandi possono attivare regole sul body inspection. Per disabilitare ModSecurity solo sul path di upload:

<LocationMatch "/upload">
    SecRuleEngine Off
</LocationMatch>

Custom rules per applicazioni interne

Oltre alle regole standard, e' possibile scrivere regole custom ModSecurity per proteggere applicazioni specifiche. Esempio per bloccare richieste a un'endpoint admin da IP non whitelistati:

SecRule REQUEST_URI "@beginsWith /admin" \
    "id:1001,phase:1,deny,status:403,\
    chain"
    SecRule REMOTE_ADDR "!@ipMatch 192.168.1.0/24"

Debug delle regole

Per capire perché' una richiesta viene bloccata, abilitare temporaneamente debug log:

SecDebugLog /var/log/modsec_debug.log
SecDebugLogLevel 9

Disabilitare in produzione: il debug log e' molto verboso e consuma spazio rapidamente.

Lockdown amministrativo

Per i path admin sensibili come wp-admin di WordPress, e' possibile usare ModSecurity per ulteriore lockdown:

SecRule REQUEST_URI "@beginsWith /wp-admin" \
    "id:2001,phase:1,nolog,pass,setvar:tx.wp_admin=1"

Integrazione con SIEM

I log audit ModSecurity in formato CRS/JSON sono facilmente ingestibili da SIEM come Splunk, ELK Stack, Wazuh. Forwarding via syslog o Filebeat permette analisi centralizzata di tutti i blocchi WAF su flotta server.

Tuning iterativo

Il setup ideale richiede tuning iterativo: parti in detection-only per 7-14 giorni, analizza i falsi positivi, crea esclusioni per quelli ripetuti, poi attiva il modo on. Ripetere periodicamente dopo update di rule set.

Hai bisogno di aiuto?

Se vuoi gestione Plesk dal team di G Tech Group, scrivici tramite il modulo di contatto.

Hai trovato utile quest'articolo?