Privé-VPN-namen werken niet? De bescherming tegen DNS-rebinding is de verdachte

Op het kantoor-LAN antwoordt de interne naam meteen. Zodra de VPN actief is, werkt hij niet meer, de applicatie meldt een time-out en de tunnel zelf transporteert verkeer zonder klagen. Wat veranderd is, is de resolver, en die resolver heeft een mening over privéadressen.

De bescherming tegen rebinding bestaat om één specifieke truc te stoppen. Een bewust gepubliceerde privénaam lijkt genoeg op een ander om de verdediging te laten afgaan.

Lees het antwoord voordat je het beleid leest

Bevraag de naam bij de resolver die de VPN echt uitdeelt, niet bij degene die je laptop thuis gebruikt. Vergelijk het antwoord met het record dat je verwacht, en noteer of het antwoord leeg, geweigerd of vol openbare adressen is die niemand had gepland.

De symptomen overlappen, dus de vorm van het antwoord bepaalt de diagnose. NXDOMAIN is een ontbrekend record, REFUSED is een toegangsregel, een openbaar adres voor een interne naam is een beleids- of split-DNS-fout, en een correct privéadres dat de client niet kan gebruiken is een heel ander probleem. Een geweigerde verbinding of een vastgelopen verzoek bewijst op zichzelf niets, daarom zou het eerste commando in zulke tickets een opzoeking moeten zijn en geen herstart. Schrijf het antwoord op voordat je iets verandert.

Wat de verdediging werkelijk tegenhoudt

DNS-rebinding werkt door te veranderen waar een naam naar verwijst nadat de client hem al heeft vertrouwd. Een pagina laadt vanaf een door de aanvaller beheerste naam, het antwoord klapt om naar een privéadres, en de browser wordt misleid om te praten met iets op het lokale netwerk waarmee hij nooit een directe verbinding zou hebben geaccepteerd. De verdediging is antwoorden weigeren die naar de privéruimte wijzen wanneer de resolver nooit is gevraagd een privénamespace te bedienen. Die asymmetrie is de hele aanval.

dnsmasq documenteert precies dat gedrag, samen met uitzonderingen per domein. In de handleiding beschrijft het rebind-domain-ok als de manier om domeinen te benoemen die zulke adressen legitiem mogen teruggeven. Lees dat als een signaal dat de bedoelde oplossing een beperkte toestemming is, geen globale schakelaar.

Beperk de uitzondering tot de namespace

Repareer eerst de namespace, dan de uitzondering. Bevestig dat de falende naam bij een domein hoort dat de organisatie beheert en dat het record bewust wordt onderhouden. Een onverwacht adres dat alleen op een bekend LAN-bereik lijkt, verdient wantrouwen en geen uitzondering, dus controleer de eigenaar van de zone voordat je enige toestemming schrijft.

# 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

Voeg dan de smalste toestemming toe die de bedoelde namen dekt: één domein, of één gedelegeerd subdomein, in de resolverconfiguratie die de VPN-clients bevragen. De bescherming uitzetten voor elke naam op die resolver haalt de verdediging voor allemaal tegelijk weg, ook voor de namen die hem nooit nodig hadden.

Split DNS hoort bij dezelfde beslissing. Als de privénamespace alleen op de interne resolver beantwoord moet worden, publiceer hem daar en stop met hem naar openbare resolvers te lekken, zodat de uitzondering één pad dekt in plaats van elk pad.

Test de bron en de verdediging opnieuw

Bevraag opnieuw, verbind dan met de dienst en controleer wat de client ziet. Een correct privéantwoord met een werkende sessie betekent dat de uitzondering is toegepast. Een correct antwoord met een vastgelopen sessie betekent dat de route of de identiteit van de dienst de volgende verdachte is.

# 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

Test ook een openbare naam via dezelfde resolver. De bescherming zou zich voor namen buiten de uitzondering nog steeds correct moeten gedragen, en als die controle faalt, was de wijziging breder dan bedoeld. Laat de certificaatvalidatie de hele tijd ongemoeid, want een naam die correct oplost moet nog steeds overeenkomen met het certificaat dat de dienst presenteert.

Noteer het geweigerde antwoord, het domein, de resolver en wie het beleid bezit in het ticket. Dat verslag is wat een mysterieuze interne storing omzet in een configuratiewijziging die iemand kan beoordelen.