{
  "schemaVersion": "1.0",
  "path": "/guias/infraestrutura/proteger-servidor-linux-ssh-brute-force",
  "url": "https://streethosting.com.br/guias/infraestrutura/proteger-servidor-linux-ssh-brute-force",
  "markdownUrl": "https://streethosting.com.br/guias/infraestrutura/proteger-servidor-linux-ssh-brute-force.md",
  "jsonUrl": "https://streethosting.com.br/guias/infraestrutura/proteger-servidor-linux-ssh-brute-force.json",
  "title": "Proteger servidor Linux contra brute force em SSH",
  "description": "Defesa prática contra brute force SSH: fail2ban, chaves ED25519, UFW, hardening do sshd_config e operação segura em VPS e servidores dedicados no Brasil.",
  "category": "infraestrutura",
  "topics": [
    "seguranca",
    "linux"
  ],
  "difficulty": "intermediario",
  "datePublished": "2026-06-11",
  "dateModified": "2026-06-11",
  "readingMinutes": 5,
  "h1": "Proteger servidor Linux contra brute force em SSH",
  "excerpt": "Minutos após publicar um IP, bots começam a testar root e senhas vazadas no SSH. Este guia mostra camadas de defesa que funcionam em produção sem trancar sua equipe fora do servidor.",
  "author": "Equipe StreetHosting",
  "wordCount": 872,
  "categoryLabel": "Infraestrutura",
  "topicLabels": [
    "Segurança e hardening",
    "Administração Linux"
  ],
  "primaryKeyword": "proteger ssh brute force",
  "secondaryKeywords": [
    "fail2ban linux",
    "ssh seguro servidor",
    "hardening ssh linux"
  ],
  "toc": [
    {
      "id": "o-que-e-brute-force-ssh",
      "label": "O que é brute force em SSH"
    },
    {
      "id": "sinais-ataque-logs",
      "label": "Sinais de ataque nos logs"
    },
    {
      "id": "camadas-defesa-praticas",
      "label": "Camadas de defesa práticas"
    },
    {
      "id": "fail2ban-ufw-hardening",
      "label": "fail2ban, UFW e hardening"
    },
    {
      "id": "operacao-vps-dedicado",
      "label": "Operação contínua em VPS e dedicado"
    }
  ],
  "faqs": [
    {
      "question": "Mudar porta SSH basta?",
      "answer": "Reduz volume de bots genéricos, mas não é defesa real. Segurança vem de chave forte, senha remota desligada e fail2ban. Porta obscura sozinha cai em scan completo eventualmente."
    },
    {
      "question": "fail2ban pode me bloquear?",
      "answer": "Sim se equipe errar senha várias vezes ou NAT corporativo compartilhar IP. Use whitelist para IPs estáveis e maxretry conservador. Documente procedimento de desban pelo console do host."
    },
    {
      "question": "Posso manter senha para emergência?",
      "answer": "Caminho mais seguro é console de recuperação do provedor e política clara de chaves. Se senha for inevitável, restrinja origem por VPN ou faixa IP e mantenha senha longa única."
    },
    {
      "question": "Quanto tempo leva para começar ataque?",
      "answer": "Em VPS nova com IP público, tentativas automáticas costumam aparecer em minutos. Por isso hardening deve ser primeiro passo após criar instância, antes de instalar Minecraft ou bot."
    }
  ],
  "howToSteps": [
    {
      "name": "Gerar e instalar chave ED25519",
      "text": "Crie chave por pessoa e dispositivo, copie para authorized_keys e valide login em sessão paralela."
    },
    {
      "name": "Endurecer sshd_config",
      "text": "Desative senha remota, proíba root direto, limite AllowUsers e valide com sshd -t antes de reload."
    },
    {
      "name": "Instalar e ajustar fail2ban",
      "text": "Configure jail para sshd com maxretry e bantime adequados, whitelist IP estável da equipe."
    },
    {
      "name": "Aplicar firewall coerente",
      "text": "UFW ou nftables na porta SSH real, default deny incoming, exceções documentadas."
    },
    {
      "name": "Auditar acesso periodicamente",
      "text": "Revise authorized_keys trimestralmente, monitore falhas de login e teste console de recuperação."
    }
  ],
  "relatedProducts": [
    "https://streethosting.com.br/vps",
    "https://streethosting.com.br/vps/ryzen",
    "https://streethosting.com.br/dedicated",
    "https://streethosting.com.br/infraestructure"
  ],
  "relatedGuides": [
    "https://streethosting.com.br/guias/vps/ssh-seguro-vps-linux",
    "https://streethosting.com.br/guias/vps/firewall-ufw-vps-ubuntu",
    "https://streethosting.com.br/guias/vps/instalar-docker-ubuntu-vps",
    "https://streethosting.com.br/guias/infraestrutura/estrategia-backup-3-2-1-servidor"
  ],
  "content": {
    "format": "markdown",
    "body": "> **Resposta rápida**\n>\n> Para **proteger Linux contra brute force SSH** use chave **ED25519**, desative login por senha no `sshd_config`, proíba root direto, configure **fail2ban** com limites conservadores e firewall coerente. Valide login em segunda sessão antes de fechar acesso atual. Teste console de recuperação do provedor antes de precisar dele.\n\n## O que é brute force em SSH\n\nBrute force em SSH é tentativa automatizada de adivinhar usuário e senha até acertar combinação fraca ou reutilizada. Não exige alvo famoso: qualquer VPS com porta 22 exposta entra em listas globais em poucos minutos. Ataque gera ruído em log, consome CPU do sshd e pode anteceder exploração se senha for fraca.\n\nObjetivo da defesa não é zero tentativas, é tornar sucesso estatisticamente improvável e detectar padrão cedo. Quem hospeda jogo em [VPS Ryzen](https://streethosting.com.br/vps/ryzen) ou [servidor dedicado](https://streethosting.com.br/dedicated) expõe IP público por necessidade: jogadores precisam conectar. SSH bem endurecido evita que comprometimento do shell vire perda do mundo ou bot Discord.\n\n- Atacante usa listas de usuário e senha vazadas da internet.\n- Bots não dormem: varredura é contínua e distribuída.\n- Sucesso inicial abre porta para minerador, ransomware ou pivot interno.\n\n## Sinais de ataque nos logs\n\nSinais claros aparecem em `/var/log/auth.log` ou `journalctl -u ssh`: dezenas de Failed password para root, admin, ubuntu e test em sequência rápida. Invalid user indica dicionário de nomes comuns. Múltiplos IPs diferentes no mesmo minuto sugerem botnet. Pico noturno é normal em VPS BR porque scanners não respeitam fuso.\n\n| Linha típica | Interpretação | Ação |\n| --- | --- | --- |\n| Failed password for root | Bot testando superusuário | Confirmar PermitRootLogin no |\n| Invalid user oracle | Dicionário de serviços | Ruído esperado, monitorar volume |\n| Accepted password for deploy | Login senha bem sucedido | Investigar imediatamente se senha deveria estar off |\n| Disconnected authenticating user | Tentativa interrompida | Correlacionar com fail2ban ban |\n\n> **Dica**\n>\n> Configure alerta quando contagem de falhas SSH ultrapassar limiar por hora. Uptime Kuma ou script simples com grep evita descobrir campanha dias depois.\n\n## Camadas de defesa práticas\n\nPrimeira camada: autenticação por chave ED25519 e PasswordAuthentication no. Segunda: PermitRootLogin no e AllowUsers com lista mínima. Terceira: fail2ban ou sshguard banindo IP após N falhas. Quarta: UFW permitindo SSH só de faixas conhecidas quando equipe tem IP fixo.\n\n1. Gere chave local: ssh-keygen -t ed25519 -a 100\n2. Copie para servidor: ssh-copy-id usuario@ip\n3. Abra segunda sessão SSH e confirme login por chave.\n4. Edite sshd_config, valide sshd -t, systemctl reload sshd.\n5. Só então desconecte sessão antiga e teste novamente.\n\n> **Atenção**\n>\n> Nunca desative senha nem reinicie sshd sem sessão paralela aberta. Erro de sintaxe ou chave errada tranca equipe inteira até console de recuperação.\n\nFluxo completo de chaves e sshd está no guia de [SSH seguro em VPS Linux](https://streethosting.com.br/guias/vps/ssh-seguro-vps-linux). Siga ordem de etapas de lá se for primeira configuração.\n\n## fail2ban, UFW e hardening\n\nfail2ban lê log do sshd, conta falhas em janela findtime e aplica ban por bantime via iptables ou nftables. Configuração conservadora para equipe remota: maxretry 5, findtime 600, bantime 3600. Whitelist IP do escritório evita lockout em NAT compartilhado com cuidado. Sempre teste jail.local antes de reiniciar produção.\n\n### Exemplo de jail.local enxuto\n\nSeção sshd com enabled true, port ssh, filter sshd, logpath apontando para auth.log, maxretry 5 e bantime 1h. Após editar, use fail2ban-client reload e fail2ban-client status sshd para confirmar jail ativo.\n\nCombine com [firewall UFW em VPS Ubuntu](https://streethosting.com.br/guias/vps/firewall-ufw-vps-ubuntu): default deny incoming, allow 22/tcp ou porta customizada documentada, allow portas do jogo explicitamente. Docker publicado exige revisão extra porque pode contornar UFW; veja [instalar Docker em VPS](https://streethosting.com.br/guias/vps/instalar-docker-ubuntu-vps) para integração segura.\n\n- [ ] PasswordAuthentication no após validar chave.\n- [ ] PermitRootLogin no ou prohibit-password se root excepcional.\n- [ ] AllowUsers lista explícita de contas humanas.\n- [ ] fail2ban instalado e habilitado no boot.\n- [ ] UFW ativo com regra mínima documentada.\n\n## Operação contínua em VPS e dedicado\n\nMudar porta SSH reduz ruído de bot simples mas não substitui chave forte. Console de recuperação do provedor é rede de segurança quando algo dá errado. Em servidor dedicado ou VPS exposta a internet, rotina trimestral revisa authorized_keys, remove chaves de ex funcionário e confirma que PasswordAuthentication permanece desligado após upgrade do sistema.\n\nCompare planos em [VPS root no Brasil](https://streethosting.com.br/vps) quando projeto mistura Minecraft, bot e painel no mesmo host. Hardware exclusivo em [servidores dedicados](https://streethosting.com.br/dedicated) reduz vizinho barulhento mas não elimina necessidade de SSH endurecido. Detalhes da rede StreetHosting estão em [infraestrutura](https://streethosting.com.br/infraestructure).\n\nBackup de chaves e configuração segue [estratégia de backup 3-2-1](https://streethosting.com.br/guias/infraestrutura/estrategia-backup-3-2-1-servidor): exporte lista de authorized_keys, jail.local e sshd_config para storage externo criptografado. Perder servidor dói menos quando reconstruir acesso leva minutos, não horas de ticket.\n\n1. Agendar revisão trimestral de chaves e permissões sudo.\n2. Testar console de recuperação uma vez por semestre.\n3. Documentar quem possui chave de produção e contato de emergência.\n4. Após incidente, rotacionar chaves e revisar logs de Accepted."
  }
}