Como proteger sua VPS com Fail2ban, UFW e Cloudflare

UFW, Fail2ban e Cloudflare não tornam uma VPS inviolável. Eles reduzem riscos distintos: portas expostas, tentativas repetidas de acesso e tráfego web. Para quem roda apps self-hosted, a configuração útil é a que mantém SSH acessível, protege o origin corretamente e inclui backup com restore testado.

Subir um app em Docker costuma ser a parte divertida. A operação começa depois: portas abertas, logs, atualizações, credenciais e uma recuperação possível quando algo sai errado.

A proposta aqui não é montar um SOC de empresa grande. É criar uma Operação Mínima Viável: poucos controles, com propósito claro e uma rotina que um solo builder consegue manter. Ela não substitui correções do sistema, senha ou chave bem gerenciada, nem um plano de recuperação.

Seu app subiu. Agora começa a operação

Uma VPS que roda n8n, WordPress, Dify ou outro serviço self-hosted acumula superfícies diferentes. Há o acesso administrativo por SSH. Há o tráfego do site. Há portas de banco, painel e proxy reverso. E há dados que precisam voltar caso um volume seja apagado ou corrompido.

O erro comum é tratar tudo como um único problema chamado “segurança”. Não é. Um proxy web não cobre SSH. Um banimento de IP não recupera banco de dados. Um firewall não corrige uma aplicação desatualizada.

A documentação do Docker é direta sobre um ponto que merece prioridade: acesso não autorizado ao daemon ou ao socket do Docker pode equivaler a controle administrativo do host. Por isso, publicar o socket, um banco ou um painel de administração por conveniência muda o risco da VPS. Veja as recomendações para proteger o acesso ao Docker daemon antes de expor esse tipo de interface.

A Operação Mínima Viável começa com uma pergunta simples: quais serviços precisam receber tráfego público? O restante não deve ganhar uma porta aberta “só para facilitar”.

UFW, Fail2ban e Cloudflare resolvem problemas diferentes

O trio funciona melhor quando cada peça tem um trabalho definido. UFW controla quais conexões chegam ao host. Fail2ban acompanha logs e reage a falhas repetidas. Cloudflare fica na frente do tráfego web compatível com seu proxy.

UFW reduz portas expostas

O UFW é uma interface para firewall Linux. Seu manual documenta ações como allow, deny, limit, enable e políticas padrão. Isso ajuda a transformar a lista de serviços necessários em regras explícitas, sem depender de lembrar o que ficou aberto meses atrás.

O risco aqui é lockout. Antes de habilitar uma política restritiva, preserve a sessão SSH atual, confirme que há uma rota de recuperação pelo console do provedor e crie uma regra para o acesso SSH que você usa. Não comece negando tudo e torça para a regra seguinte resolver.

Em Ubuntu, uma sequência conservadora para conferir o caminho é:

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

Esses comandos não definem todas as portas da sua aplicação. Eles só preservam o serviço SSH identificado pelo perfil OpenSSH, habilitam o UFW e mostram o estado. Se você usa uma porta ou método diferente, consulte antes o manual do UFW e mantenha uma sessão conectada enquanto valida a regra.

Depois disso, abra apenas os serviços que precisam ser públicos. Para uma aplicação web, 80 e 443 podem fazer sentido. Banco de dados, Redis, Portainer e painéis não devem virar regra pública por padrão. A necessidade depende da arquitetura, não da lista de comandos mais copiada da internet.

Fail2ban reage a padrões nos logs

O Fail2ban examina logs, como o de autenticação, e pode criar regras temporárias de firewall após falhas repetidas. A finalidade é reduzir tentativas persistentes contra um serviço que registra esses eventos.

Isso não é uma promessa de que alguém não entrará. O próprio projeto deixa claro que o Fail2ban não elimina riscos de autenticação fraca. Chave SSH, controle de acesso e atualização continuam sendo necessários. A referência de comportamento é a documentação do Fail2ban.

Após configurar uma jail aplicável ao SSH, verifique se ela existe e está ativa. O comando abaixo é útil porque mostra o estado, sem alterar porta, regra ou banimento:

sudo fail2ban-client status sshd

Não existe um maxretry, findtime ou bantime universal. Um valor agressivo pode bloquear uma pessoa legítima atrás de NAT. Um valor permissivo pode reduzir pouco as tentativas. Ajuste com base nos logs do seu serviço e em uma rota de acesso de emergência.

Cloudflare fica na frente do tráfego web, não de tudo

O proxy da Cloudflare atende tráfego HTTP/HTTPS em portas documentadas. SSH na porta 22, banco de dados e a maior parte das portas administrativas não passam por esse proxy web. Portanto, ativar a nuvem laranja no DNS não “fecha a VPS”.

A documentação de portas compatíveis da Cloudflare é a referência para conferir se o serviço web está no caminho esperado. Para SSH e interfaces administrativas, a proteção continua dependendo de regras no host, firewall de rede e desenho de acesso.

