एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 12: नेटवर्क सुरक्षा, भाग 3

मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 6.858। "कंप्यूटर सिस्टम की सुरक्षा।" निकोलाई ज़ेल्डोविच, जेम्स मिकेंस। 2014 साल

कंप्यूटर सिस्टम सुरक्षा सुरक्षित कंप्यूटर सिस्टम के विकास और कार्यान्वयन पर एक कोर्स है। व्याख्यान खतरे के मॉडल को कवर करते हैं, हमले जो सुरक्षा से समझौता करते हैं, और हाल के वैज्ञानिक कार्यों के आधार पर सुरक्षा तकनीक। विषय में ऑपरेटिंग सिस्टम (OS) सुरक्षा, सुविधाएँ, सूचना प्रवाह प्रबंधन, भाषा सुरक्षा, नेटवर्क प्रोटोकॉल, हार्डवेयर सुरक्षा और वेब अनुप्रयोग सुरक्षा शामिल हैं।

व्याख्यान 1: "परिचय: खतरे के मॉडल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 2: "हैकर हमलों का नियंत्रण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 3: "बफर ओवरफ्लो: शोषण और संरक्षण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 4: "पृथक्करण का पृथक्करण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 5: "सुरक्षा प्रणालियाँ कहाँ से आती हैं?" भाग 1 / भाग 2
व्याख्यान 6: "अवसर" भाग 1 / भाग 2 / भाग 3
व्याख्यान 7: "मूल ग्राहक सैंडबॉक्स" भाग 1 / भाग 2 / भाग 3
व्याख्यान 8: "नेटवर्क सुरक्षा मॉडल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 9: "वेब अनुप्रयोग सुरक्षा" भाग 1 / भाग 2 / भाग 3
व्याख्यान 10: "प्रतीकात्मक निष्पादन" भाग 1 / भाग 2 / भाग 3
व्याख्यान 11: "उर / वेब प्रोग्रामिंग भाषा" भाग 1 / भाग 2 / भाग 3
व्याख्यान 12: नेटवर्क सुरक्षा भाग 1 / भाग 2 / भाग 3

छात्र: क्या गैर-मौजूद शीर्ष-स्तरीय डोमेन के लिए किसी प्रकार के हस्ताक्षर हैं?

प्रोफेसर: मुझे लगता है कि वहाँ है। एक बिंदु डोमेन सिर्फ एक और डोमेन है, और यह एक ही तंत्र को लागू करता है। इसलिए "डॉट" और "डॉट.कॉम" डोमेन आजकल DNS एसईसी का उपयोग करते हैं, और ये सभी रिकॉर्ड हैं जो कहते हैं, उदाहरण के लिए, यह .in डोमेन नाम है जो मौजूद है, और "डॉट" नाम भी मौजूद है। और उनके बीच ज्यादा कुछ नहीं है। तो शीर्ष स्तर के डोमेन में ये सभी चीजें मौजूद हैं।



छात्र: DoS के हमलों के खतरे के अलावा, हम mit.edu के भीतर डोमेन नामों की पुनरावृत्ति के बारे में इतना ध्यान क्यों रखते हैं?

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

मुझे लगता है कि यह एक और जगह है जहां इस प्रणाली के पास स्पष्ट विनिर्देश नहीं हैं जो इसे प्रदान करना चाहिए या प्रदान नहीं करना चाहिए।

छात्र: क्या किसी हस्ताक्षर की वैधता अवधि को किसी तरह से उजागर करना संभव है?

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

