Private VPN-navn svikter? Beskyttelsen mot DNS-rebinding er den mistenkte

På kontorets LAN svarer det interne navnet umiddelbart. I det VPN-et er oppe slutter det å virke, applikasjonen rapporterer tidsavbrudd, og tunnelen selv fører trafikk uten klager. Det som endret seg er resolveren, og den resolveren har en mening om private adresser.

Beskyttelsen mot rebinding finnes for å stoppe ett bestemt triks. Et bevisst publisert privat navn ser likt nok ut til at forsvaret utløses.

Les svaret før du leser policyen

Spør navnet mot resolveren VPN-et faktisk deler ut, ikke den laptopen din bruker hjemme. Sammenlign svaret med posten du forventer, og noter om svaret er tomt, avvist eller fullt av offentlige adresser ingen hadde planlagt.

Symptomene overlapper, så formen på svaret avgjør diagnosen. NXDOMAIN er en manglende post, REFUSED er en tilgangsregel, en offentlig adresse for et internt navn er en policy- eller split-DNS-feil, og en korrekt privat adresse klienten ikke kan bruke er et helt annet problem. En avvist tilkobling eller en fastlåst forespørsel beviser ingenting alene, derfor bør den første kommandoen i slike saker være et oppslag og ikke en omstart. Skriv ned svaret før du endrer noe.

Hva forsvaret faktisk stopper

DNS-rebinding virker ved å endre hva et navn løses til etter at klienten allerede har stolt på det. En side lastes fra et navn angriperen kontrollerer, svaret vippes til en privat adresse, og nettleseren lures til å snakke med noe på det lokale nettet den aldri ville ha akseptert en direkte tilkobling til. Forsvaret er å avvise svar som peker inn i privat rom når resolveren aldri ble bedt om å betjene et privat navnerom. Den asymmetrien er hele angrepet.

dnsmasq dokumenterer nøyaktig denne oppførselen, sammen med unntak per domene. I håndboken beskriver den rebind-domain-ok som måten å navngi domener som lovlig kan returnere slike adresser. Les det som et signal om at den tiltenkte rettelsen er en avgrenset tillatelse, ikke en global bryter.

Avgrens unntaket til navnerommet

Fiks navnerommet først, deretter unntaket. Bekreft at navnet som feiler tilhører et domene organisasjonen kontrollerer og at posten vedlikeholdes bevisst. En uventet adresse som bare ligner et kjent LAN-område fortjener mistanke, ikke et unntak, så sjekk sonens eier før du skriver noen tillatelse.

# 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 smaleste tillatelsen som dekker de tiltenkte navnene: ett domene, eller ett delegert subdomene, i resolverkonfigurasjonen VPN-klientene spør. Å slå av beskyttelsen for hvert navn på den resolveren fjerner forsvaret for alle på en gang, også navnene som aldri trengte det.

Split DNS hører til i samme beslutning. Hvis det private navnerommet bare skal besvares på den interne resolveren, publiser det der og slutt å lekke det til offentlige resolvere, slik at unntaket dekker én vei i stedet for hver vei.

Test ressursen og forsvaret på nytt

Spør igjen, koble så til tjenesten og sjekk hva klienten ser. Et korrekt privat svar med en fungerende sesjon betyr at unntaket trådte i kraft. Et korrekt svar med en fastlåst sesjon betyr at ruten eller tjenestens identitet 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 også et offentlig navn gjennom samme resolver. Beskyttelsen skal fortsatt oppføre seg riktig for navn utenfor unntaket, og hvis den sjekken feiler var endringen bredere enn tiltenkt. Hold sertifikatvalideringen urørt hele veien, for et navn som løses riktig må fortsatt samsvare med sertifikatet tjenesten presenterer.

Skriv ned det avviste svaret, domenet, resolveren og hvem som eier policyen i saken. Den posten er det som gjør et mystisk internt avbrudd til en konfigurasjonsendring noen kan gjennomgå.