Instalação e Configuração do ModSecurity 2.8 com Apache + Core Rules

Fala galera, hoje vamos falar um pouquinho de segurança, mais especificamente de segurança defensiva, muitos conhecem ou pelo menos já ouviram falar do ModSecurity, bem, iremos abordar o passo a passo da instalação e configuração dessa maravilhosa ferramenta, para aqueles que nunca ouviram falar do Mod Security segue uma breve explicação.

ModSecurityLogo

O Mod Security é um Web Application Firewall que atua na camada 7 do modelo OSI e tem por objetivo bloquear diversos tipos de ataques, como o Cross-Site Scripting (XSS), SQL Injection, Command Injection, ASP e PHP Injection, Trojans & Backdoors Detection, dentre outros, que variam de acordo com as regras existentes, ele filtra todas as requisições e respostas entre o servidor Web e o cliente fazendo a checagem das regras que estão em vigor. Atualmente é suportado pelo Apache, IIS7 e Nginx.

O objetivo desse artigo é mostrar que o Mod Security não é um bicho de sete cabeças que muita gente fala, ele é PRIMORDIAL para a segurança de seu site, então chega de papo e vamos começar a “brincadeira”.

Ambiente do Lab

O sistema operacional que estou utilizando é um Ubuntu Server 14.04, você pode ficar à vontade para usar a distro que você preferir, também estou utilizando o WordPress como aplicação Web com o Apache, caso você não tenha lido acesse Instando o WordPress do Zero Passo-a-Passo.

Instalação

Vamos começar instalando os pacotes necessários para compilar nosso Mod Security:

# apt-get install apache2-threaded-dev libxml2-dev  libcurl4-gnutls-dev liblua5.1-0 liblua5.1-0-dev build-essential

Vá até o diretório /opt e faça o download do modsecurity:

# cd /opt/ && wget https://www.modsecurity.org/tarball/2.8.0/modsecurity-2.8.0.tar.gz

Agora descompacte o arquivo e acesse o diretório criado:

# tar -xvzf modsecurity-2.8.0.tar.gz && cd modsecurity-2.8.0

Agora iremos iniciar a compilação com o ./configure fazendo as configurações de path e verificando as dependências:

# ./configure  --with-apxs=/usr/bin/apxs2 --with-pcre=/usr/bin/pcre-config --with-apr=/usr/bin/apr-config --with-apu=/usr/bin/apu-config --with-libxml=/usr/bin/xml2-config --with-curl=/usr/bin/curl-config

Depois compile e instale o Mod Security:

# make
# make install

Depois de tudo instalado é hora de copiar a biblioteca do Mod Security para o diretório de módulos do apache:

# cp /usr/local/modsecurity/lib/mod_security2.so /usr/lib/apache2/modules/

Agora iremos baixar o core rules do Spider Labs. A empresa Spider Labs, mantem um projeto livre chamado core rules, esse projeto contém milhares de regras capazes de mitigar as principais vulnerabilidades e ataques a aplicações web.

Vá até o diretório do apache e baixe a última versão do core rules:

# cd /etc/apache2/ && wget https://codeload.github.com/SpiderLabs/owasp-modsecurity-crs/legacy.tar.gz/master

Descompacte o arquivo:

# tar -xvzf master

Mude o nome do diretório para ficar mais legível

# mv SpiderLabs-owasp-modsecurity-crs-ebe8790/ ModSecurity
# cd ModSecurity/

Agora iremos renomear o arquivo modsecurity_crs_10_setup:

# mv modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf

Agora iremos criar um link simbólico para o diretório activated_rules que como o próprio nome já diz é onde contém as regras ativas do nosso Mod Security

# ln -s /etc/apache2/ModSecurity/modsecurity_crs_10_setup.conf /etc/apache2/ModSecurity/activated_rules/modsecurity_crs_10_setup.conf

Depois iremos copiar o arquivo modsecurity.conf e o unicode.mapping para o diretório do apache e renomear o modsecurity.conf:

# cp /opt/modsecurity-2.8.0/modsecurity.conf-recommended /etc/apache2/ModSecurity/
# cp /opt/modsecurity-2.8.0/unicode.mapping /etc/apache2/ModSecurity
# mv modsecurity.conf-recommended modsecurity.conf

Modifique o local dos logs do Mod Security, abra o arquivo modsecurity.conf e procure a entrada SecAuditLog e deixe como é mostrado abaixo:

# pico modsecurity.conf

SecAuditLog /var/log/apache2/modsec_audit.log

Depois disso iremos criar os arquivos mod_security2.conf e mod_security2.load para ativar o modulo do Mod Security no Apache:

# cd ../mods-available/
# pico mod_security2.conf

