Este documento fornece um resumo sobre o ModSecurity, um firewall de aplicação web (WAF) open source. Ele discute como o ModSecurity funciona, como ele é implantado e como ele analisa solicitações e respostas para detectar ataques. O documento também aborda o conjunto de regras principais do ModSecurity e ferramentas como o WAF-FLE para visualização de logs.

1. ModSecurity: Firewall
OpenSource para Aplicações
Web (WAF)
Klaubert Herr da Silveira
klaubert @gmail.com
OWASP
08/2012
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org

2. Agenda
1. Firewall de Aplicação Web (WAF);
2. ModSecurity;
3. Console do ModSecurity;
4. Implantação do ModSecurity;
OWASP

3. Klaubert Herr
• Consultor em segurança da informação a 13
anos;
• Tópicos atuais:
– (D)DoS
– WAF
• Atuação com ferramentas open source e
comerciais;
• Desenvolvedor do WAF-FLE, console para o
ModSecurity
• http://waf-fle.org
• http://klaubert.wordpress.com
OWASP

4. Firewall de Aplicação Web - WAF
OWASP

5. Firewall de Aplicação Web - WAF
• Firewall (camada 7) especializado em
aplicações Web;
• Conhece os protocolos da Web: HTTP/S
(Header, Cookies), HTML (POST, GET,
Upload), XML, SOAP, entre outros;
• Efetivo mesmo com criptografia (SSL);
• Ciente de sessão;
• Implementados como software ou appliance;
• Detecta e Bloqueia ataques;
OWASP

6. Elementos de segurança para Web
Firewall IPS WAF
Controle de acesso Sim Algum Sim
Detecção de protocolo HTTP Algum Sim Sim
Bloqueio de DoS (sob HTTP) Algum Algum Algum
Identificação/Bloqueio de ataques Web
Não Algum Sim
(XSS, SQLi, CSRF etc)
Ciente de autenticação formulário
Não Não Sim
e sessão HTTP (cookies)
Suporte a tráfego criptografado (SSL) Não Não Sim
Monitoração de erros do servidor web Não Não Sim
Transcrição das sessões http(s) Não Algum Sim
Interceptação de vazamento (ex. Erro) /
Não Algum Sim
reescrita da resposta
OWASP

7. Por que usar um WAF?
• Segurança
• Ponto único de controle
• Gerenciado pela equipe de segurança
• Múltiplas camadas de segurança
• Ativado continuamente
• Sites web: foco de ataques direto ou vetor de ataque;
• Virtual patching
• Bloqueio de ataques conhecidos;
• Controle de mensagens de erro;
• Controle customizável, por URL;
• Monitoração e Logs de ataques e de erros;
OWASP

8. Por que usar um WAF?
• Compliance/Auditoria
• PCI DSS 1.2+ – requisito 6.6;
• <Coloque a sua aqui>
OWASP

9. PCI DSS 1.2
6.6 Verifique se um firewall de aplicativos da Web está
implementado diante dos aplicativos da Web voltados
ao público para detectar e impedir ataques baseados
na Web.
OWASP

10. Lembre-se
Um Firewall de Aplicação Web (WAF) é uma
importante camada de segurança, mas não é
garantia de segurança para as aplicações.
1. Design seguro;
2. Codificação segura;
3. Revisão do código;
4. Análise de vulnerabilidade;
5. Firewall de aplicação Web;
OWASP

11. WAF e o desenvolvedor web
• Permite ao desenvolvedor ver o erro da
aplicação como o usuário recebeu;
• Facilita a detecção de erros na aplicação;
• Permite a criação de correções emergenciais;
• Facilita a interação com a equipe de
segurança;
OWASP

12. ModSecurity
OWASP

13. ModSecurity
 Firewall Open Source para Aplicações Web
 Módulo para Apache (*nix ou Windows);
 Novos módulos para: IIS e Nginx;
 Muito flexível;
 Conjunto de regras Core Rule Set, um projeto
OWASP desde de Agosto/09;
 Criado por Ivan Ristic;
 Hoje da Trustwave, mantido pelo Breno Silva;
 Licenciamento: Apache License 2.0;
OWASP

