मैं एक "सुरक्षित" ओपन रिज़ॉल्वर कैसे स्थापित करूं?

Question

यह सार्वजनिक DNS रिज़ॉल्वर को सुरक्षित करने के बारे में एक कैननिकल प्रश्न है

ओपन DNS सर्वर बहुत साफ और सुविधाजनक लगते हैं, क्योंकि वे आईपी पते प्रदान करते हैं जो हम अपनी कंपनी में लगातार उपयोग कर सकते हैं, भले ही वे कहाँ स्थित हों। Google और OpenDNS इस कार्यक्षमता को प्रदान करते हैं, लेकिन मुझे यकीन नहीं है कि मैं चाहता हूं कि इन कंपनियों की हमारे DNS प्रश्नों तक पहुंच हो।

मैं अपनी कंपनी द्वारा उपयोग के लिए कुछ इस तरह स्थापित करना चाहता हूं, लेकिन मैं इस खतरनाक अभ्यास (विशेष रूप से प्रवर्धन हमलों के संबंध में ) के बारे में बहुत कुछ सुनता हूं और मैं यह सुनिश्चित करना चाहता हूं कि हम यह अधिकार करते हैं। इस प्रकार के वातावरण का निर्माण करते समय मुझे किन बातों का ध्यान रखना चाहिए?

Comments

नीचे वाले ने मुझे गदगद कर दिया।

— एंड्रयू बी

Answer 1

इसमें कुछ बातें समझने की जरूरत है:

---

यह एक नेटवर्क इंजीनियरिंग समस्या है।

इस प्रकार के वातावरण को स्थापित करने की चाह रखने वाले अधिकांश लोग सिस्टम प्रशासक हैं। यह अच्छा है, मैं एक सिस्टम प्रशासक भी हूँ! नौकरी का एक हिस्सा यह समझ रहा है कि आपकी ज़िम्मेदारियाँ कहाँ समाप्त होती हैं और किसी और की शुरुआत होती है, और मेरा विश्वास करो, यह कोई समस्या नहीं है जो सिस्टम प्रशासक अपने दम पर हल कर सकते हैं। यहाँ पर क्यों:

• यूडीपी एक स्टेटलेस प्रोटोकॉल है। कोई क्लाइंट हैंडशेक नहीं है।
• एक DNS सर्वर के खिलाफ क्वेरी एक गैर-सक्षम दो-चरण लेनदेन (क्वेरी, उत्तर) हैं। सर्वर के लिए यह जानने का कोई तरीका नहीं है कि उत्तर देने से पहले स्रोत आईपी खराब हो गया है या नहीं।
• जब तक कोई क्वेरी सर्वर तक पहुंचती है, तब तक एक खराब हो चुके यूडीपी पैकेट को रोकने में पहले ही बहुत देर हो चुकी होती है। स्पूफिंग को केवल एक अभ्यास द्वारा रोका जा सकता है जिसे इनग्रेस फ़िल्टरिंग के रूप में जाना जाता है , एक विषय जो बीसीपी 38 और बीसीपी 84 दस्तावेजों द्वारा कवर किया गया है । ये आपके DNS सर्वर के सामने बैठे नेटवर्किंग उपकरणों द्वारा कार्यान्वित किए जाते हैं।
• हम आपको इस बारे में कोई पूर्वाभास नहीं दे सकते कि कैसे अपने डेटासेंटर को अंत से अंत तक, या इन सर्वोत्तम प्रथाओं को कैसे लागू किया जाए। ये चीजें आपकी अपनी जरूरतों के लिए बहुत विशिष्ट हैं। क्यू एंड ए प्रारूप सिर्फ इसके लिए काम नहीं करता है, और यह साइट पेशेवर लोगों को काम पर रखने के लिए पेशेवर काम पर रखने के विकल्प के रूप में नहीं है।
• यह न समझें कि आपकी बिलियन डॉलर बहुत बड़ी-से-असफल कंपनी को सही ढंग से फ़िल्टर करने में लागू करती है।

यह एक सर्वोत्तम अभ्यास नहीं है। सबसे अच्छा अभ्यास यह नहीं करना है।

DNS रिज़ॉल्वर का सामना करने वाले इंटरनेट को स्थापित करना बहुत आसान है। ऐसा करने में शामिल जोखिमों को समझने की तुलना में किसी एक को स्थापित करने में बहुत कम शोध होता है। यह उन मामलों में से एक है जहां अच्छे इरादे अनजाने में दूसरों के कुकर्म (और पीड़ा) को सक्षम करते हैं।