Inclua o seguinte conteúdo no arquivo:

<IfModule security2_module>

        SecDataDir /var/cache/modsecurity 

        Include "/etc/apache2/ModSecurity/modsecurity.conf"

        Include "/etc/apache2/ModSecurity/activated_rules/*.conf"

</IfModule>

# pico mod_security2.load

Adicione as seguintes linhas no arquivo:

LoadFile /usr/lib/libxml2.so.2
LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so

Agora iremos criar um link simbólico para a biblioteca do xml2:

Se seu Linux for 64bits execute:

# ln -s /usr/lib/x86_64-linux-gnu/libxml2.so.2 /usr/lib/libxml2.so.2

Se ele for 32bits execute:

# ln -s /usr/lib/i386-linux-gnu/libxml2.so.2 /usr/lib/libxml2.so.2

Ative o modulo do Mod Security e o modulo Unique_Id no apache:

# a2enmod unique_id
# a2enmod mod_security2

Reinicie o apache:

# service apache2 restart

Execute o comando abaixo para listar os módulos ativos:

# apachectl -t -D DUMP_MODULES

Verifique se a saída contém os módulos abaixo:

unique_id_module (shared)
security2_module (shared)

Pronto agora nosso Mod Security já está funcionando, vamos configurar as regras, entre no diretório base_rules e copie todas as regras para o activated_rules:

# cd ../ModSecurity/base_rules/
# cp * /etc/apache2/ModSecurity/activated_rules/

Agora entre no diretório slr_rules e copie todas as regras para o activated_rules:

# cd ../slr_rules/
# cp modsecurity_crs_46_slr_et_wordpress_attacks.conf /etc/apache2/ModSecurity/activated_rules/

Copie também as regras especificas para o WordPress:

# cp modsecurity_46_slr_et_wordpress.data /etc/apache2/ModSecurity/activated_rules/

Depois entre no diretório optional_rules e copie as seguintes regras para o activated_rules:

# cd ../optional_rules/
# cp modsecurity_crs_42_comment_spam.conf ../activated_rules/
# cp modsecurity_42_comment_spam.data ../activated_rules/
# cp modsecurity_crs_16_session_hijacking.conf ../activated_rules/

Entre no diretório experimental_rules e copie as seguintes regras para o activated_rules:

# cd ../experimental_rules
# cp modsecurity_crs_11_brute_force.conf ../activated_rules/
# cp modsecurity_crs_11_dos_protection.conf ../activated_rules/
# cp modsecurity_crs_11_proxy_abuse.conf ../activated_rules/

Baixe o banco de dados de Geo Ip para a regra de Proxy Abuse poder funcioar:

# cd ..
# wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
# gunzip GeoLiteCity.dat.gz

Agora modifique o local do db no arquivo modsecurity_crs_11_proxy_abuse.conf:

# pico activated_rules/modsecurity_crs_11_proxy_abuse.conf

Procure a entrada SecGeoLookupDb e deixe assim:

SecGeoLookupDb /etc/apache2/ModSecurity/GeoLiteCity.dat

Agora desative a regra que bloqueia o acesso por ip ao nosso site, comente a linha 98 do arquivo modsecurity_crs_21_protocol_anomalies.conf:

# pico activated_rules/modsecurity_crs_21_protocol_anomalies.conf

Reinicie o Apache

# service apache2 restart

Agora de o comando abaixo para acompanhar os logs gerados pelo Mod Security. Lembre-se que o Mod Security ainda não está bloqueando os ataques, ele está simplesmente gerando alerta. No início é muito importante você não ativar o Mod Security pois você vai receber muitos falsos positivos, o ideal é você analisar os logs e criar as exceções para diminuir o máximo de falsos positivos possíveis.

# tail -f /var/log/apache2/modsec_audit.log

Depois no seu browser, realize algum ataque, pode ser Sql Injection, XSS ou rodar algum scanner como o Nessus, WpScan ou o Nikto, depois veja os alertas sendo gerados no terminal.

Para fazer o Mod Security bloquear os ataques você vai abrir o arquivo modsecurity.conf e procurar a entrada SecRuleEngine:

# pico modsecurity.conf

Deixe a entrada SecRuleEngine assim:

#SecRuleEngine DetectionOnly
SecRuleEngine On

Reinicie o Apache

# service apache2 restart

Agora faça um teste, no seu browser, clique em algum post e coloque uma aspa no final, assim:

http://seu.servidor/?p=1

Você deverá receber um forbidden, isso significa que seu Mod Security está bloqueando os ataques. Como eu disse antes você vai receber bastante falso positivo, principalmente na hoje que tiver logado no WordPress. Para ajustar seu Mod Security você vai precisar criar as exceções, para isso você precisar analisar os logs para ver o que aconteceu. Por exemplo, ao entrar no http://seu.servidor/wp-login.php e tentar logar, você vai receber um Forbidden, então vá até o log e veja o que aconteceu:

