dnsmasq kasserer et privat DNS-svar: er det rebinding-beskyttelsen?

Virksomhedens DNS-server returnerer den forventede private adresse, og alligevel fejler en forespørgsel gennem den lokale videresendende resolver. Svaret findes, hvilket udelukker den opstrøms zone og selve posten. Tilbage er det trin, hvor resolveren beslutter, om den vil give svaret tilbage til klienten. Er den resolver dnsmasq, står afvisningen sandsynligvis allerede i loggen.

At modtage et svar og at vælge at returnere det er to forskellige trin.

Sammenlign det samme navn på begge resolvere

Notér, hvilken resolver applikationen faktisk bruger, og det præcise værtsnavn, den spørger efter. Sammenlign derefter opstrømsresultatet med den videresendende resolvers hændelse for det samme navn. Et manglende opstrømssvar, et cachelagret negativt svar og en logført afvisning kræver tre forskellige rettelser.

En adresse, der er synlig i en direkte diagnostisk forespørgsel, beviser ikke, at applikationen modtog den ad sin sædvanlige vej. De to forespørgsler kan gå ud fra forskellige resolvere eller fra den samme resolver under forskellige politikker. Skriv begge resultater ned, før du teoretiserer, for det er her, folk erstatter det ene med det andet. Sammenligningen er hele diagnosen.

Læs afvisningen i stedet for symptomet

dnsmasqs stop-dns-rebind-indstilling afviser kvalificerende svar med private adresser, der kommer fra opstrøms, og logger dem, når den gør det. Beskyttelsen findes af en god grund: et offentligt navn, der pludselig peger på en privat adresse, er det klassiske rebinding-angreb. Den overlapper også en bevidst privat tjeneste, og det er dit tilfælde.

Søg i loggen efter afvisningen, før du ændrer noget, for meddelelsen navngiver mekanismen.

Hvis der hverken er afvisning eller opstrømssvar, er rebinding-beskyttelsen ikke dit problem, og at slå den fra ville være en ændring, der ikke løser noget og samtidig øger eksponeringen. Det er værre end den oprindelige fejl, fordi den fjerner en kontrol og lader fejlen blive. Bekræft først den konkrete loglinje. Beslut derefter.

Begræns undtagelsen til ét domæne

For et verificeret domæne tilbyder dnsmasq-manualen en domænebegrænset undtagelse i stedet for en global kontakt.

rebind-domain-ok=corp.example

Domænet ovenfor er kun et eksempel. Brug det administrative domæne, du faktisk driver, og forstå indstillingens matchning, før du anvender den, for en suffiksregel dækker mere end den ene vært, du testede. En routers konfigurationsgenerator kan vise den samme indstilling via sin egen kontrol i stedet for en rå direktiv. Begge veje er fine, så længe det resulterende omfang er det tilsigtede.

En undtagelse fra rebinding-registrering gør præcis én ting: den lader det domænes svar passere.

Den konfigurerer ikke en split-DNS-forwarder, gør ikke et utilgængeligt opstrøm tilgængeligt og opretter ikke en rute til den returnerede adresse. Hvert af disse er et separat krav med sin egen fejlsignatur, og hvert fejler forskelligt i klienten.

Verificér uden at fjerne grænsen

Forespørg værtsnavnet igen gennem den videresendende vej, og opret derefter forbindelse til tjenesten med dens normale identitetskontrol. En DNS-undtagelse er ikke en grund til at acceptere et uventet certifikat, og de to fejl er lette at forveksle, når begge viser sig som en browserfejl. Test navnet og tjenesten hver for sig. Kun en af dem var nogensinde et DNS-problem.

Gem grunden til undtagelsen ved siden af konfigurationen, med en dato og en ansvarlig.

Tjek den igen, når den private tjeneste flytter, eller domænet ændrer sig. At slå beskyttelsen fra globalt ville ændre behandlingen af urelaterede svar og ville stadig efterlade fejlen i rute eller tjeneste, hvis rebinding aldrig var årsagen.