Pró-Reitoria de Pós-Graduação e Pesquisa Lato Sensu em Perícia Digital Trabalho de Conclusão de Curso

Transcrição

1 Pró-Reitoria de Pós-Graduação e Pesquisa Lato Sensu em Perícia Digital Trabalho de Conclusão de Curso MODSECURITY E O CONSUMO DE RECURSOS COMPUTACIONAIS: UMA PROPOSTA DE OTIMIZAÇÃO. Autora: Déborah Lopes Nogueira Orientador: Prof. Esp. Alexandre Antonio Antunes de Almeida Brasília - DF 2015

2 DÉBORAH LOPES NOGUEIRA MODSECURITY E O CONSUMO DE RECURSOS COMPUTACIONAIS: UMA PROPOSTA DE OTIMIZAÇÃO Artigo apresentado ao curso Lato Sensu de Perícia Digital da Universidade Católica de Brasília como requisito parcial para obtenção do Título de Especialista em Perícia Digital. Orientador: Esp. Alexandre Antonio Antunes de Almeida Brasília 2015

3 Artigo de autoria de Déborah Lopes Nogueira, intitulado MODSECURITY E O CONSUMO DE RECURSOS COMPUTACIONAIS: UMA PROPOSTA DE OTIMIZAÇÃO., apresentado como requisito parcial para obtenção de especialização Lato Sensu em Perícia Digital pela Universidade Católica de Brasília, em 28 de maio de 2015, defendido e aprovado, pela banca examinadora abaixo assinada: Professor Esp. Alexandre Antonio Antunes de Almeida Orientador Pós-Graduação Perícia Digital UCB Prof. Msc João Paulo Batista Botelho Examinador Pós-Graduação Perícia Digital UCB Brasília 2015

4 Dedico aos meus pais Dante Nogueira de Lemos e Niedja Naclani Lopes de Lemos que me apoiaram, incentivaram e me deram as melhores oportunidades de aprendizagem.

5 AGRADECIMENTOS Aos meus professores e orientadores por todo ensino e paciência, em especial ao meu professor e orientador, Alexandre Almeida, por todas as explicações, apoio e incentivo que tornaram possível a conclusão deste trabalho e curso. Aos meus colegas de curso, que estiveram comigo nos momentos de tensão das provas e apresentações de trabalho, como também em momentos de descontração. À minha família que, com muito carinho, não mediu esforços para me ajudar a concluir essa etapa da minha vida.

6 Os analfabetos do século XXI não são os que não sabem ler e escrever, mas os que não sabem aprender, desaprender e reaprender. Alvin Toffler.

7 6 MODSECURITY E O CONSUMO DE RECURSOS COMPUTACIONAIS: UMA PROPOSTA DE OTIMIZAÇÃO DÉBORAH LOPES NOGUEIRA Resumo: Este artigo se fundamenta em um estudo sobre o ModSecurity, um firewall de aplicação web, que é executado como um módulo do servidor Web Apache. O trabalho se concentra nas informações que um arquivo de log do ModSecurity deve conter para uma futura perícia, como também quais informações devem ser armazenadas em log. O ModSecurity, também conhecido como WAF (Web Application Firewall), tem por objetivo detectar, bloquear e prevenir tentativas de invasão ao servidor. A segurança é baseada em regras configuradas, e quem determina quais regras o ModSecurity deve seguir, é o próprio administrador do servidor, tornando-o totalmente flexível, de acordo com suas necessidades. Desse modo podese evitar que algumas regras desnecessárias sejam configuradas, como, por exemplo, uma regra contra ataques de SQL injection se a página não tiver acesso a um banco de dados. O WAF gera arquivos de log amplos, ocupando muito espaço em disco e alguma sobrecarga no uso do processador. Assim, foi analisada qual é a melhor forma de armazenar e periciar esses dados, sem prejudicar os recursos e desempenho da máquina. Palavras-chave: ModSecurity. OWASP. Firewall. WAF. Log. 1 INTRODUÇÃO Hoje temos qualquer serviço disponível online para a comodidade do usuário, seja em um site de compras ou de um banco. Com isso, a necessidade de aumentar o investimento em mecanismos de segurança é cada vez maior. Os fornecedores de serviços online precisam tanto de defesa quanto o usuário final, que utiliza a aplicação, ou seja, acessa um site em seu computador. Essas aplicações web armazenam dados importantes do usuário, e tornam a segurança falha ao serem violadas, podendo causar o vazamento de informações privilegiadas. Devido ao aparecimento de diversas vulnerabilidades, surgiu a necessidade de proteger o serviço oferecido, e, no caso de um ataque, poder detectar, prevenir, bloquear e permitir a sua análise forense. O ModSecurity é um Firewall de Aplicação web (WAF, ou Web Application Firewall), de código aberto, que atua na camada de aplicação do modelo OSI (Open Systems Interconnection). Ele é posicionado entre a aplicação web e o usuário, capturando todos os pacotes da transmissão de dados. Os dados capturados são analisados pelo firewall, e, a partir daí, opera de acordo com as regras configuradas. O ModSecurity surgiu da necessidade da análise do payload (parte do pacote que contém os dados), já que alguns filtros de pacotes não o fazem (MODSECURITY,2012). O ModSecurity funciona por meio de regras que são usadas para a detecção dos ataques. Para facilitar o seu aproveitamento, foi criado o projeto OWASP ModSecurity Core Rule Set (CRS), cujo objetivo é fornecer um conjunto de regras básicas para detecção de ataques já explorados, para que não seja preciso criar uma nova regra para uma vulnerabilidade já conhecida, que demandaria um conhecimento profundo para tal. Mesmo com a regra já criada, é possível personalizá-la para que atenda às necessidades de cada aplicação. A empresa mantenedora do ModSecurity é a Trustwave e sua versão mais atual é a 2.9.

