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

मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 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

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

आप में से बहुत से लोग पूछते हैं कि हम इसका अध्ययन क्यों करते हैं यदि टीसीपी प्रोटोकॉल के आज के संस्करणों में वर्णित कई समस्याओं का समाधान किया गया था।



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

और यह वास्तव में स्पष्ट नहीं है। आपको क्या लगता है? इन सभी विचारों को देखते हुए टीसीपी प्रोटोकॉल के पास आवश्यक सुरक्षा क्यों नहीं थी? कोई सुझाव?

छात्र: उस समय, इंटरनेट बहुत अधिक भयावह स्थान था।

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

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

इसलिए, मुझे लगता है कि यह कहानी उन कई प्रोटोकॉलों के लिए समान है, जिन पर हम विचार कर रहे हैं। और आप में से बहुत से लोग एक सवाल पूछ रहे हैं, "ये लोग क्या सोच रहे थे?" यह बहुत त्रुटिपूर्ण है! ” लेकिन वास्तव में, उन्होंने एक पूरी तरह से अलग प्रणाली तैयार की, उन्होंने बस इसे आधुनिक आवश्यकताओं के लिए अनुकूलित किया।

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

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



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

ठीक है, प्रस्तावना को एक तरफ छोड़ दें और इस लेख के बारे में बात करें।

तो हमें नेटवर्क सुरक्षा के बारे में कैसे सोचना चाहिए? मुझे लगता है कि हम पहले सिद्धांत के साथ शुरुआत कर सकते हैं और यह पता लगाने की कोशिश कर सकते हैं कि हमारा खतरा मॉडल क्या है। तो एक हमलावर हमारे नेटवर्क पर क्या कर सकता है?

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



लेकिन अधिक खतरनाक बुरे लोगों के लेख में वर्णित आपके प्रोटोकॉल में हस्तक्षेप करने की संभावना है। हमलावर के पास अपना कंप्यूटर है, जिसे वह पूरी तरह से नियंत्रित करता है। यहां तक ​​कि अगर आपके द्वारा भरोसा किए गए सभी कंप्यूटर ठीक से व्यवहार कर रहे हैं, तो बुरा आदमी जिसके पास अपना कंप्यूटर है, वह आपके प्रोटोकॉल या सिस्टम में हस्तक्षेप कर सकता है।

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

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

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



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

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

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

तो इसमें ऐसा क्या खास है? उन्होंने कार्यान्वयन त्रुटियों पर ध्यान क्यों नहीं दिया, हालांकि हमने उन्हें जांचने के लिए कई सप्ताह बिताए? क्या फर्क पड़ता है?

छात्र: क्योंकि प्रोटोकॉल लिखते समय हमें इन गलतियों को दूर करना चाहिए।

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

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

टीसीपी प्रोटोकॉल त्रुटियों कि स्टीफन के बारे में चिंतित थे मौलिक थे, इसलिए उन्होंने उनके बारे में बात करने का फैसला किया। पहले उदाहरण में, वह देखता है कि टीसीपी एसएन नंबर कैसे काम करता है।

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

प्रोफेसर : हाँ, मुझे लगता है कि यह एक बहुत बड़ी समस्या है। टीसीपी में त्रुटि मिलने पर क्या करें? खैर, यह स्पष्ट नहीं है कि क्या करना है। मुझे लगता है कि यहां लेखक इससे जूझ रहा है। यदि आप टीसीपी को फिर से डिज़ाइन कर सकते हैं, तो इनमें से कई त्रुटियों को ठीक करना आसान है यदि आप पहले से जानते हैं कि क्या देखना है।

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



लेकिन यह एक बड़ी समस्या है। यदि यह किसी प्रकार की सुरक्षा समस्या है जो टीसीपी में गहराई से निहित है, तो यह सभी के लिए एक बड़ी समस्या बन जाएगी, क्योंकि टीसीपी संस्करण पर स्विच करने के लिए, एन प्लस 1 को भी मान लेना बहुत मुश्किल है।

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

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

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

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



फिर, जब सर्वर इस पैकेट को प्राप्त करता है, तो वह कहता है: "ग्राहक मुझसे जुड़ना चाहता है, इसलिए मैं पैकेट को इस पते पर वापस भेजूंगा, कोई फर्क नहीं पड़ता कि कौन कहता है कि यह मुझसे संपर्क करने की कोशिश कर रहा है।" इस प्रकार, सर्वर पैकेट को ग्राहक को भेजेगा, जहां इसमें अपना स्वयं का एसएन सर्वर तुल्यकालन अनुक्रम संख्या और एसीके ग्राहक पुष्टि संख्या (एसएनसी) शामिल है। अंत में, तीसरे पैकेट में, क्लाइंट सर्वर पर प्रतिक्रिया करता है, सिंक्रनाइज़ेशन की पुष्टि करता है और सर्वर को सर्वर एसीके सर्वर पुष्टि संख्या (एसएन) भेजता है। अब क्लाइंट डेटा भेजना शुरू कर सकता है।

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



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

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

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

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

