Como limitar a taxa e bloquear abuso de IPv6 por prefixo /64

Quase todo limitador de taxa, throttle de login e blocklist de IP em produção foi projetado para IPv4, em que o modelo mental é simples: um endereço, mais ou menos um usuário. Conte as requisições por endereço, bana o endereço, siga em frente. Esse modelo ficou silenciosamente errado. No momento em que seu tráfego inclui IPv6 (e uma parcela grande e crescente dele inclui), a unidade que você está contando deixa de corresponder a uma pessoa, e toda defesa construída sobre "um endereço" começa a vazar.

Não é um caso extremo sutil. É a diferença entre um limitador de taxa que funciona e um que o atacante atravessa direto enquanto seus dashboards mostram uma fileira arrumada de endereços com uma única requisição cada. A solução não é ter mais regras. É contar a coisa certa, o mesmo hábito por trás de verificar rastreadores de IA e bots por faixa de IP, em que o bloco CIDR publicado importa mais do que qualquer endereço individual. A contagem por prefixo é uma das camadas da detecção de bots pelo endereço IP; as outras dizem a que tipo de rede o prefixo pertence.

O hábito do IPv4 que quebra no IPv6

No IPv4, a escassez de endereços fazia um favor a você. Existem apenas cerca de 4,3 bilhões de endereços, eles são caros, e o arranjo esmagadoramente mais comum é que um assinante receba um único endereço público por vez. Então "requisições deste /32" e "requisições deste usuário" eram próximos o suficiente para serem tratados como a mesma coisa. Bana o /32 e você incomoda, no máximo, a residência ou o NAT por trás dele.

O IPv6 elimina a escassez e, com ela, essa premissa. O endereço tem 128 bits em vez de 32 (oito grupos de quatro dígitos hexadecimais), e a filosofia do projeto é o oposto da economia. Em vez de racionar endereços individuais, o IPv6 entrega a cada cliente um bloco deles. O menor bloco que alguém recebe é enorme, e esse bloco, não o endereço individual, é a verdadeira identidade do usuário.

Se o seu limitador ainda conta por endereço completo no IPv6, um abusador não precisa de botnet nem de pool de proxies. Ele precisa de uma alocação IPv6 comum e de um laço for.

Um assinante, 18 quintilhões de endereços

Aqui está o número que muda o enquadramento de todo o problema. O menor bloco roteável que um usuário final de IPv6 normalmente recebe é um /64: os primeiros 64 bits são a rede, e os últimos 64 bits ficam para ele preencher como quiser. Isso deixa 2^64 endereços utilizáveis dentro da sub-rede de um único assinante:

2^64 = 18.446.744.073.709.551.616 endereços: cerca de 18,4 quintilhões, todos pertencentes a um único usuário, todos igualmente roteáveis.

Dois fatos tornam isso inevitável, e não uma peculiaridade. Primeiro, a autoconfiguração de endereços sem estado (SLAAC), a forma padrão pela qual hosts IPv6 atribuem endereços a si mesmos, exige um /64 completo por sub-rede; não é possível entregar nada menor a uma LAN normal. Segundo, as diretrizes de planejamento de endereços que os RIRs seguem (RFC 6177 / BCP 157) orientam os provedores a dar a cada site final uma alocação generosa, geralmente um /56 ou /48, e nunca menos de um /64. A abundância é a própria razão de ser do protocolo.

Agora, o lado do atacante. Percorrer esses endereços não é caro nem engenhoso. É uma opção de socket nativa. A flag IP_FREEBIND do Linux permite que um processo faça bind e envie a partir de qualquer endereço dentro de um prefixo roteado localmente, sem precisar configurar cada endereço em uma interface antes, e ferramentas públicas como o amplamente citado projeto freebind empacotam exatamente isso em "usar um endereço de origem novo para cada conexão". Dê a ele um /64 roteado e ele emitirá tráfego a partir de 18 quintilhões de origens distintas sem custo algum.

Então, o limite de taxa por /128 não desacelera isso por fator nenhum. Cada requisição parece um endereço novinho, visto uma única vez. Os contadores do seu limitador nunca passam de um, sua blocklist se enche de milhões de entradas com uma única ocorrência e não corresponde a nada, e o ataque segue em velocidade máxima, parecendo, no papel, perfeitamente distribuído.

A hierarquia de alocação do IPv6 e o que cada nível significa