8 7 1.1 JUSTIFICATIVA Percebeu-se que, durante uma simulação de ataque a uma aplicação web que implementa as regras do ModSecurity, o arquivo de log de tráfego HTTP (Hyper Text Transfer Protocol) gerado era muito extenso, constatando-se que muitas vezes são armazenados dados dispensáveis no caso de uma perícia. Com a personalização das regras do WAF, é possível controlar quais dados serão direcionados para o log, tornando assim o arquivo de log mais claro para análise e promovendo uma otimização dos recursos que estão operando no momento, como memória, CPU (Central Processing Unit) e o canal de comunicação. Dessa forma, um estudo sobre os dados que devem ser armazenados em log, com o intuito de investigar uma tentativa de ataque, economizando recursos de hardware, pareceu uma boa oportunidade de pesquisa para este trabalho. 1.2 CONTEXTUALIZAÇÃO DO PROBLEMA E OS PROBLEMAS Quais regras devem ser configuradas no WAF? Quais informações são primordiais para o armazenamento em log? Como otimizar o desempenho e recursos da máquina onde o WAF está operando, tendo como base a configuração de suas diretivas? 1.3 PRESSUPOSTO DA PESQUISA Pretende-se analisar, em estudo de caso, como o ModSecurity opera e como interfere nos recursos da máquina, por intermédio de ferramentas e comandos de monitoramento (tais como o Zabbix, o Htop e outros comandos de estatísticas de desempenho), bem como fazer a personalização de regras, utilizando-se o projeto OWASP ModSecurity Core Rule Set (CRS) para simular ataques de Cross Site Scripting (XSS). Para os ataques, serão utilizadas ferramentas e softwares específicos, como W3AF e Nikto. A partir dos logs gerados com esses ataques, serão verificadas quais informações são essenciais para a análise pericial. Será analisada também a melhor forma de potencializar os recursos onde o ModSecurity está operando, utilizando o mínimo de recursos da máquina. 1.4 OBJETIVOS Objetivo Geral Explicar a melhor forma de utilizar as regras do WAF, sem diminuir o potencial de perícia forense e de qual maneira pode ser equilibrado o uso de recursos e o desempenho do servidor, sem que seja diminuído o potencial e significância das informações sobre os ataques Objetivos Específicos Para alcançar o objetivo geral foi necessário: a) personalizar as regras que serão utilizadas para proteção de ataques específicos; b) monitorar o consumo de recursos do servidor, tais como entrada/saída de disco, RAM (Random Access Memory) e CPU; c) simular os ataques; d) analisar os arquivos de log gerados durante o ataque; e) estudar, avaliar e comparar os tamanhos do logs de acordo com as regras; e