इसलिए, हम मान सकते हैं कि हमने टीसीपी SYN अनुक्रम संख्या का अनुमान लगाकर हमलों पर चर्चा की। टीसीपी के बारे में एक और दिलचस्प मुद्दा DDoS हमला है, जो इस तथ्य का फायदा उठाता है कि सर्वर कुछ राज्य में है। यदि आप इस हैंडशेक को देखते हैं, जो पहले बोर्ड पर खींचा गया था, तो आप देखेंगे कि जब क्लाइंट सर्वर से कनेक्शन स्थापित करता है, तो सर्वर को एसएनसी क्लाइंट का सीरियल नंबर याद रखना चाहिए। इस प्रकार, सर्वर को एक अलग ब्लॉक में कुछ डेटा संरचना का समर्थन करना चाहिए, जो दर्शाता है कि इस कनेक्शन के लिए इस अनुक्रम संख्या का उपयोग किया जाता है।



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

समस्या यह है कि इस तालिका की कोई वास्तविक सीमा नहीं है। इस तरह, आप किसी मशीन से पैकेट प्राप्त कर सकते हैं बिना यह जाने कि उन्हें कौन भेज रहा है। आपको बस एक पैकेट मिलता है जो C-> S जैसे स्रोत पते के साथ दिखता है जो कि सी होने का दावा करता है। संभवतः इस आईपी पते से इस कनेक्शन को स्वीकार करने के लिए, आपको तालिका में एक प्रविष्टि बनानी होगी। इसके अलावा, ये रिकॉर्ड लंबे समय तक मौजूद हैं, क्योंकि, शायद, कोई आपके साथ बहुत दूर से संबंध स्थापित करता है और एक ही समय में कई पैकेट खो जाते हैं। सबसे खराब स्थिति में, उदाहरण के लिए, किसी को इस टीसीपी हैंडशेक को पूरा करने में एक मिनट लग सकता है। तो आपको अपेक्षाकृत लंबे समय के लिए टीसीपी स्टैक पर इस स्थिति को रखना होगा, और यह अनुमान लगाने का कोई तरीका नहीं है कि यह मान्य होगा या नहीं।

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

समस्या यह है कि, सबसे अच्छा, एक हमलावर केवल एक ही स्रोत आईपी पते का उपयोग करता है। इस मामले में, आप बस यह कह सकते हैं कि प्रत्येक ग्राहक को केवल दो प्रविष्टियों की अनुमति है, या ऐसा कुछ। और फिर हमलावर तालिका में अधिकतम 2 दो प्रविष्टियों का उपयोग कर सकता है।

बेशक, समस्या यह है कि एक हमलावर ग्राहकों के आईपी पते को नकली कर सकता है और उन्हें यादृच्छिक बना सकता है। फिर सर्वर के लिए यह भेद करना बहुत मुश्किल होगा कि कौन इसके साथ संबंध स्थापित करने की कोशिश कर रहा है - एक हमलावर या कुछ क्लाइंट जिसे सर्वर ने पहले कभी नहीं सुना है।

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

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



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

समस्या यह है कि आप राज्य के संरक्षण की गारंटी देते हैं इससे पहले कि आप जानते हैं कि आपसे कौन जुड़ रहा है। आइए देखें कि हम SYN फ्लडिंग बाढ़ हमले का मुकाबला कैसे कर सकते हैं, जो यह है कि सर्वर बहुत अधिक स्थिति जमा कर रहा है।

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

यह, फिर से यह पता लगाने की कोशिश में एक अभ्यास है कि हम कौन सी चालें प्रदर्शन कर सकते हैं, या बल्कि, क्या धारणाएं कि हम अकेले छोड़ सकते हैं और अभी भी मौजूदा टीसीपी हेडर प्रारूप का पालन कर सकते हैं जब उनके साथ काम कर रहे हैं।

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

यदि सर्वर यह पता लगाता है कि यह इस तरह के हमले से गुजर रहा है, तो यह एक मोड में प्रवेश करता है जहां यह उसी फ़ंक्शन F के साथ एक सूत्र का उपयोग करके एसएन का चयन करता है जैसा कि हमने पहले माना था।



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

तो यह एक अच्छी योजना क्यों है? यहाँ क्या हो रहा है? इस अजीब सूत्र की आवश्यकता क्यों है? आपको याद रखना चाहिए कि हमने सीरियल नंबर से क्या पाने की कोशिश की। दो चीजें यहां होती हैं।

