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

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

इंटरनेट का उपयोग

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

इस सेगमेंट का ऑडिट करते समय, निम्नलिखित पहलुओं पर ध्यान दें:

• डिज़ाइन
• बीजीपी सेटिंग्स
• डॉस / डीडीओएस सुरक्षा
• फ़ायरवॉल ट्रैफ़िक फ़िल्टरिंग

डिज़ाइन

एंटरप्राइज़ नेटवर्क के लिए इस सेगमेंट के डिज़ाइन के एक उदाहरण के रूप में, मैं सेफ मॉडल के अंदर सिस्को से एक गाइड की सिफारिश करूंगा।

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

टिप्पणी

सेफ में, रिमोट एक्सेस सेगमेंट इंटरनेट एक्सेस का हिस्सा है। लेकिन लेखों की इस श्रृंखला में हम इस पर अलग से विचार करेंगे।

एक उद्यम नेटवर्क के लिए इस सेगमेंट में उपकरणों का मानक सेट है

• सीमा राउटर
• फायरवॉल

टिप्पणी 1

इस लेख श्रृंखला में, जब मैं फायरवॉल के बारे में बात करता हूं, मेरा मतलब एनजीएफडब्ल्यू है ।

टिप्पणी 2

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

यदि आपको इस सेगमेंट में फ़ायरवॉल नहीं मिला है, तो निष्कर्ष पर न जाएं।

चलो शुरू करते हैं, जैसा कि पिछले भाग में है , सवाल के साथ: क्या आपके मामले में इस सेगमेंट में फ़ायरवॉल का उपयोग करना आवश्यक है?

मैं यह कह सकता हूं कि यह फायरवॉल का उपयोग करने और जटिल ट्रैफ़िक फ़िल्टरिंग एल्गोरिदम लागू करने के लिए सबसे न्यायसंगत जगह है। भाग 1 में, हमने 4 कारकों का उल्लेख किया है जो डेटा सेंटर सेगमेंट में फायरवॉल के उपयोग में हस्तक्षेप कर सकते हैं। लेकिन यहाँ वे इतने महत्वपूर्ण नहीं हैं।

उदाहरण 1. देरी

जैसा कि इंटरनेट के लिए, 1 मिलीसेकंड के आदेश की भी देरी के बारे में बात करने का कोई मतलब नहीं है। इसलिए, इस सेगमेंट में देरी आतिशबाजी के उपयोग को सीमित करने वाला कारक नहीं हो सकती है।

उदाहरण 2. प्रदर्शन

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

उदाहरण 3. विश्वसनीयता

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

तो, मान लीजिए कि आपकी सेवा http / https (छोटे सत्रों के साथ) के शीर्ष पर रहती है। इस मामले में, आप दो स्वतंत्र बक्से (एचए के बिना) का उपयोग कर सकते हैं और, अगर उनमें से एक के साथ कोई समस्या है, तो रूटिंग, दूसरे पर सभी ट्रैफ़िक स्थानांतरित करें।

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

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

महत्वपूर्ण!

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

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

उदाहरण

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

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

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

आपके पास पूर्ण डेटा संरक्षण (फ़ायरवॉल, आपके इंटरनेट प्रदाताओं द्वारा प्रदान की गई डीडीओएस सुरक्षा सेवाएं) और दर्जनों या सैकड़ों "सरलीकृत" बिंदुओं के साथ केवल L2 स्विच और सर्वर के साथ उपस्थिति के दर्जनों डेटा केंद्र हो सकते हैं।

लेकिन इस मामले में सुरक्षा के बारे में क्या?

उदाहरण के लिए, हाल ही में DNS प्रवर्धन डीडीओएस हमले को देखें । इसका खतरा इस तथ्य में निहित है कि बड़ी मात्रा में ट्रैफ़िक उत्पन्न होता है, जो आपके सभी अपलिंक का केवल 100% "क्लॉग" करता है।

हमारे डिजाइन के मामले में हमारे पास क्या है।

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

और इस उदाहरण के लिए एक और छोटी टिप्पणी। यदि आप IXs के माध्यम से पर्याप्त ट्रैफ़िक भेजते हैं, तो यह इस तरह के हमलों के लिए आपके जोखिम को भी कम करता है।

कॉन्फ़िगर करें बीजीपी

दो विषय हैं।

• जुटना
• कॉन्फ़िगर करें बीजीपी

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

उदाहरण 1

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

उदाहरण 2

यदि आप एक गेमिंग कंपनी हैं और दसियों मिलीसेकंड आपके लिए महत्वपूर्ण हैं, तो, निश्चित रूप से, कनेक्टिविटी आपके लिए बहुत महत्वपूर्ण है।

उदाहरण 3

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

कनेक्टिविटी का अध्ययन एक अलग दिलचस्प विषय है, एक अलग लेख या लेखों की श्रृंखला के योग्य है और इसके लिए एक अच्छी समझ की आवश्यकता है कि इंटरनेट कैसे "व्यवस्थित" है।

उपयोगी संसाधन:

ripe.net
bgp.he.net

उदाहरण

