निजी VPN नाम विफल हो रहे हैं? DNS रीबाइंड सुरक्षा संदिग्ध है

ऑफ़िस के लैन में आंतरिक नाम तुरंत जवाब देता है। जैसे ही VPN चालू होता है वह काम करना बंद कर देता है, एप्लिकेशन समय-समाप्ति बताता है, और टनल खुद बिना शिकायत के ट्रैफ़िक गुज़ारता रहता है। जो बदला है वह रिज़ॉल्वर है, और उस रिज़ॉल्वर की निजी पतों के बारे में अपनी राय है।

रीबाइंड सुरक्षा एक ख़ास तरकीब रोकने के लिए है। जान-बूझकर प्रकाशित किया गया निजी नाम काफ़ी मिलता-जुलता लगता है और रक्षा चालू हो जाती है।

नीति पढ़ने से पहले जवाब पढ़ें

नाम उस रिज़ॉल्वर से पूछें जो VPN वाक़ई भेजता है, न कि उससे जो आपका लैपटॉप घर पर इस्तेमाल करता है। जवाब की तुलना उस रिकॉर्ड से करें जिसकी आप अपेक्षा करते हैं, और नोट करें कि जवाब ख़ाली है, ठुकराया गया है या ऐसे सार्वजनिक पतों से भरा है जिनकी किसी ने योजना नहीं बनाई थी।

लक्षण एक-दूसरे पर चढ़ते हैं, इसलिए जवाब का आकार निदान तय करता है। NXDOMAIN एक गुम रिकॉर्ड है, REFUSED पहुँच का नियम है, आंतरिक नाम के लिए सार्वजनिक पता नीति या बँटे DNS की ग़लती है, और सही निजी पता जिसे क्लाइंट इस्तेमाल नहीं कर सकता, बिल्कुल अलग समस्या है। ठुकराया गया कनेक्शन या अटका हुआ अनुरोध अपने आप में कुछ साबित नहीं करता, इसीलिए इनमें से किसी भी टिकट में पहला आदेश बहाली नहीं, खोज होना चाहिए। कुछ भी बदलने से पहले जवाब लिख लें।

रक्षा वाक़ई क्या रोकती है

DNS रीबाइंडिंग इस तरह काम करती है कि क्लाइंट के नाम पर भरोसा कर लेने के बाद यह बदल दिया जाता है कि वह नाम कहाँ हल होता है। कोई पेज हमलावर के नियंत्रित नाम से लोड होता है, जवाब निजी पते की ओर पलट जाता है, और ब्राउज़र को स्थानीय नेटवर्क की ऐसी चीज़ से बात करने के लिए धोखा दिया जाता है जिससे वह कभी सीधा कनेक्शन स्वीकार नहीं करता। रक्षा यह है कि निजी जगह की ओर इशारा करने वाले जवाब ठुकरा दिए जाएँ जब रिज़ॉल्वर से कभी निजी नाम-स्थान की सेवा करने को कहा ही न गया हो। पूरा हमला वही असमानता है।

dnsmasq ठीक इसी व्यवहार का दस्तावेज़ीकरण करता है, साथ में प्रति-डोमेन अपवाद भी। उसका मैनुअल पृष्ठ rebind-domain-ok को ऐसे डोमेन के नाम रखने का तरीक़ा बताता है जो वैध रूप से ऐसे पते लौटा सकते हैं। इसे इस संकेत के रूप में पढ़ें कि इरादा सीमित अनुमति का है, वैश्विक स्विच का नहीं।

अपवाद को नाम-स्थान तक सीमित रखें

पहले नाम-स्थान ठीक करें, फिर अपवाद। पुष्टि करें कि विफल नाम किसी ऐसे डोमेन का है जिसे संगठन नियंत्रित करता है और रिकॉर्ड जान-बूझकर बनाए रखा जाता है। अप्रत्याशित पता जो केवल जाने-पहचाने लैन दायरे जैसा दिखता है, संदेह का हक़दार है, अपवाद का नहीं, इसलिए कोई भी अनुमति लिखने से पहले ज़ोन का मालिक जाँचें।

# 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

फिर वह सबसे सँकरा अनुमति जोड़ें जो इच्छित नामों को ढकता है: एक डोमेन, या एक प्रत्यायोजित उप-डोमेन, उस रिज़ॉल्वर के कॉन्फ़िगरेशन में जिससे VPN क्लाइंट पूछते हैं। उस रिज़ॉल्वर के हर नाम के लिए सुरक्षा बंद करने से सबकी रक्षा एक साथ चली जाती है, उन नामों की भी जिन्हें इसकी कभी ज़रूरत नहीं थी।

बँटा DNS उसी फ़ैसले का हिस्सा है। अगर निजी नाम-स्थान का जवाब सिर्फ़ आंतरिक रिज़ॉल्वर पर देना चाहिए, तो उसे वहीं प्रकाशित करें और उसे सार्वजनिक रिज़ॉल्वर तक लीक होने से रोकें, ताकि अपवाद हर रास्ते की जगह एक रास्ता ढके।

संसाधन और रक्षा फिर से जाँचें

फिर से पूछें, फिर सेवा से जुड़ें और देखें कि क्लाइंट क्या देखता है। सही निजी जवाब और चालू सत्र का मतलब है कि अपवाद लग गया। सही जवाब और अटका सत्र का मतलब है कि अगला संदिग्ध रास्ता या सेवा की पहचान है।

# 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

उसी रिज़ॉल्वर से एक सार्वजनिक नाम भी जाँचें। अपवाद के बाहर के नामों के लिए सुरक्षा को अब भी काम करना चाहिए, और अगर वह जाँच विफल हो तो बदलाव इरादे से ज़्यादा व्यापक था। प्रमाणपत्र की जाँच पूरे समय अछूती रखें, क्योंकि सही ढंग से हल होने वाले नाम को अब भी उस प्रमाणपत्र से मेल खाना है जो सेवा प्रस्तुत करती है।

टिकट में ठुकराया गया जवाब, डोमेन, रिज़ॉल्वर और नीति का मालिक कौन है, लिखें। यही रिकॉर्ड एक रहस्यमय आंतरिक रुकावट को ऐसे कॉन्फ़िगरेशन बदलाव में बदलता है जिसकी कोई समीक्षा कर सके।