Bumabagsak ang mga pribadong pangalan ng VPN? Ang proteksyon sa DNS rebinding ang pinaghihinalaan

Sa LAN ng opisina, agad na sumasagot ang panloob na pangalan. Sa sandaling bukas ang VPN ay tumitigil ito sa paggana, nag-uulat ang aplikasyon ng timeout, at ang tunnel mismo ay nagdadala ng trapiko nang walang reklamo. Ang nagbago ay ang resolver, at ang resolver na iyon ay may sariling opinyon tungkol sa mga pribadong address.

Umiiral ang proteksyon sa rebinding upang pigilan ang isang partikular na pakulo. Ang sadyang inilathalang pribadong pangalan ay mukhang sapat na katulad kaya lumalabas ang depensa.

Basahin ang sagot bago ang patakaran

Itanong ang pangalan sa resolver na aktuwal na ipinapamahagi ng VPN, hindi sa ginagamit ng laptop mo sa bahay. Ihambing ang sagot sa rekord na inaasahan mo, at itala kung ang sagot ay walang laman, tinanggihan, o puno ng mga pampublikong address na walang nagplano.

Nagsasapawan ang mga sintomas, kaya hugis ng sagot ang nagtatakda ng diagnosis. Ang NXDOMAIN ay nawawalang rekord, ang REFUSED ay tuntunin sa pag-access, ang pampublikong address para sa panloob na pangalan ay pagkakamali sa patakaran o split-DNS, at ang tamang pribadong address na hindi magamit ng kliyente ay ganap na ibang problema. Ang tinanggihang koneksyon o natigil na kahilingan ay walang pinapatunayan sa sarili nito, kaya ang unang utos sa mga ganitong ticket ay dapat paghahanap at hindi restart. Isulat ang sagot bago magbago ng anuman.

Ano ang aktuwal na pinipigilan ng depensa

Gumagana ang DNS rebinding sa pagbabago kung saan nare-resolve ang isang pangalan matapos na ito ay pagtiwalaan ng kliyente. Naglo-load ang pahina mula sa pangalang kontrolado ng attacker, lumilipat ang sagot sa pribadong address, at nalilinlang ang browser na kausapin ang isang bagay sa lokal na network na hindi nito kailanman tatanggapin ang direktang koneksyon. Ang depensa ay tanggihan ang mga sagot na tumuturo sa pribadong espasyo kapag ang resolver ay hindi kailanman hiniling na magserbisyo ng pribadong namespace. Ang asimetriyang iyon ang buong atake.

Idinodokumento ng dnsmasq ang eksaktong gawi na iyon, kasama ang mga eksepsyon kada domain. Sa manwal nito inilalarawan ang rebind-domain-ok bilang paraan upang pangalanan ang mga domain na lehitimong makapagbabalik ng gayong mga address. Basahin ito bilang hudyat na ang inilaan na pagwawasto ay limitadong pahintulot, hindi pandaigdigang switch.

Limitahan ang eksepsyon sa namespace

Ayusin muna ang namespace, pagkatapos ang eksepsyon. Tiyakin na ang bumabagsak na pangalan ay kabilang sa domain na kontrolado ng organisasyon at ang rekord ay sadyang pinapanatili. Ang hindi inaasahang address na kahawig lamang ng pamilyar na saklaw ng LAN ay dapat paghinalaan, hindi bigyan ng eksepsyon, kaya suriin ang may-ari ng zone bago magsulat ng anumang pahintulot.

# 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

Pagkatapos ay idagdag ang pinakamakitid na pahintulot na sumasaklaw sa mga inilaan na pangalan: isang domain, o isang delegadong subdomain, sa konfigurasyon ng resolver na tinatanong ng mga kliyente ng VPN. Ang pagpatay sa proteksyon para sa bawat pangalan sa resolver na iyon ay nag-aalis ng depensa para sa lahat nang sabay, kasama ang mga pangalang hindi kailanman nangailangan nito.

Bahagi ng parehong desisyon ang split DNS. Kung ang pribadong namespace ay dapat sagutin lamang sa panloob na resolver, ilathala ito roon at itigil ang pagtagas nito sa mga pampublikong resolver, upang ang eksepsyon ay sumaklaw sa isang landas sa halip na bawat landas.

Subukang muli ang resource at ang depensa

Itanong muli, pagkatapos kumonekta sa serbisyo at tingnan kung ano ang nakikita ng kliyente. Ang tamang pribadong sagot na may gumaganang sesyon ay nangangahulugang nagkabisa ang eksepsyon. Ang tamang sagot na may natigil na sesyon ay nangangahulugang ang susunod na pinaghihinalaan ay ang ruta o ang pagkakakilanlan ng serbisyo.

# 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

Subukan din ang pampublikong pangalan sa parehong resolver. Dapat pa ring kumilos nang tama ang proteksyon para sa mga pangalan sa labas ng eksepsyon, at kung mabigo ang pagsusuring iyon, ang pagbabago ay mas malawak kaysa nilayon. Huwag galawin ang pagpapatunay ng sertipiko sa buong panahon, dahil ang tamang nare-resolve na pangalan ay kailangan pa ring tumugma sa sertipikong inihaharap ng serbisyo.

Itala sa ticket ang tinanggihang sagot, ang domain, ang resolver at kung sino ang may-ari ng patakaran. Ang rekord na iyon ang nagpapalit ng mahiwagang panloob na pagkaabala tungo sa pagbabago sa konfigurasyon na maaaring suriin ng iba.