Fernando Costa

IntroduçãoPra não reinventar a roda, e desenvolver um sistema de blog que eu confiasse (bom-prático-seguro), eu decidi utilizar o WordPress depois de pouca pesquisa na internet, confesso que fiquei em dúvida entre o WordPress e o Drupal, mas por “sorteio” acabei escolhendo o WordPress mesmo sem conhecê-lo a fundo.

E agora, confiar ou não confiar no código?

Depois de algumas experiências frustantes com alguns pseudo-CMS (não vou falar nomes para não ofender ninguém), decidi por não confiar em código nenhum, sendo assim tive que estudar alguma técnica de segurança externa ao código do WordPress, pois por ele a única coisa que quero fazer eu mantê-lo sempre atualizado no meu servidor.

A melhor prática de segurança para mim é o BACKUP, e como esta prática já esta sendo feita parti para outra técnica pró-ativa e não reativa.

O apache possui diversos módulos, confesso que entendo um pouco sobre cada um deles, sabia que existia formas de filtros com expressões regulares no apache, mas confesso que não conhecia o suficiente para me sentir seguro com meia dúzia de regras. O tal módulo de segurança é o ModSecurity.

Visão Geral

O ModSecurity funciona como um FIREWALL para aplicativos WEB, que foi desenvolvido exatamente com este princípio de dar segurança a aplicações web pois, segundo a documentação do ModSecurity, 70% de todos os ataques estão no nível de aplicações WEB tornando assim estes sistemas online seguros.

O ModSecurity é um WAF(Web Application Firewall) que funciona em tempo real, sendo assim ele tem o poder de detectar, e impedir um ataque antes de chegar a aplicação web. Uma grande vantagem de utilizá-lo e por ele prover a segurança independente de alterações no código da aplicação, sem alterações na rede, e diferentemente de outros IDS (Intrusion detection system), ele trabalha com dados Criptografados ou Compactados sem problema algum pois no momento que ele aplica suas regras, estes dados não estão compactados ou criptografados.

É possíve implementar o ModSecurity usando o ProxyPassReverse também, isso significar que é possível fazer um proxy/firewall HTTP que protege todos os servidores que ficam “abaixo” dele.

Lógica de Funcionamento

O ModSec. funciona da seguinte forma:
- Baseado em regras ele detecta tentativas de ataques;
- As regras seguintes determinam as ações a serem tomadas caso seja detectada a tentativa de ataque;

Utilização

Agora que já sabemos quem é, e como funciona o modsecurity, e como eu não tenho pretensão em fazer um Manual dele neste post e sim somente mostrar um técnica de como proteger um sistema intrinsicamente vamos para as regras:

É possível utilizar o ModSecurity em vários directivas dos Apache como VirtualHost, Location, LocationMatch, Directory, etc.

Abaixo um exemplo de utilização:

MANUAL ONLINE: http://www.modsecurity.org/documentation/modsecurity-apache/2.1.2/

<VirtualHost www.dominio_protegido.com.br>

# Definição do domínio deste VirtualHost
ServerName www.dominio_protegido.com.br

# Diretório raiz do site
DocumentRoot /home/www.dominio_protegido.com.br

# Sim, para habilitar o motor de filtros
SecFilterEngine On

# Habilita o filtro em requisições HTTP do tipo POST
SecFilterScanPOST On

# Habilita o filtro nas respostas das requisições HTTP
SecFilterScanOutput On

# Check URL encoding
SecFilterCheckURLEncoding On

# This setting should be set to On only if the Web site is
# using the Unicode encoding. Otherwise it may interfere with
# the normal Web site operation.
SecFilterCheckUnicodeEncoding Off

# Only allow certain byte values to be a part of the request.
# This is pretty relaxed, most applications where only English
# is used will happily work with a range 32 – 126.
SecFilterForceByteRange 1 255

# Audit log logs complete requests. Configured as below it
# will only log invalid requests for further analysis.
SecAuditEngine RelevantOnly
SecAuditLog logs/audit_log

