Les noms VPN privés échouent ? Soupçon sur la protection contre le rebinding DNS

Sur le LAN du bureau, le nom interne répond instantanément. Dès que le VPN est monté, il cesse de fonctionner, l’application signale un délai d’attente dépassé, et le tunnel lui-même continue d’acheminer du trafic sans se plaindre. Ce qui a changé, c’est le résolveur, et ce résolveur a un avis sur les adresses privées.

La protection rebind existe pour arrêter un tour précis. Un nom privé publié exprès ressemble assez pour que la défense se déclenche.

Lisez la réponse avant de lire la politique

Interrogez le nom sur le résolveur que le VPN pousse réellement, pas celui que votre portable utilise à la maison. Comparez la réponse à l’enregistrement attendu, et notez si la réponse est vide, refusée ou pleine d’adresses publiques que personne n’avait prévues.

Les symptômes se recouvrent, donc la forme de la réponse décide du diagnostic. Un NXDOMAIN est un enregistrement manquant, un REFUSED est une règle d’accès, une adresse publique pour un nom interne est une erreur de politique ou de DNS scindé, et une adresse privée correcte que le client ne peut pas utiliser est un problème entièrement différent. Une connexion refusée ou une requête bloquée ne prouve rien à elle seule, c’est pourquoi la première commande dans n’importe quel de ces tickets devrait être une requête et non un redémarrage. Écrivez la réponse avant de changer quoi que ce soit.

Ce que la défense arrête réellement

Le rebinding DNS fonctionne en changeant ce à quoi un nom résout après que le client lui a déjà fait confiance. Une page se charge depuis un nom contrôlé par l’attaquant, la réponse bascule vers une adresse privée, et le navigateur est amené à parler à quelque chose du réseau local avec quoi il n’aurait jamais accepté une connexion directe. La défense consiste à refuser les réponses qui pointent vers l’espace privé quand on n’a jamais demandé au résolveur de servir un espace de noms privé. Toute l’attaque tient dans cette asymétrie.

dnsmasq documente exactement ce comportement, avec des exceptions par domaine. Sa page de manuel décrit rebind-domain-ok comme la façon de nommer des domaines qui peuvent légitimement renvoyer de telles adresses. Lisez cela comme le signe que le correctif prévu est une autorisation limitée, pas un interrupteur global.

Encadrez l’exception à l’espace de noms

Réparez d’abord l’espace de noms, puis l’exception. Confirmez que le nom qui échoue appartient à un domaine que l’organisation contrôle et que l’enregistrement est maintenu délibérément. Une adresse inattendue qui ressemble seulement à une plage familière du LAN mérite la suspicion et non une exception, alors vérifiez qui possède la zone avant d’écrire la moindre autorisation.

# 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

Ajoutez ensuite l’autorisation la plus étroite qui couvre les noms visés : un domaine, ou un sous-domaine délégué, dans la configuration du résolveur que les clients VPN interrogent. Désactiver la protection pour tous les noms de ce résolveur retire la défense pour tous d’un coup, y compris pour les noms qui n’en ont jamais eu besoin.

Le DNS scindé relève de la même décision. Si l’espace de noms privé ne doit être répondu que sur le résolveur interne, publiez-le là et cessez de le fuiter vers les résolveurs publics, afin que l’exception couvre un chemin au lieu de tous les chemins.

Retestez la ressource et la défense

Interrogez de nouveau, puis connectez-vous au service et regardez ce que le client voit. Une réponse privée correcte avec une session qui fonctionne signifie que l’exception a pris. Une réponse correcte avec une session bloquée signifie que la route ou l’identité du service est le prochain suspect.

# 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

Testez aussi un nom public via le même résolveur. La protection devrait continuer de fonctionner pour les noms hors de l’exception, et si ce contrôle échoue, le changement était plus large que prévu. Gardez la validation du certificat intacte tout du long, car un nom qui résout correctement doit encore correspondre au certificat que présente le service.

Consignez dans le ticket la réponse refusée, le domaine, le résolveur et à qui appartient la politique. C’est cette trace qui transforme une panne interne mystérieuse en un changement de configuration que quelqu’un peut relire.