14. Características do ModSecurity
• Módulo para Apache
– Embutido;
– Proxy Reverso;
• Modos: detecção ou bloqueio;
• Inspeciona o cabeçalho e corpo da requisição;
• Inspeciona o cabeçalho e corpo da resposta;
• Definição de regras bastante completa/
complexa;
OWASP

15. Características do ModSecurity (cont.)
• Normalização, decodificação;
• Base64
• compressWhitespace;
• htmlEntityDecode;
• removeCommentsChar;
• RBL (Reputação) e GeoIP;
• Extensível: execução de scripts LUA
internamente ou scripts externos;
• Log completo do tráfego (incluindo POST);
OWASP

16. Características do ModSecurity (cont.)
• Pode inspecionar uploads (anti-vírus);
• Alterar a resposta (Append/Prepend/ Replace);
• Ataques podem ser bloqueados, redirecionados,
logados etc;
• Dados persistentes usados entre requisições
diferentes:
• IP;
• Sessão;
• Username;
• Resource;
• Global;
OWASP

17. Características recentes
• Metadado para regras: ver, maturity, accuracy;
• Sanitização de SSN, CC, CPF -> evitar
vazamento;
• Desativação de compressão com o backend;
• SecEncryption*: cria um token criptografado de
href/frame src/iframe scr/form action; (2.7RC)
OWASP

18. Implantando o ModSecurity
 Modo Embutido (local);
 Baseado em rede (proxy reverso);
OWASP

19. Implantando o ModSecurity:
Modo Embutido (Local)
• Apache (IIS e Nginx a caminho);
• Instalado no próprio servidor web;
• Sem mudança na topologia de rede;
• Escalabilidade herdada do servidor web;
• Algum impacto em performance pode ocorrer;
• Gerencia de segurança e do servidor web
compartilhada;
OWASP

20. Implantando o ModSecurity:
Baseado em rede (proxy reverso);
• Apache como Proxy Reverso (breve Nginx);
• Qualquer servidor web pode ser um
backend;
• Pode abranger vários servidores;
• Vira o front-end para o(s) site(s), alterando a
topologia da rede;
• Alta-disponibilidade e/ou escalabilidade
própria;
• Separa o gerenciamento de segurança do
gerenciamento do servidor web;
OWASP

21. ModSecurity: Modelos de segurança
• Modelo Positivo
• Modelo Negativo
• Modelo Híbrido
OWASP

22. Modelo Positivo
• As regras definem o que pode ser requisitado e
respondido;
• As regras precisam ser definidas para cada aplicação,
para cada URI ou conjunto de URI’s;
• Alterações na aplicação precisam refletir na política do
WAF(!);
• Quanto mais complexa a aplicação, mas complexo
será definir a política
• Campos muito abrangentes (livres) terão uma política
frágil;
• As demais requisições são bloqueadas;
• Ferramentas: Remo e mod_profiler (abandonadas)
OWASP

23. Modelo Negativo
– Conjuntos genérico de regras, ex. XSS, SQL Injection,
fora dos padrões etc;
– Exceções precisam ser tratadas pontualmente;
– As demais requisições são permitidas;
– Atualizações nas regras precisam ser novamente
validadas no tráfego real;
OWASP

24. Modelo Híbrido
• Usa o definido no modelo positivo;
... se passar...
• Aplica as regras negativas para bloquear
ataques genéricos;
OWASP

25. Virtual Patching
• Definição de regras para impedir a exploração
de uma vulnerabilidade conhecida, sem
alteração da aplicação;
• Reduz o tempo de exposição;
• Permite “corrigir” falhas de segurança em
aplicações escritas por terceiros;
• Não deve ser considerado como a “solução”
para correção de vulnerabilidade;
OWASP

26. ModSecurity Core Rule Set (CRS)
• 2319 regras (08/2012);
• Regras próprias;
• Conversão de outras assinaturas:
PHPIDS, Emerging Threats,
• Testes com tráfego real;
• Detecção genérica de ataques:
– Melhor performance;
– Menos updates;
• Plug and play:
– Ok, leia o README primeiro... 
– Ajustes poderão ser necessários;
OWASP