# Command execution attacks
SecFilter /etc/password
SecFilter /bin/ls
SecFilter /bin/lynx
SecFilter /bin/wget
SecFilter /bin/curl
SecFilter /bin/links

# Directory traversal attacks
SecFilter “\.\./”

# XSS attacks
SecFilter “<(.|\n)+>”
SecFilter “<[[:space:]]*script”

# SQL injection attacks
SecFilter “delete[[:space:]]+from”
SecFilter “insert[[:space:]]+into”
SecFilter “select.+from”

# MS SQL specific SQL injection attacks
SecFilter xp_enumdsn
SecFilter xp_filelist
SecFilter xp_availablemedia
SecFilter xp_cmdshell
SecFilter xp_regread
SecFilter xp_regwrite
SecFilter xp_regdeletekey

# Protecting a vulnerable script
# Some PHP applications are vulnerable when a register_globals configuration option is turned on,
# allowing attackers to set an internal variable to a value of their choice. This usually leads to
# attacker executing some code on the server. Here is an example from the real world (Cafelog
# b2, http://www.securityfocus.com/bid/7786):

SecFilterSelective ARG_b2inc “!^$”

# Protecting from XSS attacks through the PHP session cookie
# PHP versions prior to 4.3.2 are vulnerable to XSS attacks carried out through the session
# identifier (http://www.securityfocus.com/bid/7761). If you can’t upgrade your PHP version to
# the latest version you can still protect yourself:

SecFilterSelective ARG_PHPSESSID “!^[0-9a-z]*$”
SecFilterSelective COOKIE_PHPSESSID “!^[0-9a-z]*$”

# Stop FormMail from being used to send spam
# Some versions of FormMail can be used to send email to arbitrary email addresses. The
# following rule demonstrates how you can have a filter applied only to certain locations, in this
# case just the FormMail script. The request will be rejected if the email is intended to any address
# except the one ending in “@modsecurity.org”:

<Location /cgi-bin/FormMail>
SecFilterSelective “ARG_recipient” “!@modsecurity\.org$”
</Location>

# Restrict administrative login to an IP address
# Here is a nice one. I have this application where the administrator logs in through the same log
# in panel as other users, but I still wanted to restrict administration login to certain IP addresses.
# So I used two chained rules. The second rule will apply only if the first rule matches; in this case
# – if the incoming username is “admin”.

SecFilterSelective ARG_username admin chain
SecFilterSelective REMOTE_ADDR “!^ADMIN_IP_ADDRESS_HERE$”

# Preventing information leak
# In all versions of PHP, if a fatal error occurs the script will be terminated immediately (standard
# error handling routine will not be invoked). Information leak through these problems can be
# prevented by scanning the output and preventing it from reaching the user if it contains error
# messages.

SecFilterSelective OUTPUT “Fatal error:”

# Detecting intrusions
# Output filtering can also be used to detect successful intrusions. These rules will monitor output
# and detect typical keywords resulting from a command execution on the server.

SecFilterSelective OUTPUT “Volume Serial Number”
SecFilterSelective OUTPUT “Command completed”
SecFilterSelective OUTPUT “Bad command or filename”
SecFilterSelective OUTPUT “file(s) copied”
SecFilterSelective OUTPUT “Index of /cgi-bin/”
SecFilterSelective OUTPUT “.*uid\=\(”

# Você poderá precisar desta opção habilitada depois mas nunca deixe
# esta opção habilitada por definitivo pois debugar as regras pode deixar
# o servidor muito lento
SecFilterDebugLevel 0
SecFilterDebugLog logs/dominio_protegido.com.br-modsec_debug_log

# A ação padrão tomada para requisições negadas é o status 500
SecFilterDefaultAction “deny,log,status:500″

# Escreva suas regras do mod_security aqui
# …
</VirtualHost>

Para fazer regras efetivas é necessário ter conhecimentos de cabeçalhos e corpos de requisições e respostas HTTP, e ter uma mente bem fértil para imaginar as falcatruas que usuários ou programas mal-intencionados podem fazer… boa sorte em suas construções!

Algumas regras