मैं सिर्फ एक छोटा सा उदाहरण दूंगा।

मान लीजिए कि आपका डेटा सेंटर मॉस्को में स्थित है, और आपके पास केवल अपलिंक है - रोस्टेलकॉम (AS12389)। इस मामले में, आपको (सिंगल होमेड) बीजीपी की आवश्यकता नहीं है, और आप सार्वजनिक पते के रूप में रोस्टेलकॉम के एड्रेस पूल का सबसे अधिक उपयोग करते हैं।

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

ट्रेसरआउट करके, आपने देखा कि ट्रैफ़िक AS1299 (तेलिया) से होकर जाता है, और पिंग करने से, आपको 70 - 80 मिलीसेकंड का औसत RTT मिला। आप इसे रोस्टेलकॉम के लुकिंग ग्लास पर भी देख सकते हैं।

Whois उपयोगिता (ripe.net या स्थानीय उपयोगिता पर) के साथ आप आसानी से निर्धारित कर सकते हैं कि ब्लॉक 37.52.0.0/21 AS6849 (Ukrtelecom) से संबंधित है।

इसके अलावा, bgp.he.net पर जाकर आप देखते हैं कि AS6849 का AS12389 के साथ कोई संबंध नहीं है (वे न तो ग्राहक हैं और न ही एक-दूसरे के अपलिंक हैं, उनके पास भी सहानुभूति नहीं है)। लेकिन अगर आप AS6849 के लिए साथियों की सूची देखें, तो आप देखेंगे, उदाहरण के लिए, AS29226 (मास्टर्टल) और AS31133 (मेगाफोन)।

इन प्रदाताओं के लुकिंग ग्लास को पाकर, आप पथ और आरटीटी की तुलना कर सकते हैं। उदाहरण के लिए, मास्टर्टल आरटीटी के लिए पहले से ही लगभग 30 मिलीसेकंड होगा।

इसलिए, यदि आपकी सेवा के लिए 80 और 30 मिलीसेकंड का अंतर महत्वपूर्ण है, तो शायद आपको कनेक्टिविटी के बारे में सोचने की जरूरत है, अपना AS नंबर, RIPE में अपना एड्रेस पूल प्राप्त करें और अतिरिक्त अपलिंक और / या IXs पर उपस्थिति के बिंदु बनाएं।

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

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

डॉस / डीडीओएस सुरक्षा

अब DOS / DDOS हमले कई कंपनियों के लिए एक दैनिक वास्तविकता बन गए हैं। वास्तव में, एक रूप या किसी अन्य में, आप पर अक्सर हमला किया जाता है। तथ्य यह है कि आप अभी तक इस पर ध्यान नहीं देते हैं, केवल इसका मतलब है कि आपके खिलाफ एक लक्षित हमला अभी तक आयोजित नहीं किया गया है, और यह कि आपके द्वारा उपयोग किए जाने वाले बचाव, यहां तक ​​कि संभवतः इस पर संदेह किए बिना (ऑपरेटिंग सिस्टम के विभिन्न अंतर्निहित बचाव), पर्याप्त है ताकि प्रदान की गई सेवा का ह्रास आपके और आपके ग्राहकों के लिए कम से कम हो।

ऐसे इंटरनेट संसाधन हैं जो उपकरणों से लॉग के आधार पर वास्तविक समय में सुंदर हमले के नक्शे खींचते हैं।

यहां आप उनसे लिंक पा सकते हैं।

चेकपॉइंट से मेरा पसंदीदा नक्शा ।

डीडीओएस / डॉस सुरक्षा आमतौर पर स्तरित है। यह समझने के लिए कि, आपको यह समझने की आवश्यकता है कि किस प्रकार के डॉस / डीडीओएस हमले मौजूद हैं (उदाहरण के लिए, यहां या यहां देखें )

अर्थात्, हमारे पास तीन प्रकार के हमले हैं:

• वॉल्यूमेट्रिक हमले
• प्रोटोकॉल पर हमला
• अनुप्रयोग के हमले

यदि आप अपने आप को अंतिम दो प्रकार के हमलों से बचा सकते हैं, उदाहरण के लिए, फायरवॉल का उपयोग करते हुए, तो आप अपने उत्थान को "ओवरफ्लो करने" के उद्देश्य से होने वाले हमलों से सुरक्षित नहीं रहेंगे (यदि आपकी इंटरनेट चैनल क्षमता की गणना टेराबाइट में नहीं की गई है, लेकिन दर्जनों में बेहतर है। terabits)।

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

उदाहरण

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

इस मामले में, आपको हमले के दौरान आंशिक रूप से कनेक्टिविटी का त्याग करना होगा। लेकिन

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

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

सिद्धांत रूप में, आप अपनी सुरक्षा को पूरी तरह से आउटसोर्स करके खुद को इस तक सीमित कर सकते हैं। इस समाधान के प्लसस हैं, लेकिन एक स्पष्ट माइनस है। तथ्य यह है कि हम व्यापार के अस्तित्व के बारे में (आपकी कंपनी क्या कर रही है, इसके आधार पर) फिर से बात कर सकते हैं। और ऐसी बातों पर तीसरे पक्ष को भरोसा ...

