Como bloquear ataques de força bruta no Nginx com IP Rate Limiting

Por que proteger suas APIs com controle de taxa no Nginx

Imagine que sua API recém-lançada comece a receber milhares de requisições por segundo vindas do mesmo endereço IP. Na melhor das hipóteses, trata-se de um robô de indexação desregulado; na pior, é um script malicioso tentando adivinhar senhas por força bruta ou derrubar sua infraestrutura por exaustão de recursos. Para blindar aplicações web contra esse tipo de comportamento abusivo, engenheiros de redes costumam usar o controle de taxa, conhecido tecnicamente como rate limiting. Se você já precisou resolver problemas semelhantes em outras camadas, vale a pena conferir dicas complementares ao implementar como configurar regras de firewall com UFW no Linux para reforçar a segurança perimetral do seu servidor.

Na prática, o Nginx atua como um porteiro rigoroso na entrada do seu ecossistema digital. Ele examina cada pacote que chega, identifica de onde ele vem com base no endereço IP e decide se o visitante pode prosseguir ou se deve receber uma negativa educada. Esse mecanismo evita que picos repentinos de tráfego sobrecarreguem o banco de dados ou esgotem as conexões disponíveis no servidor de aplicação, mantendo o serviço estável para usuários legítimos.

Como funciona a diretiva limit_req_zone na prática

O coração do controle de taxa no Nginx reside em duas peças fundamentais: a zona de memória e a diretiva de aplicação. A primeira etapa consiste em definir quem será monitorado e quanta memória RAM será dedicada para essa tarefa. Para isso, utilizamos o bloco http do arquivo de configuração principal para declarar a diretiva limit_req_zone, que aloca um espaço reservado na memória para guardar o histórico recente dos endereços IP.

Quando declaramos uma zona de memória, informamos ao Nginx que ele deve reservar, por exemplo, dez megabytes para guardar o estado dos clientes. Cada endereço IP consome um espaço minúsculo nessa tabela de controle, permitindo monitorar centenas de milhares de visitantes simultâneos sem comprometer o desempenho da máquina. Essa abordagem garante que a checagem ocorra em frações de milissegundo antes mesmo da requisição tocar na sua aplicação principal.

Configurando o bloco limit_req e a zona de memória

Para colocar a mão na massa, precisamos editar o arquivo de configuração do Nginx, geralmente localizado em /etc/nginx/nginx.conf ou dentro dos arquivos de configuração do seu site na pasta sites-available. O primeiro passo é criar a zona de armazenamento na memória e, em seguida, aplicar a regra propriamente dita dentro do contexto do servidor ou de uma rota específica de API.

O código abaixo demonstra uma configuração típica e funcional pronta para ser aplicada em seu ambiente de produção:

http {
    # Define uma zona de 10MB chamada 'api_limit' com limite de 5 requisições por segundo por IP
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;

    server {
        listen 80;
        server_name api.exemplo.com;

        location /api/v1/login {
            # Aplica a regra permitindo um burst de 10 requisições extras sem atraso
            limit_req zone=api_limit burst=10 nodelay;
            
            proxy_pass http://127.0.0.1:3000;
        }
    }
}

Neste exemplo prático, a variável binary_remote_addr captura o endereço IP do cliente de forma compacta para economizar memória. A taxa é definida como cinco requisições por segundo (5r/s). Caso queira entender como problemas semelhantes de tráfego excessivo se manifestam em outras tecnologias de backend, você pode ler mais sobre como implementar rate limiting no Node.js para complementar sua estratégia de resiliência em microsserviços.

Entendendo os parâmetros burst e nodelay

Usuários reais raramente enviam requisições em intervalos matematicamente perfeitos; eles clicam em botões rapidamente ou carregam páginas com múltiplos arquivos estáticos em microssegundos. É exatamente aqui que entram os parâmetros burst e nodelay. O burst define uma tolerância temporária para absorver rajadas legítimas de acesso acima do limite estipulado pela taxa principal.

Sem a diretiva nodelay, o Nginx enfileira essas requisições excedentes e as libera de forma espaçada no tempo, introduzindo uma latência artificial que pode frustrar o usuário. Quando adicionamos nodelay ao lado do burst, dizemos ao servidor para permitir que todas as requisições dentro da margem de tolerância passem instantaneamente, aplicando o bloqueio apenas se o volume total ultrapassar o limite combinado.

Como testar e validar o funcionamento do rate limiting

Após aplicar as alterações de configuração no Nginx e recarregar o serviço com o comando de teste de sintaxe, é fundamental validar se o bloqueio está funcionando conforme o esperado. Para isso, podemos utilizar ferramentas de linha de comando como o utilitário curl em um loop rápido para disparar dezenas de requisições simultâneas contra o endpoint protegido.

Se a configuração estiver correta, as primeiras requisições retornarão com sucesso, enquanto as excedentes receberão imediatamente o código de status HTTP 429, indicando que o limite de taxa foi atingido. Abaixo está o procedimento padrão para realizar esse teste básico de estresse na sua estação de trabalho:

1. Abra o terminal do seu sistema operacional e prepare o comando de disparo contínuo.
2. Execute um loop simples utilizando curl para enviar vinte requisições rápidas para a rota protegida.
3. Inspecione os códigos de resposta retornados pelo servidor para confirmar o surgimento do erro 429.

for i in {1..20}; do
  curl -I http://api.exemplo.com/api/v1/login
done

Caso precise investigar problemas mais profundos de entrega de pacotes ou comportamento atípico na camada de rede durante testes de carga, ferramentas de diagnóstico avançado como as discutidas em como monitorar tráfego HTTP/3 e QUIC no terminal com tshark podem oferecer uma visão cirúrgica do tráfego.

Considerações finais e boas práticas de operação

Implementar regras de limitação de taxa baseadas em endereço IP no Nginx é uma das defesas mais eficazes e simples de manter contra abusos automatizados em APIs modernas. No entanto, é preciso ter cautela ao definir os limites para não penalizar redes corporativas onde centenas de funcionários compartilham o mesmo endereço IP através de um proxy NAT. Combinar essa estratégia com tokens de autenticação e monitoramento contínuo garante um ambiente robusto e seguro.