Como prevenir ataques de força bruta: 9 controles comprovados

Para evitar ataques de força bruta, exija autenticação multifatorial em cada login voltado para a Internet, limite de taxa de tentativas fracassadas por conta, IP e globalmente, bloqueie senhas violadas, armazene hashes com Argon2id ou bcrypt e alerte sobre falhas anormais de login. Coloque esses controles em camadas, porque ninguém interrompe todas as variantes.

Abra o log de autenticação de qualquer servidor SSH algumas horas depois de ficar online e você verá isto:

3 de outubro 02:14:07 web01 sshd [2231]: Falha na senha para root da porta 203.0.113.45 51022 ssh2
3 de outubro 02:14:09 web01 sshd [2233]: Falha na senha do administrador da porta 198.51.100.17 40318 ssh2
3 de outubro 02:14:11 web01 sshd [2236]: Falha na senha do Ubuntu da porta 192.0.2.88 33874 ssh2

Três nomes de usuário, três IPs, com dois segundos de intervalo. Ninguém está digitando. Os bots testam cada página de login, porta SSH e endpoint de API que encontram, e uma única tentativa bem-sucedida leva direto paraaquisição de conta. Abaixo estão nove controles classificados por impacto, além de como detectar e responder a um ataque em andamento.

Como prevenir ataques de força bruta: 9 controles classificados por impacto

1. Aplique a autenticação multifator.Um palpite correto ou uma senha vazada não concede mais acesso.

2. Limite de taxa e aceleração de logins.Adivinhação lenta a uma velocidade que a torna inútil.

3. Siga as regras de senha do NIST SP 800-63B.Favoreça o comprimento, bloqueie senhas violadas, elimine a rotação forçada.

4. Hash de senhas com Argon2id ou bcrypt.Um banco de dados roubado não deve se tornar um banco de dados crackeado.

5. Adicione CAPTCHA e detecção de bot seletivamente.Desafie apenas tráfego suspeito.

6. Fortaleça logins SSH, RDP, CMS e APIs.Feche os serviços que os invasores atingiram primeiro.

7. Use reputação de IP, regras geográficas e WAF.Corte o tráfego ruim conhecido antecipadamente.

8. Monitore e alerte sobre falhas de autenticação.Pegue o que escapa da prevenção.

9. Teste suas próprias defesas.Confirme se os controles funcionam antes que um invasor o faça.

Com pouco tempo? Faça os controles 1, 2 e 8 primeiro. A MFA limita o dano, a limitação da taxa retarda o ataque e o monitoramento informa que isso está acontecendo.

Por que a prevenção difere por variante

Cada variante é interrompida por um controle diferente, então saiba qual você enfrenta.

A pulverização anula os bloqueios por conta porque cada conta quase não apresenta falhas. O cracking offline não deixa rastros, e é por isso que o hash é importante, mesmo que sua página de login seja perfeita.

Controle 1: Aplicar autenticação multifator

O MFA está em primeiro lugar porque torna insuficiente uma senha correta. Classificado por força:

1. Senhas e chaves FIDO2.Resistente a phishing porque a credencial está vinculada ao domínio real.

2. Aplicativo autenticador TOTP.Sólido, embora um proxy de phishing ativo possa retransmitir o código.

3. Empurre com correspondência de números.Bloqueia aprovações cegas.

4. Códigos SMS.Mais fraco, exposto à troca de SIM. Use apenas como alternativa.

Combata a fadiga do MFA, em que os invasores enviam spam para prompts até que alguém aprove, com correspondência de números, limite de prompts por hora e alertas após negações repetidas. Implementação por raio de ação: painéis de administração e consoles em nuvem, depois e-mail, VPN e hospedagem de código, e depois todos os demais. Bloqueie o caminho de recuperação também. Nunca deixe o suporte desabilitar a MFA apenas por e-mail.

Controle 2: Limite de taxa e tentativas de login de aceleração

