ModSecurity | NEXT chapters | |||||||||||||||||||||||||
Questa guida può interessare tutti coloro che abbiano un sito web ospitato su un server web Apache e che abbiano installato il modulo ModSecurity, un firewall open source e gratuito per il server web Apache.
ModSecurity offre una protezione da una varietà di attacchi sferrati contro le applicazioni web, permette il monitoraggio e l'analisi, in tempo reale, del traffico HTTP, senza richiedere cambiamenti consistenti all'infrastruttura esistente. I server web, normalmente, sono ben forniti di strumenti di analisi del traffico web, utilizzati come veri e propri strumenti di marketing, ma, spesso, non sono in grado di registrare il traffico destinato alle applicazioni web. In particolare, molti server non hanno strumenti per catturare i messaggi di richiesta ( header e body ), inviati alle applicazioni residenti. I vostri avversari sanno tutto questo. Ecco perchè, oggi, molti attacchi vengono sferrati attraverso le richieste HTTP POST, rendendo i sistemi ciechi di fronte ad essi. ModSecurity può, invece, intercettare tutte le transazioni HTTP, permettendo di registrare tutte le richieste inviate al server e tutte le risposte spedite dal server. Inoltre, ModSecurity è in grado di monitorare, in tempo reale, il traffico HTTP e di identificare eventuali attacchi, proprio come un web "intrusion detection tool". Affinchè ModSecurity possa fare tutto questo, però, è necessario che qualcuno, l'amministratore del server, scriva una serie di regole che dicano a ModSecurity cosa analizzare ( per esempio, le richieste POST e GET ), cosa cercare ( per esempio: l'header HTTP
Questo è un tipico messaggio di errore di ModSecurity, che ha, in qualche modo, interrotto una transazione HTTP ( Access denied ), perchè l'applicazione
alla riga 52. Leggere questa direttiva, quindi, potrà aiutarvi a correggere l'errore presente nel vostro programma
Le direttive e le regole standard di ModSecurity vengono salvate in uno o più file di configurazione. Esse evolvono costantemente, con lo sviluppo stesso di ModSecurity. Per esempio, se sul vostro server è installata la release Core ModSecurity Rule Set ver.1.5, i file di configurazione sono i seguenti:
modsecurity_crs_10_config.conf Se, invece, sul vostro server è installata la release ModSecurity Core Rule Set, Version 2.2.3, i file di configurazione li trovate in questa pagina, dove dovreste sempre trovare la versione più recente. Per capire come scrivere nuove regole per ModSecurity, è importante capire cosa facciano e quale sintassi utilizzino le regole standard. Trattandosi di un argomento molto vasto, il percorso più semplice e lineare credo che sia quello di leggere ciascun file di configurazione e comprenderne la struttura. Nei file di configurazione, spesso troverete delle direttive commentate:
che, quindi, non vengono lette ed eseguite. Siete voi che dovrete decidere se è il caso di renderle effettive, tenendo a mente due suggerimenti essenziali: verificate se davvero avete compreso quale effetto, quella regola o direttiva, avrà durante l'esecuzione dei programmi installati sul vostro server ( soprattutto, cercate di evitare che un eccesso di zelo comporti il respingimento di richieste legittime ); ricordate che l'implementazione dei diversi livelli di sicurezza sul vostro server comporta un fabbisogno sempre maggiore di risorse, quali la RAM e la CPU. Ma, in quale ordine vengono caricati i file di configurazione, da parte del server Apache? L'ordine viene stabilito dalla direttiva Apache
oppure specificare i singoli file da caricare in memoria:
Se viene specificato un gruppo di file, come nel primo esempio, i file saranno caricati in ordine alfabetico. ModSecurity viene eseguito come modulo del server Apache. Per tutte le transazioni HTTP in arrivo, Apache riceve lo stream di dati ( se si tratta di una transazione criptata SSL, esegue la decriptazione dei dati ), lo fraziona in header HTTP ( HTTP request ), esegue una prima analisi degli header HTTP ( per esempio, combinando quegli header che utilizzano lo stesso nome ), invoca ModSecurity, ricompone, se necessario, il BODY del messaggio della richiesta HTTP.
Se Apache identifica una richiesta HTTP non valida, la respinge immediatamente, senza invocare ModSecurity. Per quanto riguarda la risposta HTTP, occorre ricordare che gli header
In questo file, troviamo una serie di direttive generali di configurazione, che influenzano il comportamento di ModSecurity.
La direttiva
La direttiva
Con ModSecurity 2.5, a quest'ultima direttiva viene data la precedenza solo nel caso in cui la richiesta HTTP stia tentando di inviare un file:
L'upload dei file, infatti, non prevede l'utilizzo della RAM: in questo caso, è possibile accettare una maggiore quantità di dati. Per tutti gli altri casi, è disponibile la direttiva:
Visto che l'utilizzo della RAM velocizza il processo, è possibile anche prevedere un limite massimo entro il quale anche l'upload di un file possa utilizzare la RAM:
In conformità al comportamento di Apache, nel caso in cui il BODY della richiesta superasse i limiti previsti, ModSecurity respingerebbe la richiesta con un codice di stato 413 ( Request Entity Too Large ).
La direttiva
La direttiva
La direttiva
Nel secondo caso, ModSecurity limiterebbe l'analisi del BODY ai soli byte disponibili nel buffer, lasciando passare tutto il resto. Se questo comportamento può sembrare pericoloso, è sufficiente ricordare le osservazioni di Ivan Ristic ( l'autore di ModSecurity ), nel suo libro "ModSecurity Handbook": "per un intruso che avesse il controllo dell'output, potrebbe risultare semplice creare una risposta, la cui lunghezza eccessiva impedirebbe a ModSecurity di intercettarla. Questo è vero. Tuttavia, quale affidabilità potrebbe avere un monitoraggio, di qualsiasi tipo, in un sistema in cui un intruso avesse il pieno controllo dell'output?".
La direttiva
La direttiva
La direttiva
La sezione seguente di questo file si occupa della scrittura su file log delle attività svolte da ModSecurity ( audit ). ModSecurity è, potenzialmente, in grado di registrare ogni transazione HTTP. E' possibile impostare l'attività di audit, e la sua frequenza, utilizzando la direttiva
Di default, troverete impostata questa ultima opzione, che dice a ModSecurity di registrare solo le transazioni che considera rilevanti. Il livello di rilevanza viene impostato nella direttiva immediatamente successiva:
In questo caso, ModSecurity eseguirà la registrazione di tutte quelle transazioni che genereranno un codice di stato il cui numero inizi per 4 o per 5. Infatti, l'espressione alla destra della direttiva altro non è che una espressione regolare ( REGEX ), in cui il carattere
che richiede immediatamente la definizione del nome e del percorso del file nel quale scrivere gli eventi:
Nel caso desideraste modificare questa impostazione, per avere una registrazione degli eventi di tipo concorrente, modificate il valore della direttiva
A questo punto, non ci resta che impostare le parti della transazione che vogliamo vengano registrate:
Ciascuna lettera riportata nella parte destra di questa direttiva corrisponde ad una parte della transazione.
Completata la configurazione dell'attività di audit di ModSecurity, il file di configurazione
La direttiva
La direttiva
Per questa direttiva
La direttiva
Il livello massimo consigliato è, normalmente, il 3.
La direttiva
La direttiva
Questa è l'ultima direttiva contenuta nel file
Una regola utilizza un operatore ( OPERATOR, nel nostro caso: "
occorre avere un po' di dimestichezza con le espressioni regolari PCRE. L'operatore REGEX ( espressioni regolari o regular expression ) prende un modello ( pattern ), composto da una sequenza di caratteri, e lo cerca all'interno di un testo di riferimento. Nel nostro caso, il testo di riferimento è la variabile
Ma in questa sequenza, o "pattern", sono presenti anche un certo numero di operatori che indicano al motore di espressioni regolari non solo cosa cercare, ma dove cercarlo e come. Il primo carattere che troviamo nel pattern (
La barra verticale, o pipe, indica un operatore OR. Quindi, l'intera espressione è da interpretare come: trova la sequenza:
oppure la sequenza:
Come abbiamo già visto, parlando della direttiva
rappresenta un solo carattere, che dovrà essere 1 oppure 2. Allo stesso modo, l'espressione:
rappresenta un solo carattere, che dovrà essere 4 oppure 5. La sequenza
A questo punto, dovrebbe essere chiaro l'intento dell'ultima direttiva contenuta nel file di configurazione
|
| |||||||||||||||||||||||||
ModSecurity | The .bit guides: original contents |