A leitura do Runzos é prática: use Cloudflare como camada web, não como atalho mental para chamar o servidor inteiro de protegido. Essa distinção evita deixar uma porta administrativa exposta enquanto o site parece bem coberto no navegador.

A configuração mínima sem se trancar fora da VPS

Antes de mexer em regras, desenhe o caminho de acesso. Você precisa saber como entra na VPS, qual serviço atende o público e como recupera o controle caso erre uma regra.

Alerta anti-lockout: mantenha a sessão SSH atual aberta. Confirme chave SSH e console do provedor antes de tornar a entrada restritiva. Só então valide novas regras em outra sessão.

Uma ordem razoável é esta:

1. Identifique os serviços realmente públicos: SSH, proxy web ou aplicação.
2. Confirme que o SSH está acessível pelo método pretendido.
3. Crie a regra de SSH antes de habilitar uma política de entrada restritiva.
4. Habilite e confira o UFW com uma segunda sessão ainda ativa.
5. Instale e habilite o Fail2ban apenas para jails cujos logs você consegue verificar.
6. Revise serviços publicados por Docker, principalmente painéis, bancos e socket do daemon.

Não copie uma configuração completa de outra VPS. A mesma porta pode ser necessária num host e inadequada em outro. A melhor regra é aquela que corresponde a um serviço que você consegue nomear e manter.

Se você usa Docker Compose, separe a rede interna dos serviços que não precisam sair para a internet. Uma aplicação pode falar com PostgreSQL ou Redis sem que esses componentes precisem receber conexões públicas. Essa decisão reduz exposição, mas não é substituto para credenciais, atualização de imagens e backup.

Portainer também merece o mesmo cuidado. Ele simplifica a administração de containers, mas não deve receber uma abertura pública automática apenas porque facilita a operação. Se houver painel, defina quem precisa acessá-lo, por qual caminho e com qual controle adicional.

O objetivo não é ter a lista de regras mais longa. É poder explicar cada exceção. Quando uma porta deixa de ser necessária, a revisão deve removê-la de forma planejada, com acesso de recuperação disponível.

Se usa Cloudflare, não ignore o IP real e o TLS do origin

Cloudflare ajuda a intermediar o tráfego web. Para que isso não crie uma configuração enganosa, duas perguntas importam: o origin só aceita o tráfego esperado? E os logs registram quem realmente visitou a aplicação?

Por que Fail2ban pode ver o IP errado

Atrás da Cloudflare, o origin pode registrar o IP da própria Cloudflare em vez do visitante. O endereço original é enviado no cabeçalho CF-Connecting-IP. Nginx pode usar real_ip_header e faixas confiáveis para restaurar esse contexto nos logs.

Mas há uma condição importante: não basta confiar cegamente no cabeçalho. Primeiro, o origin precisa aceitar o tráfego proxied apenas conforme as faixas atuais da Cloudflare. Caso qualquer origem consiga chegar direto à aplicação, um cliente poderia tentar enviar cabeçalhos que não deveriam ser confiados.

A Cloudflare orienta permitir suas faixas de IP no origin e manter o firewall alinhado a elas. Consulte as faixas de IP da Cloudflare na fonte oficial, em vez de congelar uma lista em um tutorial. Para o ajuste do cabeçalho e do servidor web, siga o material sobre restaurar o IP original do visitante.

Esse detalhe importa para auditoria de logs e para qualquer banimento baseado em tráfego HTTP. Sem ele, uma regra pode reagir ao endereço errado. Com ele mal configurado, você pode confiar em uma origem que não deveria.

Full (strict) é o estado final; Flexible não é

O cadeado do navegador não conta toda a história. No modo Flexible, o trecho entre visitante e Cloudflare pode usar HTTPS, mas o trecho entre Cloudflare e a VPS não é criptografado. Para produção, isso não deveria ser o estado final.

Quando o origin tem certificado válido, a recomendação é Full (strict). Esse modo valida o certificado no origin, que pode vir de uma autoridade pública ou da Cloudflare Origin CA. A documentação oficial descreve Full (strict) e explica os limites de Flexible.

A recomendação não elimina a necessidade de atualizar o origin ou revisar regras de firewall. Ela apenas fecha uma lacuna de transporte entre Cloudflare e VPS.

O que o trio não cobre: Docker, backup e restore

Firewall, banimento e proxy reduzem exposição. Eles não trazem de volta um volume apagado, um banco corrompido ou uma credencial comprometida.

Também não é prudente assumir que o proxy web esconde serviços de administração. Docker socket, banco de dados e painéis expostos por engano continuam sendo problemas de arquitetura. SSH e banco não entram no proxy web padrão da Cloudflare, então precisam de regras próprias e acesso deliberado.

Um firewall de rede do provedor pode complementar o UFW. A DigitalOcean descreve seu Cloud Firewall como stateful e separado do firewall do host. A ideia útil aqui não é trocar um pelo outro, mas bloquear em mais de uma camada quando o provedor oferece esse recurso. Isso não remove a necessidade de regras locais, porque o host ainda precisa saber quais serviços aceita.

