Rate limiting por endereço IP: como desenhar limites para ambientes com IP compartilhado

Rate limiting é um mecanismo essencial para proteger aplicações web e APIs contra abuso, consumo excessivo de recursos e ataques de negação de serviço. A abordagem mais simples — e também a mais comum — é contabilizar requisições por endereço IP. O problema é que esse modelo deixa de funcionar bem diante de uma realidade cada vez mais presente nas redes modernas: IPs compartilhados.

IPs compartilhados estão em toda parte: NATs corporativos, redes de operadoras móveis, Wi-Fi público, VPNs, proxies e nós de saída TOR. Confiar apenas no IP de origem para identificar um usuário ou uma entidade única inevitavelmente leva a dois problemas: bloquear usuários legítimos, gerando falsos positivos, ou permitir que atacantes mais sofisticados contornem os limites alternando entre IPs compartilhados, gerando falsos negativos.

Este artigo apresenta estratégias para desenhar limites de requisição mais resilientes em ambientes com IP compartilhado, indo além da simples contagem por IP /32 ou /128.

The Core Problem: IP Address != User

Historicamente, um endereço IP costumava ter uma correlação razoável com um único usuário ou com um pequeno grupo de usuários atrás de um NAT estático. Hoje, essa premissa já não se sustenta:

• Mobile Carriers: Milhares — ou até dezenas de milhares — de usuários podem compartilhar um único endereço IPv4 público por meio de Carrier-Grade NAT (CGNAT).
• Enterprise Networks: Grandes organizações frequentemente concentram todo o tráfego de saída em um conjunto reduzido de IPs públicos.
• Public Wi-Fi/Hotspots: Muitos usuários se conectam simultaneamente usando o mesmo IP de gateway.
• Proxies, VPNs, TOR: Esses serviços agrupam usuários atrás de IPs compartilhados por privacidade ou para contornar restrições. Atacantes também se aproveitam disso para ganhar anonimato e distribuir volume entre vários IPs.
• Cloud Providers/Data Centers: Cargas de trabalho executadas em ambientes de nuvem ou data centers muitas vezes partem de grandes faixas de IP conhecidas, compartilhadas por inúmeros clientes.

Quando muitos usuários legítimos compartilham o mesmo IP, um limite simples por IP será atingido rapidamente, bloqueando todos eles. Por outro lado, um atacante pode alternar entre um conjunto de IPs de proxy, mantendo cada um aparentemente abaixo do limite, mas ultrapassando o volume total que a regra pretendia conter.

Beyond Simple IP: Augmenting Rate Limiting Signals

Para criar limites mais robustos, é preciso combinar o IP de origem com sinais adicionais.

1. User-Centric Identifiers

Quando disponível e adequado, associe o rate limiting a um ID de usuário, e não apenas ao IP. Esse é o cenário ideal para ações autenticadas.

• Session ID/Cookie: Monitore requisições por sessão. Isso ajuda a identificar ações repetidas a partir da mesma sessão.