Para limitar a unidade certa, você precisa saber o que cada comprimento de prefixo realmente representa. Prefixos IPv6 são simplesmente blocos CIDR (a mesma notação /n do IPv4, em que um número menor cobre mais endereços), mas os limites convencionais carregam significado sobre quem está do outro lado.

A forma da decisão sai da própria tabela. O /128 nunca é a unidade. O /64 é o piso: o escopo mais estreito que ainda corresponde a um único agente e, portanto, o padrão. Tudo o que for mais amplo é uma escalada que você só usa quando tem evidência de que a alocação mais ampla, como um todo, é o problema.

Regra um: limite a taxa de IPv6 por prefixo, começando pelo /64

A única mudança que corrige a maior parte da quebra é parar de contar por endereço e começar a contar por /64. Concretamente, para cada requisição IPv6 recebida, derive o /64 mantendo os quatro primeiros hextetos (64 bits) e use isso como chave para os contadores de rate limiting, as contagens de tentativas de login e as consultas à blocklist.

Todas as ferramentas de borda populares já suportam isso, então raramente você precisa construir sozinho:

• nginx: monte a chave de limite a partir de um bloco map/geo que mascara o IPv6 para /64 e passe-a para limit_req_zone / limit_conn_zone em vez de $binary_remote_addr.
• HAProxy: defina uma máscara de 64 bits na origem ao montar as chaves da stick-table, para que src seja agregado ao /64 em vez do endereço completo.
• Cloudflare e a maioria das CDNs / WAFs: já tratam o IPv6 em blocos /64 na própria lógica de rate limiting e de desafio; replique essa granularidade nas regras da sua origem para que as duas camadas concordem.
• O limitador da sua própria aplicação: troque o remote_addr bruto pela chave /64 acima antes que ele chegue ao Redis, ao token bucket ou ao contador.

Faça só isso e o ataque de rotação gratuita volta a ser o que deveria: 18 quintilhões de endereços viram um contador, e o abusador é limitado exatamente como se fosse um único endereço IPv4. Esta é a linha de código de maior valor de todo o assunto.

Regra dois: escale para /56 e /48 quando houver persistência

Indexar pelo /64 resolve o atacante que alterna endereços dentro de uma sub-rede. O próximo degrau é o atacante que alterna sub-redes, porque um assinante muitas vezes detém não um /64, mas um /56 ou /48 inteiro cheio deles, e ferramentas no estilo do freebind também conseguem percorrê-los.

O sinal para ampliar é a persistência: /64s novos que continuam se comportando mal enquanto compartilham um prefixo pai comum. Quando você vê isso, a alocação inteira é uma única entidade e deve ser tratada como tal.

Pense nisso como um contador que se acumula para cima. Mantenha a contagem por /64 como unidade básica, mas também acompanhe o abuso agregado em cada /56 e /48. Quando um prefixo pai ultrapassar um limite que nenhum cliente legítimo ultrapassaria (muitos /64s filhos distintos, todos infringindo em uma janela curta), aplique o limite no nível do pai e deixe-o cobrir todos os filhos de uma vez. É assim que você se mantém à frente de um atacante que detém uma alocação grande sem punir quem detém uma alocação pequena e bem-comportada.

Regra três: amplie pelo tipo de rede, não por reflexo

A escalada tem um modo de falha, e é o mais caro: amplie demais e um único banimento apaga milhares de usuários inocentes. Um /48 pode ser uma empresa, ou pode ser uma fatia de uma operadora móvel. Um /32 quase nunca é um único agente; normalmente é um provedor de internet ou de hospedagem inteiro. O sinal de persistência diz que o prefixo pai está envolvido; não diz quantas pessoas reais estão por trás dele. Para isso, você precisa saber que tipo de rede o prefixo é.

É exatamente aqui que uma consulta de IP justifica seu lugar no pipeline. Uma chamada à API de consulta de IP com um endereço representativo do prefixo infrator diz se você está diante de infraestrutura alugada, que pode agregar de forma agressiva, ou de acesso de consumidor, que precisa tratar com cuidado.

Os campos que determinam até onde você pode ampliar com segurança:

Veja o que essa consulta retorna para um endereço IPv6 real, o Google Public DNS em 2001:4860:4860::8888, consultado em 5 de outubro de 2026 (resumido; os resultados mudam à medida que as faixas se movem):