पहला नकली पैकेट के खिलाफ सुरक्षा है। इस पुराने शैली के सीरियल नंबर के साथ बोर्ड पर एक सर्किट बना रहा, जिसमें हम पिछले कनेक्शनों से पैकेज के दोहराव को रोकने के लिए एक फ़ंक्शन जोड़ते हैं।



यह पता चला है कि लोग इस कार्रवाई योजना का उपयोग करने के अलावा, SYN फ्लडिंग जैसे हमलों से खुद को बचाने के लिए एक बेहतर तरीका नहीं खोज सके, जो कुछ स्थितियों में अच्छी तरह से काम करता है। यह एक योजना थी, लेकिन एक अन्य योजना एक समय-मुद्रांकित फ़ंक्शन थी जहां हमने पुरानी शैली के इस घटक को छोड़ दिया। इसके बजाय, हम यह सुनिश्चित करने पर ध्यान केंद्रित करेंगे कि यदि कोई हमें पैकेज के जवाब में यह ACK अनुक्रम संख्या (SNs) प्रदान करता है, तो वह व्यक्ति "सही" ग्राहक होगा।

आपको याद है कि आईपी स्पूफिंग हमलों को रोकने के लिए, हम इस मूल्य (एसएन) पर भरोसा करते हैं। वास्तव में, यदि सर्वर दूसरे चरण में क्लाइंट को यह एसएन मान भेजता है, तो हम उम्मीद करते हैं कि केवल यह क्लाइंट कनेक्शन को पूरा करने के लिए हमें तीसरे चरण में सही एसएन मान भेजने में सक्षम होगा।

यही कारण है कि आपको इस सीरियल नंबर को एक तालिका में संग्रहीत करना था, क्योंकि अन्यथा, आपको यह कैसे पता चलेगा कि यह वास्तविक उत्तर है या नकली है? इस एफ फ़ंक्शन का उपयोग करने का कारण यह है कि अब हम इस तालिका को स्मृति में नहीं बचा सकते हैं।

इसके बजाय, जब कनेक्शन का प्रयास दिखाया गया है, जो पहले चरण में दिखाया गया है, दूसरे चरण में हम इस सूत्र का उपयोग करके एसएन की गणना करते हैं और बस इसे उस क्लाइंट को वापस भेजते हैं जो हमसे संपर्क करना चाहता है, और फिर इस कनेक्शन के बारे में भूल जाएं।



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

छात्र: एसएनसी केवल एक सीमित समय तक ही रहता है?

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



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

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

स्टूडेंट: क्या मुझे टाइमस्टैम्प रखने की जरूरत है?

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

छात्र: मेरा मानना ​​है कि आप इसका उपयोग तब करते हैं जब आप पर हमला किया जाता है, केवल इसलिए कि आप सुरक्षा के 8 बिट खो देते हैं, या किसी अन्य कारण से?

प्रोफेसर: हाँ, यह बहुत अच्छा नहीं है, इसमें कई बुरे गुण हैं। एक तरह से, हम वास्तव में सुरक्षा के 8 बिट्स खो रहे हैं। क्योंकि अब निर्विवाद हिस्सा 32 के बजाय केवल 24 बिट्स है।

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

"हाय, यह एक एसएमटीपी सर्वर है, कृपया मुझे अपना ईमेल भेजें!"

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

छात्र: यदि आप एक के बाद एक मेजबान से दो बहुत अल्पकालिक कनेक्शन स्थापित करते हैं, तो आपको डेटा हानि भी हो सकती है।

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

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

छात्र: क्या दूसरे और तीसरे चरण में एसएन समान होना चाहिए?

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



स्टूडेंट: लेकिन टाइमस्टैम्प अलग होगी, है ना? अगर यह राज्य को स्टोर नहीं करता है तो सर्वर एक नए टाइमस्टैम्प का उपयोग करके इसे कैसे पुनः प्राप्त कर सकता है?

