Instalei o mod_security e atualmente estou executando no DetectionOnly
modo enquanto monitoro os logs e configuro para atender às necessidades dos meus servidores.
Eu configurei-o para pontuação de anomalias e ajustei minhas pontuações de acordo para reduzir falsos positivos.
No Apache2 error_log
estou recebendo eventos de log assim:
[Fri May 01 14:48:48 2015] [error] [client 81.138.5.14] ModSecurity: Warning. Operator LT matched 20 at TX:inbound_anomaly_score. [file "/etc/apache2/modsecurity-crs/activated_rules/modsecurity_crs_60_correlation.conf"] [line "33"] [id "981203"] [msg "Inbound Anomaly Score (Total Inbound Score: 13, SQLi=11, XSS=): Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded"] [hostname "www.domain.co.uk"] [uri "/wp-admin/admin-ajax.php"] [unique_id "VUOEQNRurOYAABA-HZEAAAAA"]
Esses eventos não excedem minha pontuação de anomalia de entrada configurada, que atualmente está definida como 20. Posso registrar esses tipos de eventos cerca de 25 vezes em um único carregamento de página, sobrecarregando meu Apache2 error_log
.
Existe alguma maneira de limitar o que é enviado error_log
para que apenas anomalias que excedam meu limite sejam registradas?
O objectivo
Estou tentando alcançar duas coisas aqui. Quero mantê-lo o error_log
mais limpo possível para que não inche e ocupe espaço excessivo.
Também quero poder revisar e monitorar esses logs para continuar minha configuração contínua do mod_security. O ideal seria mostrar apenas eventos que ultrapassaram o limite de anomalia, para que eu possa ver se são falsos positivos ou não.
Obrigado.
Responder1
A regra é a seguinte:
SecRule TX:INBOUND_ANOMALY_SCORE "@gt 0" \
"chain,phase:5,id:'981203',t:none,log,noauditlog,pass,skipAfter:END_CORRELATION,msg:'Inbound Anomaly Score (Total Inbound Score: %{TX.INBOUND_ANOMALY_SCORE}, SQLi=%{TX.SQL_INJECTION_SCORE}, XSS=%{TX.XSS_SCORE}): %{tx.inbound_tx_msg}'"
SecRule TX:INBOUND_ANOMALY_SCORE "@lt %{tx.inbound_anomaly_score_level}"
que basicamente diz que se a pontuação estiver acima de 0, mas abaixo de tx.inbound_anomaly_score_level, registre-a. Presumivelmente, para que você possa revisar as regras que foram acionadas, mas não o suficiente para serem bloqueadas.
Se esta regra não for muito útil para você, talvez seja melhor removê-la completamente para não perder tempo testando se deve executá-la ou não:
SecRuleRemoveById 981203
Observe que isso deve ser especificado APÓS a definição da regra.
Remover regras dessa maneira geralmente é melhor do que editar os arquivos CRS para facilitar atualizações futuras.