9 8 f) concluir a pesquisa propondo qual a melhor configuração de regra, de acordo com a vulnerabilidade, e quais dados são relevantes para o armazenamento em log. 2. REFERENCIAL TEÓRICO A seguir apresentam-se conceitos básicos e informações relevantes para o entendimento deste trabalho. 2.1 MODSECURITY ModSecurity (2010) descreve o ModSecurity como sendo um kit de ferramentas para monitoramento em tempo real das aplicações web, onde as regras são todas personalizáveis, o que quer dizer que toda a configuração do firewall é criada de acordo com sua necessidade. O ModSecurity possui inúmeras funcionalidades, entre elas, Virtual Patching, log de tráfego HTTP, monitoramento em tempo real, prevenção de ataques, regras flexíveis e controle de acesso. Segundo Ristic (2010), o ModSecurity tem como sua melhor característica a detecção de intrusão HTTP. Além disso, pode ser executado no Linux, Solaris, FreeBSD, OpenBSD, NetBSD, AIX e Windows Características a) Monitoramento em tempo real e controle de acesso - O ModSecurity dá acesso ao fluxo de tráfego HTTP, em tempo real, juntamente com a capacidade para inspecioná-lo (MODSECURITY,2010). Já que o ModSecurity age como um detector de intrusão, é possível reagir ao ataque no mesmo momento, utilizando-se as regras configuradas para isso. b) Virtual Patching - É a camada de aplicação da política de segurança que impede a exploração de uma vulnerabilidade conhecida, conforme o Owasp (2010). A ideia é que o ModSecurity utilize essa técnica definindo algumas regras para que possa evitar que a vulnerabilidade seja explorada, porém sem removê-la. Se houver uma exposição de uma vulnerabilidade, é possível protegê-la temporariamente até que seja corrigida. É uma das técnicas do ModSecurity cuja implementação é importante pois a solução, mesmo que provisória, pode evitar um desastre no servidor web (LINUX MAGAZINE, 2011). c) Log de tráfego HTTP - De acordo com ModSecurity (2010), os servidores web tradicionalmente não armazenam dados relevantes para fins de segurança, e, mesmo quando fazem, por padrão, não são capazes de guardar tudo o que é necessário para perícia. O ModSecurity pode ser configurado para registrar em log tudo o que for preciso, e dispensar o que não for. Pode inclusive escolher quais transações, ou qual parte dela precisa ser registrada. Assim, pode-se analisar todo o tráfego HTTP. Estarão disponíveis para leitura cabeçalhos da requisição (Request headers), corpo da requisição (Request body), cabeçalhos da resposta (Response headers), corpo da resposta (Response body), entre outros. d) Mecanismo de regras - Segundo Ristic (2010), o ModSecurity opera por configuração de regras, onde a configuração define como o ModSecurity deve agir sobre os dados. Por sua vez, as regras decidem o que fazer com os dados processados. As regras são feitas com expressões regulares em perl (MISCHEL,2009)