छात्र: अनुक्रम संख्या के लिए कितने बिट उपलब्ध हैं?

प्रोफेसर: टीसीपी अनुक्रम संख्या 32 बिट लंबी है, और हालांकि यह एक यादृच्छिक संख्या नहीं है, यह अनुमान लगाना आसान नहीं है, यह बहुत अधिक बैंडविड्थ लेगा।

छात्र: सीरियल नंबर प्रारंभिक सीरियल नंबर से अधिक है?

प्रोफेसर: हाँ, सिद्धांत रूप में, ये चीजें बढ़ रही हैं। इसलिए, जब भी आप SYN भेजते हैं, तो यह आपके अनुक्रम संख्या से 1 बाइट अधिक माना जाता है। यही है, अगर पहली पंक्ति में हमारे पास तर्क (एसएनसी) था, तो चौथे में पहले से ही (एसएनसी + 1) होगा, और फिर नंबरिंग यहां से जारी है। इस प्रकार, यदि आप 5 बाइट्स ट्रांसफर करते हैं, तो निम्नलिखित मूल्य (SNc) +6 होगा। यह बस आपके द्वारा भेजे गए बाइट्स को गिनता है, प्रत्येक SYN की गिनती 1 बाइट के साथ। टीसीपी विनिर्देश इन सीरियल नंबरों को चुनने की सलाह देता है ताकि उनका वेतन वृद्धि कुछ स्थिर गति से हो। आरएफसी प्रोटोकॉल के प्रारंभिक कार्य दस्तावेजों ने सुझाव दिया कि आप इन चीजों को लगभग 250,000 यूनिट और 250,000 प्रति सेकंड बढ़ाते हैं।



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

तो यह वही है जो टीसीपी डेवलपर्स बहुत चिंतित थे - ये अनट्रेंड पैकेट या देरी से पैकेट। नतीजतन, वे वास्तव में इन अनुक्रम संख्याओं को यौगिकों के बीच भी काफी नीरस समय अनुक्रम चाहते थे।

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

छात्र: यदि आपको ठीक से पता नहीं है कि पैकेज अनुक्रम का चरण क्या होगा, तो आप कैसे जानते हैं कि आपको प्राप्त पैकेज अगला पैकेज है, और पिछले एक का हिस्सा नहीं है जो आप ...

प्रोफेसर: एक नियम के रूप में, आपको प्राप्त अंतिम पैकेट याद है। और अगला अनुक्रम संख्या अनुक्रम में अगला पैकेट है। इसलिए, उदाहरण के लिए, सर्वर जानता है कि मैंने वास्तव में तारीख (एसएनसी +1) डेटा का एक हिस्सा देखा है, तो अगला SYN (SNc +1) पैकेट होगा, क्योंकि कनेक्शन की शुरुआत में पिछला पैकेट SYN (SNc) था।

छात्र: तो, आप कहते हैं कि जब आप सीरियल नंबर सेट करते हैं, उसके बाद भी आप ...

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

लेकिन एक कनेक्शन के भीतर, यह स्थापित होते ही सबकुछ समाप्त हो जाता है - सीरियल नंबर तय हो जाते हैं। और वे केवल इस कनेक्शन को चिह्नित करते हैं क्योंकि डेटा इसके ऊपर भेजा जाता है।

ऐसी योजनाएं थीं जो इन सीरियल नंबरों को प्रबंधित करने का सुझाव देती थीं। , . , , , .

, - , 250000. , , , 64k 128k, . , – , SYN .

, 64 . , .

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

, ? , , , — SNc. , , - , , , .

, . ACK (SNs).

- .



SNs , , , IP- C.

, . , : , , , data (SNc +1).



(SNs). ?

: , ?

: . , , , , . , , , , .

: , , ?

: . , ?

, . , , 32 , , .

, .

: , , , . …

: , TCP .

: , .

: , .

: , , .

: , , , . , , 1000 , 2 32 .

, - , , . . , .



: - , ?

: , . , , IP-, ?

: ?

: — ? , . ?

: , , , , - .

: , , , , , . IP-, TCP , , , .

TCP , - , , , C RST (SN…), , .



- , , C , .

, C , . , S , : «, , , ».

, , , , , C .

, «» C , . , «» C , . , TCP.

: , . , SYN , .

: , , . , , , , NAT, . , NAT RST , . , , , , , Comcast , RST .

: ?

: , , TCP. , . , , , . /, .

, data (SNc +1). , IP- , : « », , S.



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

25:50 मि

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


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

हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक आदेश रखकर या अपने दोस्तों को इसकी अनुशंसा करके हमें समर्थन दें, एंट्री-लेवल सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 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 सर्वर का उपयोग कर वर्ग?