Proteção de páginas de login com WAF: rate limit, bots e boas práticas
O login é o endpoint mais atacado. Veja como reduzir abuso na borda preservando a experiência de quem é legítimo.
A página de login é um dos endpoints mais atacados de qualquer aplicação. Força bruta, credential stuffing com listas de credenciais vazadas e automação por bots batem nela continuamente. Um WAF bem ajustado mitiga grande parte desse abuso na borda, antes que ele consuma recursos da aplicação ou comprometa contas. O desafio é fazer isso sem transformar o login em um campo minado para o usuário legítimo.
Este guia mostra como combinar rate limiting, reputação, desafios e regras específicas para proteger o login, e como ajustar tudo isso de forma a não bloquear pessoas reais, especialmente as que compartilham um mesmo IP de saída corporativo.
Rate limiting e o cuidado com IPs compartilhados
Rate limiting limita quantas tentativas uma origem pode fazer em uma janela de tempo, mitigando força bruta. O cuidado central é que muitos usuários legítimos saem por um mesmo IP, como uma empresa inteira atrás de um gateway ou uma operadora de celular que agrega milhares de assinantes em poucos endereços. Um limite agressivo por IP pode bloquear todos eles de uma vez. Ajuste o limite considerando esse cenário e, quando possível, combine sinais além do IP, como identificadores de sessão e comportamento.
Credential stuffing é diferente de força bruta: o atacante testa muitas combinações de usuário e senha, cada uma poucas vezes, distribuídas por muitos IPs. Limites simples por IP não pegam bem esse padrão, porque nenhum endereço isolado ultrapassa o teto. Por isso reputação de IP e detecção de comportamento automatizado entram em cena, olhando o conjunto do tráfego e não apenas cada origem em separado.
Janela, limite e a ação ao exceder
Uma regra de taxa tem três decisões: a chave de contagem, o limite dentro de uma janela e o que fazer quando o limite é atingido. Contar apenas por IP é o ponto fraco em ambientes corporativos; sempre que a plataforma permitir, componha a chave com outro sinal. E prefira uma ação graduada: em vez de bloquear na primeira ultrapassagem, aplique um desafio, que separa humano de automação sem punir quem apenas errou a senha algumas vezes.
# Pseudocódigo defensivo, adapte à sintaxe do seu WAF
SE requisicao.caminho == "/login" E requisicao.metodo == "POST":
chave_de_contagem = combinar(ip_cliente, token_de_sessao)
limite = 10 tentativas por janela de 5 minutos
ao_exceder: aplicar_desafio # não bloqueio imediato
ao_persistir_apos_desafio: bloquear por período curtoOs números acima são um ponto de partida, não um valor universal. Meça o tráfego legítimo do seu login antes de fixar o limite: uma janela curta com limite baixo demais gera bloqueio de gente real, e uma janela larga demais deixa a força bruta lenta passar. Comece observando, ajuste com os dados do seu contexto.
Reputação, bots e desafios
Listas de reputação de IP bloqueiam origens conhecidas por abuso, e regras de bot identificam automação por características da requisição. Desafios, quando disponíveis, pedem uma prova ao cliente suspeito antes de permitir a tentativa, o que separa humanos de automação sem bloquear definitivamente. Use desafios de forma dosada, porque atrito demais afasta usuários legítimos.
Onde os desafios ajudam e onde atrapalham
O desafio certo, no lugar certo, é quase invisível para o humano e caro para a automação. O erro é aplicá-lo a todo o tráfego: aí a conversão cai e o suporte enche de reclamação. Direcione o desafio pelo sinal de suspeita, reputação ruim, comportamento automatizado, taxa acima do normal, e mantenha o caminho limpo para quem parece legítimo. Prefira desafios que não dependam de o usuário resolver quebra-cabeças; muitos separam automação de forma transparente.
- Aplicar rate limiting calibrado para IPs compartilhados
- Usar reputação de IP contra origens conhecidas por abuso
- Detectar automação com regras de bot
- Aplicar desafios de forma dosada a tráfego suspeito
- Combinar sinais além do IP, como sessão e comportamento
Sinais além do IP para conter o stuffing distribuído
Quando o ataque se espalha por milhares de IPs, cada um com poucas tentativas, o endereço deixa de ser um bom identificador. O que ainda diferencia a campanha do tráfego real é o padrão do conjunto: uma proporção anormal de logins que falham, um volume súbito de usuários distintos testados, requisições sem os cabeçalhos e a sequência de navegação que um cliente legítimo produz. Regras que olham essa taxa agregada, e não só cada origem, pegam o que o rate limit por IP deixa passar.
Some a isso os sinais de sessão e de dispositivo. Um cliente que resolve o desafio e recebe um token de sessão pode circular com mais folga; um que chega sempre sem cookie, sem histórico e com cabeçalhos inconsistentes merece mais escrutínio. A ideia não é impor atrito a todos, e sim gastar o atrito onde o risco está.
Um cuidado importante: credencial vazada em lista pública é testada em vários serviços ao mesmo tempo. Se a sua base de usuários reaproveita senhas, o stuffing acerta contas reais mesmo com a borda ajustada. Por isso a defesa da conta não termina na borda, e a próxima seção trata do que a aplicação precisa fazer.
A borda complementa, não substitui
A proteção de borda reduz o volume de abuso, mas a aplicação ainda precisa de controles próprios: bloqueio progressivo após tentativas falhas, MFA, detecção de login anômalo e armazenamento seguro de senhas com algoritmo apropriado. O WAF e a aplicação trabalham em camadas; confiar só na borda deixa a conta vulnerável quando uma requisição passa.
Armazenamento de senha e resposta a login válido suspeito
Guarde senhas com uma função de derivação lenta e específica para o fim, com sal por usuário, de modo que o vazamento da base não entregue as senhas em claro. Trate ainda o login que autentica mas destoa do padrão da conta, um país incomum, um dispositivo novo, um horário atípico, exigindo um segundo fator ou uma verificação adicional. É a diferença entre barrar a tentativa e proteger a conta quando a senha correta chega de uma origem estranha.
Padronize também as mensagens de erro do login para não revelar se o usuário existe. Uma resposta que distingue senha errada de usuário inexistente entrega ao atacante meio caminho da enumeração de contas, e isso enfraquece justamente a proteção que você está montando.
Detecção e resposta a campanhas de credential stuffing
Monitore as métricas de bloqueio do login. Um pico repentino costuma indicar uma campanha em andamento, e os logs ajudam a ajustar regras e a investigar contas possivelmente afetadas. A métrica mais reveladora é a taxa de falha de autenticação: em operação normal ela oscila pouco, e uma subida abrupta, especialmente com muitos usuários distintos, é o sinal clássico de stuffing.
- Volume de tentativas de login por minuto e sua variação
- Taxa de falha de autenticação e número de usuários distintos testados
- Proporção de tráfego que recebeu desafio e falhou
- Concentração de tentativas por faixa de rede ou por sistema autônomo
- Logins bem-sucedidos que destoam do padrão histórico da conta
Tenha um plano para quando o pico aparece: apertar temporariamente o rate limit e os desafios, cruzar os acessos com listas de credenciais sabidamente vazadas e, para as contas que autenticaram durante a campanha, forçar redefinição de senha e encerrar as sessões ativas. Registrar o incidente e revisar as regras depois fecha o ciclo, porque cada campanha ensina onde a calibragem estava frouxa.
Checklist prático
- Aplicar rate limiting calibrado para o login
- Considerar IPs compartilhados ao definir limites
- Compor a chave de contagem com sinal além do IP quando possível
- Preferir ação graduada (desafio antes de bloqueio) ao exceder o limite
- Ativar reputação de IP contra origens abusivas
- Usar regras de bot para detectar automação
- Aplicar desafios de forma dosada ao tráfego suspeito
- Monitorar a taxa agregada de falha de autenticação, não só cada IP
- Manter MFA e bloqueio progressivo na aplicação
- Armazenar senhas com função de derivação lenta e sal por usuário
- Padronizar mensagens de erro do login para não revelar contas
- Exigir verificação adicional em login válido com padrão anômalo
- Monitorar métricas de bloqueio para detectar campanhas
- Ter plano de resposta a pico: apertar regras, redefinir senha, encerrar sessões
- Ajustar regras observando o impacto em usuários reais
Boas práticas
- Calibre limites pensando em quem compartilha IP de saída
- Combine sinais além do IP para pegar credential stuffing
- Use desafios com parcimônia e direcionados ao tráfego suspeito
- Meça o tráfego legítimo antes de fixar limites e janelas
- Mantenha MFA e detecção de login anômalo na aplicação
- Trate a borda como camada complementar, não única
- Monitore a taxa de falha de autenticação como indício de campanha
- Revise as regras após cada incidente, aprendendo com a calibragem
Erros comuns
Rate limit agressivo por IP em ambiente corporativo
Bloqueia muitos usuários legítimos que saem pelo mesmo gateway.
Confiar só no IP contra credential stuffing
Ataques distribuídos por muitos IPs passam pela barreira.
Bloquear na primeira ultrapassagem, sem ação graduada
Pune quem apenas errou a senha e aumenta o atrito legítimo.
Excesso de desafios aplicados a todo o tráfego
Atrito alto afasta usuários legítimos e prejudica conversão.
Mensagem de erro que revela se o usuário existe
Facilita a enumeração de contas antes do ataque de senha.
Depender só da borda e ignorar a aplicação
Contas ficam vulneráveis quando uma requisição maliciosa passa.
Não monitorar a taxa de falha de autenticação
Campanhas de credential stuffing passam despercebidas.
Quando procurar apoio especializado
Calibrar proteção de login sem prejudicar usuários reais exige medir tráfego e ajustar regras com método. A GUARDIASEC faz esse tuning no serviço de WAF e Proteção de Borda, combinando rate limiting, reputação e desafios com observação contínua.
Perguntas frequentes
Rate limiting sozinho protege o login?
Ajuda contra força bruta de um mesmo IP, mas não é suficiente. Credential stuffing distribui as tentativas por muitos IPs, escapando de limites simples. Por isso o rate limiting precisa ser combinado com reputação de IP, detecção de bots e controles na própria aplicação, como MFA e bloqueio progressivo.
Como evito bloquear usuários de uma mesma empresa?
Empresas costumam sair por um único IP de gateway, então um limite agressivo por IP pode bloquear todos. A solução é calibrar os limites considerando esse cenário e combinar sinais além do IP, como identificadores de sessão e comportamento, para distinguir abuso real de muitos usuários legítimos compartilhando a mesma origem.
Desafios atrapalham a experiência do usuário?
Podem atrapalhar se aplicados a todo mundo. A boa prática é direcionar desafios apenas ao tráfego suspeito, com base em reputação e comportamento, mantendo o caminho limpo para quem parece legítimo. Usados com parcimônia, os desafios separam automação de humanos sem criar atrito desnecessário.
O WAF substitui MFA no login?
Não. O WAF reduz o volume de abuso na borda, mas o MFA protege a conta mesmo quando a senha é comprometida. São camadas diferentes e complementares: a borda filtra tráfego malicioso, enquanto o MFA e a detecção de login anômalo defendem a conta no nível da aplicação.
Qual limite de tentativas devo configurar no login?
Não existe um número universal. O limite depende do comportamento real do seu tráfego, e o único jeito de acertar é medir antes de fixar. Comece observando quantas tentativas um usuário legítimo costuma fazer numa janela curta, defina o limite com folga acima disso e prefira aplicar um desafio ao exceder, em vez de bloqueio imediato. Ambientes com muitos usuários atrás de um mesmo IP exigem limites mais altos ou uma chave de contagem que combine o IP com outro sinal.
Como sei que estou sofrendo credential stuffing agora?
O sinal mais claro é uma subida abrupta na taxa de falha de autenticação, geralmente acompanhada de muitos usuários distintos sendo testados em pouco tempo e de tráfego concentrado em automação. Diferente da força bruta contra uma conta, o stuffing espalha poucas tentativas por muitas contas e muitos IPs. Monitorar essa taxa agregada, e não apenas cada origem, é o que revela a campanha enquanto ela acontece.
O que faço com as contas que fizeram login durante o ataque?
Trate-as como possivelmente comprometidas até prova em contrário. O procedimento comum é cruzar esses acessos com listas de credenciais sabidamente vazadas, forçar a redefinição de senha das contas afetadas e encerrar as sessões ativas para cortar qualquer acesso já estabelecido. Registrar o incidente e revisar as regras depois ajuda a calibrar melhor a proteção para a próxima campanha.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.