Os nomes privados da VPN fallan? A protección rebind de DNS é a sospeitosa

Na LAN da oficina o nome interno responde ao instante. No momento en que a VPN está activa deixa de funcionar, a aplicación informa dun tempo de espera esgotado e o túnel segue pasando tráfico sen queixarse. O que cambiou é o resolutor, e ese resolutor ten unha opinión sobre os enderezos privados.

A protección rebind existe para deter un truco concreto. Un nome privado publicado a propósito parécese o suficiente e a defensa actívase.

Le a resposta antes de ler a política

Consulta o nome no resolutor que a VPN entrega realmente, non no que o teu portátil usa na casa. Compara a resposta co rexistro que esperas e anota se a resposta está baleira, rexeitada ou chea de enderezos públicos que ninguén previra.

Os síntomas solápanse, así que a forma da resposta decide o diagnóstico. Un NXDOMAIN é un rexistro que falta, un REFUSED é unha regra de acceso, un enderezo público para un nome interno é un erro de política ou de DNS dividido, e un enderezo privado correcto que o cliente non pode usar é un problema completamente distinto. Unha conexión rexeitada ou unha petición atascada non demostran nada por si soas, por iso o primeiro comando en calquera destes tíckets debería ser unha consulta e non un reinicio. Anota a resposta antes de cambiar nada.

Que detén realmente a defensa

O rebinding de DNS funciona cambiando a que resolve un nome despois de que o cliente xa confiase nel. Unha páxina cárgase desde un nome controlado polo atacante, a resposta cambia a un enderezo privado e o navegador é enganado para falar con algo da rede local co que nunca aceptaría unha conexión directa. A defensa consiste en rexeitar as respostas que apuntan ao espazo privado cando nunca se lle pediu ao resolutor que servise un espazo de nomes privado. Esa asimetría é todo o ataque.

dnsmasq documenta exactamente ese comportamento, xunto con excepcións por dominio. A súa páxina de manual describe rebind-domain-ok como a forma de nomear dominios que poden devolver lexitimamente tales enderezos. Léoo como un sinal de que o arranxo previsto é un permiso acotado, non un interruptor global.

Acota a excepción ao espazo de nomes

Arranxa primeiro o espazo de nomes e despois a excepción. Confirma que o nome que falla pertence a un dominio que a organización controla e que o rexistro se mantén a propósito. Un enderezo inesperado que só se parece a un rango familiar da LAN merece sospeita e non unha excepción, así que comproba quen é o dono da zona antes de escribir calquera permiso.

# 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

Despois engade o permiso máis estreito que cubra os nomes previstos: un dominio, ou un subdominio delegado, na configuración do resolutor que consultan os clientes da VPN. Desactivar a protección para todos os nomes dese resolutor elimina a defensa para todos á vez, incluídos os nomes que nunca a necesitaron.

O DNS dividido pertence á mesma decisión. Se o espazo de nomes privado só se debe responder no resolutor interno, publícao alí e deixa de filtralo a resolutores públicos, para que a excepción cubra un camiño en lugar de todos os camiños.

Volve probar o recurso e a defensa

Consulta de novo, logo conéctate ao servizo e mira que ve o cliente. Unha resposta privada correcta cunha sesión que funciona significa que a excepción entrou. Unha resposta correcta cunha sesión atascada significa que a ruta ou a identidade do servizo é o seguinte sospeitoso.

# 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

Proba tamén un nome público a través do mesmo resolutor. A protección debería seguir funcionando para os nomes fóra da excepción, e se esa comprobación falla, o cambio foi máis amplo do previsto. Mantén a validación do certificado intacta en todo momento, porque un nome que resolve correctamente aínda ten que coincidir co certificado que presenta o servizo.

Anota no tícket a resposta rexeitada, o dominio, o resolutor e quen é o dono da política. Ese rexistro é o que converte unha interrupción interna misteriosa nun cambio de configuración que alguén pode revisar.