ModSecurity: Firewall OpenSource para A plicações W eb (WAF)

1. ModSecurity: Firewall OpenSource para Aplicações Web (WAF) Klaubert Herr da Silveira Consultor em segurança klaubert@gmail.com 30/10/2009

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

3. Firewall de Aplicação Web (WAF) • Firewall (camada 7) especializado em aplicações Web; • Conhecem 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; • Detecção e Bloqueio a ataques;

4. Elementos de segurança para Web

5. Por que usar um WAF? • Bloqueio de ataques conhecidos; • Sites web: foco de ataques direto e indireto; • Correções rápidas/emergenciais; • Controle de mensagens de erro; • Controle customizável, por URL; • Log de ataques e de erros; • Monitoração de segurança; • PCI DSS 1.2 – requisito 6.6;

6. 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.

7. Lembre-se • Um Firewall de Aplicação Web (WAF) é mais uma camada de segurança, ele não é garantia de segurança para as aplicações. • Design seguro; • Codificação segura; • Revisão do código; • Análise de vulnerabilidade; • Firewall de aplicação Web;

8. 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;

9. ModSecurity • Firewall Open Source para Aplicações Web • Módulo do Apache (*nix ou Windows); • Diversos (e crescentes) recursos; • Muito flexível; • Conjunto de regras (Core Rules: um projeto OWASP desde de Agosto/09); • Criado por Ivan Ristic, e agora pela Breach Security; • Licenciamento duplo: GPL e comercial;

10. Características do ModSecurity • Módulo para Apache • Embutido; • Proxy Reverso; • Modos: apenas detecção ou bloqueio; • Inspeciona o cabeçalho e corpo da requisição; • Inspeciona o cabeçalho e corpo da resposta; • Redução do vazamento de informação; • Definição de regras bastante completa/complexa, usando RegExp e Aho-Corasick;

11. Características do ModSecurity (cont.) • Controle com GeoIP e RBL; • Normalização, decodificação; • Extensível: execução de scripts LUA internamente ou scripts externos; • Log completo do tráfego (incluindo POST); • Pode inspecionar uploads (anti-vírus); • Alterar a resposta (Append/Prepend); • Validação de XML; • Ataques podem ser bloqueados, redirecionados, logados etc;

12. ModSecurity Core Rule Set (CRS) • 460 regras (09/2009); • Otimizadas para performance; • Testes com tráfego real para garantir qualidade; • Detecção genérica de ataques: • Melhor performance; • Menos updates; • Plug and play: • Alguns ajustes poderão ser necessários;

13. 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: • Detecção de ataques genéricos; • Detecção de Trojans e Backdoors; • Outras: • Detecção de erros; • Proteção de XML;

14. Fases de Processamento Request headers; Request body; Response headers; Response body; Logging;

15. Fases de Processamento Request headers; Request body; Response headers; Response body; Logging; POST/app/?id=123&pref=noneHTTP/1.1 Host: 192.168.249.128 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 GTB5 FirePHP/0.3 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Cookie: NID=27=OBP_7aEMkW_20_VG3kk4P Keep-Alive: 300 Connection: keep-alive • REQUEST_COOKIES • REQUEST_FILENAME • REQUEST_HEADERS • QUERY_STRING • REQUEST_PROTOCOL • REQUEST_METHOD

16. Fases de Processamento Requestbody; count=1&req0_type=i&req0_time=754341&req0_evtype=click&req0__sc=c • REQUEST_BODY • FILES_TMPNAMES (@inspectFile)

17. Fases de Processamento • Response headers; HTTP/1.1 200 OK Cache-control: must-revalidate Content-Length: 6589 Connection: close Content-Type: text/html;charset=utf-8 RESPONSE_HEADERS RESPONSE_STATUS RESPONSE_CONTENT_LENGTH

18. Fases de Processamento 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> RESPONSE_BODY

19. Fases de Processamento Logging Message: Warning. Pattern match "^[\d\.]+$" at REQUEST_HEADERS:Host. [file "/etc/httpd/modsecurity.d/modsecurity_crs_21_protocol_anomalies.conf"] [line "60"] [id "960017"][msg "Host header is a numeric IP address"][severity "CRITICAL"][tag "PROTOCOL_VIOLATION/IP_HOST"] Apache-Handler: mod_python Stopwatch: 1253311105441030 1021989 (14209 19300 1018538) Response-Body-Transformed: Dechunked Producer: ModSecurity for Apache/2.5.7 (http://www.modsecurity.org/); core ruleset/1.6.1. Server: Apache/2.2.3 (Red Hat)

20. Implantando o ModSecurity • Modo Embutido (local); • Baseado em rede (proxy reverso);

21. Implantando o ModSecurity: Modo Embutido (Local) • Somente para Apache (até o momento); • Instalado no próprio servidor web; • Sem mudança na topologia de rede; • Escalabilidade herdada do servidor web; • Gerencia de segurança e do servidor web compartilhada;

22. Implantando o ModSecurity: Baseado em rede (proxy reverso); • Apache como Proxy Reverso; • 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; • Necessita de solução de alta-disponibilidade e/ou escalabilidade própria; • Separa o gerenciamento de segurança do gerenciamento do servidor web;

23. ModSecurity: Modelos de segurança • Modelo Positivo: • As regras definem o que pode ser requisitado/respondido; • As regras precisam ser escritas para cada aplicação; • A demais requisições são bloqueadas; • Ferramentas: Remo e mod_profiler • Modelo Negativo: • Conjuntos genérico de regras, ex. XSS, SQL Injection, fora dos padrões etc, (ajustes podem ser necessário); • As demais requisições são permitidas;

24. ModSecurity: Modelos de segurança (cont.) • Modelo Híbrido: • Aplica as regras para bloquear os ataques conhecidos (modelo Negativo) para o site todo; • Cria regras específicas para cada aplicação (modelo Positivo);

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;

26. Gerenciamento: ModSecurity Console • ModSecurity Community Console, escrita pela Breach Security; • Grátis para até 3 sensores; • Código fechado; • Centraliza os eventos; • Simples e funcional para a monitoração dos eventos; • Pouco escalável; • Desenvolvimento parado a 1 ano, sem planos para melhorias;

27. Gerenciamento: WAF∙FLE • Console OpenSource em desenvolvimento; • Deve atender a todas as funcionalidades existentes na ModSecurity Community Console; • Significativo ganho de performance; • Sem limite para sensores; • Desenvolvimento em pleno curso; • Contribuições serão muito bem-vindas; • Liberação do código inicial em breve, checar: • http://klaubert.wordpress.com; • Mailing-list do ModSecurity

28. Demonstração

29. Entendendo os eventos

30. Entendendo os eventos

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

32. Ajuste fino das regras • Desabilitar regras; • Desabilitar regras para <Location...> específicos • Alterar/Corrigir a aplicação; • Ajustar partes de uma regra: • Cookies; - Headers; • POST; - Response Body; SecRuleRemoveById 950009 <Location /path/to/foo.php> SecRuleRemoveById 950009 </Location>

33. Performance • Inspecionar as respostas (SecResponseBodyAccess) pode afetar a performance; • Inspecione somente as requisições relevantes (ex. conteúdo dinâmico, html, xml, txt); • Não inspecione conteúdo estático; • A quantidade de regras influencia a performance: • Desative regras desnecessárias; • Habilite o mod_cache;

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

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

36. 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; • Dedique tempo para ajustar seu WAF; • Dê um passo de cada vez; • Acrescente mais uma camada de segurança à sua aplicação;

37. Perguntas