Para começar, vou abordar a instalação do mod_security, que é um Firewall de aplicação WEB, também conhecido como WAF.

O mod_security é hoje suportado pela equipe da SpiderLabs, blog sustentado pela Truswave, uma das gigantes da segurança.

O mod_security é um WAF Open Source que, em minha opinião, não perde em nada para os proprietários. Ele possui algumas regras pagas, desenvolvidas pelo pessoal do SpiderLabs e possui regras disponíveis de forma gratuita no site da OWASP, mas, a nossa intenção não é pegar nada pronto e sim entender como a ferramenta funciona, para criarmos nossas próprias regras.

Neste primeiro artigo, iremos abordar o conceito, funcionamento e instalação do mod_security. Já no próximo, vamos ver a integração dele com os dois principais WEB Servers Open Source.

Vamos começar listando onde o mod_security pode nos ajudar:

• Visualização em tempo real dos acessos e das tentativas de burlar nossa aplicação.
• Virtual patching, protegendo nossa aplicação até que a equipe de developers possa corrigir uma possível falha.
• Log de todo o tráfego HTTP.
• Avaliação contínua da segurança. Através de testes de segurança e análise dos logs, pode-se saber se nossa aplicação está vulnerável, antes de um terceiro.
• Hardening de aplicação WEB.

Opções de instalação

O mod_security pode ser instalado direto no servidor WEB, ou pode ser usado com o proxy reverso.

• No servidor WEB seria a melhor escolha para quem já tem sua arquitetura de rede e não deseja alterará-la. O ponto fraco dessa escolha, seria a administração dos recursos, já que o mod_security iria compartilhar desses recursos junto com o sistema.
• Como proxy reverso, na minha opinião a melhor escolha, pois você está isolando de forma completa a sua rede e não compromete os recursos do servidor WEB.

Definições

Principais características:

• Parsing.
• Buffering :: na instalação padrão, o mod_security faz buffer do request e do response, podendo assim alterar ambos antes de concluir a ação.
• Logging :: todas as transações são logadas, para que se possa fazer uma análise, caso seja preciso.
• Rule Engine :: as rules, nós podemos dizer que são o coração do mod_security, pois são as responsáveis pelas execuções dos bloqueios.

Um exemplo de rule:

As regras

Por padrão, as regras seguem a seguinte sequência:

• Variáveis :: vão dizer ao mod_security onde procurar. Em nosso exemplo, foi usada a variável ARGS, que diz ao mod_security para olhar todo os parâmetros de request.
• Operador :: vai dizer ao mod_security o que procurar. Em nosso exemplo, temos a string JS <script>, usado em ataques XSS.
• Ações :: vai dizer ao mod_security, a ação que deve tomar, caso a condição anterior for verdadeira. Em nosso exemplo o mod_security vai registar em log, vai negar o acesso e dar como resposta o status 404.

Fluxo

Podemos dividir as regras em 5 fases, onde em cada fase específica o mod_security executa a regra definida para a mesma.

1. Request headers
2. Request body
3. Response headers
4. Response body
5. Logging

Onde:

• Nas fases de request, o mod_security faz análise das requisições e aplica as regras de acordo com o que foi configurado, se é para header ou pra body, e depois repassa a requisição ao WEBserver.
• Nas fases de response, o mod_security faz a análise da resposta do WEBserver, a requisição enviada, tanto pra header quanto para body e depois repassa a resposta ao cliente.
• Na fase de logging, dizemos ao mod_security como queremos que as requisições e respostas sejam registradas no log.

Instalação

*A instalação é baseada em derivados Red Hat.

Primeiro, vamos instalar todas as dependências:

# yum install gcc make libxml2 libxml2-devel httpd-devel pcre-devel curl-devel

Para a instalação do mod_security, vamos usar o Git (yum install git), e baixar a versão mais recente do projeto:

git clone git://github.com/SpiderLabs/ModSecurity.git
cd ModSecurity
./autogen.sh
./configure
make
# make install


Pronto, finalizamos a nossa instalação.

No próximo artigo, veremos como integrar o mod_security ao WEBserver.