इसलिए, आइए देखें कि रक्षा की दूसरी और तीसरी पंक्ति को कैसे व्यवस्थित किया जाए (प्रदाता से सुरक्षा के रूप में)।

तो, रक्षा की दूसरी पंक्ति आपके नेटवर्क के प्रवेश द्वार पर फ़िल्टरिंग और अधिकारी है।

उदाहरण 1

मान लीजिए कि आप प्रदाताओं में से किसी एक का उपयोग करके DDOS से "एक छतरी के साथ बंद" हैं। मान लीजिए कि यह प्रदाता अपने नेटवर्क के किनारे पर ट्रैफ़िक को फ़िल्टर करने के लिए आर्बर का उपयोग करता है।

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

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

उदाहरण 2

एक असामान्य रूप से बड़ी संख्या में SYN पैकेट न केवल SYN बाढ़ के हमले का परिणाम हो सकता है। मान लें कि आप एक सेवा प्रदान करते हैं जिसमें आप एक साथ लगभग 100 हजार टीसीपी कनेक्शन (एक डेटा सेंटर में) कर सकते हैं।

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

यदि, इन सत्रों के शीर्ष पर, उदाहरण के लिए, आपके पास ssl / tls हैंडशेक होना चाहिए, जिसमें प्रमाणपत्रों का आदान-प्रदान शामिल है, तो आपके लोड बैलेंसर के लिए संसाधनों से बाहर निकलने के दृष्टिकोण से, यह एक साधारण SYN बाढ़ की तुलना में बहुत अधिक मजबूत "DDOS" होगा। ऐसा लगता है कि बैलेन्कर्स को इस तरह की घटना पर काम करना चाहिए, लेकिन ... दुर्भाग्य से, हमें पूर्ण विकास में इस तरह की समस्या का सामना करना पड़ा।

और, निश्चित रूप से, बॉर्डर राउटर पर पुलिस आपके उपकरण को इस मामले में भी बचाएगा।

डीडीओएस / डॉस के खिलाफ सुरक्षा का तीसरा स्तर आपके फ़ायरवॉल की सेटिंग है।

यहां आप दूसरे और तीसरे प्रकार के दोनों हमलों को रोक सकते हैं। सामान्य तौर पर, फ़ायरवॉल तक पहुंचने वाली हर चीज़ को यहाँ फ़िल्टर किया जा सकता है।

परिषद

रक्षा की पहली दो पंक्तियों पर जितना संभव हो उतना फ़िल्टर करके फ़ायरवॉल को यथासंभव कम काम देने का प्रयास करें। और यहाँ क्यों है।

यह आपके साथ नहीं हुआ है कि दुर्घटना से, जाँच के क्रम में ट्रैफ़िक उत्पन्न करना, उदाहरण के लिए, ऑपरेटिंग सिस्टम पर आपके डीडीओएस हमले कितने प्रतिरोधी हैं, आपने अपने फ़ायरवॉल को "मार" दिया, इसे 100 प्रतिशत लोड करके, सामान्य तीव्रता के ट्रैफ़िक के साथ? यदि नहीं, तो शायद सिर्फ इसलिए कि आपने इसकी कोशिश नहीं की है?

सामान्य तौर पर, एक फ़ायरवॉल, जैसा कि मैंने पहले ही कहा था, एक जटिल चीज़ है, और यह ज्ञात कमजोरियों और परीक्षण किए गए समाधानों के साथ अच्छी तरह से काम करता है, लेकिन यदि आप कुछ असामान्य भेजते हैं, तो बस कुछ कचरा या पैकेट गलत हेडर के साथ, तो आप कुछ के साथ इस तरह के एक छोटे से (मेरे अनुभव के आधार पर) संभावना के साथ आप शीर्ष-अंत उपकरण को एक स्तूप में पेश कर सकते हैं। इसलिए, चरण 2 में, नियमित एसीएल (एल 3 / एल 4 स्तर पर) का उपयोग करके, केवल ट्रैफ़िक को आपके नेटवर्क में प्रवेश करने की अनुमति दें।

फ़ायरवॉल ट्रैफ़िक फ़िल्टरिंग

हम फ़ायरवॉल के बारे में बातचीत जारी रखते हैं। आपको यह समझने की आवश्यकता है कि डॉस / डीडीओएस हमले केवल एक प्रकार के साइबर हमले हैं।

डॉस / डीडीओएस सुरक्षा के अलावा, हम अभी भी सुविधाओं की सूची की तरह कुछ कर सकते हैं:

• आवेदन फ़ायरवॉल
• खतरे की रोकथाम (एंटीवायरस, एंटी-स्पाइवेयर और भेद्यता)
• URL फ़िल्टरिंग
• डेटा फ़िल्टरिंग (सामग्री फ़िल्टरिंग)
• फ़ाइल अवरुद्ध (फ़ाइल प्रकार अवरुद्ध)

यह आप पर निर्भर है कि आपको इस सूची से क्या चाहिए।

जारी रखा जाए