परिचय
इस लेख में मैं एक बिल्कुल स्पष्ट बात करना चाहता हूं, यह मुझे लगता है, डीएनएस प्रवर्धन हमले को छानने की विधि, और एक छोटे मॉड्यूल के बारे में जो विचार को लागू करने के लिए लिखा गया था।
तथ्य यह है कि इस तरह के डीएनएस प्रवर्धन हमले को एक से अधिक बार लिखा गया है, उदाहरण के लिए
यहां ; कई ने इसका सामना किया, कई ने संघर्ष किया, कुछ और सफलतापूर्वक, कुछ कम। हमला DNS सर्वर पर DNS क्वेरी भेजने के आधार पर पीड़ित के आईपी पते के स्रोत आईपी पते के साथ होता है। DNS सर्वर से प्रतिक्रिया लगभग हमेशा अनुरोध से बड़ी होती है, खासकर यह देखते हुए कि हमलावर आमतौर पर किसी भी अनुरोध को निष्पादित करते हैं। AAAA रिकॉर्डिंग अब असामान्य नहीं है, SPF और TXT रिकॉर्डिंग में अन्य जानकारी, यह सब 5 या अधिक बार प्रवर्धन प्राप्त करने के लिए काफी आसान बनाता है। एक हमलावर के लिए, यह बहुत लुभावना लग रहा है, आप एक अच्छे डोस की व्यवस्था कर सकते हैं, यहां तक कि एक बड़े बोटनेट के बिना भी। आप लंबे समय तक तर्क दे सकते हैं कि इंटरनेट पर आईपी एड्रेस स्पूफिंग क्यों संभव है, लेकिन वास्तविकता यह है कि यह अभी भी संभव है, इसलिए आज ऐसे हमलों को अंजाम देने में अपने स्वयं के डीएनएस सर्वर का उपयोग करना मुश्किल काम है। मैं यह भी ध्यान देता हूं कि इस हमले में आधिकारिक डीएनएस सर्वर और सार्वजनिक रिसोल्वर दोनों का उपयोग करना संभव है; प्रस्तावित समाधान का उपयोग दोनों मामलों में भी किया जा सकता है।
Dns सर्वर पर लागू संघर्ष के मुख्य तरीके:
अवांछित को ब्लॉक करें।
सिद्धांत रूप में, यहां कुछ भी मुश्किल नहीं है, कई फायरवॉल प्रति सेकंड गुजरने वाले पैकेट की संख्या से अधिक होने पर यातायात को अवरुद्ध करने की क्षमता रखते हैं। आप किसी भी नियम से ब्लॉक कर सकते हैं, उदाहरण के लिए उपरोक्त लेख में किया गया था। यदि आप डीएनएस सर्वर पर फ़ायरवॉल का उपयोग नहीं करना चाहते हैं, तो आप एक निश्चित अवधि में एक बार tcpdump चला सकते हैं, इसके आउटपुट को पार्स कर सकते हैं और रूट ट्रैफ़िक को रूट / dev / null कर सकते हैं। चरम मामलों में, आप हमलावर के आईपी को लूपबैक इंटरफ़ेस में जोड़ सकते हैं (इस तकनीक को एक कॉन्फ्रेंस में I. Sysoev द्वारा अनुशंसित किया गया था, फ्रीबीएसडी पर फ़ायरवॉल के बिना करने का एक तरीका)। आप स्विच पर ट्रैफ़िक मिररिंग कॉन्फ़िगर कर सकते हैं, इसे कहीं अलग से विश्लेषण कर सकते हैं, और फिर परिणाम राउटर को इसे ब्लॉक करने के लिए भेज सकते हैं। कई विकल्प हैं, शून्य से एक - हम यातायात में से कुछ खो रहे हैं। यह मत भूलो कि हम प्रतिस्थापित आईपी को अवरुद्ध कर रहे हैं, और डीएनएस सर्वर प्रदाताओं से लेकर आपके अपने संगठन के सर्वरों तक कुछ भी हो सकता है।आइए टीसीपी के लिए पूछें।
पैकेट हेडर DNS में एक टीसी फ्लैग फील्ड होता है। यदि टीसी ध्वज सेट किया गया है, तो क्लाइंट को टीसीपी का उपयोग करके अनुरोध को फिर से प्रयास करना चाहिए, और अन्य सभी प्रतिक्रिया डेटा को अनदेखा किया गया है। इस पद्धति का विचार यह है कि हमलावर टीसीपी पर स्विच नहीं करेगा, इसका उसे कोई मतलब नहीं है, जबकि एक ईमानदार ग्राहक स्विच करेगा और टीसीपी के माध्यम से प्रतिक्रिया प्राप्त करेगा। बेशक, DNS के लिए टीसीपी धीमा है, लेकिन, सबसे पहले, उत्तर को पुनरावर्ती या क्लाइंट के कैश में बसना चाहिए, और दूसरी बात, इस मामले में कुछ विलंबता कम बुराई है। यह दृष्टिकोण पहले से ही कुछ डीएनएस सर्वरों में लागू किया गया है: उदाहरण के लिए, पावरडानों में आप किसी भी अनुरोध का जवाब देने के लिए टीसी ध्वज सेट कर सकते हैं, जो एक अच्छा समझौता है। लेकिन यह विकल्प भी आदर्श नहीं है। तथ्य यह है कि बड़े इंटरनेट पर अभी भी सर्वर हैं जो आरएफसी का काफी अनुसरण नहीं कर रहे हैं या केवल गलत तरीके से बनाए गए हैं, और बस सभी उत्तरों के लिए टीसी सेट करना यह गारंटी नहीं देता है कि हर कोई टीसीपी पर जवाब को सही ढंग से फिर से लिख देगा। इसके अलावा, यह मत भूलिए कि टीसी फ्लैग सेट करके, हम, निश्चित रूप से, आउटगोइंग ट्रैफ़िक की मात्रा को कम कर देंगे और इसलिए नेटवर्क उपकरण पर लोड होगा, लेकिन यहां सर्वर स्वयं अभी भी अनुरोधों की इस विशाल आवक प्रक्रिया को संसाधित करेंगे, कीमती संदर्भ स्विच और वार्मिंग डेटा सेंटर खर्च करेंगे। ।
दरअसल, कुछ नया करने का आइडिया आया। हालांकि, एक नियम के रूप में, डॉस के खिलाफ सुरक्षा के कोई आदर्श साधन नहीं हैं, और प्रस्तावित विकल्प भी कमियों के बिना नहीं है: उदाहरण के लिए, यह प्रवर्धन के बिना डीएनएस ट्रैफ़िक को प्रतिबिंबित करने के लिए सर्वर का उपयोग करने से रक्षा नहीं करता है। हालांकि, प्रस्तावित समाधान के लाभ इस प्रकार हैं:
- हम किसी को ब्लॉक नहीं करते हैं, जब सीमा पार हो जाती है, हम बस कुछ निश्चित आईपी पते के लिए टीसीपी के उपयोग को मजबूर करते हैं, अर्थात, टीसी ध्वज को सेट करें और एक काटे गए डीएनएस प्रतिक्रिया के साथ जवाब दें।
- मजबूरन टीसीपी का उपयोग कर्नेल में किया जाता है।
मैं उपयोग के संदर्भ में भी संभव के रूप में समाधान को सरल बनाना चाहता था, बिना iptables का उपयोग करने की आवश्यकता के बिना, किसी भी अतिरिक्त नियमों को कॉन्फ़िगर करना आदि मॉड्यूल लिनक्स-विशिष्ट है, लेकिन मुझे लगता है कि कुछ भी मौलिक रूप से विचार को FreeBSD पर लागू होने से रोकता है।
यह कैसे काम करता है?
हम एक निश्चित समय अवधि में प्रत्येक आईपी पते से प्राप्त पैकेटों की संख्या पर विचार करते हैं। यदि एक निश्चित आईपी से प्राप्त पैकेटों की संख्या सीमा से अधिक है, तो हम टीसी ध्वज के साथ एक यूडीपी प्रतिक्रिया बनाते हैं और अनुरोध को छोड़ देते हैं। इस प्रकार, हम DNS सर्वर एप्लिकेशन द्वारा इस ट्रैफ़िक को संसाधित करने की आवश्यकता के कारण संदर्भ स्विच की संख्या को तेज़ी से कम करते हैं। एक वैध क्लाइंट, जिसे tc फ्लैग के साथ udp रिस्पॉन्स मिला है, को TCP पर अनुरोध दोहराने के लिए मजबूर किया जाएगा, और यह ट्रैफ़िक पहले से ही dns सर्वर तक पहुंच जाएगा।
प्रभावी कार्यान्वयन के लिए, यह तथ्य कि डीएनएस अनुरोध और प्रतिक्रिया के लिए हेडर प्रारूप एक ही है, इससे हमें बहुत मदद मिलेगी, इसके अलावा, हेडर पैकेज का एकमात्र आवश्यक हिस्सा है ताकि डीएनएस प्रतिक्रिया को सही माना जाए। आइए dns हेडर को और अधिक विस्तार से देखें:
एक और अच्छी खबर: डीएनएस हेडर में 12 बाइट्स का एक निश्चित आकार होता है। यह एक बहुत ही सरल योजना है, हमें डीएनएस हेडर को पूरी तरह से पार्स करने की भी आवश्यकता नहीं है। हम जाँचते हैं कि 53 UDP पोर्ट पर पहुंचने वाले पैकेट में 12 बाइट्स से बड़ा डेटा होता है, पहले 12 बाइट्स डेटा की प्रतिलिपि बनाएँ (लिखते समय, यह विचार प्रकट हुआ कि शायद हमें अतिरिक्त हेडर फ़ील्ड की जाँच करनी चाहिए) नए पैकेट में अनुरोध से, टीसी बिट सेट करें। और एक प्रतिक्रिया बिट, और इसे वापस भेजें। चूंकि हमने केवल हेडर की प्रतिलिपि बनाई है, इसलिए QDCOUNT फ़ील्ड को रीसेट करना भी उचित है, अन्यथा हम क्लाइंट पक्ष पर पार्सर चेतावनी प्राप्त करेंगे। अनुरोध स्वयं हटा दिया जाता है। यह सारा काम सीधे NF_INET_LOCAL_IN हुक में किया जा सकता है, उसी हुक में हमें आगे के आँकड़ों की गणना के लिए KFIFO कतार में स्रोत आईपी लगाना होगा। हम आने वाले पैकेटों के आंकड़ों पर अतुल्यकालिक रूप से, एक अलग स्ट्रीम में, लाल-काले पेड़ों का उपयोग करके विचार करेंगे। इस प्रकार, हम पैकेट के पारित होने में न्यूनतम देरी का परिचय देते हैं - KFIFO एक लॉक फ्री डेटा संरचना है, इसके अलावा, प्रत्येक सीपीयू के लिए एक कतार बनाई जाती है। सच है, अपेक्षित pps के आधार पर अंतराल को कॉन्फ़िगर करने की आवश्यकता है। प्रति सीपीयू डेटा के लिए आवंटित मेमोरी के आकार पर अभी भी प्रतिबंध है: अब यह 32kB है, प्रत्येक सीपीयू के लिए 4096 आईपी पते की कतार को ध्यान में रखते हुए। इस प्रकार, 100ms के अंतराल को चुनते हुए, हम प्रत्येक सीपीयू के लिए 40960 pps तक की गणना करने में सक्षम होंगे, जो कि ज्यादातर मामलों में पर्याप्त लगता है। दूसरी ओर, कतार को ओवरफ्लो करने से आंकड़ों के लिए कुछ डेटा की हानि होगी।
एक तार्किक सवाल उठता है: सिर्फ हैश का उपयोग क्यों नहीं?
दुर्भाग्य से, ऐसी जगहों पर हैश के गलत उपयोग से किसी अन्य प्रकार के हमले की संभावना खुल जाती है - टकराव पैदा करने के उद्देश्य से किए गए हमले: यह जानते हुए कि निष्पादन के समय क्रिटिकल के कुछ टुकड़ों में एक हैश का उपयोग किया जाता है, इस तरह के डेटा को चुनना संभव है कि हैश पर उनके साथ ऑपरेशन तालिका पहले से ही O (n) के बजाय O (n) से परे होगी। इस तरह के हमले भी अप्रिय हैं कि उन्हें पहचानना मुश्किल हो सकता है - जाहिरा तौर पर कुछ भी नहीं हुआ, और सर्वर बीमार हो गया।
यदि अवरुद्ध आईपी से pps थ्रेशोल्ड मान से कम है, तो ब्लॉक हटा दिया जाता है। डिफ़ॉल्ट रूप से थ्रेसहोल्ड मान के 10% के बराबर एक हिस्टैरिसीस को कॉन्फ़िगर करना संभव है।
लेख के अंत में परियोजना की एक कड़ी है; किसी भी रचनात्मक टिप्पणी, सुझाव और परिवर्धन का स्वागत है।
उदाहरण का उपयोग करें
इकट्ठे मॉड्यूल के साथ निर्देशिका में, निष्पादित करें
insmod ./kfdns.ko threshold=100 period=100 hysteresis=10दहलीज - दहलीज जिस पर हम tc झंडा सेट करेंगे;
अवधि - गणना की अवधि, एमएस (यानी, इस मामले में, फिल्टर काम करेगा यदि एक आईपी से 100 से अधिक पैकेट 100ms में प्राप्त हुए थे);
हिस्टैरिसीस - प्रतिक्रिया थ्रेशोल्ड और फिल्टर रिलीज थ्रेशोल्ड के बीच का अंतर। संकेत: यदि आप हिस्टैरिसीस = थ्रेशोल्ड सेट करते हैं, तो लॉक चालू होने के बाद, इसे कभी भी जारी नहीं किया जाएगा, कुछ मामलों में यह उपयोगी हो सकता है।
में मॉड्यूल लोड करने के बाद
cat /proc/net/kfdnsआप आईपी पर आंकड़े पा सकते हैं जो फ़िल्टरिंग के तहत गिर गए।
परीक्षण के परिणाम
एक परजीवी लोड बनाने के लिए, dnsperf का उपयोग किया गया था (दो प्रतियों में, एक पड़ोसी वर्चुअल मशीन पर, दूसरा लैपटॉप पर, और दुर्भाग्य से यह सिस्टम को विफल करने के लिए पर्याप्त नहीं था), dns सर्वर को केवीएम वर्चुअल मशीन में CentOS चलाने के रूप में उठाया गया था, dns सर्वर स्वयं pdns-recursor द्वारा उपयोग किया गया था।
रेखांकन सक्रियण के बाद, सक्रियण के बाद, और फिर से लोड किए गए मॉड्यूल के साथ काउंटर मान दिखाता है। पूरे प्रयोग के दौरान पीपीएस 80kpps के स्तर पर था।
इसलिए, हमने जो हासिल किया वह आउटगोइंग ट्रैफिक में कमी थी। यह देखा जा सकता है कि मॉड्यूल चालू करने के बाद आउटगोइंग ट्रैफिक आने वाले से कम हो गया,
जो सिद्धांत रूप में तर्कसंगत है: यह मत भूलो कि हम केवल शीर्षक की नकल करते हैं।
संदर्भ स्विच की संख्या में तेज कमी अच्छी है।
और यहां सिस्टम के साथ क्या हुआ है: सिस्टम समय की खपत में ध्यान देने योग्य कमी, उपयोगकर्ता समय दिखाई देता है। इस मामले में चोरी के समय में बदलाव, वर्चुअलाइजेशन का प्रभाव है, जो तार्किक भी है। लेकिन irq समय में एक मुश्किल से ध्यान देने योग्य वृद्धि दिलचस्प है और आगे के प्रयोगों का कारण हो सकता है।
आप भविष्य में क्या जोड़ना चाहते हैं?
- PREROUTING हुक (या फ़ॉरवर्डिंग से, लेकिन आपको जांचने की आवश्यकता है) से काम करें। यह न केवल डीएनएस सर्वर पर मॉड्यूल का उपयोग करने की अनुमति देगा, बल्कि उदाहरण के लिए, बैलेंसरों, या सीमा फायरवॉल पर भी।
- मुख्य वितरण के लिए पैकेज तैयार करना।
- प्रलेखन, सर्वोत्तम अभ्यास
परियोजना ही:
github.com/dcherednik/kfdns4linuxहालांकि यह परियोजना काफी युवा अवस्था में है, लेकिन मुझे उम्मीद है कि खब्रासोसिटी में रुचि रखने वाले लोग हैं, और शायद यह किसी के लिए उपयोगी होगा।
संदर्भ और साहित्य:
लिनक्स नेटफिल्टर हैकिंग HOWTOनेटफिल्टर मॉड्यूल लिखनाताला लगाने के लिए अविश्वसनीय गाइडआईएसबीएन 978-5-8459-1779-9 रॉबर्ट लव, द लिनक्स कर्नेल: डेवलपमेंट प्रोसेस का विवरण