Um bot que tenta 10.000 senhas por minuto é uma ameaça. Mantido a 5 por minuto, não é. Acelere antes de bloquear, porque bloqueios rígidos permitem que invasores neguem serviço a usuários reais.

• Falhas 1 a 3: sem atraso

• Falhas de 4 em diante: 1, 2, 4, 8 segundos, limitado a 60

• Após 10 falhas: bloqueio de 15 minutos mais um e-mail para o proprietário da conta

Limite em três dimensões, já que cada variante ultrapassa uma diferente: por conta (10 falhas a cada 15 minutos), por IP (20 tentativas por minuto) e global (alerta acima de 3x falhas de linha de base).

nginx

limit_req_zone $binary_remote_addr zone=login:10m taxa=5r/m;

localização /login {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    proxy_pass http://app_backend;
}

O Nginx vê apenas IPs, portanto, use contadores Redis ou um WAF para a conta e as camadas globais. Aplique os mesmos limites à redefinição de senha, entrada MFA (um código de 6 dígitos tem apenas 1.000.000 de combinações) e rotas de login de API.

Controle 3: Definir regras de senha com base no NIST SP 800-63B

O NIST substituiu antigas regras de complexidade por orientações baseadas em como os invasores adivinham.

• Exige no mínimo 8 caracteres com MFA e 15 ou mais para contas de administrador. Permitir 64 ou mais.

• Elimine misturas forçadas de símbolos e números.grampo correto para bateria de cavalobateP@ssw0rd!.

• Verifique as novas senhas com a API Have I Been Pwned Pwned Passwords, que usa k-anonimato para que a senha completa nunca saia do seu sistema.

• Encerrar a rotação programada. Force uma redefinição apenas com evidências de comprometimento, como uma correspondência encontrada emmonitoramento da dark web.

• Permitir colar para que os gerenciadores de senhas funcionem.

Se um auditor ainda exigir rotação, documente a lógica do NIST e aplique a regra mais rigorosa apenas quando uma estrutura assim o exigir.

Controle 4: Hash de senhas para impedir ataques offline

Os limites de taxa não fazem nada quando um invasor controla seu banco de dados. Uma GPU moderna testa bilhões de suposições MD5 por segundo, de modo que hashes rápidos caem em horas. É aqui queentendendo como funciona o hashcompensa. Use um algoritmo lento e com muita memória:

1. Argônio2id.A recomendação atual do OWASP.

2. criptografia.Alternativa forte.

3. bcrypt.Testado em batalha, fator de custo 12 ou superior.

4. PBKDF2.Somente onde a conformidade exigir, em 600.000 ou mais iterações.

Nunca use MD5, SHA-1 ou SHA-256 sozinhos. As bibliotecas cuidam da salga, então nunca escreva você mesmo. Ajuste o fator de trabalho para aproximadamente 250 a 500 ms por hash e refaça o hash no próximo login quando as configurações melhorarem.

píton

de argon2 importar PasswordHasher
ph = PasswordHasher(time_cost=2, memory_cost=19456, paralelismo=1)
armazenado = ph.hash(senha)
ph.verify(stored, password) # aumenta em caso de incompatibilidade

Confirme os parâmetros em relação à Folha de Dicas de Armazenamento de Senhas OWASP atual antes do envio.

Controle 5: Adicionar CAPTCHA e detecção de bot seletivamente

CAPTCHA adiciona fricção, não uma parede. Os serviços de resolução vendem desafios resolvidos por humanos a baixo custo, e os modelos de IA agora superam muitos quebra-cabeças de imagens. Acione desafios com base no risco: três ou mais falhas, um novo dispositivo ou país, IPs de provedores de hospedagem ou assinaturas de navegador headless. Cloudflare Turnstile, hCaptcha e reCAPTCHA v3 pontuam riscos de forma invisível. Combine-os com impressão digital do dispositivo e análise de tempo e ofereça uma alternativa acessível para usuários que não conseguem completar desafios visuais.