• यदि आपका DNS सर्वर किसी भी स्रोत आईपी पते पर प्रतिक्रिया देगा, तो यह एक खुला रिज़ॉल्वर चला रहा है। निर्दोष पार्टियों के खिलाफ बढ़ रहे हमलों में इनका लगातार लाभ उठाया जा रहा है । नए सिस्टम प्रशासक हर दिन खुले रिसोल्वर खड़े कर रहे हैं , जिससे यह दुर्भावनापूर्ण व्यक्तियों के लिए लगातार स्कैन करने के लिए आकर्षक है। वहाँ वास्तव में एक सवाल नहीं है कि क्या आपकी खुली रिवाल्वर किसी हमले में इस्तेमाल होने जा रही है या नहीं: 2015 तक, यह बहुत ज्यादा दिया गया है। यह तत्काल नहीं हो सकता है, लेकिन यह निश्चित रूप से होने वाला है।
• यहां तक ​​कि अगर आप अपने DNS सॉफ़्टवेयर (यानी BIND) का उपयोग करके एक ACL लागू करते हैं, तो यह सब करता है जो आपके सर्वर को जवाब देगा DNS पैकेट को बिगाड़ता है। यह समझना महत्वपूर्ण है कि आपके DNS इन्फ्रास्ट्रक्चर का उपयोग न केवल एसीएल में उपकरणों पर हमला करने के लिए किया जा सकता है, बल्कि आपके DNS सर्वर और इसके लिए जवाब देने वाले उपकरणों के बीच किसी भी नेटवर्किंग डिवाइस। यदि आप डेटासेंटर के मालिक नहीं हैं, तो यह सिर्फ आपके लिए अधिक समस्या है।

Google और OpenDNS ऐसा करते हैं, तो मैं क्यों नहीं कर सकता?

कभी-कभी वास्तविकता के प्रति उत्साह को तौलना आवश्यक होता है। यहाँ अपने आप से पूछने के लिए कुछ कठिन प्रश्न हैं:

• क्या यह कुछ ऐसा है जिसे आप एक वैश्या पर स्थापित करना चाहते हैं, या क्या यह कुछ ऐसा है जिसके लिए कुछ मिलियन डॉलर आपके पास सही निवेश करने के लिए हैं?

• क्या आपके पास एक समर्पित सुरक्षा टीम है? समर्पित दल? क्या आपके नए बुनियादी ढांचे के दुरुपयोग और बाहरी दलों से मिलने वाली शिकायतों से निपटने के लिए दोनों के पास साइकिल है?

• क्या आपके पास एक कानूनी टीम है?

• जब यह सब कहा और किया जाता है, तो क्या यह सब प्रयास दूरस्थ रूप से भी स्वयं के लिए भुगतान करने लगेंगे, कंपनी के लिए लाभ कमाएंगे, या इस दिशा में आपको हुई असुविधा से निपटने के मौद्रिक मूल्य को पार करेंगे?

---

समापन में, मुझे पता है कि यह थ्रेड Q & A है, आप में से अधिकांश के लिए एक तरह की सुस्ती है, जो इससे जुड़े हुए हैं। सर्वरफॉल्ट यहां उत्तर प्रदान करने के लिए है, और "यह एक बुरा विचार है, ऐसा मत करो" का उत्तर आमतौर पर बहुत मददगार नहीं माना जाता है। कुछ समस्याएं बहुत अधिक जटिल हैं जितना वे शुरुआत में दिखाई देते हैं, और यह उनमें से एक है।

यदि आप इस कार्य को करने का प्रयास करना चाहते हैं, तब भी आप हमसे मदद मांग सकते हैं क्योंकि आप इस तरह के समाधान को लागू करने का प्रयास करते हैं। मुख्य बात यह है कि सुविधाजनक प्रश्नोत्तर प्रारूप में दिए गए उत्तर के लिए समस्या अपने आप में बहुत बड़ी है । आपको पहले से ही इस विषय पर शोध करने के लिए एक महत्वपूर्ण राशि का निवेश करने की आवश्यकता है, और हमें उन विशिष्ट तर्क समस्याओं के साथ संपर्क करें, जिन्हें आपने अपने कार्यान्वयन के दौरान सामना किया है। इस प्रश्नोत्तर का उद्देश्य आपको बड़ी तस्वीर की बेहतर समझ प्रदान करना है, और आपको यह समझने में मदद करना है कि हम इस प्रश्न का व्यापक रूप से उत्तर क्यों नहीं दे सकते हैं।