प्रोफेसर: जैसा कि मैंने कहा, ये टाइमस्टैम्प काफी “मोटे-मोटे” होते हैं और मिनटों में वर्गीकृत हो जाते हैं। यदि आप एक ही मिनट में कनेक्ट करते हैं, तो सब कुछ क्रम में है, यदि आप मिनट की सीमा पर जुड़ते हैं - यह बहुत बुरा है।

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

छात्र: यदि कोई हमलावर बड़ी संख्या में IP पतों को नियंत्रित करता है और आपके द्वारा स्विच किए जाने पर भी आपने क्या कहा है, तो ...

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

और फिर सर्वर के लिए यह निर्धारित करना बहुत मुश्किल होगा कि क्या वैध ग्राहकों से अनुरोध प्राप्त होते हैं या यह सिर्फ एक हमलावर है जो सर्वर के संसाधनों को बांधता है। तो आप बिलकुल सही हैं। यह योजना केवल तभी काम करती है जब हमलावर के पास कम संख्या में आईपी पते हों और वह एक प्रभाव प्राप्त करना चाहता हो।

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

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



आपने mit.edu सर्वर के बारे में पूछा। , , mit.edu — , mit.edu, , DNS SEC, .

100 , — 1000 . , «» - . , DNS- . 100 - DNS-, , , 1000 .

, . , TCP SYN Flooding, DNS- , . , , « ».

DNS. . , DNS-. , . .

: DNS- …

: , DNS- , - .

: , ?

: , DNS-, . DNS-, . 10 DNS-, , , , , . . , , DNS-, .

, DNS , , , . , .

, , , – , , , . , , . .

DNS- , . , , .

, : «, , »! , , DNS- .

, . - -, . DoS , . , , , , .



, , . , , , .

, , . .

, DHCP, . , , IP-. , , MIT DHCP, , , , IP-, , DNS-, , .

, DHCP DHCP-, , DHCP-. , , . , DHCP IP-, : «, DNS- »! DNS .

, . , BGP, IP-, . , , BGP, : «, IP-!», : „, , “.



, , , IP- . IP- , , IP- . IP- , . , . , , , IP-. , , .

DNS SEC. , , DNS, , . , , , , DNS SEC.

, , , . : , , , , , DoS — . .

इसलिए, आपको ऐसी चीजों से बचने का प्रयास करना चाहिए जैसे कि SYN बाढ़ के हमले और RST हमले जो आपको एक मनमाना नेटवर्क उपयोगकर्ता को डिस्कनेक्ट करने की अनुमति देते हैं। ये ऐसी चीजें हैं जो वास्तव में निम्न स्तर पर हानिकारक हैं और जिन्हें उच्च स्तर पर ठीक करना मुश्किल है। लेकिन कम या ज्यादा एन्क्रिप्शन का उपयोग करके डेटा की अखंडता और गोपनीयता सुनिश्चित करते हैं। हम इस बारे में बात करेंगे कि सेरेबस पर अगले व्याख्यान में यह कैसे किया जाए।


पाठ्यक्रम का पूरा संस्करण यहां उपलब्ध है ।

हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक आदेश रखकर या अपने दोस्तों को इसकी अनुशंसा करके हमें समर्थन दें, एंट्री-लेवल सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 30% छूट जो हमने आपके लिए ईजाद की है: VPS (KVM) E5-2650 v4 (6 कोर) 10GB DDR4 240GB SSD 1Gbps से पूरा सच $ 20 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

VPS (KVM) E5-2650 v4 (6 करोड़) 10GB DDR4 240GB SSD 1Gbps दिसंबर तक मुफ्त में जब छह महीने की अवधि के लिए भुगतान करते हैं, तो आप यहां ऑर्डर कर सकते हैं ।

डेल R730xd 2 बार सस्ता? केवल हमारे पास 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps नीदरलैंड और यूएसए में $ 249 से 100 टीवी है ! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?