As duas metades da resposta respondem a duas perguntas diferentes. asn_type: "hosting", connection_type: "datacenter" e is_hosting: true dizem que o prefixo é infraestrutura, então ampliar um bloqueio além do /64 não atingiria residências. Mas scoring.fraud_score é 15 e recommended_action é allow: o endereço em si não tem nenhum sinal de VPN, Tor ou abuso, e detection_methods lista apenas datacenter_ip e no_ptr_datacenter. O tipo de rede diz até onde você pode ampliar; seus próprios contadores de persistência precisam fornecer o motivo para ampliar. Um prefixo de hospedagem que nunca se comportou mal continua aberto.

A leitura é direcional e espelha o mesmo princípio por trás dos motivos da pontuação de risco que somam e subtraem: alguns campos permitem agir com mais força, outros dizem para você se conter.

O Google Ads conta da mesma forma: sua API aceita 2001:db8::/48 como uma única entrada de exclusão de IP, então um /48 custa um dos seus 500 espaços de exclusão do Google Ads.

A disciplina é a mesma que defendemos em detalhe em detectar tráfego anonimizado sem bloquear clientes reais: em um prefixo hosting ou datacenter, você pode ampliar o bloqueio com confiança, porque um checkout ou um cadastro não tem nenhum motivo honesto para se originar de um rack de servidores. É o mesmo indício que explicamos em o que é um endereço IP de datacenter. Em um prefixo mobile ou residential, você mantém o escopo estreito e deixa a pontuação de risco, e não um banimento CIDR amplo, carregar o peso. Ampliar por reflexo é como um limitador de taxa vira, silenciosamente, uma indisponibilidade para usuários reais.

Regra quatro: deixe a reputação do prefixo decair

A última regra é sobre tempo. As blocklists de IPv4 já ficam desatualizadas porque os endereços são reatribuídos; o IPv6 piora isso, porque prefixos inteiros são delegados, devolvidos e redelegados, e o /64 que martelou sua página de login no mês passado pode pertencer hoje a uma residência comum. Uma blocklist permanente em um espaço de endereços rotativo vira, aos poucos, uma lista de lugares que você já não consegue alcançar com segurança.

Então não armazene um veredicto permanente por prefixo. Armazene uma reputação que se move:

• Aumente com o abuso. Cada requisição infratora eleva a pontuação do /64 e propaga um incremento menor para os pais /56 e /48.
• Deixe decair com o tempo. Se um prefixo fica quieto, sua pontuação cai segundo um cronograma (horas para um throttle leve, dias para um bloqueio rígido) até voltar a ficar abaixo do seu limite, e o bloqueio se desfaz sozinho.
• Aja pela pontuação atual, não pelo histórico. Limite a taxa, desafie ou bloqueie com base em onde a reputação está agora, para que um prefixo regenerado ou reatribuído se recupere automaticamente em vez de ficar em uma lista que ninguém limpa.
• Guarde a evidência. Armazene quais sinais motivaram cada mudança de pontuação (os detection_methods da consulta, o padrão de persistência) para que um bloqueio amplo seja uma decisão que você consegue explicar, e não uma entrada misteriosa.

A decadência é o que mantém o sistema inteiro honesto. Ela significa que uma escalada agressiva durante um ataque não vira uma cicatriz permanente, e que sua blocklist reflete quem é hostil agora, e não quem foi hostil um dia.

Por onde começar esta semana

• Troque a chave do limitador para o /64. Em todo lugar onde você hoje conta ou bloqueia por endereço, mascare o IPv6 para os primeiros 64 bits antes. Essa única mudança fecha o buraco da rotação gratuita e normalmente são poucas linhas no nginx, no HAProxy ou na sua aplicação.
• Adicione contadores acumulados para /56 e /48. Acompanhe o abuso agregado nos prefixos pais para que um atacante que alterna sub-redes acione um limite mais amplo, sem que você amplie por padrão.
• Consulte a rede antes de ampliar. Em qualquer escalada além do /64, verifique asn_type / connection_type: agregue livremente em hospedagem, mantenha-se restrito em redes móveis e residenciais, nunca bloqueie de forma rígida uma faixa de operadora ou de CGNAT.
• Pontue os casos ambíguos. Onde um prefixo for compartilhado ou de consumidor, use o fraud_score composto e o recommended_action por endereço em vez de um banimento CIDR grosseiro.
• Dê decadência a todo bloqueio. Armazene a reputação do prefixo com uma meia-vida, aja pela pontuação atual e deixe o espaço reatribuído se liberar automaticamente.