10 9 e) Funcionamento - Conforme Ristic (2010), toda transação no ModSecurity passa por cinco fases. Em cada fase, o ModSecurity faz algum trabalho no início e, depois recorre às regras específicas. Cada regra é processada em uma fase diferente. As fases estão detalhadas no Quadro 1. Quadro 1 Fases de processamento do ModSecurity Número Fase Designador Atividades 1 Fase de prévisualização REQUEST_HEADERS Filtragem o mais cedo possível de requisições antes do controle de acesso, autenticação,autorização e detecção MIME que são realizados pelo Apache. 2 Requisição do cliente REQUEST_BODY Acesso completo ao conteúdo de requisições de cliente 3 Requisição POST RESPONSE_HEADERS Opção inicial para filtragem de respostas do servidor 4 Resposta do servidor RESPONSE_BODY 5 Logging LOGGING Fonte: RISTIC (2010, pág. 71) Fases de processamento do ModSecurity Acesso completo ao conteúdo de resposta do servidor a uma requisição de entrada do cliente Acesso a todas as informações relevantes antes de que ela seja gravada nos arquivos de log do Apache. f) Diretivas de Configuração - O ModSecurity trabalha por meio da configuração de suas diretivas. Cada diretiva responde por parâmetros que são responsáveis pela maneira de como o ModSecurity vai agir caso a regra do mesmo esteja ativa. De acordo as diretivas estão classificadas conforme o Quadro 2. Quadro 2 Diretivas de Configuração do ModSecurity DIRETIVA SecArgumentSeparator SecAuditEngine SecAuditLog SecAuditLog2 SecAuditLogParts SecAuditLogRelevantStatus SecAuditLogStorageDir SecAuditLogType SecCookieFormat SecDataDir SecDebugLog SecDebugLogLevel SecRequestBodyAccess SecRequestBodyLimit SecRequestBodyInMemoryLimit SecResponseBodyLimit SecResponseBodyMimeType SecResponseBodyMimeTypesClear SecResponseBodyAccess SecRuleEngine SecTmpDir Fonte: RISTIC (2010, pág. 34) DIRETIVAS DE CONFIGURAÇÃO DESCRIÇÃO Define qual será o separador para argumentos Modo de funcionamento do mecanismo de log Define o caminho para o principal arquivo de log de auditoria Define o caminho para outro arquivo de log (cópia) Define quais informações serão registradas nos arquivos de log Define qual status de resposta é considerado relevante para o log Define o diretório de onde as entradas de log serão gravadas Define o modo de gravação dos arquivos Define qual será a versão de formato do Cookie Define o diretório para armazenar os arquivos de dados do ModSecurity Define onde ficarão as informações de debug Define o nível de detalhe das informações de debug Configura se o Request Body será armazenado em buffer e processado pelo ModSecurity Define o tamanho máximo do Request Body que o ModSecurity aceitará para buffering. Define o tamanho máximo do Request Body que ModSecurity irá armazenar na memória. Define o tamanho máximo do Response Body que o ModSecurity aceitará para buffering. Configura quais tipos MIME devem ser considerados para o buffer do Response Body Limpa a lista de tipos MIME Configura se o Response Body deve ir para o buffer Configura o mecanismo de regras Configura o diretório onde os arquivos temporários serão criados. A diretiva SecAuditLogParts é de grande importância para o desenvolvimento deste estudo. Nela é determinado quais informações serão armazenadas nos logs do ModSecurity. O

11 10 SecAuditLogParts define com parâmetros as partes do log (informações detalhadas da transação http) que deverão ser armazenadas. Esses parâmetros são definidos por letras: A - Contém as informações básicas sobre a transação, é o cabeçalho do log (Hora, porta de origem e destino, IP de origem e destino, ID) - Obrigatório B - Cabeçalho da requisição C - Corpo da requisição D - Reservado E - Corpo da resposta. (Apenas quando a transação foi interceptada) F - Cabeçalho da resposta G - Reservado H - Contém informações adicionais sobre a transação I - Alternativa para o corpo da requisição J - Reservado K- Contém uma lista de regras que correspondem a transação. Z - Determina o limite do arquivo de log - Obrigatório 2.2 PROJETO OWASP ModSecurity Core Rule Set A OWASP (Open Web Application Security Project) é uma entidade sem fins lucrativos que contribui para a melhoria da segurança de softwares, dedicando-se a capacitar as organizações a desenvolver, adquirir e manter aplicações confiáveis. A OWASP reúne informações importantes como normas e documentos (OWASPTOP10,2013). Como o ModSecurity opera através das regras configuradas, o projeto OWASP criou um conjunto de regras básicas que tem por objetivo proteger os servidores web de ataques mais conhecidos, como SQL injection, Cross Site Scripting, requisições inválidas de clientes, ataques remotos, locais de injeção de comandos ou . Com essas regras, o administrador tem a base para então poder personalizar de acordo com a necessidade do ambiente. Algumas das técnicas utilizadas pelo projeto OWASP Modsecurity Core Rule Set são listadas a seguir (OWASP,2012): Proteção HTTP Detecta violação no protocolo e utiliza a política de uso que foi definida localmente. Detecção de código malicioso baseado na web Identifica conteúdo malicioso utilizando a API Google Safe Browsing. Proteções HTTP de negação de serviço Defesa contra envenenamento de HTTP e ataques de negação de serviço pelo protocolo HTTP. Proteção a ataques web comuns Detecção de ataques de segurança comuns em aplicações web. Detecção automatizada Detecta bots (softwares de varredura automatizada), crawlers, scanners e outras atividades maliciosas. Integração com antivírus para upload de arquivos Detecta arquivos maliciosos enviados para a aplicação web. Rastreamento de dados sensíveis Controla o uso do cartão de crédito e vazamentos de blocos. Proteção contra trojans Detecção de acesso a cavalos de troia. Identificação de defeitos de aplicativos Alertas sobre erros de configuração de aplicativos. Detecção de erro e hiding Camufla mensagens de erro enviadas pelo servidor.