इंटरनेट को सुरक्षित रखने में हमारी मदद करें! :)

Comments

एक पूरक के रूप में, लोग देख सकते हैं कि उनके पास ओपनर्सोल्वर परियोजना के माध्यम से अपने सार्वजनिक रेंज पर खुले डीएनएस रिले नहीं हैं । सभी को ध्यान में रखना चाहिए कि इंटरनेट में लगभग 20 मिलियन खुले रिले होते हैं जो पुनरावर्ती प्रश्नों को स्वीकार करते हैं। परिणामों का एक उदाहरण: CloudFlare ने इनमें से 0.1% का उपयोग करके 300 Gb / s DNS प्रवर्धन हमले का सामना किया

— Xavier Lucas

क्या आप UDP को अक्षम नहीं कर सकते और इसके बजाय TCP का उपयोग करने के लिए सभी प्रश्नों को बाध्य कर सकते हैं?

— 小 小

@ @ 小इस प्रश्न का संदर्भ लें। एक रिज़ॉल्वर लाइब्रेरी UDP मोड में डिफ़ॉल्ट हो जाएगी और कई मामलों में TCP से पुनः प्रयास किया जाएगा यदि कोई उत्तर काट दिया गया था, लेकिन वह इसके बारे में है। यह काम करेगा यदि एप्लिकेशन ओएस को दरकिनार कर रहा है और अपनी स्वयं की खोज कर रहा है, लेकिन यह आमतौर पर इस उद्देश्य को पूरा करेगा कि लोग इस सेटअप के साथ क्या करने की कोशिश कर रहे हैं।

— एंड्रयू बी

Answer 2

चाहे आप एक ओपन डीएनएस रिकर्सर या एक आधिकारिक डीएनएस सर्वर चला रहे हों, समस्या समान है और अधिकांश संभावित समाधान भी समान हैं।

सबसे अच्छा समाधान

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

पुराने ग्राहकों के लिए वापसी

क्योंकि DNS कुकीज़ अभी तक मानकीकृत नहीं हैं, इसलिए निश्चित रूप से पुराने ग्राहकों को समर्थन देने और आने वाले वर्षों के लिए आवश्यक होगा।

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

दर सीमाओं का एक फायदा यह है कि अगर कोई हमलावर DNS अनुरोधों के साथ आपके DNS सर्वर को बाढ़ कर देता है, तो आपके पास क्षमता अधिक होने की संभावना है जो आपको सर्वर पर ssh और स्थिति की जांच करने की अनुमति देगा। इसके अतिरिक्त दर सीमा को मुख्य रूप से क्लाइंट आईपी से अनुरोध भेजने के लिए डिज़ाइन किया जा सकता है, जो कई अनुरोध भेज रहा है, जो आपको DoS के खिलाफ उन हमलावरों से बचाने के लिए पर्याप्त हो सकता है, जिनके पास ग्राहक IP को खराब करने की पहुंच नहीं है।

उन कारणों के लिए आपकी वास्तविक क्षमता के तहत दर की सीमा एक अच्छा विचार हो सकती है, भले ही यह वास्तव में प्रवर्धन के खिलाफ की रक्षा न करे।

टीसीपी का उपयोग करना

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

दो अतिरिक्त राउंडट्रीप की लागत इस दृष्टिकोण का उपयोग करके केवल पहले अनुरोध तक सीमित हो सकती है:

जब क्लाइंट आईपी की पुष्टि नहीं की गई है, तो DNS सर्वर क्लाइंट को टीसीपी में स्विच करने के लिए मजबूर करने के लिए एक छंटनी की प्रतिक्रिया भेज सकता है। छंटनी की गई प्रतिक्रिया अनुरोध के रूप में कम हो सकती है (या यदि ग्राहक EDNS0 का उपयोग करता है और प्रतिक्रिया नहीं करता है) जो प्रवर्धन को समाप्त करता है।

कोई भी क्लाइंट IP जो एक TCP हैंडशेक पूरा करता है और कनेक्शन पर DNS अनुरोध भेजता है, अस्थायी रूप से श्वेतसूची में हो सकता है। एक बार आईपीएल यूडीपी प्रश्नों को भेजने और 512 बाइट्स तक (यूडीएनएस का उपयोग करने पर 4096 बाइट्स) यूडीपी प्रतिक्रिया प्राप्त करने के लिए आईपी को श्वेत करता है। यदि एक UDP प्रतिक्रिया ICMP त्रुटि संदेश को ट्रिगर करती है, तो IP को फिर से श्वेतसूची से हटा दिया जाता है।

