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:
1 2 | apt-getinstall libxml2 libxml2-dev libxml2-utils apt-getinstall libaprutil1 libaprutil1-dev |
e passiamo all’installazione di mod-security:
1 | apt-getinstall libapache-mod-security |
Ora attiviamo il modulo headers, necessario al corretto funzionamento di mod-security:
1 | a2enmod headers |
e poi attiviamo mod-security:
1 | a2enmod 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:
1 2 | cd/etc/modsecurity cpmodsecurity.conf-recommended modsecurity.conf |
e poi modifichiamo il file modsecurity.conf modificando la direttiva:
1 | SecRuleEngine DetectionOnly |
in
1 | SecRuleEngine On |
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:
1 | ln-s/usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf/etc/modsecurity/modsecurity_crs_10_setup.conf |
ed avviamo il servizio:
1 | service apache2 restart |
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:
1 | http://www.il_sito.ext/?test=MY_UNIQUE_TEST_STRING |
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:
1 2 3 4 | cd/usr/share/modsecurity-crs/base_rules forfin*;doln-s/usr/share/modsecurity-crs/base_rules/$f/etc/modsecurity/$f;done cd/usr/share/modsecurity-crs/optional_rules forfin*;doln-s/usr/share/modsecurity-crs/optional_rules/$f/etc/modsecurity/$f;done |
e poi riavviare il servizio:
1 | service apache2 restart |
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!
Ti interessa acquistare un dominio a prezzi ultraconvenienti? clicca qui
Se hai trovato utili le informazioni su questo blog,
Fai una donazione!
Clicca sul bottone qui sotto o almeno clicca sul banner pubblicitario 🙂
Commenta