Espaço de endereços público vs. privado
IP público
192.0.2.10
globalmente único, roteável de qualquer lugar
Faixas privadas
não roteáveis na internet pública
Por que faixas de IP privadas nunca devem resolver publicamente
A RFC 1918 reservou três faixas IPv4 — 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 — especificamente para uso dentro de redes privadas, justamente porque não há endereços IPv4 públicos suficientes para que cada dispositivo de cada rede privada tenha um endereço globalmente único. Essas faixas são reutilizadas, simultaneamente, dentro de milhões de redes sem relação entre si no mundo todo. O seu roteador doméstico quase certamente distribui endereços 192.168.x.x; o de praticamente todo mundo também.
O que significa um domínio público resolver para essa faixa
Como esses endereços só têm significado dentro da rede local que faz a consulta, um domínio público que resolve para um deles é, no mínimo, uma configuração incorreta — e, no pior caso, uma tentativa deliberada de fazer um sistema voltado ao público enviar uma requisição para o que quer que esteja naquele endereço em sua própria rede interna. A internet pública não tem uma ideia consistente do que 10.0.0.5 sequer significa; é uma máquina diferente dependendo inteiramente de qual rede está perguntando.
| Faixa | Nome | Por que é bloqueada |
|---|---|---|
| 10.0.0.0/8 | Privada (RFC 1918) | Reutilizada dentro de milhões de redes sem relação entre si |
| 172.16.0.0/12 | Privada (RFC 1918) | Igual à anterior |
| 192.168.0.0/16 | Privada (RFC 1918) | Igual à anterior — a faixa comum de roteadores domésticos |
| 127.0.0.0/8 | Loopback | Refere-se à própria máquina que faz a consulta |
| 169.254.0.0/16 | Link-local | Inclui 169.254.169.254, o endpoint de metadados da nuvem |
| 100.64.0.0/10 | Espaço de endereços compartilhado (RFC 6598) | NAT de nível de operadora — frequentemente ausente de listas de bloqueio feitas à mão |
| 0.0.0.0/8 | Não especificada | Não é um destino roteável de verdade |
| 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 | Faixas de documentação | Reservadas para exemplos, nunca destinadas a estarem ativas |
- Um domínio público legítimo não tem motivo algum para resolver para um endereço de faixa privada — se você vir um, trate-o como um sinal que merece investigação, não como um resultado normal.
- O IPv6 tem suas próprias faixas privadas/reservadas equivalentes — endereços locais únicos (fc00::/7) e link-local (fe80::/10) — que exigem exatamente o mesmo tratamento.
Filtrar essas faixas no momento da resolução — em vez de confiar que um domínio de aparência pública sempre resolve para um endereço de aparência pública — é a expectativa básica para qualquer ferramenta que resolve domínios em nome do usuário.
A faixa que a maioria das listas de bloqueio esquece
100.64.0.0/10 — o "espaço de endereços compartilhado", definido pela RFC 6598 — nem de longe tem o reconhecimento de 10.0.0.0/8 ou 192.168.0.0/16, apesar de ser igualmente não roteável na internet pública. Ela existe especificamente para o NAT de nível de operadora, permitindo que um provedor de internet atenda internamente um grande número de conexões de clientes sem consumir espaço IPv4 público para cada uma. Por ser mais nova e menos conhecida que as faixas clássicas da RFC 1918, é a que mais comumente falta em uma lista de bloqueio feita à mão — exatamente o tipo de lacuna que só aparece quando alguém aponta deliberadamente um domínio para um endereço dentro dela.
"Falhar de forma fechada" importa tanto quanto a própria lista
Uma lista de bloqueio é tão boa quanto o que acontece quando um endereço não pode ser interpretado. Uma entrada malformada, uma notação incomum ou um valor que não corresponde claramente a nenhuma faixa conhecida nunca deve ser tratado como "provavelmente bom" por padrão — o padrão seguro é rejeitar tudo o que não puder ser classificado com confiança como público, em vez de rejeitar apenas endereços que correspondam positivamente a uma faixa sabidamente ruim. Essa postura de "falhar de forma fechada" é o que mantém uma lista de bloqueio robusta contra as faixas que ninguém pensou em adicionar ainda, e não apenas contra as bem conhecidas que já estão na lista.
Precisa conferir os endereços DNS públicos de um domínio? Use a ferramenta Domain IP Lookup.
Ferramentas gratuitas sobre este assunto
Leitura relacionada
O SSRF transforma um servidor em um proxy involuntário
Atacante
elabora uma URL de requisição
Servidor vulnerável
acessa a URL, enganado por SSRF
169.254.169.254
o endpoint de metadados
Credenciais
devolvidas ao atacante
Endpoints de metadados na nuvem: a superfície de ataque oculta
Um único endereço IP, aparentemente não roteável, dá às instâncias de nuvem acesso a credenciais e configurações, e é um alvo comum de SSRF.
O mesmo endereço, quatro formas de escrevê-lo
Ataques SSRF explicados: como o DNS é explorado
A falsificação de requisição no servidor (SSRF) muitas vezes começa com um simples nome de domínio que o seu servidor foi induzido a resolver e acessar.
O mesmo domínio, duas respostas diferentes
Primeira requisição
resolve para um IP público
Validação
passa: parece seguro
O TTL expira
segundos depois
Segunda requisição
resolve para 127.0.0.1
O que é DNS rebinding e por que você deveria se importar?
Um domínio que resolve para um endereço seguro e depois para um interno: o DNS rebinding transforma o próprio DNS em superfície de ataque.