Private VPN-Namen schlagen fehl? Der Verdacht fällt auf den DNS-Rebind-Schutz

Im Büro-LAN antwortet der interne Name sofort. Sobald das VPN steht, hört er auf zu funktionieren, die Anwendung meldet eine Zeitüberschreitung, und der Tunnel selbst leitet weiterhin Verkehr ohne Beschwerde. Geändert hat sich der Resolver, und dieser Resolver hat eine Meinung zu privaten Adressen.

Der Rebind-Schutz existiert, um einen bestimmten Trick zu stoppen. Ein absichtlich veröffentlichter privater Name sieht ähnlich genug aus, dass die Abwehr auslöst.

Lesen Sie die Antwort, bevor Sie die Richtlinie lesen

Fragen Sie den Namen bei dem Resolver ab, den das VPN tatsächlich zustellt, nicht bei dem, den Ihr Laptop zu Hause nutzt. Vergleichen Sie die Antwort mit dem erwarteten Eintrag und notieren Sie, ob die Antwort leer, verweigert oder voller öffentlicher Adressen ist, die niemand geplant hat.

Die Symptome überschneiden sich, deshalb entscheidet die Form der Antwort über die Diagnose. Ein NXDOMAIN ist ein fehlender Eintrag, ein REFUSED ist eine Zugriffsregel, eine öffentliche Adresse für einen internen Namen ist ein Richtlinien- oder Split-DNS-Fehler, und eine korrekte private Adresse, die der Client nicht nutzen kann, ist ein ganz anderes Problem. Eine verweigerte Verbindung oder eine hängende Anfrage beweist für sich genommen nichts, deshalb sollte der erste Befehl in jedem dieser Tickets eine Abfrage sein und kein Neustart. Schreiben Sie die Antwort auf, bevor Sie etwas ändern.

Was die Abwehr tatsächlich stoppt

DNS-Rebinding funktioniert, indem es ändert, worauf ein Name auflöst, nachdem der Client ihm bereits vertraut hat. Eine Seite lädt von einem vom Angreifer kontrollierten Namen, die Antwort kippt auf eine private Adresse, und der Browser wird dazu verleitet, mit etwas im lokalen Netz zu sprechen, zu dem er eine direkte Verbindung nie akzeptiert hätte. Die Abwehr besteht darin, Antworten abzulehnen, die in den privaten Raum zeigen, wenn der Resolver nie gebeten wurde, einen privaten Namensraum zu bedienen. Genau diese Asymmetrie ist der ganze Angriff.

dnsmasq dokumentiert genau dieses Verhalten, samt Ausnahmen pro Domain. Seine Handbuchseite beschreibt rebind-domain-ok als den Weg, Domains zu benennen, die solche Adressen legitim zurückgeben dürfen. Lesen Sie das als Signal, dass die beabsichtigte Korrektur eine begrenzte Erlaubnis ist, kein globaler Schalter.

Grenzen Sie die Ausnahme auf den Namensraum ein

Reparieren Sie zuerst den Namensraum, dann die Ausnahme. Bestätigen Sie, dass der fehlschlagende Name zu einer Domain gehört, die die Organisation kontrolliert, und dass der Eintrag bewusst gepflegt wird. Eine unerwartete Adresse, die einem vertrauten LAN-Bereich nur ähnelt, verdient Misstrauen und keine Ausnahme, prüfen Sie also den Eigentümer der Zone, bevor Sie irgendeine Erlaubnis schreiben.

# 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

Fügen Sie dann die engste Erlaubnis hinzu, die die beabsichtigten Namen abdeckt: eine Domain oder eine delegierte Subdomain in der Resolver-Konfiguration, die die VPN-Clients abfragen. Den Schutz für jeden Namen auf diesem Resolver abzuschalten, entfernt die Abwehr für alle auf einmal, einschließlich der Namen, die sie nie gebraucht haben.

Split-DNS gehört zur selben Entscheidung. Wenn der private Namensraum nur auf dem internen Resolver beantwortet werden soll, veröffentlichen Sie ihn dort und unterbinden Sie das Durchsickern zu öffentlichen Resolvern, damit die Ausnahme einen Pfad abdeckt statt jeden Pfad.

Testen Sie die Ressource und die Abwehr erneut

Fragen Sie erneut ab, verbinden Sie sich dann mit dem Dienst und prüfen Sie, was der Client sieht. Eine korrekte private Antwort mit einer funktionierenden Sitzung bedeutet, dass die Ausnahme gegriffen hat. Eine korrekte Antwort mit einer hängenden Sitzung bedeutet, dass die Route oder die Dienstidentität der nächste Verdächtige ist.

# 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

Testen Sie auch einen öffentlichen Namen über denselben Resolver. Der Schutz sollte für Namen außerhalb der Ausnahme weiterhin greifen, und wenn diese Prüfung fehlschlägt, war die Änderung weiter als beabsichtigt. Lassen Sie die Zertifikatsprüfung durchgehend unangetastet, denn ein Name, der korrekt auflöst, muss immer noch zum Zertifikat passen, das der Dienst vorlegt.

Halten Sie im Ticket die abgelehnte Antwort, die Domain, den Resolver und den Eigentümer der Richtlinie fest. Dieser Eintrag ist es, der aus einem rätselhaften internen Ausfall eine Konfigurationsänderung macht, die jemand prüfen kann.