dnsmasq laat 'n private DNS-antwoord val: is dit rebinding-beskerming?

Die maatskappy se DNS-bediener gee die verwagte private adres terug, en tog misluk ’n navraag deur die plaaslike aanstuur-oplosser. Die antwoord bestaan, wat die boonste sone en die rekord self uitsluit. Wat oorbly, is die stap waar die oplosser besluit of hy daardie antwoord aan die kliënt teruggee. As daardie oplosser dnsmasq is, is die weiering waarskynlik al in die log.

Om ’n antwoord te ontvang en om te kies om dit terug te gee, is twee verskillende stappe.

Vergelyk dieselfde naam op albei oplossers

Skryf neer watter oplosser die toepassing werklik gebruik en die presiese gasheernaam waarvoor dit vra. Vergelyk dan die boonste resultaat met die aanstuur-oplosser se gebeurtenis vir dieselfde naam. ’n Ontbrekende antwoord van bo, ’n gekaste negatiewe antwoord en ’n aangetekende weiering verg drie verskillende regstellings.

’n Adres wat in ’n direkte diagnostiese navraag sigbaar is, bewys nie dat die toepassing dit op sy gewone pad ontvang het nie. Die twee navrae kan van verskillende oplossers kom, of van dieselfde oplosser onder verskillende beleide. Skryf albei resultate neer voordat jy teoretiseer, want dit is juis die stap waar mense die een deur die ander vervang. Die vergelyking is die hele diagnose.

Lees die weiering eerder as die simptoom

dnsmasq se stop-dns-rebind-opsie verwerp kwalifiserende antwoorde met private adresse wat van bo kom, en teken dit aan wanneer dit dit doen. Daardie beskerming bestaan om ’n goeie rede: ’n openbare naam wat skielik na ’n private adres wys, is die klassieke rebinding-aanval. Dit kruis egter ook ’n doelbewus private diens, en dit is jou geval.

Soek die weiering in die log voordat jy enigiets verander, want die boodskap noem die meganisme.

As daar geen weiering en geen antwoord van bo is nie, is rebinding-beskerming nie jou probleem nie, en om dit af te skakel sou ’n verandering wees wat niks regmaak nie en die blootstelling vergroot. Dit is erger as die oorspronklike fout, want dit verwyder ’n beheer en laat die gebrek staan. Bevestig eers die spesifieke logreël. Besluit dan.

Beperk die uitsondering tot een domein

Vir ’n geverifieerde domein bied die dnsmasq-handleiding ’n domeinbeperkte uitsondering eerder as ’n globale skakelaar.

rebind-domain-ok=corp.example

Die domein hierbo is net ’n voorbeeld. Gebruik die administratiewe domein wat jy werklik bestuur, en verstaan die opsie se passingomvang voordat jy dit toepas, want ’n agtervoegselreël dek meer as die een gasheer wat jy getoets het. ’n Roeteerder se konfigurasiegenerator kan dieselfde instelling deur sy eie beheer bied eerder as ’n rou richtlijn. Albei weë is goed solank die resulterende omvang die een is wat jy bedoel het.

’n Uitsondering op rebinding-opsporing doen presies een ding: dit laat die antwoorde van daardie domein deur.

Dit stel nie ’n split-DNS-aanstuurder op nie, maak nie ’n onbereikbare bron van bo bereikbaar nie en skep nie ’n roete na die teruggegewe adres nie. Elkeen daarvan is ’n aparte vereiste met sy eie foutpatroon, en elkeen misluk anders in die kliënt.

Verifieer sonder om die grens te verwyder

Vra weer die gasheernaam deur die aanstuurpad, en verbind dan aan die diens met sy gewone identiteitskontroles. ’n DNS-uitsondering is nie ’n rede om ’n onverwagte sertifikaat te aanvaar nie, en die twee foute is maklik om te verwar wanneer albei as ’n blaaierfout verskyn. Toets die naam en die diens afsonderlik. Net een van die twee was ooit ’n DNS-probleem.

Hou die rede vir die uitsondering langs die konfigurasie, met ’n datum en ’n verantwoordelike.

Herkontroleer dit wanneer die private diens skuif of die domein verander. Om die beskerming globaal af te skakel, sou die hantering van onverwante antwoorde verander en sou steeds die fout in die roete of diens laat staan as rebinding nooit die oorsaak was nie.