O que é
O fail2ban é o coração da defesa do GW Server. Ele lê os logs, identifica padrões de ataque e bane os IPs automaticamente. O painel já vem com cerca de 50 jails personalizadas, criadas a partir de anos de logs reais de ataque analisados: regras muito bem definidas para cada tipo de ameaça conhecida.
As jails personalizadas
As jails protegem as áreas conhecidas como críticas. Elas detectam, entre outros:
- Brute force no login do painel e no SSH
- Tentativas de login no WordPress (ver Proteção do WordPress)
- Scanners buscando
.env,.git, backups e outros arquivos sensíveis - Atacantes persistentes: pegos com mais rigor
- Flood em sites WordPress: um mesmo IP pedindo páginas demais em pouco tempo
- Ataques específicos a Mautic, n8n e outras aplicações
Cada tipo de site ativa as jails próprias dele: um WordPress recebe jails de WordPress; um Mautic, de Mautic; e assim por diante. Você vê os IPs banidos e os padrões nos logs do site.
Onde ficam
- Global (Configurações → Fail2ban): as jails do servidor e do painel, ativas desde a instalação. Aqui você vê os IPs banidos, desbloqueia um deles e ajusta a lista de liberados.
- Por site (aba Segurança do site): as jails específicas do site, que você ativa individualmente ao instalar (ver Proteção do WordPress).
Um ataque real, visto por dentro
Um exemplo concreto (registrado em vídeo): uma instalação de Mautic recém-criada recebeu, em poucas
horas, um bot varrendo o site: visível no rastreador de contatos do Mautic e nos
logs. O IP procurava alvos clássicos: sitemap, .env, wp-config.php,
wp-config.backup, .git, docker-compose, ou seja, falhas conhecidas de WordPress e de
aplicações Docker, mesmo o alvo sendo um Mautic.
Duas lições disso:
- A varredura é constante. Há centenas de bots vasculhando todos os sites o tempo todo. Não é pessoal: é ruído de internet. O que importa é ter as jails ativas para bani-los.
- Regras cruzadas. Como os atacantes usam o mesmo repertório em qualquer alvo, o GW Server aplica também no Mautic (e em outras aplicações) as regras que protegem contra varreduras de WordPress e de Docker. Cada aplicação nova abre novas portas de ataque, e o sistema evolui a cada atualização justamente por isso: mais um motivo para manter o painel atualizado.
O Mautic ajuda aqui por acaso: ele registra as visitas de forma visual (no rastreador de contatos), o que torna um ataque fácil de enxergar. Mas o essencial está sempre nos logs: é deles que o fail2ban extrai os padrões para banir. Ver Geolocalização de leads para o rastreador do Mautic.
Quanto tempo dura o bloqueio
Depende do que o IP fez. A ideia é simples: errar uma senha não é o mesmo que procurar uma brecha.
| O que o IP fez | Bloqueio |
|---|---|
| Errou a senha no login do site | o que você definir na aba Segurança do site, por padrão 1 hora |
| Pediu páginas que não existem em excesso, ou fechou conexões de forma suspeita | 1 a 24 horas |
Procurou brecha: arquivos .env e .git, backdoor em PHP, caminhos de outros sistemas, lista de usuários, endereço interno da nuvem |
7 dias, e dobra a cada vez que ele volta, até 30 dias |
| Insistiu a ponto de levar 3 bloqueios em qualquer jail dentro de 7 dias | mais 24 horas, agora cobrindo também a porta do painel |
O bloqueio longo da terceira linha é a mudança mais recente. O motivo veio de medição em servidor
real: a maior parte dos IPs bloqueados voltava depois que o bloqueio de 24 horas vencia, e um
deles derrubou o desempenho de um site justamente numa dessas voltas. Como ninguém procura
/.env por acidente, esse tipo de acesso passou a custar caro.
Login errado nunca entra nessa escalada. Você, seu cliente ou um visitante que erra a senha continua com o bloqueio curto de sempre. A escalada só vale para a varredura, que visitante nenhum faz sem querer.
Nenhum desses bloqueios fecha a porta SSH: ela fica de fora de propósito, coberta só pela jail própria do SSH. É assim que o dono do servidor nunca fica trancado para fora por completo: o SSH continua disponível para você se destravar. Ver CLI de emergência (gws-cli).
Liberando o seu IP
A lista de liberados (a whitelist) é a relação de IPs que o fail2ban nunca bane, aconteça o que acontecer.
Coloque o seu IP nessa lista. Sem isso, uma sequência de tentativas suas: errar a senha algumas vezes, testar uma URL, rodar uma ferramenta: pode fazer o fail2ban banir você do seu próprio servidor. O IP usado na instalação já entra sozinho.
- Descubra seu IP (busque “qual é o meu IP” ou acesse um site como meuip.com).
- Em Configurações → Fail2ban, adicione o IP à lista de liberados.
Se a sua internet é residencial, o IP costuma mudar de tempos em tempos. Se um dia o painel parar de responder só para você, é provável que o IP novo não esteja na lista: o desbloqueio abaixo resolve.
Desbloquear um IP
Se um IP legítimo foi banido (o seu, o de um cliente, o do escritório), informe o endereço na função de desbloqueio e ele é liberado na hora. Para não se repetir, acrescente também à lista de liberados.
Se o próprio IP banido é o que impede o acesso ao painel (ele bane as portas 80/443/22222, não a
22), o acesso por SSH continua de pé. Rode sudo gws-cli liberar no servidor: ele solta o ban e
já adiciona o IP à lista de liberados num só comando, sem precisar abrir o painel. Ver
CLI de emergência (gws-cli).
Firewall de portas
O painel tem um firewall clássico de portas, que libera automaticamente as principais: 22 (SSH), 80 e 443 (web) e 22222 (o acesso de emergência ao painel).
Se você usa SMTP, pode precisar liberar a porta 587 (ou a alternativa do seu provedor) no firewall. Adicione a regra, aplique e confirme. Ver E-mail e SMTP.
O firewall evita que aplicações fiquem escaneando portas abertas sem serviço. O cuidado principal é liberar exatamente as portas que você precisa, nem mais, nem menos.
