ModSecurity Series 3 - SecRuleEngine

   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!