Nesse post irei falar um pouco sobre o parâmetro
SecRuleEngine:
Esse parâmetro, definido no arquivo
modsecurity.conf (copiado de
modsecurity.conf-recommended do código fonte do ModSecurity), define se as regras estão ativadas, desativadas, ou atuando no modo de somente detecção. Conforme a
Wiki do ModSecurity:
SecRuleEngine
Descrição: Configura o mecanismo das regras.
Sintaxe:
SecRuleEngine On|Off|DetectionOnly
Exemplo de uso: SecRuleEngine On
Escopo: Qualquer
Versão: 2.0.0
Padrão: Off
Os valores possíveis são:
On: processa as regras
Off: não processa as regras
DetectionOnly: processa as regras mas nunca executa nenhuma ação de bloqueio (block, deny, drop, allow, proxy and redirect)
No modsecurity.conf-recommended incluído no código fonte do ModSecurity e normalmente utilizado como base, esse parâmetro vem como
DetectionOnly por padrão.
Um exemplo simples e prático: no post anterior,
Instalando o ModSecurity 2.6.7 + CRS 2.2.5 no Debian Wheezy, o ModSecurity está instalado no Apache, mas como não foi alterada a sua configuração, o parâmetro
SecRuleEngine está configurado como somente como deteção e não realizará nenhum tipo de bloqueio.
- Vamos criar um arquivo chamado test.cfg e publicar ele no Apache previamente instalado com o ModSecurity:
echo "TEST" > /var/www/test.cfg
- Acesse em um browser esse arquivo, e você poderá visualizar o seu conteúdo:
Isso não é bom, se você tiver alguma informação confidencial como credenciais de acesso ao banco de dados dentro desse arquivo, por exemplo...
Apesar de não ter sido bloqueado o acesso, o ModSecurity estava configurado no modo de detecção e registrou um
alerta (
warning) no log de erros do Apache:
[Fri Aug 10 13:24:19 2012] [error] [client X.X.X.X] ModSecurity:
Warning. String match within ".asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/
.cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .resources/ .resx/ .sql/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/" at TX:extension. [file "/etc/apache2/modsecurity/crs/activated_rules/modsecurity_crs_30_http_policy.conf"] [line "88"] [id "960035"] [msg "
URL file extension is restricted by policy"]
[data ".cfg"] [severity "CRITICAL"] [tag "POLICY/EXT_RESTRICTED"] [tag "WASCTC/WASC-15"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "test.domain.com"] [uri "/test.cfg"] [unique_id "UCU1s38AAQEAAFLrARoAAABA"]
Interpretando o log de erro acima, a regra com o ID 960035, que está na linha 88 do arquivo /etc/apache2/modsecurity/crs/activated_rules/modsecurity_crs_30_http_policy.conf, identificou que um arquivo com uma extensão não permitida foi acessado. Abaixo a regra que deu match:
SecRule REQUEST_BASENAME "\.(.*)$" "chain,capture,setvar:tx.extension=.%{tx.1}/,phase:2,t:none,t:urlDecodeUni,t:lowercase,block,msg:'URL file extension is restricted by policy', severity:'2',id:'960035',tag:'POLICY/EXT_RESTRICTED',tag:'WASCTC/WASC-15',tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',logdata:'%{TX.0}'"
SecRule
TX:EXTENSION "@within %{tx.restricted_extensions}" "t:none,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.policy_score=+%{tx.warning_anomaly_score},setvar:tx.%{rule.id}-POLICY/EXT_RESTRICTED-%{matched_var_name}=%{matched_var}"
Na verdade, se você for ver a regra 960035, verá que as extensões bloqueadas estão definidas na variável "
tx.restricted_extensions", que está definido no arquivo
modsecurity_crs_10_setup.conf da CRS. Caso desejar adicionar ou remover alguma extensão bloqueada, é nessa variável que isso deve ser feito, e não na regra.
A Core Rule Set também traz bastante documentação sobre cada regra, como a utilizada nesse exemplo: ela aponta para referências à:
-
WASCTC/WASC-15: Application Misconfiguration
-
OWASP_TOP_10/A7: Insecure Cryptographic Storage
-
PCI/6.5.10: Insecure configuration management
Ok, então agora vamos então bloquear esse tipo de evento.Habilite o modo de bloqueio no ModSecurity:
SecRuleEngine On
Reinicie o Apache, e agora tente acessar o mesmo arquivo através do browser:
Mesmo o arquivo existindo no servidor web, o bloqueio foi realizado. O log do Apache registra o bloqueio:
Fri Aug 10 13:43:30 2012] [error] [client X.X.X.X] ModSecurity:
Access denied with code 403 (phase 2). String match within ".asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/
.cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .resources/ .resx/ .sql/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/" at TX:extension. [file "/etc/apache2/modsecurity/crs/activated_rules/modsecurity_crs_30_http_policy.conf"] [line "88"] [id "960035"] [msg "URL file extension is restricted by policy"]
[data ".cfg"] [severity "CRITICAL"] [tag "POLICY/EXT_RESTRICTED"] [tag "WASCTC/WASC-15"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "test.domain.com"] [uri "/test.cfg"] [unique_id "UCU6Mn8AAQEAAFSeASsAAAAA"]
Esse é um exemplo de uma regra simples, mas é fácil de entender como funciona e como interpretar esses logs, o que dará base para interpretar posteriormente regras mais complexas. Até o próximo post!
Postagens