# pico /var/log/apache2/modsec_audit.log

Você vai ver algo parecido com isso:

–e02be206-A–
[26/May/2014:02:22:45 –0400] U4LdtVzyjBQAAEp0Gq8AAAAE 192.168.5.104 57870 192.168.5.103 80
–e02be206-B–
POST /wordpress2/wp-login.php HTTP/1.1
Host: 192.168.5.103
Connection: keep-alive
Content-Length: 120
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://192.168.5.103
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.197616.114 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://192.168.5.103/wordpress2/wp-login.php
Accept-Encoding: gzip,deflate,sdch
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: wp-settings-time-1=1401080801; wordpress_test_cookie=WP+Cookie+check
 
–e02be206-C–
log=jo&pwd=123456&wp-submit=Log+In&redirect_to=http%3A%2F%2F192.168.5.103%2Fwordpress2%2Fwp-admin%2F&testcookie=1
–e02be206-F–
HTTP/1.1 403 Forbidden
Content-Length: 303
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
 
–e02be206-E–
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don’t have permission to access /wordpress2/wp-login.php
on this server.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at 192.168.5.103 Port 80</address>
</body></html>
 
–e02be206-H–
Message: Access denied with code 403 (phase 2). Pattern match “^(?i)(?:ht|f)tps?:\\/\\/(\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3})” at ARGS:redirect_to. [file “/etc/apache2/ModSecurity/activated_rules/modsecurity_crs_40_generic_attacks.conf”] [line “154”] [id “950117”] [rev “2”] [msg “Remote File Inclusion Attack”] [data “Matched Data: http://192.168.5.103 found within ARGS:redirect_to: http://192.168.5.103/wordpress2/wp-admin/”] [severity “CRITICAL”] [ver “OWASP_CRS/2.2.9”] [maturity “9”] [accuracy “9”] [tag “OWASP_CRS/WEB_ATTACK/RFI”]
Action: Intercepted (phase 2)
Apache-Handler: application/x-httpd-php
Stopwatch: 1401085365732908 31693 (- – -)
Stopwatch2: 1401085365732908 31693; combined=3047, p1=550, p2=1329, p3=0, p4=0, p5=646, sr=225, sw=522, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.8.0 (http://www.modsecurity.org/); OWASP_CRS/2.2.9.
Server: Apache/2.4.7 (Ubuntu)
Engine-Mode: “ENABLED”
–e02be206-Z—
 

As linhas em negrito são as que mais nos interessa nesse momento, elas nos dizem que ao dar um POST na url /wordpress2/wp-login.php foi gerado um alerta de ID 950117, o que precisamos fazer é criar uma exceção para essa url, abra o arquivo modsecurity.conf e no final no arquivo coloque as seguintes linhas:

<LocationMatch “/wp-login.php”>
  SecRuleRemoveById 950117
</LocationMatch>

Agora reinicie o Apache

# service apache2 restart

Provavelmente você irá receber mais alguns alertas, então você deverá fazer o mesmo processo até que acerte as regras do Mod Security para não gerar mais esses falsos positivos, coloque o Mod Security em DetectionOnly e analise os alertas. É um trabalho bem cansativo mas que faz toda a diferença na segurança de seu site.

Galera é isso ai, espero que esse artigo ajude bastante gente e aumente a segurança dos sites por ai, futuramente irei abordar a instalação do Mod Security no Nginx e mostrar todas ou pelo menos a maioria das exceções que você precisa para usar o WordPress sem tomar block. Até a próxima.

Siga me

Ricardo Galossi

É um apaixonado por segurança da informação, atua profissionalmente há mais de 7 anos na área de tecnologia da informação, onde é focado em análise de vulnerabilidades e testes de invasão.Criou o blog Guia do TI para compartilhar conhecimento, ajudar os mais novos, incentivar debates e manter a comunidade atualizada com as principais notícias da área de TI.
Ricardo Galossi
Siga me

Últimos posts por Ricardo Galossi (exibir todos)

Artigos Relacionados

Ricardo Galossi

É um apaixonado por segurança da informação, atua profissionalmente há mais de 7 anos na área de tecnologia da informação, onde é focado em análise de vulnerabilidades e testes de invasão. Criou o blog Guia do TI para compartilhar conhecimento, ajudar os mais novos, incentivar debates e manter a comunidade atualizada com as principais notícias da área de TI.

3 comentários em “Instalação e Configuração do ModSecurity 2.8 com Apache + Core Rules

Deixe seu comentário