Configurando o ModSecurity em VirtualHosts e Mais Dicas
Boa noite a todos. Gostaria de começar esse post pedindo desculpas pela demora nas publicações das dicas e tutoriais. Estou bem atolado de trabalho ultimamente, tenho postado somente algumas notícias do mundo de TI, mas não abandonei nem deixei o blog de lado. É só falta de tempo mesmo, mas vamos que vamos 🙂
No post de hoje iremos dar continuidade nas dicas sobre o ModSecurity, caso você ainda não tenha visto o meu último artigo sobre o tema, é só acessar o link “Instalação e Configuração do ModSecurity 2.8 com Apache + Core Rules“. Nesse post mostrei como instalar e realizar a configuração inicial para o ModSecurity, além de mostrar como criar algumas exceções de alertas em sua configuração.
Iremos começar aprendendo um pouco mais sobre o arquivo de configuração do ModSecurity “modsecurity.conf”. Existe uma linha nesse arquivo com a entrada “SecResponseBodyAccess”, ela define se o conteúdo das respostas será armazenado. Isso só é necessário se a detecção e proteção contra vazamento de dados for requerida. Configurando essa opção como “On” o uso de recursos do servidor será requisitado além do tamanho do arquivo de log ter um crescimento considerável. Por isso analise bem seu ambiente para analisar a real necessidade dessa opção.
Procure a entrada abaixo no arquivo “/etc/apache2/ModSecurity/modsecurity.conf” e mude para Off.
SecResponseBodyAccess On
Agora iremos ver duas entradas responsáveis por limitar o tamanho máximo de conteúdos que podem ser postados na aplicação Web.
A entrada “SecRequestBodyLimit” limita o tamanho máximo dos dados utilizando o método POST. Caso alguma coisa maior que o tamanho definido for enviado para a aplicação o servidor irá responder com uma mensagem de erro 413 Request Entity Too Large. O valor padrão utilizado é 13107200, o que corresponde a 12,5 MB.
A outra entrada mencionada é a “SecRequestBodyNoFilesLimit”, responsável por limitar o tamanho mínimo de arquivos enviados para o servidor utilizando o método POST. O valor padrão utilizado é 131072, o que corresponde a 128KB.
Uma outra entrada que pode afetar a performance do servidor é “SecRequestBodyInMemoryLimit”. Ela é responsável por especificar a quantidade de memória RAM utilizada para armazenar o corpo das requisições, qualquer coisa a mais do que o especificado será armazenado no disco, similar ao Swap utilizado pelos SOs. Caso seu servidor utilize disco SSDs esse “swap” não será um grande problema para a performance. Entretanto esse valor deve ser incrementado caso exista memória RAM disponível no servidor. O valor padrão utilizado é 131072, correspondentes a 128KB.
No último artigo sobre o ModSecurity ensinei como criar as exceções dentro do próprio arquivo de configuração, porém caso você não queira que essas exceções sejam aplicadas em um “VirtualHost” do seu servidor ou até mesmo que alguma exceção de um “VirtualHost” não seja aplicada em outro basta manusear o ModSecurity no arquivo de configuração do seu “VirtualHost”, que podem ser localizados em “/etc/apache2/sites-available/”.
Caso deseje desativar o ModSecurity em algum “VirtualHost” é só adicionar as linhas abaixo no arquivo de configuração do “VirtualHost” entre as tags <VirtualHost>.
<IfModule security2_module>SecRuleEngine Off</IfModule>
Ou ainda se deseja desativar o ModSecurity apenas para um determinado diretório adicione as seguintes linhas:
<Directory “/var/www/seu-site/wp-admin”><IfModule security2_module>SecRuleEngine Off</IfModule></Directory>
Caso não deseja desativar totalmente o ModSecurity completamente ou para um determinado diretório, pode-se criar as exceções baseadas em um determinado arquivo e o ID da regra, adicione as seguintes linhas no arquivo de configuração do “VirtualHost”:
<LocationMatch “/wp-admin/update.php”><IfModule security2_module>SecRuleRemoveById 981173</IfModule></LocationMatch>
Lembrando que para descobrir o ID da regra é só olhar o log do ModSecurity localizado em “/var/log/apache2/modsec_audit.log”.
É isso ai, espero que esse artigo ajude bastante gente e aumente a segurança dos sites por ai. Não esqueçam de curtir nossas páginas nas redes sociais, Facebook, G+ e seguir o Guia do Ti no Twitter. Compartilhem e comentem esse artigo, isso é muito importante para divulgação do nosso trabalho.
- Metasploit Framework de cabo a rabo – Parte 6 - 4 de junho de 2018
- Metasploit Framework de cabo a rabo – Parte 5 - 28 de maio de 2018
- CEH – Scanning Networks – Parte 2 - 24 de maio de 2018
