Nomes VPN privados falham? A proteção contra rebinding de DNS é a suspeita

Na LAN do escritório o nome interno responde de imediato. No momento em que a VPN está ativa ele deixa de funcionar, a aplicação reporta um tempo limite e o próprio túnel transporta tráfego sem queixas. O que mudou foi o resolvedor, e esse resolvedor tem uma opinião sobre endereços privados.

A proteção contra rebinding existe para travar um truque específico. Um nome privado publicado de propósito parece suficientemente semelhante para a defesa disparar.

Leia a resposta antes da política

Consulte o nome no resolvedor que a VPN realmente distribui, não no que o seu portátil usa em casa. Compare a resposta com o registo que espera e anote se a resposta está vazia, recusada ou cheia de endereços públicos que ninguém planeou.

Os sintomas sobrepõem-se, por isso é a forma da resposta que decide o diagnóstico. NXDOMAIN é um registo em falta, REFUSED é uma regra de acesso, um endereço público para um nome interno é um erro de política ou de split-DNS, e um endereço privado correto que o cliente não consegue usar é um problema completamente diferente. Uma ligação recusada ou um pedido bloqueado não prova nada por si só, e é por isso que o primeiro comando nestes casos deve ser uma consulta e não um reinício. Anote a resposta antes de mudar seja o que for.

O que a defesa está realmente a travar

O rebinding de DNS funciona mudando aquilo para que um nome resolve depois de o cliente já ter confiado nele. Uma página carrega a partir de um nome controlado pelo atacante, a resposta muda para um endereço privado e o navegador é enganado para falar com algo na rede local com que nunca teria aceitado uma ligação direta. A defesa é recusar respostas que apontem para o espaço privado quando o resolvedor nunca foi convidado a servir um espaço de nomes privado. Essa assimetria é todo o ataque.

O dnsmasq documenta exatamente esse comportamento, junto com exceções por domínio. No seu manual descreve rebind-domain-ok como a forma de nomear domínios que podem legitimamente devolver tais endereços. Leia isso como o sinal de que a correção pretendida é uma permissão delimitada, não um interruptor global.

Limite a exceção ao espaço de nomes

Corrija primeiro o espaço de nomes, depois a exceção. Confirme que o nome que falha pertence a um domínio controlado pela organização e que o registo é mantido deliberadamente. Um endereço inesperado que apenas se assemelha a uma gama de LAN familiar merece suspeita, não uma exceção, por isso verifique o dono da zona antes de escrever qualquer permissão.

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

Depois acrescente a permissão mais estreita que cobre os nomes pretendidos: um domínio, ou um subdomínio delegado, na configuração do resolvedor que os clientes VPN consultam. Desligar a proteção para todos os nomes nesse resolvedor retira a defesa a todos de uma vez, incluindo os nomes que nunca precisaram dela.

O split DNS faz parte da mesma decisão. Se o espaço de nomes privado só deve ser respondido no resolvedor interno, publique-o lá e pare de o deixar escapar para resolvedores públicos, para que a exceção cubra um caminho em vez de todos os caminhos.

Volte a testar o recurso e a defesa

Consulte outra vez, depois ligue ao serviço e verifique o que o cliente vê. Uma resposta privada correta com uma sessão a funcionar significa que a exceção ficou ativa. Uma resposta correta com uma sessão bloqueada significa que o próximo suspeito é a rota ou a identidade do serviço.

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

Teste também um nome público através do mesmo resolvedor. A proteção deve continuar a comportar-se corretamente para nomes fora da exceção, e se essa verificação falhar a mudança foi mais ampla do que se pretendia. Não mexa na validação de certificados em momento algum, porque um nome que resolve corretamente continua a ter de corresponder ao certificado que o serviço apresenta.

Registe no pedido a resposta recusada, o domínio, o resolvedor e quem é dono da política. É esse registo que transforma uma avaria interna misteriosa numa alteração de configuração que alguém pode rever.