12 11 O arquivo de regras do CRS possui quatro diretórios: base_rules, experimental_rules, optional_rules e slr_rules. No base_rules é onde se encontram todos os arquivos de regras do CRS para cada vulnerabilidade conhecida. 2.3 VULNERABILIDADES SELECIONADAS O projeto OWASP, desde 2003, publica a cada três anos um documento intitulado OWASP Top 10 que tem por intuito enumerar os 10 riscos mais comuns em aplicações web, e educar desenvolvedores sobre as consequências das mais importantes vulnerabilidades de segurança de aplicações web. No último documento que foi publicado em 2013, o Top 10 foi classificado conforme apresentado no Quadro 3. Quadro 3 Classificação de Vulnerabilidades WEB OWASP Top A1 - Injeção de código A2 - Quebra de autenticação e Gerenciamento de Sessão A3 - Cross-Site Scripting (XSS) A4 - Referência Insegura e Direta a Objetos A5 - Configuração Incorreta de Segurança A6 - Exposição de Dados Sensíveis A7 - Falta de Função para Controle do Nível de Acesso A8 - Cross-Site Request Forgery (CSRF) A9 - Utilização de Componentes Vulneráveis Conhecidos A10 - Redirecionamentos e Encaminhamentos Inválidos Fonte: OWASPTOP10,2013. Baseado no projeto OWASP Top 10, foi escolhido o Cross-Site Scripting como modo de ataque nas simulações. 2.4 CROSS SITE SCRIPTING (XSS) Segundo o projeto OWASP TOP 10 (2007) Cross Site Scripting (XSS) é um subconjunto de inserções HTML. As falhas XSS ocorrem em quaisquer aplicações que recebam dados originados do usuário e os enviem ao navegador sem primeiramente validar ou codificar o conteúdo. O XSS permite a atacantes executarem script no navegador da vítima, que pode sequestrar sessões de usuários, desfigurar web sites, inserir conteúdo hostil, conduzir ataques de roubo de informações pessoais e obter o controle do navegador. O script malicioso é frequentemente em Java Script, mas qualquer linguagem de script suportada pelo navegador da vítima é um vetor potencial para este ataque. Para combater esse tipo de ataque, será utilizado o arquivo de regra modsecurity_crs_41_xss_attacks.conf. Neste arquivo existem mais de 100 regras habilitadas para detectar ataques Cross-Site Scripting (XSS). 2.5 ZABBIX O Zabbix é uma ferramenta para monitoramento de infraestrutura de rede e aplicações. Possui suporte a maioria dos sistemas operacionais, interface gráfica, envio de alertas, geração de gráficos em tempo real entre outras características. Com isso, o Zabbix será utilizado no ambiente de teste para o monitoramento dos servidores e ajudar na observação dos recursos da máquina, bem como seu desempenho (ZABBIX,2015).

