O que é um IP bogon e por que isso importa
Um endereço IP bogon é um endereço de espaço privado, reservado ou não alocado que nunca deveria aparecer como origem de tráfego na internet pública. O nome vem de "bogus" (falso), e as faixas envolvidas são definidas pela IANA e por um conjunto de RFCs, de modo que verificar se um endereço é um bogon é uma consulta a uma lista publicada e baseada em padrões, e não um palpite.
As principais faixas bogon
Há dois grupos que vale separar. As faixas reservadas de finalidade especial são definidas por padrões e nunca serão roteadas publicamente. O espaço não alocado, às vezes chamado de "full bogons", é espaço de endereços que nenhum registro ainda distribuiu. As faixas reservadas abaixo são as que você encontrará com mais frequência.
0.0.0.0/8: "esta rede"; aparece como origem quando um host ainda não tem endereço.10.0.0.0/8,172.16.0.0/12,192.168.0.0/16: redes privadas da RFC 1918.100.64.0.0/10: espaço de endereços compartilhado para NAT de nível de operadora (RFC 6598).127.0.0.0/8: loopback.169.254.0.0/16: link-local, atribuído automaticamente quando o DHCP falha.192.0.0.0/24: atribuições de protocolo da IETF.192.0.2.0/24,198.51.100.0/24,203.0.113.0/24: blocos de documentação (RFC 5737) que você verá em exemplos e tutoriais.198.18.0.0/15: benchmarking de rede (RFC 2544).224.0.0.0/4: multicast.240.0.0.0/4: reservado para uso futuro, mais255.255.255.255, o endereço de broadcast limitado.
No IPv6, os equivalentes incluem ::/128 (não especificado), ::1/128 (loopback), fc00::/7 (endereços locais únicos), fe80::/10 (link-local), ff00::/8 (multicast) e 2001:db8::/32 (documentação). Endereços IPv4 mapeados, como ::ffff:0:0/96, e o prefixo NAT64 64:ff9b::/96 também merecem atenção, porque são mecanismos de tradução que tampouco deveriam aparecer como endereços de cliente. Alguns textos mais antigos também listam 192.88.99.0/24 (anycast de relay 6to4), que foi descontinuado.
Por que um bogon nos seus logs importa
Se um bogon aparece como o suposto cliente de uma requisição que atravessou a internet pública, uma de algumas coisas é verdadeira, e nem sempre é malicioso. Muitas vezes a causa é de infraestrutura: um proxy reverso ou balanceador de carga não está repassando o endereço real do cliente, então sua aplicação vê o endereço privado do proxy; uma entrada de X-Forwarded-For foi tirada da posição errada; ou uma configuração de NAT vazou um endereço interno para um campo público. São bugs de configuração que vale corrigir, pois quebram a limitação de taxa, a geolocalização e a denúncia de abusos.
A outra causa é deliberada. Endereços de origem podem ser forjados em pacotes e em cabeçalhos, e atacantes usam origens bogon em inundações falsificadas ou para sondar a filtragem. Como o tráfego legítimo não pode se originar dessas faixas, os operadores upstream as filtram na borda da rede (a ideia por trás da filtragem de entrada na BCP 38), e seu próprio firewall deve descartar origens bogon que chegam por interfaces públicas. Note a nuance: dentro da sua rede, endereços privados são normais, então aplique a regra apenas na fronteira pública.
Espaço reservado versus não alocado
A distinção importa quando você constrói seu próprio filtro. As faixas reservadas são fixadas por padrões e mudam raramente, então uma tabela estática delas permanece correta por anos. O espaço não alocado é diferente, porque os registros distribuem blocos ao longo do tempo e um endereço que era bogon no ano passado pode pertencer hoje a uma rede real. Filtros que fixam blocos não alocados no código historicamente bloquearam novos clientes de faixas recém-atribuídas, e é por isso que a lista de reservados é a mais segura para embutir no código da aplicação e que as questões de titularidade de endereços públicos pertencem aos dados de registro, e não a uma lista de bogons.
Verificando um endereço
Você pode testar qualquer endereço no verificador de IP bogon, que o compara com as faixas reservadas publicadas de IPv4 e IPv6 e mostra o bloco correspondente com uma tabela de referência. Na API, a resposta da consulta de IP inclui bogon e bogon_type, de modo que um pipeline de logs pode sinalizar esses endereços sem nenhuma tabela de faixas personalizada. A documentação da API lista a resposta completa.
Vale conhecer um limite. O verificador usa uma lista de reservados baseada em padrões, não uma visão ao vivo do que é roteado. Um endereço fora das faixas reservadas não tem garantia de estar alocado ou alcançável. Para descobrir se um endereço público realmente tem um proprietário, use a consulta whois de IP para ver o registro no registry, ou a consulta de ASN para ver a rede que o anuncia.
Tratamento prático
- Normalize e valide os endereços cedo; rejeite bogons em campos que esperam um IP de cliente público.
- Descarte origens bogon na sua borda pública com regras de firewall, mas não as aplique ao tráfego interno.
- Quando um bogon surgir inesperadamente, verifique primeiro a configuração do proxy e do balanceador de carga, já que configuração incorreta é mais comum que ataque.
- Lembre-se de que endereços bogon não têm geolocalização, então pule as consultas de geolocalização e reputação para eles e economize a requisição.