Private VPN-navne fejler? DNS-rebind-beskyttelsen er den mistænkte

På kontorets LAN svarer det interne navn øjeblikkeligt. I det øjeblik VPN’et er oppe holder det op med at virke, applikationen rapporterer en timeout, og tunnelen selv sender trafik uden klager. Det, der ændrede sig, er resolveren, og den resolver har en mening om private adresser.

Rebind-beskyttelse findes for at stoppe et bestemt trick. Et bevidst offentliggjort privat navn ligner tilstrækkeligt, og forsvaret udløses.

Læs svaret, før du læser politikken

Spørg navnet hos den resolver, VPN’et faktisk sender ud, ikke den din laptop bruger derhjemme. Sammenlign svaret med den post, du forventer, og noter, om svaret er tomt, afvist eller fuld af offentlige adresser, som ingen havde planlagt.

Symptomerne overlapper, så svarets form afgør diagnosen. Et NXDOMAIN er en manglende post, et REFUSED er en adgangsregel, en offentlig adresse til et internt navn er en politik- eller split-DNS-fejl, og en korrekt privat adresse, som klienten ikke kan bruge, er et helt andet problem. En afvist forbindelse eller en fastlåst anmodning beviser intet i sig selv, og derfor bør den første kommando i enhver af disse sager være et opslag og ikke en genstart. Skriv svaret ned, før du ændrer noget.

Hvad forsvaret egentlig stopper

DNS-rebinding virker ved at ændre, hvad et navn opløses til, efter at klienten allerede har stolet på det. En side indlæses fra et navn, en angriber kontrollerer, svaret skifter til en privat adresse, og browseren narres til at tale med noget på det lokale netværk, som den aldrig ville have accepteret en direkte forbindelse til. Forsvaret er at afvise svar, der peger ind i det private rum, når resolveren aldrig er blevet bedt om at betjene et privat navnerum. Netop den asymmetri er hele angrebet.

dnsmasq dokumenterer præcis den adfærd sammen med undtagelser pr. domæne. Dens manualside beskriver rebind-domain-ok som måden at navngive domæner, der lovligt må returnere sådanne adresser. Læs det som et signal om, at den tilsigtede rettelse er en afgrænset tilladelse, ikke en global kontakt.

Afgræns undtagelsen til navnerummet

Ret først navnerummet, derefter undtagelsen. Bekræft, at det fejlende navn hører til et domæne, organisationen kontrollerer, og at posten vedligeholdes bevidst. En uventet adresse, der blot ligner et velkendt LAN-område, fortjener mistanke og ikke en undtagelse, så kontrollér zonens ejer, før du skriver nogen tilladelse.

# 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

Tilføj derefter den snævreste tilladelse, der dækker de tilsigtede navne: ét domæne eller ét delegeret underdomæne i den resolverkonfiguration, VPN-klienterne spørger. At slå beskyttelsen fra for hvert navn på den resolver fjerner forsvaret for dem alle på én gang, også for de navne, der aldrig havde brug for det.

Split-DNS hører til samme beslutning. Hvis det private navnerum kun skal besvares på den interne resolver, så offentliggør det der, og stop med at lække det til offentlige resolvere, så undtagelsen dækker én vej i stedet for hver vej.

Test ressourcen og forsvaret igen

Spørg igen, og forbind derefter til tjenesten og se, hvad klienten ser. Et korrekt privat svar med en fungerende session betyder, at undtagelsen virkede. Et korrekt svar med en fastlåst session betyder, at ruten eller tjenestens identitet er den næste mistænkte.

# 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 også et offentligt navn gennem den samme resolver. Beskyttelsen bør stadig virke for navne uden for undtagelsen, og hvis den kontrol fejler, var ændringen bredere end tilsigtet. Hold certifikatvalideringen urørt hele vejen, for et navn, der opløses korrekt, skal stadig passe til det certifikat, tjenesten fremviser.

Skriv det afviste svar, domænet, resolveren og ejeren af politikken ned i sagen. Den registrering er det, der gør et mystisk internt udfald til en konfigurationsændring, som nogen kan gennemgå.