Privata VPN-namn slutar fungera? Skyddet mot DNS-rebinding är den misstänkte

På kontorets LAN svarar det interna namnet direkt. I samma stund som VPN:et är uppe slutar det fungera, programmet rapporterar timeout och själva tunneln transporterar trafik utan klagomål. Det som ändrades är resolvern, och den resolvern har en åsikt om privata adresser.

Skyddet mot rebinding finns för att stoppa ett specifikt trick. Ett medvetet publicerat privat namn ser tillräckligt likt ut för att försvaret ska slå till.

Läs svaret innan du läser policyn

Fråga namnservern som VPN:et faktiskt delar ut, inte den som din laptop använder hemma. Jämför svaret med posten du förväntar dig och notera om svaret är tomt, avvisat eller fullt av publika adresser som ingen hade planerat.

Symtomen överlappar, så det är svarets form som avgör diagnosen. NXDOMAIN är en saknad post, REFUSED är en åtkomstregel, en publik adress för ett internt namn är ett policy- eller split-DNS-fel, och en korrekt privat adress som klienten inte kan använda är ett helt annat problem. En avvisad anslutning eller en fastnad begäran bevisar ingenting i sig, därför bör det första kommandot i sådana ärenden vara en sökning och inte en omstart. Skriv ned svaret innan du ändrar något.

Vad försvaret faktiskt stoppar

DNS-rebinding fungerar genom att ändra vad ett namn löses upp till efter att klienten redan har litat på det. En sida laddas från ett namn angriparen kontrollerar, svaret växlar till en privat adress och webbläsaren lurats att prata med något på det lokala nätet som den aldrig skulle ha accepterat en direkt anslutning till. Försvaret är att avvisa svar som pekar in i privat adressrymd när resolvern aldrig har ombetts betjäna ett privat namnområde. Den asymmetrin är hela attacken.

dnsmasq dokumenterar exakt det beteendet, tillsammans med undantag per domän. I sin handbok beskriver den rebind-domain-ok som sättet att namnge domäner som lagligt får returnera sådana adresser. Läs det som en signal om att den avsedda rättelsen är ett avgränsat tillstånd, inte en global brytare.

Begränsa undantaget till namnområdet

Rätta namnområdet först, sedan undantaget. Bekräfta att namnet som misslyckas tillhör en domän som organisationen kontrollerar och att posten underhålls medvetet. En oväntad adress som bara liknar ett bekant LAN-intervall förtjänar misstanke, inte ett undantag, så kontrollera zonens ägare innan du skriver något tillstånd.

# 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

Lägg sedan till det smalaste tillståndet som täcker de avsedda namnen: en domän, eller en delegerad underdomän, i resolverkonfigurationen som VPN-klienterna frågar. Att stänga av skyddet för varje namn på den resolvern tar bort försvaret för alla på en gång, även namnen som aldrig behövde det.

Split DNS hör till samma beslut. Om det privata namnområdet bara ska besvaras på den interna resolvern, publicera det där och sluta läcka det till publika resolvrar, så att undantaget täcker en väg i stället för varje väg.

Testa resursen och försvaret igen

Fråga igen, anslut sedan till tjänsten och kontrollera vad klienten ser. Ett korrekt privat svar med en fungerande session betyder att undantaget gick igenom. Ett korrekt svar med en fastnad session betyder att rutten eller tjänstens identitet är nästa misstä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

Testa också ett publikt namn genom samma resolver. Skyddet bör fortfarande bete sig korrekt för namn utanför undantaget, och om den kontrollen misslyckas var ändringen bredare än avsett. Låt certifikatvalideringen vara orörd hela tiden, för ett namn som löses upp korrekt måste ändå matcha certifikatet som tjänsten presenterar.

Skriv ned det avvisade svaret, domänen, resolvern och vem som äger policyn i ärendet. Det är den posten som förvandlar ett mystiskt internt avbrott till en konfigurationsändring som någon kan granska.