Private VPN-namn sviktar? Vernet mot DNS-rebinding er den mistenkte

På kontorets LAN svarar det interne namnet med ein gong. I det augneblinken VPN-et er oppe sluttar det å verke, programmet rapporterer tidsavbrot, og tunnelen sjølv fører trafikk utan klager. Det som endra seg er resolveren, og den resolveren har ei meining om private adresser.

Vernet mot rebinding finst for å stoppe eitt bestemt triks. Eit medvite publisert privat namn ser likt nok ut til at forsvaret blir utløyst.

Les svaret før du les policyen

Spør namnet mot resolveren VPN-et faktisk deler ut, ikkje den laptopen din brukar heime. Samanlikn svaret med posten du ventar, og noter om svaret er tomt, avvist eller fullt av offentlege adresser ingen hadde planlagt.

Symptoma overlappar, så forma på svaret avgjer diagnosen. NXDOMAIN er ein manglande post, REFUSED er ei tilgangsregel, ei offentleg adresse for eit internt namn er ein policy- eller split-DNS-feil, og ei korrekt privat adresse klienten ikkje kan bruke er eit heilt anna problem. Ei avvist tilkopling eller ein fastlåst førespurnad provar ingenting åleine, difor bør den første kommandoen i slike saker vere eit oppslag og ikkje ein omstart. Skriv ned svaret før du endrar noko.

Kva forsvaret faktisk stoppar

DNS-rebinding verkar ved å endre kva eit namn blir løyst til etter at klienten alt har stole på det. Ei side blir lasta frå eit namn åtvikaren kontrollerer, svaret vippar til ei privat adresse, og nettlesaren blir lurt til å snakke med noko på det lokale nettet han aldri ville ha godteke ei direkte tilkopling til. Forsvaret er å avvise svar som peikar inn i privat rom når resolveren aldri blei beden om å tene eit privat namnerom. Den asymmetrien er heile åtaket.

dnsmasq dokumenterer nøyaktig denne åtferda, saman med unntak per domene. I handboka skildrar han rebind-domain-ok som måten å namngje domene som lovleg kan returnere slike adresser. Les det som eit signal om at den tiltenkte rettinga er ei avgrensa løyve, ikkje ein global brytar.

Avgrens unntaket til namnerommet

Fiks namnerommet først, deretter unntaket. Stadfest at namnet som sviktar høyrer til eit domene organisasjonen kontrollerer og at posten blir halden ved like medvite. Ei uventa adresse som berre liknar eit kjent LAN-område fortener mistanke, ikkje eit unntak, så sjekk eigaren av sona før du skriv noka løyve.

# 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

Legg så til den smalaste løyva som dekkjer dei tiltenkte namna: eitt domene, eller eitt delegert subdomene, i resolverkonfigurasjonen VPN-klientane spør. Å slå av vernet for kvart namn på den resolveren fjernar forsvaret for alle på ein gong, òg namna som aldri trong det.

Split DNS høyrer til i same avgjerda. Viss det private namnerommet berre skal svarast på den interne resolveren, publiser det der og slutt å lekke det til offentlege resolverar, slik at unntaket dekkjer éin veg i staden for kvar veg.

Test ressursen og forsvaret på nytt

Spør igjen, kople så til tenesta og sjekk kva klienten ser. Eit korrekt privat svar med ein fungerande sesjon betyr at unntaket tok til. Eit korrekt svar med ein fastlåst sesjon betyr at ruta eller identiteten til tenesta er den neste mistenkte.

# 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 òg eit offentleg namn gjennom same resolver. Vernet skal framleis oppføre seg rett for namn utanfor unntaket, og viss den sjekken sviktar var endringa breiare enn tiltenkt. Hald sertifikatvalideringa urørt heile vegen, for eit namn som blir løyst rett må framleis samsvare med sertifikatet tenesta presenterer.

Skriv ned det avviste svaret, domenet, resolveren og kven som eig policyen i saka. Den posten er det som gjer eit mystisk internt avbrot til ei konfigurasjonsendring nokon kan gå gjennom.