# Usare ModSecurity e OWASP Core Rule Set > Usare ModSecurity e OWASP CRS: scegliere il motore giusto, capire soglie di anomalia e livelli di paranoia, gestire in modo mirato i falsi allarmi. Fonte: https://phpsos.de/it/blog/modsecurity-owasp-crs/ Stato: 25/10/2026 Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6 **In breve:** ModSecurity è una Web Application Firewall che gira nel server web; l'OWASP Core Rule Set (CRS) fornisce le relative regole liberamente disponibili contro i tipi di attacco più diffusi. Per Apache il progetto CRS raccomanda ModSecurity v2, per Nginx entrano in considerazione il connettore v3 o Coraza. Parta in modalità di blocco con soglie di anomalia molto alte, le abbassi gradualmente e tratti i falsi allarmi con eccezioni mirate. Non sostituisce un aggiornamento di PHP. ## Una WAF propria come livello aggiuntivo Da PHP2Shell molte aziende si chiedono se abbiano bisogno di una Web Application Firewall. Chi consegna i propri siti tramite Cloudflare, secondo Cloudflare ha regole di protezione attive automaticamente dal 21 ottobre 2026. Chi non lo fa, o non vuole instradare il traffico tramite una terza parte, può far girare una WAF direttamente sul proprio server. La combinazione più nota è ModSecurity con l'OWASP Core Rule Set. Entrambi sono open source e gratuiti. Il CRS è una raccolta di regole di rilevamento generali, ad esempio contro SQL injection, cross-site scripting o l'iniezione di file. Il progetto stesso descrive il proprio obiettivo come rilevamento generale degli attacchi con il minor numero possibile di falsi allarmi, come un elemento tra più. Con ciò è indicato anche il limite. Una WAF controlla richieste e risposte, non ripara una falla nell'interprete PHP. Perché servano entrambi lo descrive [WAF o aggiornamento: perché servono entrambi](https://phpsos.de/it/blog/waf-oder-update/). ## Quale motore si adatta al Suo server web Il set di regole ha bisogno di un motore che lo esegua. Secondo la documentazione CRS esistono tre opzioni compatibili: | Motore | Server web | Inquadramento secondo il progetto CRS | |---|---|---| | ModSecurity v2 | Apache (modulo) | implementazione di riferimento, raccomandata per Apache | | ModSecurity v3 (libModSecurity) | soprattutto Nginx tramite connettore | solo il connettore Nginx è davvero utilizzabile in produzione; non supera dal 2 al 4 per cento dei test CRS | | Coraza | proxy e integrazioni basati su Go | supera per intero la suite di test CRS v4 | Sullo sfondo: ModSecurity è stato sviluppato a lungo da Trustwave. Trustwave nel 2021 ha annunciato la fine dello sviluppo nel 2024. Il 25 gennaio 2024 il progetto è passato alla OWASP Foundation. Per le nuove installazioni verifichi quale versione consegna la Sua distribuzione e quanto sia aggiornata. ## Come lavora il Core Rule Set Nell'impostazione predefinita il CRS non blocca alla prima anomalia sospetta. Lavora con punti di anomalia: ogni regola attivata somma punti secondo la sua gravità, e solo quando la somma supera una soglia la richiesta viene respinta. 1. Livelli di gravità: critico 5 punti, errore 4, avviso 3, nota 2. 2. Soglia per le richieste: `tx.inbound_anomaly_score_threshold`, valore predefinito 5. 3. Soglia per le risposte: `tx.outbound_anomaly_score_threshold`, valore predefinito 4. 4. Livelli di paranoia da 1 a 4 in `crs-setup.conf`: il livello 1 è la protezione di base per ogni server su Internet, il livello 2 secondo il progetto si adatta ad applicazioni con dati reali degli utenti come gli shop online, i livelli 3 e 4 portano molti più falsi allarmi. Un livello di paranoia più alto riconosce di più, ma genera anche più falsi allarmi. Per la maggior parte dei siti aziendali il livello 1 è l'inizio, il livello 2 un obiettivo successivo. ## Introdurre ModSecurity con OWASP CRS senza paralizzare il sito Per le nuove installazioni il progetto CRS raccomanda di attivare la modalità di blocco fin dall'inizio, ma con soglie molto alte, fino a 10000, e di abbassarle poi gradualmente. Così si raccolgono esperienze con accessi reali senza escludere gli utenti. Le soglie le imposti in `crs-setup.conf`: ```apache # crs-setup.conf: fase iniziale con soglie molto alte SecAction \ "id:900110,\ phase:1,\ pass,\ t:none,\ nolog,\ setvar:tx.inbound_anomaly_score_threshold=10000,\ setvar:tx.outbound_anomaly_score_threshold=10000" ``` L'inclusione sotto Apache segue l'ordine che la documentazione CRS prescrive per i plugin. I percorsi variano secondo la distribuzione: ```apache SecRuleEngine On Include /etc/modsecurity/crs/crs-setup.conf Include /etc/modsecurity/crs/plugins/*-config.conf Include /etc/modsecurity/crs/plugins/*-before.conf Include /etc/modsecurity/crs/rules/*.conf Include /etc/modsecurity/crs/plugins/*-after.conf ``` Poi analizzi l'audit log, definito in `SecAuditLog`. Come scandire sistematicamente i registri lo descrive [Analizzare i log del server web dopo un attacco](https://phpsos.de/it/ratgeber/logfiles-auswerten/). Abbassi le soglie per gradi, ad esempio nell'arco di più settimane, fino ad arrivare al valore predefinito. ## Trattare i falsi allarmi in modo mirato I falsi allarmi sono normali, soprattutto nei backend dei CMS con editor che salvano HTML. La reazione peggiore è disattivare la WAF. Meglio due strumenti. Primo, i plugin: il progetto CRS cura plugin con regole di eccezione per applicazioni diffuse, ad esempio per WordPress. Si copiano nella cartella dei plugin e si caricano tramite le righe Include mostrate sopra. L'elenco ufficiale lo tiene il progetto nella sua directory dei plugin. Secondo, eccezioni proprie e ben delimitate. Invece di disattivare una regola ovunque, la tolga solo per il percorso in cui disturba: ```apache # Eccezione propria, da caricare PRIMA delle regole CRS (ad es. in un *-before.conf) SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \ "id:1000010,\ phase:1,\ pass,\ nolog,\ ctl:ruleRemoveById=941100" ``` L'ID della regola lo ricava dall'audit log del falso allarme. Documenti ogni eccezione con motivo e data, in modo che possa essere riesaminata in seguito. > **Consiglio:** > Dopo ogni modifica a soglie o eccezioni testi i percorsi critici della Sua applicazione: login, ordine, pagamento, modulo di contatto e redazione. Una WAF che blocca gli ordini viene presto disattivata di nuovo. Per i server Apache vale la pena affrontare la WAF insieme al resto della configurazione; le basi sono in [Configurare Apache per PHP in sicurezza](https://phpsos.de/it/blog/apache-fuer-php-absichern/). Come inquadrare le regole di Cloudflare per confronto lo mostra [Regole di protezione Cloudflare contro PHP2Shell](https://phpsos.de/it/blog/cloudflare-waf-php2shell/). Le misure transitorie sul server stesso sono in [Misure immediate se non può ancora applicare la patch](https://phpsos.de/it/php2shell/sofortmassnahmen-ohne-patch/). ## Conclusione: una WAF richiede manutenzione ModSecurity con l'OWASP Core Rule Set Le dà una Web Application Firewall potente, senza costi di licenza e senza dipendere da un servizio esterno. Il prezzo è il lavoro: scegliere il motore adatto al server web, iniziare con soglie alte, analizzare i falsi allarmi, curare le eccezioni e tenere aggiornate le regole. Chi non può sostenere questo impegno si trova spesso meglio con una WAF cloud ben configurata. Chi lo sostiene ottiene un livello che intercetta molti attacchi standard e fornisce negli audit log preziose indicazioni. In nessun caso sostituisce l'aggiornamento: contro PHP2Shell proteggono solo PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 o un backport confermato, seguiti dal riavvio di tutti i processi PHP. ## Come aiuta PHP SOS in concreto? - **Scegliere il motore:** verifichiamo server web, distribuzione e pacchetti disponibili e raccomandiamo la combinazione adatta. - **Introdurre:** installiamo il CRS con soglie iniziali alte, integriamo i plugin adatti e configuriamo la registrazione. - **Tarare:** nell'arco di più settimane analizziamo i falsi allarmi, creiamo eccezioni mirate e abbassiamo le soglie. - **Inquadrare:** nell'ambito di [WAF e virtual patching](https://phpsos.de/it/leistungen/waf-virtuelles-patching/) colleghiamo la WAF alle misure transitorie e al percorso verso la patch regolare. ## Domande frequenti **L'OWASP CRS protegge da PHP2Shell?** Non dovrebbe darlo per scontato. Il Core Rule Set riconosce schemi di attacco generali e non è tagliato su una vulnerabilità specifica. Cloudflare fa inoltre notare che per PHP2Shell le regole basate solo sui dati della richiesta non bastano. L'aggiornamento di PHP resta obbligatorio. **Quale motore devo scegliere per Nginx?** Secondo il progetto CRS, con ModSecurity v3 solo il connettore Nginx è davvero utilizzabile in produzione, e la v3 non supera una piccola parte dei test CRS. In alternativa c'è Coraza, che secondo il progetto supera per intero la suite di test CRS v4. Per Apache il progetto raccomanda ModSecurity v2. **ModSecurity è ancora mantenuto?** Secondo la documentazione CRS, Trustwave aveva annunciato la fine dello sviluppo nel 2024. Il 25 gennaio 2024 il progetto è stato ceduto alla OWASP Foundation e da allora vi prosegue. **Come evito che la WAF paralizzi il mio shop?** Parta con soglie di anomalia molto alte, come raccomanda il progetto CRS, e le abbassi gradualmente. Analizzi nel frattempo i registri e crei eccezioni mirate per la Sua applicazione, invece di disattivare le regole in blocco. ## Fonti - [OWASP CRS: documentazione](https://coreruleset.org/) - [OWASP Top 10](https://owasp.org/www-project-top-ten/) - [Blog di Cloudflare](https://blog.cloudflare.com/) - [php.net: avvisi di sicurezza](https://www.php.net/)