13 FERRAMENTAS Com a finalidade de observar o desempenho de três dos principais recursos da máquina (CPU, memória e entrada/saída de disco rígido), serão utilizadas algumas ferramentas livres: a) Vmstat: reporta informações sobre processos, memória, paginação, blocos de I/O (Input/Output), interrupções, discos e atividade da CPU; b) Mpstat: é um software de linha de comando de computador utilizado em sistemas operacionais do tipo Unix para relatar (na tela) estatísticas relacionadas ao processador; c) Nmon: é um administrador de sistemas, sintonizador, ferramenta de benchmark. Ele pode exibir o CPU, memória, rede, discos (mini gráficos ou números), sistemas de arquivos, NFS, os processos principais, recursos (versão do Linux e processadores) e outras informações; d) Iostat: exibe relatório com estatísticas da CPU e de entrada/saída de dispositivos e partições. Usado para monitorar o sistema de carga de entrada/saída de dispositivos, observando o tempo que os dispositivos estão ativos em relação às suas taxas de transferências médias; e e) Htop: é um avançado sistema interativo para visualizar processos. Escrito para Linux, o comando htop mostra uma lista frequentemente atualizada de processos que rodam na máquina, e utiliza-se de cores para facilitar a leitura de informações sobre o processador, swap, status da memória entre outros. 2.7 NIKTO Nikto é um software Open Source (código aberto), que age como um scanner de vulnerabilidades para servidores web. Através de testes, ele pode identificar um software vulnerável hospedado em um servidor web. Ele também é capaz de gerar um relatório destacando as possíveis vulnerabilidades (NIKTO2,2015). 2.8 W3AF O W3AF é um framework de auditoria de vulnerabilidades em aplicações web. Seu objetivo é criar um quadro para encontrar e explorar vulnerabilidades de aplicações web (W3AF,2015). 3. ESTUDO DE CASO Para realização dos testes foram criados dois ambientes virtuais utilizando o software de virtualização VirtualBox. Em uma máquina virtual está instalado o sistema operacional Kali Linux e na outra o sistema operacional Debian Wheezy, cada uma com a configuração de 1GB de memória. A máquina com o sistema operacional Kali será a atacante e realizará os ataques contra a máquina Debian utilizando os softwares: Nikto e W3AF. A máquina com o sistema operacional Debian agirá como o servidor web, nela está instalado o ModSecurity para a proteção do servidor e o Zabbix para ajudar o monitoramento, juntamente com o htop. Para a simulação dos ataques foi criada uma página web com formulário contendo login e senha (aplicação web protegida pelo ModSecurity e atacada pelo W3AF e Nikto).

14 13 O objetivo de cada ataque é observar os recursos e desempenho da máquina, bem como o tamanho dos seus logs gerados. Serão analisados os logs do apache2: access.log e error.log; e do ModSecurity: modsec_audit.log. As informações que serão gravadas no arquivo modsec_audit.log serão determinados através da diretiva SecAuditLogParts dentro do arquivo.conf do ModSecurity. Serão realizados os testes de acordo com a mudança dos parâmetros (A, B, C, D, E, F, G, H, I, J, K, Z) da diretiva SecAuditLogParts. Serão testadas três configurações diferentes. Ficaram determinadas as configurações da seguinte maneira: Primeiro todos os parâmetros possíveis (A, B, C, D, E, F, G, H, I, J, K, Z), segundo foram retirados os parâmetros reservados e o parâmetro que age como alternativa para o corpo da requisição (A, B, C, E, F, H, K, Z), e por último será testado com a configuração (A, B, C, F, H, Z) sugerida por Ivan Ristic em MODSECURITY HANDBOOK (2012). Durante a observação do desempenho e dos recursos da máquina Debian no decorrer dos ataques, foi notado que o uso da memória e CPU são diretamente proporcionais ao aumento de parâmetros inseridos na diretiva SecAuditLogParts, quanto mais diretivas (representadas pelas letras) configuradas, mais é necessário o uso dos recursos da máquina consequentemente, afetando o desempenho da mesma. Isso pode ser melhor observado no gráfico 1 e 2, que mostra a porcentagem da média de uso da CPU do servidor durante os ataques, como também o status da memória, respectivamente. Gráfico 1 Média da porcentagem de uso da CPU durante os ataques. Fonte: a autora.

15 14 Gráfico 2 Média de uso da memória durante os ataques. Fonte: a autora. Ao longo dos ataques e a partir de cada parâmetro diferente configurado na diretiva SecAuditLogParts, foi observado o tamanho dos arquivos de log gerados de três arquivos específicos: access.log, error.log e modsec_audit.log. Assim, foi possível observar o espaço que o arquivo de log utilizou em disco, e quais informações são importantes estarem presentes no log para análise pericial, com objetivo de retirar informações sobre uma tentativa ou um ataque realizado ao servidor. De acordo com os dados extraídos foram elaborados os gráficos 3 e 4, em conformidade com a configuração da diretiva, da média do tamanho do arquivo. Gráfico 3 Configuração da diretiva SecAuditLogParts ABCDEFGHIJKZ Fonte: a autora. No gráfico 1, destaca-se o tamanho dos três arquivos de log durante os ataques com a configuração da diretiva SecAuditLogParts contendo todos os parâmetros possíveis. É possível observar o quanto o tamanho do arquivo modsec_audit.log é extenso.

