Qualquer instalação do WHMCS exposta publicamente é bombardeada com tentativas de login de força bruta poucas horas após entrar em operação. O Fail2ban monitora seus logs, detecta falhas repetidas e bloqueia automaticamente os IPs ofensivos. Este guia o configura para o WHMCS (e a pilha SSH + web ao redor dele) no Ubuntu.

Pré-requisitos

  • Ubuntu 22.04 com acesso root
  • WHMCS rodando atrás de nginx ou Apache
  • Registro de atividades do WHMCS habilitado (é por padrão)

Passo 1 — Instalar o Fail2ban

apt update
apt install -y fail2ban
systemctl enable fail2ban

Passo 2 — Criar uma configuração de jail local

Nunca edite jail.conf diretamente (atualizações o sobrescrevem). Crie /etc/fail2ban/jail.local:

[DEFAULT]
# Ban for 1 hour after 5 failures within 10 minutes
bantime  = 3600
findtime = 600
maxretry = 5
# Ignore your own IPs (office, home, monitoring)
ignoreip = 127.0.0.1/8 ::1 YOUR.OFFICE.IP

[sshd]
enabled = true
port    = 2222

Ajuste port para a sua porta SSH real e adicione seus IPs estáticos a ignoreip para nunca se bloquear.

Passo 3 — Habilitar banimentos escalonados para reincidentes

A jail recidive bane IPs que continuam retornando após a expiração do primeiro banimento — por muito mais tempo:

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
banaction = iptables-allports
bantime  = 604800   ; 1 week
findtime = 86400    ; 1 day
maxretry = 3

Passo 4 — Criar um filtro WHMCS

O WHMCS registra logins de administrador falhos em seu banco de dados, mas também escreve no log do servidor web em acessos repetidos. A abordagem mais limpa é um filtro no próprio log de falhas de login do WHMCS. Primeiro, aponte o WHMCS para um arquivo de log — ou analise o log de acesso web para o endpoint de login.

Crie /etc/fail2ban/filter.d/whmcs.conf:

[Definition]
# Matches failed admin/client login POSTs returning to login page
failregex = ^<HOST> .* "POST /(dologin|admin/login)\.php.* 200
            ^<HOST> .* "POST /index\.php\?rp=/login.* 200
ignoreregex =

Este é um padrão inicial — ajuste failregex à sua estrutura de URL e template do WHMCS. O segredo é corresponder ao POST de login do IP do cliente.

Passo 5 — Adicionar a jail do WHMCS

Adicione ao final de /etc/fail2ban/jail.local:

[whmcs]
enabled  = true
port     = http,https
filter   = whmcs
logpath  = /var/log/nginx/access.log
maxretry = 5
findtime = 600
bantime  = 7200

Aponte logpath para o seu log de acesso real do nginx/Apache para o vhost do WHMCS.

Passo 6 — Cuidado com o problema do IP real

Se o WHMCS estiver atrás de uma CDN ou proxy reverso, seu log de acesso mostrará o IP da CDN, não o do visitante — o Fail2ban baniria a CDN e derrubaria todo o seu site.

Corrija isso no nginx restaurando o IP real primeiro. Para SprintCDN ou Cloudflare, adicione seus intervalos a uma configuração de IP real:

# /etc/nginx/snippets/realip.conf
set_real_ip_from 1.2.3.0/24;   # your CDN's ranges
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Inclua-o no seu bloco de servidor e certifique-se de que o formato do log use $remote_addr (que agora reflete o cliente real). Somente então o Fail2ban banirá o IP correto.

Passo 7 — Iniciar e verificar

systemctl restart fail2ban
fail2ban-client status

Você deve ver suas jails ativas: sshd, recidive, whmcs. Verifique uma jail específica:

fail2ban-client status sshd

Isso mostra os IPs atualmente banidos e as contagens totais.

Passo 8 — Testar se funciona

De um IP descartável (um telefone com dados móveis funciona), falhe deliberadamente o login SSH ou o login WHMCS 6 vezes. Em seguida, no servidor:

fail2ban-client status sshd
# Should list the test IP under "Banned IP list"
iptables -L -n | grep <TEST_IP>

Desbanir quando terminar:

fail2ban-client set sshd unbanip <TEST_IP>

Passo 9 — Receber notificações de banimentos (opcional)

O Fail2ban pode enviar e-mail a você a cada banimento. Em jail.local sob [DEFAULT]:

destemail = you@yourdomain.com
sender    = fail2ban@yourdomain.com
action    = %(action_mwl)s

action_mwl = banimento + e-mail com whois + linhas de log, para que você tenha contexto sobre quem está atacando.

Defesa em camadas

O Fail2ban lida com a camada de aplicação, mas ataques volumétricos (alguém lançando 50 Gbit/s na sua página de login) precisam de defesa em nível de rede. Na Hostfory, o DDoS scrubbing absorve a camada volumétrica antes que ela chegue ao seu servidor, e o Fail2ban limpa os ataques de força bruta inteligentes e de baixo volume que escapam. Use ambos.

Solução de problemas

Fail2ban não bane ninguém: seu failregex não corresponde às linhas de log. Teste-o: fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/whmcs.conf. Ele mostra quantas linhas foram correspondidas.

Fail2ban baniu minha CDN / toda a minha base de usuários: o problema do IP real do Passo 6. Você está lendo o IP do proxy. Corrija a restauração do IP real antes de reativar.

Você se bloqueou: se você tiver acesso via console/IPMI (incluído em todos os servidores dedicados da Hostfory), acesse por essa via e adicione seu IP a ignoreip. É por isso que o IPMI é importante.

Próximos passos

Combine isso com um túnel de gerenciamento WireGuard para que o SSH nem seja exposto publicamente, e restrinja o caminho de administração do WHMCS ao IP do seu escritório no nível do nginx. A defesa em profundidade supera qualquer controle único.