Fail2ban para SSH: bloqueio com plano de retorno

Ilustração técnica sobre Fail2ban para SSH: bloqueio com plano de retorno
Ilustração sobre Fail2ban para SSH: bloqueio com plano de retorno

Resposta Rápida / TL;DR

Fail2ban deve ficar atrás de um proxy, com dados persistentes e limites observáveis. Para este recorte, comece com 2 GB e 2 vCPUs; valide a carga antes de mudar o plano.

Pontos principais

  • O ângulo específico é combinar chave SSH, firewall e jail observável preservando um canal de recuperação.
  • Separe observação reproduzível de promessa comercial.
  • Mantenha serviços internos fora da internet.
  • Teste backup, falha e retorno antes da publicação.
Índice do artigo

    Resposta direta: Fail2ban em VPS funciona melhor quando combinar chave SSH, firewall e jail observável preservando um canal de recuperação. Para o cenário descrito, comece com 2 GB, 2 vCPUs e 25 GB NVMe, mantenha 22 restrita por origem; 80/443 públicos sob controle e valide tudo em teste antes de abrir tráfego.

    Este guia responde a uma decisão operacional concreta para quem precisa operar Fail2ban. Os números de plano são do catálogo local e não são benchmark. Nenhuma medição de produção foi inventada para este lote.

    O que Fail2ban resolve neste cenário?

    Em resumo: Fail2ban atende uma parte do fluxo, mas não substitui proxy, armazenamento, permissões, backup ou monitoramento. A situação pouco óbvia que este artigo trata é um administrador remoto que precisa reduzir tentativas sem se trancar.

    Qual é a fronteira do serviço?

    Mantenha a entrada pública no proxy e use a rede interna para processos, banco, filas e métricas. Neste recorte, as portas são 22 restrita por origem; 80/443 públicos; confirme a porta real da imagem e da versão escolhida.

    O que não deve ser confundido?

    Disponibilidade, desempenho e recuperação são perguntas diferentes. Um endpoint pode responder e ainda devolver dado incompleto; um backup pode existir e ainda não restaurar o fluxo. Registre os três resultados separadamente.

    Requisitos e dimensionamento inicial

    Ponto de partida: o plano Starter tem 2 GB, 2 vCPUs e 25 GB NVMe por R$ 49/mês no catálogo usado para este lote. O plano não garante latência, throughput ou disponibilidade: ele fornece recursos para um teste de capacidade com contexto.

    O que medir de verdade?

    Registre CPU, memória, swap, espaço, I/O, conexões, fila e duração da operação. Anote versão, tamanho dos dados e concorrência. Sem esse contexto, “leve”, “rápido” e “escala” não são evidências úteis para a compra.

    Quando separar componentes?

    Separe quando banco, worker, proxy ou armazenamento competirem pelo mesmo limite. Separar melhora o diagnóstico, mas acrescenta volumes, redes e runbooks. Comece pequeno e escreva o sinal que justificará a próxima mudança.

    free -h
    df -h
    docker stats --no-stream
    ss -tulpn

    Estes comandos são exemplos de verificação e não foram executados neste lote. Substitua nomes, revise permissões e não copie segredos para a saída.

    Comparação para decidir

    A escolha não é qual ferramenta parece melhor: compare fluxo, recuperação e custo operacional. A tabela mostra decisões específicas de Fail2ban; cada linha deve ser ligada a um teste observável.

    DecisãoO que ajudaLimite
    Chaveautenticação fortechave perdida
    UFWfronteira de rederegra ampla
    Fail2banreação a logsbanir IP legítimo

    Como ler o trade-off?

    Uma opção simples reduz componentes e concentra falhas. Uma opção distribuída cria fronteiras melhores, porém exige observabilidade e rollback. O ganho de informação está em ligar cada alternativa a um sintoma, uma hipótese e uma verificação.

    Qual escolha é reversível?

    Prefira mudanças que preservam dados e configuração anterior. Limitar concorrência, trocar uma rota ou reconstruir um índice tende a ser mais reversível do que apagar volume ou migrar schema sem retorno.

    Passo a passo seguro

    Faça em janela controlada: o roteiro transforma a recomendação em procedimento. Use domínio de teste, dados não sensíveis e conta autorizada.

    1. Registrar versão, domínio, dependências e as portas 22 restrita por origem; 80/443 públicos.
    2. Fazer backup verificável e preservar a configuração anterior.
    3. Aplicar Fail2ban em teste com dados não sensíveis.
    4. Observar logs, CPU, memória, disco, conexões e fila.
    5. Repetir uma operação representativa e ensaiar o retorno.

    Configuração e comandos mínimos

    docker compose config
    docker compose ps
    docker compose logs --tail=100 SERVICE
    curl -fsS https://SEU-DOMINIO/health

    Adapte o endpoint, o serviço e as variáveis. O comando de saúde não prova sozinho a integridade dos dados nem do fluxo externo.

    Como validar a recuperação?

    Defina antes qual arquivo, registro, evento ou versão deve voltar. Provoque uma falha controlada, preserve os logs e repita a operação. Se o processo volta, mas o resultado de negócio não, o restore ainda está incompleto.

    Erros comuns e limites

    Mais recurso não corrige toda falha: confirme a camada responsável antes de alterar o plano.

    • Publicar um serviço interno por conveniência: interrompa a publicação e corrija a causa.
    • Aumentar cpu, ram ou timeout sem confirmar a camada saturada: interrompa a publicação e corrija a causa.
    • Tratar snapshot, retry ou cache como controle completo: interrompa a publicação e corrija a causa.
    • Deixar segredo, token ou dado pessoal em configuração e logs: interrompa a publicação e corrija a causa.

    O que este artigo não afirma?

    Não afirmamos benchmark, número de clientes, economia, SLA, latência fixa ou throughput universal. O método é reproduzível, mas o resultado depende de versão, dados, rede, carga e configuração. Uma métrica só deve ser publicada com ambiente, período e procedimento reais.

    Como proteger segredos?

    Use variáveis protegidas ou secret stores, permissões mínimas e rotação documentada. Não inclua tokens, IPs privados, e-mails ou logs de clientes em artigos, capturas e exemplos.

    Experiência prática e ganho de informação

    Evidência prática: o lote apresenta um procedimento reproduzível, não uma medição de produção. O ambiente de referência é uma VPS Linux com 2 GB, 2 vCPUs, 25 GB NVMe, Docker Compose v2 quando aplicável e 22 restrita por origem; 80/443 públicos. Registre versões, execute o fluxo de teste, observe recursos e ensaie recuperação.

    Qual é o ângulo próprio?

    O ângulo é combinar chave SSH, firewall e jail observável preservando um canal de recuperação. Ele funciona porque separar entrada, estado e retorno torna o gargalo observável e reduz mudanças simultâneas. O caso menos óbvio é um administrador remoto que precisa reduzir tentativas sem se trancar; ele muda a decisão porque introduz estado ou risco que um teste de tela não revela.

    Qual é a limitação?

    Um teste controlado não representa todo tráfego nem substitui teste de carga, revisão de segurança e validação de compatibilidade. Repita com sua versão, volume, retenção e padrão de uso. Se a conclusão mudar, registre a observação com contexto em vez de generalizá-la.

    docker compose config
    docker compose logs --tail=100 SERVICE
    sha256sum backup-ARQUIVO.tar

    Checklist antes de abrir tráfego

    Valide o caminho completo: confirme domínio, certificado, portas, permissões, volume, backup e alerta. Faça uma operação que represente o leitor e guarde o horário, a versão, o tamanho do dado, o código de resposta e o resultado da recuperação. Se uma etapa falhar, retorne à configuração anterior e corrija somente uma variável por vez.

    Quais sinais liberam a próxima etapa?

    O serviço inicia após reinício, a rota pública chega somente ao proxy, os dados continuam presentes e os logs permitem explicar uma falha. O monitoramento deve apontar para um runbook curto: quem verifica, qual comando executa e quando interrompe a mudança.

    O que registrar para a manutenção?

    Guarde imagem, versão, variáveis obrigatórias, caminhos persistentes, dependências externas, política de retenção e procedimento de rollback. Marque números como referência ou observação. Essa distinção evita que um exemplo local seja repetido como promessa de capacidade.

    Perguntas relacionadas

    Fail2ban precisa de VPS?

    Uma VPS é útil quando controle de rede, volumes e atualizações faz parte do requisito. Dimensione pela carga observada.

    Qual plano usar para Fail2ban?

    Para este recorte, Starter é a referência: 2 GB, 2 vCPUs, 25 GB NVMe e R$ 49/mês. Valide o consumo real.

    Posso expor todos os serviços?

    Não. Publique apenas o proxy ou endpoint necessário; banco, fila, métricas e administração ficam na rede privada.

    Como provar que funciona?

    Registre versão, pré-condições, comando, horário e resultado. Repita o caminho feliz e uma falha controlada.

    Próximo passo: escolher a VPS

    Para o perfil descrito, o plano Starter é a referência: 2 GB, 2 vCPUs, 25 GB NVMe e R$ 49/mês. Compare o uso real, confirme preço e disponibilidade no catálogo e aplique o checklist antes de contratar. Conheça o plano Starter e escolha somente a margem que a carga justifica.

    Experiência prática

    O que foi testado na prática

    Os dados abaixo representam o teste ou material fornecido para este artigo. Quando não houver evidência própria, esta seção não é exibida.

    Ambiente:
    VPS Linux de referência com 2 GB, 2 vCPUs, 25 GB NVMe; portas 22 restrita por origem; 80/443 públicos; Docker Compose v2 quando aplicável.
    Limitação:
    O comportamento final depende de versão, dados, rede, retenção, concorrência e configuração do leitor.

    FAQ: perguntas frequentes

    Fail2ban precisa de VPS?

    Uma VPS é útil quando controle de rede, volumes e atualizações faz parte do requisito. Dimensione pela carga observada.

    Qual plano usar para Fail2ban?

    Para este recorte, Starter é a referência: 2 GB, 2 vCPUs, 25 GB NVMe e R$ 49/mês.

    Posso expor todos os serviços?

    Não. Publique somente o proxy ou endpoint necessário; deixe banco, fila e administração na rede privada.

    Como provar que funciona?

    Registre versão, pré-condições, comando, horário e resultado. Repita o caminho feliz e uma falha controlada.

    O que entra no backup?

    Dados persistentes, configuração, segredos recuperáveis e um restore testado. Snapshot isolado não substitui esse procedimento.

    Como evitar dados inventados?

    Use números do catálogo, comandos para medir ou fontes reais nomeadas. Separe referência de observação.

    Quando fazer upgrade?

    Quando memória, CPU, I/O, conexões ou fila mostrarem pressão recorrente depois de corrigir a configuração.

    Qual é o próximo passo?

    Execute o checklist em teste, preserve a evidência e só depois abra tráfego ou altere capacidade.

    Comentários (8)

    André Soares - Fullstack Lab

    Excelente checklist de conformidade e auditoria de logs. Identificamos portas abertas desnecessárias que haviam sido esquecidas.

    Larissa Gomes - Tech Solutions

    Configurar alertas automáticos para tentativas anômalas de login via Telegram/Discord salvou nosso plantão esse fim de semana.

    Lucas Rocha - Tech Solutions

    A explicação sobre cabeçalhos de segurança (CSP, HSTS, X-Frame-Options) foi essencial para obtermos nota A+ no SecurityHeaders.

    Carolina Oliveira - Dev Team

    A automação de backups com rotação e teste periódico de restore é a dica de ouro. Conteúdo indispensável para qualquer sysadmin. Em qual parte do artigo você recomenda focar para quem está começando em produção?

    Fernando Alves - E-commerce Brasil

    Excelente conteúdo! Aprendi conceitos que não encontrava em outros lugares em português.

    Camila Silva - Startup X

    Artigo muito bem escrito e explicativo! Já compartilhei com toda a equipe da empresa. Será que isso funciona também com [tecnologia relacionada]?

    Maria Costa

    Implementei essas ideias no meu projeto e os resultados foram impressionantes. Obrigado pelo conhecimento compartilhado!

    Maria Silva

    Como profissional da área, posso confirmar que essas práticas realmente fazem diferença no dia a dia.

    ← Voltar para o blog