ModSecurity: CRS 20, protocol violations, parte 2 | OTHER chapters | |||
Nella prima parte dell'analisi di questo file di configurazione, abbiamo visto la prima direttiva SecRule 981227 - WEBSERVER_ERROR_LOG
Anche in questo caso, abbiamo una direttiva
Visto che la struttura di questa seconda regola, le azioni e le variabili in essa contenute sono, in molti casi, le stesse viste nella prima regola, visto che il nostro obiettivo è comprendere il meccanismo di ModSecurity, vedremo, in dettaglio, solo gli elementi che incontreremo per la prima volta. Intanto, troviamo la variabile su cui questa regola opera:
Com'è facilmente intuibile, questa variabile contiene le righe dell'error_log di Apache, eventualmente generate nel corso della transazione corrente. Questa variabile, quindi, potrebbe essere vuota ( nel caso il server Apache non avesse riscontrato alcun errore ), oppure contenere uno o più messaggi di errore. In questa regola, troviamo anche un nuovo operatore:
che ha il compito di cercare, all'interno della stringa di riferimento, o delle stringhe di riferimento, se WEBSERVER_ERROR_LOG ne contenesse più di una, il testo esatto che gli viene passato come argomento:
Non dobbiamo dimenticare la stretta correlazione esistente tra il lavoro svolto da Apache e quello svolto da ModSecurity. Apache è un server web ed è perfettamente in grado di riconoscere una URL ( o URI ) malformata e potrebbe avere già prodotto un suo messaggio di errore, ancor prima della fase 1 di ModSecurity ( analisi dei Request Header ). Il compito esclusivo di ModSecurity è cercare eventuali anomalie che, pur non rappresentando veri e propri errori, possono rivelare un tentativo di attuare una qualche azione illecita sul server. L'operatore
per tentare di intercettare la transazione e potere, quanto meno, registrare l'evento. La registrazione di un evento è la sola fase che verrà sempre percorsa da ModSecurity:
La regola, poi, esegue le azioni che impostano l'ID della regola e il messaggio di errore restituito dalla regola:
per poi impostare alcune TAG ed inizializzare o aggiornare alcune variabili ( le stesse viste nella regola precedente ). Due parole sull'operatore. Gli operatori, tutti, vengono identificati dal carattere
Nella regola precedente, non avevamo trovato alcun operatore. Quando ModSecurity non trova un operatore, seleziona l'operatore di default, che altro non è che il motore delle espressioni regolari. L'operatore delle espressioni regolari è:
Quindi, le due espressioni seguenti sono equivalenti:
Anche le tre espressioni seguenti sono equivalenti:
con una fondamentale differenza: l'operatore
|
||||
ModSecurity: CRS 20, protocol violations, parte 2 | The .bit guides: original contents |