27. ModSecurity Core Rule Set (CRS)
Modo de Operação
– Self-Contained
– Caso ocorra o match de uma requisição com
uma regra a ação de regra é executada;
– Collaborative Detection
– A cada match de regra um score é
incrementado
– Pontuação de acordo com a criticidade;
– Pontuação específica para tipos de ataque;
– Ao final da avaliação das regras, é verificada a
pontuação, podendo: permitir ou bloquear;
• Maior segurança no bloqueio;
OWASP

28. ModSecurity Core Rule Set (CRS)
Categorias
• Conformidade de protocolos:
– Validação de requisições HTTP (RFC);
– Anomalias do protocolo HTTP;
– Restrições globais;
– Política de uso;
• Detecção de ataques:
– Mitigação de Slow DoS;
– XSS, SQLi, Buffer Overflow, etc;
– Detecção de Trojans e Backdoors;
• Outras:
– Detecção de erros;
– Proteção de XML; OWASP

29. Como o Modsecurity atua
• Fases de Processamento
1.Request headers;
2.Request body;
3.Response headers;
4.Response body;
5.Logging;
OWASP

30. Fases de Processamento
OWASP

31. Fases de Processamento
1. Request headers;
2. /teste2.php?%3Cscript%3Ealert(%22xss%22)%3C/script%3E
GET Request body;
HTTP/1.0
3. Response headers;
Host: waf-fle.org
Connection: close
4. Response body;
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1
5. Logging; Chrome/21.0.1180.60 Safari/537.1
(KHTML, like Gecko)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: PHPSESSIONID=JFNDECOIPLMDODKEDBAFPC
1.REQUEST_COOKIES 1.QUERY_STRING
2.REQUEST_FILENAME 2.REQUEST_PROTOCOL
3.REQUEST_HEADERS 3.REQUEST_METHOD
OWASP

32. Fases de Processamento
2. Request body (POST, PUT);
count=1&req0_type=i&req0_time=754341' OR 'x'='x
• SecRequestBodyAccess ->On;
• application/x-www-form-urlencoded – Dados de formulários
• multipart/form-data – Ttransferência de arquivos
• text/xml – Dados em XML
1.REQUEST_BODY
2.ARGS (ARGS_POST, ARGS_COMBINED_SIZE)
3.FILES_TMPNAMES (@inspectFile)
OWASP

33. Fases de Processamento
3. Response headers;
HTTP/1.1 403 Forbidden
Accept-Ranges: bytes
Connection: close
Content-Type: text/html; charset=iso-8859-1
text/html
Content-Language: pt-br
Expires: Wed, 22 Aug 2012 23:19:52 GMT
1.RESPONSE_HEADERS
2.RESPONSE_STATUS
3.RESPONSE_CONTENT_LENGTH
4.RESPONSE_CONTENT_TYPE
OWASP

34. Fases de Processamento
4. Response body;
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>
Test App
</title>
<link rel="search" href="/app" />
<link rel="help" href="/app" />
<link rel="alternate" href="/app" title="Plain Text" />
...
</body>
</html>
1.RESPONSE_BODY
2.rsub
OWASP