16 15 Gráfico 4 Configuração da diretiva SecAuditLogParts ABCEFHKZ Fonte: a autora. Foi observado no gráfico 4 que, somente em retirar os parâmetros reservados e o parâmetro que funciona como alternativa para o corpo da requisição, o arquivo de log do ModSecurity obteve uma pequena redução em seu tamanho. Não cooperando tanto, com a diminuição do espaço utilizado em disco sem perder informações importantes. Gráfico 5 Configuração da diretiva SecAuditLogParts ABCFHZ Fonte: a autora. Foi percebido que os dados contidos nos parâmetros ABCFHZ, sugeridos por Ristic (2012), são suficientes na busca de informações sobre uma tentativa de ataque ao servidor, pois assim, no arquivo de log estarão incluídos dados como o cabeçalho da requisição e da resposta, o corpo da requisição e as informações adicionais sobre a transação. Como também houve economia no tamanho do arquivo de log, pode-se inferir sobre a melhor utilização dos recursos de espaço em disco. O maior objetivo é mostrar o quanto difere o tamanho do arquivo modsec_audit.log, pois é ele que contém os registros de log determinados na configuração da diretiva

17 16 SecAuditLogParts. Desta forma, foram analisados quais parâmetros trazem as informações mais importantes, e quais dados podem ser descartados (economia de espaço em disco) ao armazenar log, assim como otimizar a utilização dos recursos da máquina para não comprometer o desempenho. Como foram realizadas diferentes configurações, a próxima figura mostra a diferença do tamanho do arquivo modsec_audit.log durante os ataques entre as três configurações, observando que a configuração com o menor tamanho de log é a ABCFHZ. Gráfico 6 Média do tamanho do arquivo modsec_audit.log durantes os ataques Fonte: a autora. Como os testes foram elaborados em um ambiente fictício, com poucas requisições e ataques, foram coletadas algumas informações de um site real (foi escolhido o site e então calculado uma estimativa de tamanho do log do ModSecurity com os mesmos parâmetros configurados nas simulações. O cálculo foi baseado em um número de acesso diário do site da UCB. Gráfico 7 Seguindo como base os dados dos testes, foi feita uma estimativa do tamanho de logs em um site real. Fonte: a autora.

18 17 De acordo com a comparação do que poderia vir a ser o tamanho do arquivo de log de um site real com umas das três configurações da diretiva SecauditLogParts, ficou constatado de que os parâmetros ABCFHZ é a melhor escolha, visto que contém os dados necessários na busca de informações sobre a tentativa de ataque ao servidor, permitindo que o tamanho do arquivo de log fosse reduzido ao máximo. 4. MATERIAIS E METODOLOGIA 4.1 Classificação da pesquisa A metodologia utilizada embasou-se em Vergara (2010, p. 41) que a divide em dois critérios básicos: quanto aos fins e quanto aos meios. Quanto aos fins, esta pesquisa é aplicada, e, quanto aos meios de investigação, pesquisa bibliográfica e de laboratório. A pesquisa é aplicada, porque o intuito deste estudo é fornecer dados: bibliográfica, visto que, para o desenvolvimento deste trabalho, foram consultados autores de livros e artigos eletrônicos sobre o tema; e de laboratório, porque serão realizados testes em ambientes virtuais. 5. CONCLUSÃO Geralmente o ModSecurity utiliza de recursos mínimos necessários para realizar as funções desejadas, porém é um caso de troca de moedas: quanto maior for o nível de segurança, maior será o consumo de recursos e desempenho da máquina. A configuração do ModSecurity pode ser facilmente entendida, graças aos seus desenvolvedores que explicam cada regra de sua composição detalhadamente. Isso facilita sua configuração, porém não descarta a possibilidade de uma configuração incorreta, o que pode causar muitos problemas inclusive o bloqueio de uma requisição legitima. O ModSecurity acrescenta uma análise que já é feita pelo Apache, causando um aumento do consumo de CPU desnecessário. Toda regra em sua configuração utiliza uma parte do tempo da CPU e memória, porque tem de transformar os dados de entrada antes de serem analisados. Por isso, quanto mais regras, mais será exigido da máquina. O log de transações completo do WAF é uma operação bastante cara no que diz respeito ao comportamento de recursos e desempenho da máquina. Por isso existia a necessidade de saber o que realmente deve ser armazenado em log. Quanto mais informações forem configuradas para serem guardadas em log, mais espaço em disco será utilizado, mais desempenho e consumo de recursos do servidor serão necessários, implicando assim também na parte física do equipamento utilizado para abrigar o ModSecurity. Por isso foi realizado configurações diferentes da diretiva que determina quais informações serão gravadas, sem dispensar os dados que realmente importam no log. Os testes foram realizados em pequena escala, apenas simulando uma aplicação local com poucas requisições e poucas tentativas de ataques, mas se considerarmos um site real, como exemplo o site da Universidade Católica de Brasília ( que tem 380 mil acessos por mês, de acordo com a estimativa retirada do site (que apura o tráfego de requisições em sites), e considerando os valores extraídos dos testes como base, em aproximadamente um mês, o tamanho dos arquivos de log será enorme, comprometendo o espaço em disco do servidor e exigindo muito dos recursos da máquina. O ModSecurity deve ser utilizado com cautela, pois qualquer configuração determinada irá consumir recursos do servidor. A grande característica desse WAF não é o que ele faz, mas sim o que ele é capaz de fazer, visando a abrangente configuração possível e

19 18 que deve ser determinada por seu administrador, é ele quem vai designar o que o ModSecurity deverá fazer. 6. TRABALHOS FUTUROS A compactação de dados é de suma importância para o complemento da otimização dos recursos da máquina, portanto, um estudo sobre a aplicação dessa técnica é indicada como sugestão para trabalhos futuros relacionados a este artigo. 7. RESUMO EM LÍNGUA ESTRANGEIRA MODSECURITY AND THE CONSUMPTION OF COMPUTATIONAL RESOURCES: A PROPOSAL FOR OPTIMIZATION. DEBORAH LOPES NOGUEIRA Abstract: This article is based on a study of ModSecurity, a web application firewall that runs as an Apache Web server module. The work focuses on the information that a ModSecurity log file should contain for future analysis, as well as what information must be stored in log. ModSecurity also known as WAF (Web Application Firewall) aims to detect, block and prevent server intrusion attempts. Security is based on configured rules, and the server manager defines which rules ModSecurity must follow, making it totally flexible, according to the needs. In this way it is possible to avoid that some unnecessary rules are set, like, for example, a rule against SQL injection attacks if the page has no access to a database. The WAF generates large log files, taking up too much disk space. Thus, it will analyze what is the best way to store and investigate such data, without wasting the resources and decreasing machine performance. Keywords: ModSecurity. OWASP. Firewall. WAF. Log. 8. REFERÊNCIAS MISCHEL, M. ModSecurity 2.5: Securing your Apache installation and web applications. Packt Publishing, MODSECURITY. PDF Universal XSS Protection. Disponível em: < html>. Acesso em: 18 dez ModSecurity: Open Source Web Application Firewall. Disponível em: < Acesso em: 10 fev NIKTO2. Nikto: web server scanner. Disponível em: < Acesso em: 18 abr OWASP. OWASP ModSecurity Core Rule Set Project. Disponível em: < Project>. Acesso em: 14 abr

20 19 OWASP TESTING GUIDE. Disponível em: < >. Acesso em: 18 abr Top OWASP. Disponível em: < Acesso em: 10 abr Top OWASP. Disponível em: < Top_10>. Acesso em: 14 abr RISTIC, I. ModSecurity Handbook. Feisty Duck Limited, STUTTARD, D.; PINTO, M. The Web Application Hacker s Handbook: Finding and Exploiting Security Flaws, Wiley Publishing, 2.ed., SIMILARWEB. SimilarWeb: Website Traffic & Mobile App Analytics. Disponível em: < Acesso em: 12 abr SOURCEFORGE. Reference Manual. Disponível em: < Acesso em: 11 abr TRUSTWAVE. Detecting Malice with ModSecurity: Open Proxy Abuse. Disponível em: < Acesso em: 12 abr VERGARA,S. C. Projetos e Relatórios de Pesquisa em Administração. São Paulo: Atlas, 12.ed., W3AF. w3af - Open Source Web Application Security Scanner. Disponível em: < Acesso em: 13 abr ZABBIX. Zabbix: The Enterprise-class Monitoring Solution for Everyone. Disponível em: < Acesso em: 13 abr