O outro limite é backup. Ter um snapshot ou arquivo armazenado não prova que a recuperação funciona. Um backup só vira parte da Operação Mínima Viável quando há um caminho de restore ensaiado em ambiente isolado ou quando você tem evidência de que os dados necessários voltaram.

Registre o que foi restaurado, de onde veio o backup e como o acesso de emergência funciona. Sem esse teste, a frase honesta é “backup configurado”, não “recuperação garantida”.

Stack mínima por cenário e quando usar firewall do provedor

A tabela abaixo é uma recomendação editorial para organizar a operação. Não é benchmark, nem substitui requisitos específicos da sua aplicação.

Um firewall de rede do provedor entra antes do host e pode limitar tráfego que nunca deveria chegar à VPS. Ele é uma camada complementar. UFW continua útil para expressar a política local, e Fail2ban continua dependente dos logs do serviço que você quer proteger.

Se a sua operação precisa de uma VPS para apps self-hosted, o ponto de partida comercial deve vir depois dessa arquitetura, não no lugar dela. Compare a infraestrutura na página de VPS e infraestrutura recomendada para rodar apps self-hosted. Para uma alternativa de VPS brasileira voltada a n8n e Coolify, consulte a oferta de VPS para n8n da Servla. Ambas as escolhas ainda exigem a configuração e a manutenção descritas neste artigo.

Checklist operacional antes de escolher a infraestrutura

Marque estes itens apenas quando puder verificar cada um:

• SSH por chave e método de recuperação definidos.
• Regra de SSH criada e sessão atual preservada antes de restringir entrada.
• UFW expondo somente os serviços necessários.
• Fail2ban ativo na jail aplicável e status conferido.
• Aplicação web proxied usando Full (strict), não Flexible.
• Origin aceitando HTTP/HTTPS proxied conforme as faixas atuais da Cloudflare.
• Logs preservando o IP do visitante quando esse dado for necessário.
• Docker socket, banco e painel administrativo sem publicação acidental.
• Backup existente e ao menos um restore testado.
• Atualizações de sistema, containers e dependências com responsável e periodicidade.

Para WordPress e hospedagem gerenciada, a oferta Turbo Cloud é uma rota comercial contextual. Ela não é uma garantia de hardening, backup ou disponibilidade. Confira os termos atuais na página da oferta antes de contratar.

FAQ: dúvidas práticas sobre VPS, UFW, Fail2ban e Cloudflare

Cloudflare substitui UFW ou Fail2ban?

Não. Cloudflare atua no tráfego web HTTP/HTTPS em portas compatíveis com seu proxy. UFW controla a entrada no host Linux. Fail2ban reage a eventos registrados em logs. Os três podem ser complementares, mas nenhum substitui atualização, credenciais bem controladas, proteção do Docker socket ou backup com restore testado.

Posso bloquear a porta 22 depois de configurar a VPS?

Só faça alterações de SSH com uma rota de recuperação. Preserve a sessão atual, confirme a chave SSH e o console do provedor, crie a regra necessária antes de habilitar uma política restritiva e teste por uma segunda sessão. Fechar ou mudar o acesso sem esse plano pode bloquear você fora da VPS.

Por que Fail2ban atrás da Cloudflare pode bloquear o IP errado?

Em logs HTTP, o origin pode enxergar o IP da Cloudflare, não o IP do visitante. O cabeçalho CF-Connecting-IP carrega o endereço original, mas ele só deve ser confiado depois que a origem aceita o tráfego proxied conforme as faixas atuais da Cloudflare. Sem essa configuração, logs e bans podem representar a origem errada.

O plano Free da Cloudflare basta para uma VPS?

A Cloudflare lista o plano Free por US$0 por mês em sua página oficial de planos. Isso não define o custo total da sua VPS e não equivale a backup, firewall de host ou proteção integral. Planos, preços, recursos e condições podem mudar; avalie a necessidade técnica da aplicação antes de escolher.

Como sei que meu backup funciona?

Você sabe depois de restaurar. Faça um teste em ambiente isolado, registre a origem do backup, os dados recuperados e o caminho de acesso. Sem esse processo, existe backup configurado, mas não uma recuperação verificada. Firewall e proxy não compensam a falta desse teste.

Conclusão: segurança suficiente é a que você consegue manter

Segurança operacional não é instalar três ferramentas e esquecer. É limitar exposição com UFW, usar Fail2ban onde os logs permitem, posicionar Cloudflare corretamente diante do tráfego web e testar se seus dados voltam.

A Operação Mínima Viável cabe na rotina de quem trabalha sozinho porque evita controles decorativos. Cada camada precisa reduzir um risco identificável e ter uma verificação simples: regra ativa, jail ativa, origin correto, TLS correto e restore testado.

Escolher uma VPS é só o começo. A infraestrutura pode dar o ambiente para seus apps, mas a configuração responsável continua sendo sua. Use uma rota de oferta do Runzos para comparar opções, depois aplique o checklist antes de colocar dados ou clientes em produção.