O IPv6 não tornou a prevenção de abuso mais difícil, e sim mudou a unidade. O endereço já não é o usuário; o /64 é. Conte isso, escale com base em evidências, pondere pelo tipo de rede e deixe o tempo cuidar do perdão. Aí, todas as defesas em que você já confia no IPv4 voltam a funcionar.

Perguntas frequentes

Por que não dá para limitar a taxa de um endereço IPv6 do mesmo jeito que um endereço IPv4?

Porque os dois protocolos distribuem quantidades muito diferentes de espaço de endereços por usuário. No IPv4, um assinante normalmente recebe um endereço, então limitar por /32 (um único endereço) é limitar por usuário. No IPv6, um único assinante recebe rotineiramente um /64 inteiro. Isso é 2^64, cerca de 18,4 quintilhões de endereços, e ferramentas como IP_FREEBIND permitem que um processo envie tráfego a partir de qualquer endereço desse bloco sem custo. Limitar a taxa ou colocar em blocklist um único /128 (um endereço IPv6) portanto não impede nada: o abusador simplesmente usa o próximo dos 18 quintilhões de endereços. A unidade correta no IPv6 é o /64, não o /128.

Em qual comprimento de prefixo devo limitar a taxa de IPv6?

Comece pelo /64. O /64 é o menor bloco com garantia de pertencer a um único usuário final, porque o SLAAC exige um /64 completo por sub-rede e os provedores alocam pelo menos um /64 para cada cliente. Indexe seus contadores e blocklists pelos primeiros 64 bits do endereço e trate o /64 inteiro como um único agente. Quando o abuso persistir em muitos /64s do mesmo cliente, escale o escopo para o /56 (256 /64s) e depois para o /48 (65.536 /64s), que são os tamanhos típicos de uma alocação inteira de residência ou empresa.

É seguro bloquear um /64 IPv6 inteiro?

Quase sempre sim, e é mais seguro do que bloquear um único endereço IPv4. Um /64 é projetado para ser a sub-rede de um único assinante, então bloqueá-lo raramente atinge um terceiro sem relação, como acontece com um endereço IPv4 compartilhado por CGNAT. O risco real está nos prefixos mais amplos: um /48 ou /32 pode ser um provedor inteiro, uma operadora móvel ou uma faixa de hospedagem compartilhada que cobre milhares de usuários sem relação entre si. Amplie o escopo apenas quando o tipo de rede justificar: de forma agressiva em prefixos de hospedagem/datacenter, com cautela nos móveis e residenciais.

Como saber até onde ampliar um bloqueio?

Deixe duas coisas decidirem: persistência e tipo de rede. Persistência: se o abuso continua reaparecendo a partir de /64s novos dentro do mesmo /56 ou /48, toda essa alocação é uma única entidade e você amplia para ela. Tipo de rede: uma consulta que retorna um ASN de hospedagem ou de datacenter significa que o prefixo é infraestrutura e você pode agregar para cima rapidamente; uma operadora móvel ou um provedor residencial significa que muitos usuários reais podem estar atrás do prefixo mais amplo, então você se mantém restrito e se apoia em uma pontuação de risco em vez de um banimento rígido.

CGNAT e redes móveis mudam a forma como devo tratar o IPv6?

Sim, na ponta mais ampla. Um único /64 IPv6 normalmente é um assinante, mesmo em rede móvel, então limitar por /64 continua correto. Mas operadoras móveis e implantações de 464XLAT/NAT64 podem colocar muitos assinantes sob um prefixo mais amplo compartilhado, então um banimento na largura de /48 ou /32 em um ASN móvel pode derrubar uma grande fatia dos clientes de uma operadora. A regra é a mesma do IPv4: nunca bloqueie de forma rígida uma faixa compartilhada com base em um único agente mal-intencionado. Pontue-a e reserve os banimentos amplos para prefixos de infraestrutura.

Por quanto tempo um prefixo IPv6 deve ficar bloqueado?

Não para sempre. Prefixos IPv6 são reatribuídos, e um /64 que abusou de você no mês passado pode ser outro cliente no mês que vem. Associe a cada prefixo uma reputação que decai, em vez de uma entrada permanente: aumente a pontuação com abuso, deixe a pontuação cair com o tempo se nada de ruim acontecer e remova o bloqueio automaticamente quando ela decair abaixo do seu limite. Uma blocklist permanente em um espaço de endereços rotativo vira, aos poucos, uma lista de endereços que você já não consegue alcançar com segurança.