Configurar o Fail2ban para servidores web

Em resumo: O Fail2ban lê ficheiros de registo e bloqueia na firewall os endereços que, dentro de uma janela de tempo, se destacam demasiadas vezes. Para o Nginx e o Apache traz jails prontos, como nginx-botsearch ou apache-noscript; os filtros próprios testa-os com fail2ban-regex. As definições pertencem ao jail.local, os seus próprios endereços ao ignoreip, e os reincidentes apanha-os o jail recidive. Contra ataques dirigidos isolados, o Fail2ban não ajuda; contra análises em massa, sim.

Quando os registos estão cheios de scanners

Quem nestes dias olha para os registos de acesso dos seus servidores web encontra-os muitas vezes cheios de pedidos a caminhos que nem existem: interfaces de administração antigas, ficheiros de teste, vulnerabilidades conhecidas de outros produtos. Numa situação como a do PHP2Shell, acresce a procura dirigida de servidores vulneráveis: a Cloudflare e a Patchstack relataram tentativas de ataque, e a Unit 42 contou mais de 22,6 milhões de instâncias expostas e potencialmente vulneráveis.

O Fail2ban é uma ferramenta comprovada contra esta massa. Lê ficheiros de registo, reconhece com filtros entradas invulgares e bloqueia o endereço do remetente durante um tempo definido na firewall. Isso alivia o servidor, reduz o ruído nos registos e torna mais trabalhosa a tentativa sistemática a partir de uma só origem.

O que o Fail2ban não consegue é igualmente importante: um único pedido que explore uma vulnerabilidade não é impedido. Contra o PHP2Shell, só ajuda a atualização do PHP. Como decorrem os ataques automatizados é descrito em Análises em massa ao PHP sem patch.

Fail2ban para Nginx e Apache: os jails fornecidos

Um jail liga um filtro a um ficheiro de registo e a uma ação de bloqueio. O jail.conf fornecido já contém jails para servidores web. Estão por defeito desativados e são ativados individualmente.

Os valores por defeito da configuração fornecida são antes suaves: bloqueio de 10 minutos após 5 ocorrências em 10 minutos. Para servidores web com muito tráfego de análise, vale a pena um bloqueio mais longo e um fator crescente para repetições.

A configuração de base no jail.local

O jail.conf diz ele próprio que não deve ser alterado, porque as atualizações o substituem. Os valores próprios pertencem a /etc/fail2ban/jail.local. O exemplo seguinte para o Nginx define padrões sensatos e ativa jails adequados:

# /etc/fail2ban/jail.local
[DEFAULT]
# Registar os seus próprios endereços fixos (substituir o endereço de exemplo)
ignoreip = 127.0.0.1/8 ::1 203.0.113.10
bantime  = 1h
findtime = 10m
maxretry = 5
bantime.increment = true

[nginx-http-auth]
enabled = true

[nginx-botsearch]
enabled = true

[recidive]
enabled  = true
bantime  = 1w
findtime = 1d

Para o Apache, ative em vez disso, por exemplo, apache-auth, apache-noscript e apache-botsearch. Os caminhos de registo vêm com o Fail2ban consoante a distribuição; se os seus caminhos divergirem, defina logpath no respetivo jail. Se o seu sistema ler registos apenas através do journal, ajuda backend = systemd.

Um filtro próprio para pedidos em massa a ficheiros PHP

Um padrão típico na situação atual são muitos pedidos em pouco tempo a ficheiros PHP que não existem. Um filtro próprio reconhece-o pelo código de estado 404. Descreve apenas o que consta do seu próprio registo:

# /etc/fail2ban/filter.d/nginx-php-404.conf
[Definition]
failregex = ^<HOST> -.*"(GET|POST|HEAD) [^"]*\.php[^"]*" 404
ignoreregex =

# Complemento em /etc/fail2ban/jail.local
[nginx-php-404]
enabled  = true
port     = http,https
filter   = nginx-php-404
logpath  = /var/log/nginx/access.log
maxretry = 20
findtime = 1m
bantime  = 1h

Antes de ativar o filtro, verifique-o contra o registo real. Assim vê quantas linhas atinge e se há acessos legítimos entre elas:

fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-php-404.conf
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status nginx-php-404
# Libertar um endereço bloqueado por engano
sudo fail2ban-client set nginx-php-404 unbanip 203.0.113.25

Escolha o limiar com generosidade. Um rastreador que percorre ligações desatualizadas ou um serviço de monitorização não pode acabar no bloqueio.

As armadilhas mais frequentes

O Fail2ban instala-se depressa, mas usa-se facilmente de forma errada. Estes pontos devem ser verificados antes do uso em produção:

1. Autobloqueio: os endereços do escritório, da VPN e da monitorização pertencem ao ignoreip antes de os jails ficarem ativos.
2. Serviços intermédios: atrás de uma CDN ou de um balanceador de carga, o Fail2ban vê, sem adaptação, apenas os endereços destes. Mais informação no guia Proteger inícios de sessão de administração contra força bruta.
3. Rotação de registos: após a mudança do ficheiro de registo, o Fail2ban tem de ler o novo ficheiro. Verifique, após a primeira rotação, se os jails continuam a contar ocorrências.
4. Interação com a firewall: o Fail2ban regista os bloqueios na firewall. Quem gere a sua firewall com um recarregamento completo do conjunto de regras pode apagar essas entradas. Como construir a própria firewall está em Firewall para servidores web: abrir só as portas necessárias.
5. IPv6: os ataques chegam também por IPv6. Verifique se a sua ação de bloqueio cobre ambos os protocolos.

Conclusão: uma ferramenta contra a massa, não contra tudo

O Fail2ban configura-se depressa e retira aos servidores web uma parte do bombardeamento contínuo. Os jails fornecidos cobrem padrões típicos, os filtros próprios podem ser testados sem perigo contra registos reais com fail2ban-regex, e o jail recidive garante que as origens persistentes ficam mais tempo de fora.

Não o sobrestime. O Fail2ban reage à repetição, não à primeira ocorrência, e só vê o que consta dos registos. Contra uma vulnerabilidade como o PHP2Shell ajuda apenas a atualização; contra ataques distribuídos a partir de muitos endereços, o Fail2ban ajuda pouco. O seu valor revela-se como uma camada entre várias: ao lado de uma firewall enxuta, de uma configuração reforçada do servidor web, de autenticação de dois fatores e de uma monitorização que não só bloqueia as anomalias, mas também as comunica.

Como ajuda concretamente a PHP SOS?

• Analisar registos: vemos que padrões surgem nos seus registos de acesso e escolhemos os jails adequados.
• Configurar e testar: configuramos o Fail2ban com filtros próprios, testamos cada filtro contra registos reais e registamos os seus endereços fixos como exceção.
• Esclarecer a interação: CDN, balanceador de carga, firewall e rotação de registos são articulados por nós de modo que os bloqueios atinjam os endereços certos.
• Observar: no âmbito da monitorização de segurança, analisamos continuamente bloqueios e anomalias.

Perguntas frequentes

Fontes

• Fail2ban: jail.conf fornecido
• BSI IT-Grundschutz
• OWASP Cheat Sheets