SMsoft – informatica e dintorni

Modsecurity su Debian 7 Wheezy

Non mi dilungo molto a spiegare cosa è ed a cosa server Modsecurity: un sistema che analizza le richieste al server web e tenta di bloccare richieste anomale che identifica con una serie di espressioni regolari.

Vediamo come installarlo (do per scontato che apache2 sia già stato installato).

Iniziamo con l’installazione di alcune librerie:

e passiamo all’installazione di mod-security:

Ora attiviamo il modulo headers, necessario al corretto funzionamento di mod-security:

e poi attiviamo mod-security:

Il file di configurazione principare è in /etc/apache2/mods-enabled/mod-security.conf e definisce la directory dei dati persistenti ed il path degli altri files di configurazione, ovvero i files .conf che si trovano in /etc/modsecurity/

Attiviamo il modulo. Iniziamo con:

e poi modifichiamo il file modsecurity.conf modificando la direttiva:

in

Questo evita che il modulo venga usato solo in modalità debug, utile per i primi giorni di test, ovvero se la direttiva è impostata a DetectionOnly effettuerà i controlli e scriverà nel file di log senza però bloccare le richieste.

Modifichiamo le direttive:

SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072

in

SecRequestBodyLimit 16384000
SecRequestBodyNoFilesLimit 16384000

Modifichiamo la direttiva:

SecRequestBodyInMemoryLimit 131072

in

SecRequestBodyInMemoryLimit 16384000

Modifichiamo le direttive:

SecPcreMatchLimit 1000
SecPcreMatchLimitRecursion 1000

in

SecPcreMatchLimit 150000
SecPcreMatchLimitRecursion 150000

inoltre decommentiamo le direttive per il logging:

SecDebugLog /opt/modsecurity/var/log/debug.log
SecDebugLogLevel 3

e poi verifichiamo che la direttiva che definisce cosa loggare sia impostata a:

SecAuditLogParts ABIJDEFHZ

tale direttiva potrà essere modificata dopo alcuni giorni, ovvero quando avrete verificato che uttto funziona correttamente, perché più informazioni vengono loggate e più carico dovrà sostenere il server…

Aggiungiamo infine al file di configurazione la seguente direttiva:

SecRule ARGS “MY_UNIQUE_TEST_STRING”\
“phase:1,log,deny,status:503”

che servirà a verificare che il modulo stia funzionando.

Attiviamo ora la prima regola di mod-security:

ed avviamo il servizio:

A questo punto possiamo richiamare la seguente pagina nel browser (relativa alla precedente direttiva di test inserita nel file id configurazione) per verificare che il modulo stia funzionando:

dove www.il_sito.ext è l’indirizzo del sito web.

A questo punto, mod-security sta funzionando e possiamo controllare quello che accade nel file si log /var/log/apache2/modsec_debug.log. E’ possibile attivare anche altre regole di filtraggio; mod-security ne propone molte e tante altre sono scritte da terze parti e possono essere utilizzate in base alle proprie esigenze. Per attivare le regole di base /usr/share/modsecurity-crs/base_rules e quelle opzionali /usr/share/modsecurity-crs/optional_rules, basta fare un link dalle relative cartelle verso /etc/modsecurity. Si può automatizzare il tutto con:

e poi riavviare il servizio:

Per finire, è possibile escludere alcune url per determinare regole di filtraggio. Ad esempio, se controllando il file di log /var/log/apache2/modsec_audit.log notate blocchi ad url particolari che volete evitare, basterà recuperare l’url e l’id della regola da disabilitare. Ipotizziamo che il messaggio di blocco sia:

Message: Warning. Pattern match “(?i:([\\s’\”\xc2\xb4\xe2\x80\x99\xe2\x80\x98\\(\\)]*)?([\\d\\w]+)([\\s'\"\xc2\xb4\xe2\x80\x99\xe2\x80\x98\\(\\)]*)?(?:=|<=>|r?like|sounds\\s+like|regexp)([\\s’\”\xc2\xb4\xe2\x80\x99\xe2\x80\x98\\(\\)]*)?\\2|([\\s'\"\xc2\xb4\xe2\x80\x99\xe2\x80\x98\ …” at REQUEST_COOKIES:__utmz. [file “/etc/modsecurity/modsecurity_crs_41_sql_injection_attacks.conf”] [line “77”] [id “950901”] [rev “2.2.5”] [msg “SQL Injection Attack”] [data “r=r”] [severity “CRITICAL”] [tag “WEB_ATTACK/SQL_INJECTION”] [tag “WASCTC/WASC-19”] [tag “OWASP_TOP_10/A1”] [tag “OWASP_AppSensor/CIE1”] [tag “PCI/6.5.2”]
Message: Warning. Operator GE matched 5 at TX:inbound_anomaly_score. [file “/etc/modsecurity/modsecurity_crs_60_correlation.conf”] [line “37”] [id “981204”] [msg “Inbound Anomaly Score Exceeded (Total Inbound Score: 15, SQLi=15, XSS=): SQL Injection Attack”]

gli id saranno 950901 e 981204.
A questo punto potremo creare un file in cui inseriremo le esclusioni, es /etc/modsecurity/whitelist.conf, in cui inseriremo:

< LocationMatch "/css.html" >
SecRuleRemoveById 950901 981204
< /LocationMatch >

enjoy!




Se hai trovato utili le informazioni su questo blog,
Fai una donazione!
Clicca sul bottone qui sotto o almeno clicca sul banner pubblicitario :-)
*
Taggato su: ,

Commenti

Page optimized by WP Minify WordPress Plugin