35. Fases de Processamento
5. Logging
Message: Pattern match "< ?scriptb" at
ARGS_NAMES:<script>alert("xss")</script>. [file
"/etc/mod_security/modsecurity_crs_41_xss_attacks.conf"] [id "958051"] [rev
"2.1.1"] [msg "Cross-site Scripting (XSS) Attack"] [data "<script"] [severity
"CRITICAL"] [tag "WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag
"WASCTC/WASC-22"] [tag "OWASP_TOP_10/A2"] [tag "OWASP_AppSensor/IE1"]
[tag "PCI/6.5.1"]
Message: Warning. Operator GE matched 19 at TX:inbound_anomaly_score. [file
"/etc/mod_security/modsecurity_crs_60_correlation.conf"] [msg "Inbound Anomaly
Score Exceeded (Total Inbound Score: 48, SQLi=, XSS=48): IE XSS Filters - Attack
XSS=48
Detected"]
Action: Intercepted (phase 2)
...
Producer: ModSecurity for Apache/2.6.2 ...; core ruleset/2.1.1.
Server: Apache
OWASP

36. Logs
• Logs detalhados dos eventos;
• Muito log se...
• Muitas aplicações
• Múltiplos servidores (1,2,4 … 1.000 ...)
• DoS
• Robôs
• Falsos positivos
• Opções para visualização dos logs
• Grep • Splunk for modSecurity
• WAF-FLE • SIEM’s
• AuditConsole OWASP

37. WAF∙FLE
• Console centralizadora de logs para modsecurity
• http://waf-fle.org;
• Disponível na Versão 0.5 -> Breve 0.6
• Suporta regras nos modos “Self-Containend” e
“Collaborative Detection”;
• Recebe eventos em tempo real ou em batch,
com mlogc
• mlog2waffle na versão 0.6
• Sem limite de sensores
• PHP e Mysql DB
• Open Source: GPL v2
OWASP

38. WAF∙FLE
• Dashboard
• Eventos ao longo do dia
• Top Sources
• Top Sensors
• Top Severity
• Top Rules
• Top Targets
• Status http
• Top countries (0.6)
• Top ASN’s (0.6)
• Path (0.6)
OWASP

39. WAF∙FLE
• Filtros Drill-Down
• Cada campo deve ser uma pesquisa
• Invertidos (not)
• A partir do dashboard (atualizando o dashboard,
0.6);
• Por faixa de rede
• Por score
• Por regra
• Path
• Hostname
• etc
OWASP

40. Falso positivos
• Regras que são disparadas indevidamente, o
evento é identificado como um ataque;
• Podem ser muito ruidosos no início de uma
implantação;
• Devem ser analisados, e as regras ajustadas
para eliminá-los;
OWASP

41. Ajuste fino das regras
• Desabilitar regras;
SecRuleRemoveById 950009
SecRuleRemoveById 950009
• Desabilitar regras para <Location...>
específicos
<Location /path/to/foo.php>
<Location /path/to/foo.php>
SecRuleRemoveById 950009
SecRuleRemoveById 950009
</Location>
</Location>
• Ajustar partes de uma regra:
– Cookies; - Headers;
– POST; - Response Body;
OWASP

42. Ajuste fino das regras
• Alterando as regras pelo ID
SecRuleUpdateTargetById 981260 !REQUEST_COOKIES:UserPref
SecRuleUpdateTargetById 981260 !REQUEST_COOKIES:UserPref
SecRule REQUEST_URI “@streq /mail/” “phase:1,t:none,
SecRule REQUEST_URI “@streq /mail/” “phase:1,t:none,
nolog,pass,ctl:ruleUpdateTargetById=950901;
nolog,pass,ctl:ruleUpdateTargetById=950901;
!REQUEST_COOKIES:/^UserPref/”
!REQUEST_COOKIES:/^UserPref/”
• Alterar/Corrigir a aplicação;
OWASP

43. Performance
• Inspecionar as respostas pode afetar a
performance (SecResponseBodyAccess);
• Inspecione somente as requisições relevantes
(ex. conteúdo dinâmico, html, xml, json);
• Não inspecione conteúdo estático;
• A quantidade de regras influencia a
performance:
• Desative regras desnecessárias;
• Habilite o mod_cache;
• Coloque um cache na frente (Nginx/Varnish);
OWASP

44. Customização
• Crie suas próprias regras;
• Modifique as regras existentes;
• Intercepte e customize as páginas de erro;
• Use a criatividade;
OWASP

45. Cuidados e fatores de sucesso na
implantação do ModSecurity
• Iniciar o uso no modo de monitoração:
SecRuleEngine DetectionOnly
SecRuleEngine DetectionOnly
• Ativar o bloqueio aplicação a aplicação;
• Tamanho das respostas;
SecResponseBodyLimit
SecResponseBodyLimit
• Deixar passar o que exceder;
SecResponseBodyLimitAction ==ProcessPartial
SecResponseBodyLimitAction ProcessPartial
• Elimine os falso positivos, eles podem ser
muito intensivos em:
– I/O
– Espaço em disco; OWASP

46. Palavas finais
• Explique aos demais envolvidos (gerentes,
desenvolvedores, gestores das aplicações,
service-desk) os benefícios e potenciais
problemas na adoção de um WAF;
• Monitore, refine as regras;
• Dedique tempo para ajustar seu WAF;
• Dê um passo de cada vez;
• Acrescente mais uma camada de segurança à
sua aplicação;
OWASP

47. Demonstração
OWASP

48. Perguntas
OWASP

49. Obrigado
Klaubert @gmail.com
OWASP