Controle 6: Fortaleça os serviços mais atingidos pelos invasores

SSH.Remova a senha e a força bruta não terá nada para adivinhar.

SenhaAutenticação não
PermitRootLogin não
Permitir que usuários implantem administrador
MaxAuthTries 3

Gere chaves comssh-keygen -t ed25519, confirme o login da chave em uma segunda sessão e recarreguesshd. Adicione Fail2ban como camada de suporte. Alterar a porta reduz o ruído do registro, mas não é um controle.

PDR.Nunca exponha a porta 3389. Coloque-a atrás de uma VPN ou gateway (veja comoZTNA e VPN se adaptam às estratégias de segurança modernas), habilite a autenticação em nível de rede, exija MFA e defina uma política de bloqueio de 5 falhas por 15 minutos.

WordPress e CMS.Limitar tentativas de login, bloquear/xmlrpc.php(ésystem.multicallmétodo testa centenas de senhas por solicitação), restringir/wp-login.phppor IP e aplicar MFA de administrador.

APIs.Defina limites por chave e por IP com429respostas, use chaves aleatórias de 332 bytes ou mais, expire tokens dentro de uma hora e retorne erros idênticos para nomes de usuário e senhas errados.

Controle 7: Use reputação de IP, regras geográficas e WAF

A filtragem de borda é um pré-filtro, não uma defesa primária. Obtenha feeds de reputação como AbuseIPDB e Spamhaus DROP, desafie intervalos de provedores de hospedagem e nós de saída Tor em rotas de login e aplique regras geográficas onde seus clientes estão concentrados. Use MFA intensificado em vez de bloqueios rígidos para que os viajantes não fiquem bloqueados. Implante regras WAF baseadas em taxas (Cloudflare, AWS WAF ou ModSecurity), começando no modo de contagem antes de mudar para bloco. As redes proxy residenciais alternam IPs residenciais reais e evitam tudo isso, de modo que a MFA e a limitação por conta ainda carregam a carga.

Controle 8: Monitorar e alertar sobre falhas de autenticação

A prevenção eventualmente falha e, sem monitorar, um login de força bruta bem-sucedido parece normal. Bommonitorização da cibersegurançacomeça com os logs corretos: IDs de eventos do Windows 4625, 4624 e 4740; SSHauth.logPicos 401 em logins da web e registros de login do provedor de identidade. Nunca registre senhas.

Escreva uma detecção por variante:

• Força bruta:mais de 10 falhas para uma conta em 5 minutos

• Pulverização:um IP falhando em mais de 15 nomes de usuário em 30 minutos

• Recheio:volume de login acima de 3x a linha de base com uma alta taxa de falhas

• Compromisso:um login bem-sucedido após uma explosão de falha. Chame alguém para este.

• Abuso de AMF:três ou mais prompts push negados

index=wineventlog EventCode=4625
| bin _intervalo de tempo=30m
| stats dc(TargetUserName) como usuários por _time, IpAddress
| onde usuários > 15

Wazuh é um ponto de partida gratuito com SSH integrado e regras de força bruta. Execute alertas no modo somente relatório por uma semana e ajuste sua própria linha de base.

Controle 9: Teste suas próprias defesas

Um controle não testado é uma suposição. Teste apenas sistemas que você possui ou tem autorização por escrito para testar, usando uma conta de teste dedicada. Hydra, Medusa e Burp Intruder cobrem formulários e serviços de login, e Hashcat testa a resistência offline contra uma cópia de seus próprios hashes em um laboratório. Dobrando isso em um contexto mais amplotestes de penetração e avaliação de vulnerabilidadesprograma o mantém dentro de uma programação.

Verifique se 15 falhas rápidas acionam atrasos, uma senha em 30 contas aciona a detecção de pulverização, uma senha correta sem MFA é negada, o SSH rejeita senhas e uma explosão de falha seguida de sucesso atinge seu pager. O teste de alerta é tão importante quanto o teste de bloco. Teste novamente trimestralmente e após qualquer alteração de autenticação.