विधि को एक ब्लैकलिस्ट का उपयोग करके भी उलटा किया जा सकता है, जिसका अर्थ है कि क्लाइंट आईपी को डिफ़ॉल्ट रूप से यूडीपी पर क्वेरी करने की अनुमति है, लेकिन किसी भी आईसीएमपी त्रुटि संदेश के कारण आईपी को ब्लैकलिस्ट करने के लिए टीसीपी क्वेरी की आवश्यकता को ब्लैकलिस्ट किया जा सकता है।

सभी प्रासंगिक IPv4 पतों को कवर करने वाला बिटमैप 444MB मेमोरी में संग्रहीत किया जा सकता है। IPv6 पतों को किसी अन्य तरीके से संग्रहीत करना होगा।

मुझे नहीं पता कि किसी DNS सर्वर ने इस दृष्टिकोण को लागू किया है या नहीं।

यह भी बताया गया है कि प्रवर्धन हमलों में कुछ टीसीपी स्टैक्स का फायदा उठाया जा सकता है। हालांकि यह किसी भी टीसीपी आधारित सेवा पर लागू होता है, न कि केवल डीएनएस पर। इस तरह की कमजोरियों को एक कर्नेल संस्करण में अपग्रेड करके कम किया जाना चाहिए जहां एक स्टैक को SYN पैकेट के जवाब में एक से अधिक पैकेट नहीं भेजने के लिए तय किया गया है।

Comments

निष्पक्ष होने के लिए, मेरा जवाब उस बॉक्स तकनीक से है, जो अब हमारे हाथ में है। सर्वरफॉल्ट पर यह सवाल पूछने वाले अधिकांश लोग अपने नाम के सॉफ्टवेयर को विकसित करने या मौजूदा नाम बदलने वाले सॉफ्टवेयर के लिए पैच लिखने की तलाश नहीं कर रहे हैं। अलनीतक ने हमें सलाह दी है कि आपके द्वारा सुझाए जा रहे टीसीपी + व्हाइटटेलिंग दृष्टिकोण का पेटेंट कराया गया है , हालांकि उन्होंने सटीक पेटेंट का हवाला नहीं दिया है।

— एंड्रयू बी

इसके अलावा, क्या आप RRL को लागू करने वाले किसी भी मौजूदा डीएनएस सर्वर सॉफ़्टवेयर का उपयोग करने में उल्लिखित DoS हमले का उत्पादन करने में सक्षम हैं, या एक ऐसे मामले के बारे में जानते हैं जहां किसी और ने इसे हासिल किया है? मुझे पूरा यकीन है कि मैं जिस भी मेलिंग लिस्ट को सब्सक्राइब करता हूं, उस नंबर पर आया होगा।

— एंड्रयू बी

@AndrewB मैंने अभी तक परीक्षण नहीं किया है क्योंकि मैं किसी और के सर्वर पर बाढ़ का कारण नहीं बनना चाहूंगा। और कुछ लोगों ने रेट लिमिट का उल्लेख करते हुए एक दृष्टिकोण रखा है जो मुझे लगता है कि वे परिणामों पर भरोसा नहीं करेंगे अगर मैंने इसे अपने सर्वर पर किया। लेकिन जब से आप पूछ रहे हैं कि मैं इसे एक कोशिश देने जा रहा हूं, तो मुझे इसे परीक्षण के लिए एक अलग DNS सर्वर स्थापित करने की आवश्यकता है। क्या उबंटू LTS 14.04 पर डिफॉल्ट बिंद संस्करण का उपयोग एक समझदार सेटअप की तरह है? आधिकारिक सर्वर पर कौन सी सटीक सेटिंग्स आप इस तरह के परीक्षण के लिए उचित समझेंगे?

— 13

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

— एंड्रयू बी

@AndrewB मुझे यहाँ एक छोटी सी विसंगति का एहसास हुआ। यह प्रश्न पुनरावर्ती रिसोल्वर के बारे में है। लेकिन पुनरावर्ती रिज़ॉल्वर के लिए दर सीमित नहीं की गई है। Deliberately open recursive DNS servers are outside the scope of this document.अभी के लिए मैंने इसके बारे में एक चेतावनी जोड़ी है। मुझे परीक्षण करना चाहिए कि क्या यह भी संभव है कि पुनरावर्ती रिज़ॉल्वर के रूप में कॉन्फ़िगर किए गए बिंद पर दर सीमित करने में सक्षम हो, और अगर यह ठीक से व्यवहार करेगा।

— कास्परड