O que fazer durante um ataque ativo

1. Confirme o escopo.Identifique contas de destino, IPs de origem e qualquer sucesso após uma falha.

2. Bloqueie a fonte.Use regras de firewall ou WAF, ou bloqueie por ASN ou padrão de solicitação se os IPs girarem. Mude as regras do modo de contagem para bloquear.

3. Bloqueie contas comprometidas.Redefina senhas, revogue sessões e verifique a propriedade de MFA por meio de outro canal.

4. Aperte temporariamente.Reduzir os limites e exigir a intensificação da MFA e, em seguida, remover as medidas após o ataque.

5. Atividade pós-compromisso de caça.Procure novos dispositivos MFA, regras de encaminhamento de caixa de correio, chaves de API e concessões OAuth.

6. Documento.Registre qual controle deveria ter interrompido isso e corrija a lacuna. Verifique os prazos de notificação de violação se os dados foram acessados.

Lista de verificação de prevenção de força bruta

Faça hoje

• Liste todos os logins voltados para a Internet

• Habilite MFA em contas de administrador, e-mail e nuvem

• Desative as senhas SSH e feche o RDP público

Faça esta semana

• Adicionar limites de taxa de login, redefinição e endpoint de MFA

• Filtrar senhas em listas de violações

• Defina alertas de sucesso após explosões de falha

Faça este trimestre

• Execute um teste autorizado em cada controle

• Ajustar limites de alerta

• Reavaliar fatores de trabalho de hash

Conclusão

Os ataques de força bruta são automatizados e constantes, portanto a defesa também deve ser automática. Priorize MFA, limitação de taxa em camadas, hash forte com triagem de violação e alertas sobre sucesso após fracasso. Juntos, eles aumentam o custo de atacar você além do que a maioria dos bots gasta.

Próximo passo hoje:liste todos os logins voltados para a Internet e marque quais não possuem MFA e limitação de taxa. Corrija primeiro os painéis de administração, e-mail e acesso remoto.

Perguntas Frequentes

Qual é a maneira mais eficaz de prevenir ataques de força bruta?

MFA resistente a phishing, como chaves de acesso ou chaves FIDO2. Isso torna insuficiente uma senha correta, o que neutraliza a adivinhação, o preenchimento e as credenciais de phishing. Combine-o com limitação de taxa.

O bloqueio de conta impede ataques de força bruta?

Ele impede a adivinhação de contas únicas, mas os invasores podem acionar bloqueios para bloquear usuários reais e não faz nada contra a pulverização de senhas. Use atrasos progressivos além de limites globais e por IP.

Quanto tempo leva para forçar uma senha com força bruta?

Depende do comprimento, conjunto de caracteres e tipo de hash. O comprimento é o que mais importa, e hashes rápidos como MD5 caem muito mais rápido que Argon2id. Teste seus próprios hashes em um laboratório, em vez de confiar em uma figura genérica.

Uma VPN ou a alteração da porta padrão podem impedir ataques de força bruta?

Uma VPN remove a exposição pública, portanto, os invasores devem primeiro passar pela autenticação. Alterar a porta apenas reduz o ruído do scanner e é encontrado em minutos.

Qual é a diferença entre força bruta e preenchimento de credenciais?

A força bruta adivinha senhas. O preenchimento de credenciais reproduz pares reais vazados, apostando na reutilização. Senhas exclusivas, triagem de violação e MFA interrompem o preenchimento.

Como posso saber se estou sendo forçado a usar força bruta?

Procure picos de login com falha, falha de um IP em vários nomes de usuário, tentativa de senha em várias contas e inundações de bloqueios. Um sucesso logo após a explosão de um fracasso é o sinal mais sério.

O Fail2ban é suficiente para proteger o SSH?

Não. Os ataques distribuídos permanecem abaixo dos limites. Desative a autenticação por senha e exija chaves, e mantenha o Fail2ban como camada de suporte.