हा लेख "तुमच्या नेटवर्क इन्फ्रास्ट्रक्चरचे नियंत्रण कसे करावे" या मालिकेतील चौथा आहे. मालिकेतील सर्व लेखांचा मजकूर आणि लिंक्स मिळू शकतात येथे.

В पहिला भाग या प्रकरणात, आम्ही डेटा सेंटर विभागातील नेटवर्क सुरक्षिततेच्या काही पैलूंकडे पाहिले. हा भाग "इंटरनेट प्रवेश" विभागासाठी समर्पित असेल.

इंटरनेट प्रवेश

सुरक्षिततेचा विषय निःसंशयपणे डेटा नेटवर्कच्या जगात सर्वात जटिल विषयांपैकी एक आहे. मागील प्रकरणांप्रमाणे, खोली आणि पूर्णतेचा दावा न करता, मी येथे अगदी सोप्या पद्धतीने विचार करेन, परंतु, माझ्या मते, महत्त्वाचे प्रश्न, ज्यांची उत्तरे, मला आशा आहे की, तुमच्या नेटवर्कच्या सुरक्षिततेची पातळी वाढविण्यात मदत होईल.

या विभागाचे ऑडिट करताना, खालील पैलूंकडे लक्ष द्या:

• डिझाइन
• BGP सेटिंग्ज
• DOS/DDOS संरक्षण
• फायरवॉलवर रहदारी फिल्टरिंग

डिझाईन

एंटरप्राइझ नेटवर्कसाठी या विभागाच्या डिझाइनचे उदाहरण म्हणून, मी शिफारस करतो नेतृत्व आत सिस्को पासून सुरक्षित मॉडेल.

अर्थात, कदाचित इतर विक्रेत्यांचे समाधान तुम्हाला अधिक आकर्षक वाटेल (पहा. गार्टनर क्वाड्रंट 2018), परंतु तुम्हाला या डिझाइनचे तपशीलवार अनुसरण करण्यास प्रोत्साहित न करता, मला अजूनही त्यामागील तत्त्वे आणि कल्पना समजून घेणे उपयुक्त वाटते.

टीप

SAFE मध्ये, "रिमोट ऍक्सेस" सेगमेंट "इंटरनेट ऍक्सेस" विभागाचा भाग आहे. परंतु लेखांच्या या मालिकेत आपण त्याचा स्वतंत्रपणे विचार करू.

एंटरप्राइझ नेटवर्कसाठी या विभागातील उपकरणांचा मानक संच आहे

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

टिप्पणी 1

लेखांच्या या मालिकेत, जेव्हा मी फायरवॉलबद्दल बोलतो तेव्हा मला म्हणायचे आहे NGFW.

टिप्पणी 2

L2/L1 कनेक्टिव्हिटी सुनिश्चित करण्यासाठी आवश्यक असलेल्या L2/L3 किंवा L1 सोल्यूशन्सवर ओव्हरले L2 च्या विविध प्रकारांचा विचार मी वगळत आहे आणि केवळ L3 स्तरावरील आणि त्यावरील समस्यांपुरते मर्यादित आहे. अंशतः, L1/L2 मुद्द्यांवर या अध्यायात चर्चा करण्यात आली.स्वच्छता आणि दस्तऐवजीकरण".

जर तुम्हाला या विभागात फायरवॉल सापडला नसेल, तर तुम्ही निष्कर्षापर्यंत घाई करू नये.

मध्ये सारखेच करू मागील भागचला प्रश्नासह प्रारंभ करूया: आपल्या बाबतीत या विभागात फायरवॉल वापरणे आवश्यक आहे का?

मी असे म्हणू शकतो की फायरवॉल वापरण्यासाठी आणि जटिल ट्रॅफिक फिल्टरिंग अल्गोरिदम लागू करण्यासाठी हे सर्वात न्याय्य ठिकाण आहे. IN भाग 1 आम्ही 4 घटकांचा उल्लेख केला आहे जे डेटा सेंटर विभागामध्ये फायरवॉलच्या वापरामध्ये व्यत्यय आणू शकतात. परंतु येथे ते आता इतके लक्षणीय नाहीत.

उदाहरण 1 विलंब

जोपर्यंत इंटरनेटचा संबंध आहे, सुमारे 1 मिलीसेकंदच्या विलंबाबद्दल बोलण्यात काही अर्थ नाही. त्यामुळे, या विभागातील विलंब हा फायरवॉलचा वापर मर्यादित करणारा घटक असू शकत नाही.

उदाहरण 2 उत्पादकता

काही प्रकरणांमध्ये हा घटक अजूनही महत्त्वपूर्ण असू शकतो. म्हणून, फायरवॉलला बायपास करण्यासाठी तुम्हाला काही रहदारी (उदाहरणार्थ, लोड बॅलन्सरकडून ट्रॅफिक) परवानगी द्यावी लागेल.

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

हा घटक अद्याप विचारात घेणे आवश्यक आहे, परंतु तरीही, इंटरनेटचीच अविश्वसनीयता लक्षात घेता, या विभागासाठी त्याचे महत्त्व डेटा सेंटरसाठी इतके महत्त्वपूर्ण नाही.

तर, आपली सेवा http/https (लहान सत्रांसह) वर राहतात असे मानू या. या प्रकरणात, आपण दोन स्वतंत्र बॉक्स (HA शिवाय) वापरू शकता आणि त्यापैकी एकामध्ये मार्ग समस्या असल्यास, सर्व रहदारी दुसऱ्यावर हस्तांतरित करा.

किंवा तुम्ही फायरवॉल पारदर्शक मोडमध्ये वापरू शकता आणि ते अयशस्वी झाल्यास, समस्या सोडवताना ट्रॅफिकला फायरवॉल बायपास करण्याची परवानगी द्या.

म्हणून, बहुधा फक्त किंमत हा घटक असू शकतो जो तुम्हाला या विभागातील फायरवॉलचा वापर सोडून देण्यास भाग पाडेल.

महत्त्वाचे!

या फायरवॉलला डेटा सेंटर फायरवॉलसह एकत्र करण्याचा मोह आहे (या विभागांसाठी एक फायरवॉल वापरा). उपाय, तत्त्वतः, शक्य आहे, परंतु आपल्याला ते समजून घेणे आवश्यक आहे कारण इंटरनेट अ‍ॅक्सेस फायरवॉल तुमच्या संरक्षणासाठी सर्वात पुढे आहे आणि कमीतकमी काही दुर्भावनापूर्ण रहदारी “घेते”, तर नक्कीच, तुम्हाला ही फायरवॉल अक्षम केली जाण्याची जोखीम लक्षात घेणे आवश्यक आहे. म्हणजेच, या दोन विभागांमध्ये समान उपकरणे वापरून, तुम्ही तुमच्या डेटा सेंटर विभागाची उपलब्धता लक्षणीयरीत्या कमी कराल.

नेहमीप्रमाणे, तुम्हाला हे समजून घेणे आवश्यक आहे की कंपनी प्रदान करत असलेल्या सेवेवर अवलंबून, या विभागाची रचना मोठ्या प्रमाणात बदलू शकते. नेहमीप्रमाणे, तुम्ही तुमच्या गरजेनुसार भिन्न पध्दती निवडू शकता.

उदाहरण:

तुम्ही CDN नेटवर्कसह सामग्री प्रदाता असल्यास (पहा, उदाहरणार्थ, लेखांची मालिका), तर तुम्ही ट्रॅफिक रूटिंग आणि फिल्टरिंगसाठी स्वतंत्र उपकरणे वापरून डझनभर किंवा अगदी शेकडो उपस्थितीच्या ठिकाणी पायाभूत सुविधा निर्माण करू इच्छित नाही. हे महाग असेल आणि ते अनावश्यक असू शकते.

BGP साठी तुमच्याकडे समर्पित राउटर असणे आवश्यक नाही, तुम्ही ओपन सोर्स टूल्स वापरू शकता जसे की क्वाग्गा. त्यामुळे कदाचित तुम्हाला फक्त एक सर्व्हर किंवा अनेक सर्व्हर, एक स्विच आणि BGP आवश्यक आहे.

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

तुमच्याकडे संपूर्ण संरक्षणासह (फायरवॉल, तुमच्या इंटरनेट प्रदात्यांद्वारे प्रदान केलेल्या DDOS संरक्षण सेवा) आणि फक्त L2 स्विच आणि सर्व्हरसह डझनभर किंवा शेकडो "सरलीकृत" उपस्थिती असलेली अनेक डेटा केंद्रे असू शकतात.

पण या प्रकरणात संरक्षणाचे काय?

चला, उदाहरणार्थ, अलीकडील लोकप्रिय पाहू DNS प्रवर्धन DDOS हल्ला. त्याचा धोका या वस्तुस्थितीत आहे की मोठ्या प्रमाणात रहदारी निर्माण होते, जी तुमच्या सर्व अपलिंक्सपैकी 100% फक्त "बंद" करते.

आमच्या डिझाइनच्या बाबतीत आमच्याकडे काय आहे.

• तुम्ही AnyCast वापरत असल्यास, तुमच्या उपस्थितीच्या बिंदूंमध्ये रहदारी वितरीत केली जाते. जर तुमची एकूण बँडविड्थ टेराबिट्स असेल, तर हे स्वतःच (तथापि, अलीकडे टेराबिटच्या ऑर्डरवर दुर्भावनापूर्ण रहदारीसह अनेक हल्ले झाले आहेत) तुमचे "ओव्हरफ्लोइंग" अपलिंकपासून संरक्षण करते.
• तथापि, काही अपलिंक बंद पडल्यास, तुम्ही ही साइट सेवेतून काढून टाका (जाहिराती उपसर्ग थांबवा)
• तुम्ही तुमच्या "पूर्ण" (आणि त्यानुसार, संरक्षित) डेटा सेंटरमधून पाठवलेल्या ट्रॅफिकचा वाटा देखील वाढवू शकता, अशा प्रकारे दुर्भावनापूर्ण रहदारीचा एक महत्त्वाचा भाग उपस्थितीच्या असुरक्षित बिंदूंमधून काढून टाकू शकता.

आणि या उदाहरणासाठी आणखी एक छोटी टीप. जर तुम्ही IXs द्वारे पुरेशी रहदारी पाठवली, तर हे अशा हल्ल्यांना तुमची असुरक्षितता देखील कमी करते

BGP सेट करत आहे

येथे दोन विषय आहेत.

• कनेक्टिव्हिटी
• BGP सेट करत आहे

मध्ये कनेक्टिव्हिटीबद्दल आम्ही आधीच थोडे बोललो आहोत भाग 1. मुद्दा हा आहे की आपल्या ग्राहकांना ट्रॅफिक इष्टतम मार्गाचे अनुसरण करते. जरी इष्टतमता नेहमीच केवळ विलंबतेबद्दल नसते, कमी विलंब हे सहसा अनुकूलतेचे मुख्य सूचक असते. काही कंपन्यांसाठी हे अधिक महत्वाचे आहे, इतरांसाठी ते कमी आहे. हे सर्व तुम्ही देत ​​असलेल्या सेवेवर अवलंबून आहे.

उदाहरणार्थ 1

जर तुम्ही एक्सचेंज असाल आणि तुमच्या क्लायंटसाठी मिलिसेकंद पेक्षा कमी वेळेचे अंतर महत्त्वाचे असेल, तर अर्थातच, कोणत्याही प्रकारच्या इंटरनेटबद्दल अजिबात चर्चा होऊ शकत नाही.

उदाहरणार्थ 2

जर तुम्ही गेमिंग कंपनी असाल आणि दहापट मिलिसेकंद तुमच्यासाठी महत्त्वाचे असतील, तर नक्कीच तुमच्यासाठी कनेक्टिव्हिटी खूप महत्त्वाची आहे.

उदाहरणार्थ 3

तुम्हाला हे देखील समजून घेणे आवश्यक आहे की, TCP प्रोटोकॉलच्या गुणधर्मांमुळे, एका TCP सत्रातील डेटा हस्तांतरण दर देखील RTT (राउंड ट्रिप टाइम) वर अवलंबून असतो. सामग्री वितरण सर्व्हर या सामग्रीच्या ग्राहकांच्या जवळ हलवून या समस्येचे निराकरण करण्यासाठी CDN नेटवर्क देखील तयार केले जात आहेत.

कनेक्टिव्हिटीचा अभ्यास हा स्वतःचा एक मनोरंजक विषय आहे, जो त्याच्या स्वतःच्या लेखासाठी किंवा लेखांच्या मालिकेसाठी योग्य आहे आणि इंटरनेट "कसे कार्य करते" हे समजून घेणे आवश्यक आहे.

उपयुक्त संसाधने:

ripe.net
bgp.he.net

उदाहरण:

मी फक्त एक लहान उदाहरण देईन.

समजू की तुमचे डेटा सेंटर मॉस्कोमध्ये आहे आणि तुमच्याकडे एकच अपलिंक आहे - Rostelecom (AS12389). या प्रकरणात (सिंगल होम्ड) तुम्हाला BGP ची गरज नाही आणि तुम्ही बहुधा Rostelecom मधील अॅड्रेस पूल सार्वजनिक पत्ते म्हणून वापरता.

समजा तुम्ही एक विशिष्ट सेवा प्रदान करता आणि तुमच्याकडे युक्रेनमधील ग्राहकांची पुरेशी संख्या आहे आणि ते दीर्घ विलंबाबद्दल तक्रार करतात. तुमच्या संशोधनादरम्यान, तुम्हाला आढळले की त्यापैकी काहींचे IP पत्ते 37.52.0.0/21 ग्रिडमध्ये आहेत.

ट्रेसरूट चालवून, तुम्ही AS1299 (Telia) वरून वाहतूक जात असल्याचे पाहिले आणि एक पिंग चालवून, तुम्हाला सरासरी 70 - 80 मिलीसेकंदचा RTT मिळाला. आपण येथे देखील पाहू शकता लुकिंग ग्लास रोस्टेलेकॉम.

Whois युटिलिटी (ripe.net किंवा स्थानिक युटिलिटी वर) वापरून, तुम्ही सहजपणे निर्धारित करू शकता की ब्लॉक 37.52.0.0/21 AS6849 (Ukrtelecom) चा आहे.

पुढे, जाऊन bgp.he.net तुम्ही पहाल की AS6849 चा AS12389 शी कोणताही संबंध नाही (ते क्लायंट नाहीत किंवा एकमेकांशी अपलिंक नाहीत किंवा त्यांच्याकडे पीअरिंग नाही). पण बघितले तर समवयस्कांची यादी AS6849 साठी, तुम्हाला दिसेल, उदाहरणार्थ, AS29226 (Mastertel) आणि AS31133 (Megafon).

एकदा तुम्हाला या प्रदात्यांचा लुकिंग ग्लास सापडला की, तुम्ही पथ आणि RTT यांची तुलना करू शकता. उदाहरणार्थ, Mastertel RTT साठी सुमारे 30 मिलीसेकंद असेल.

त्यामुळे, जर तुमच्या सेवेसाठी 80 आणि 30 मिलीसेकंदमधील फरक महत्त्वाचा असेल, तर कदाचित तुम्हाला कनेक्टिव्हिटीबद्दल विचार करावा लागेल, तुमचा AS क्रमांक, तुमचा पत्ता पूल RIPE वरून मिळवा आणि अतिरिक्त अपलिंक कनेक्ट करा आणि/किंवा IX वर उपस्थितीचे बिंदू तयार करा.

जेव्हा तुम्ही BGP वापरता, तेव्हा तुम्हाला केवळ कनेक्टिव्हिटी सुधारण्याची संधी नसते, परंतु तुम्ही अनावश्यकपणे तुमचे इंटरनेट कनेक्शन राखता.

हा दस्तऐवज BGP कॉन्फिगर करण्यासाठी शिफारसी आहेत. या शिफारशी प्रदात्यांच्या "सर्वोत्तम सराव" च्या आधारे विकसित केल्या गेल्या असूनही, तरीही (जर तुमची BGP सेटिंग्ज मूलभूत नसतील तर) त्या निःसंशयपणे उपयुक्त आहेत आणि खरं तर आम्ही चर्चा केलेल्या कठोरपणाचा भाग असावा. पहिला भाग.

DOS/DDOS संरक्षण

आता DOS/DDOS हल्ले हे अनेक कंपन्यांसाठी रोजचे वास्तव बनले आहे. खरं तर, तुमच्यावर अनेकदा कोणत्या ना कोणत्या स्वरूपात हल्ला होतो. तुम्ही अद्याप हे लक्षात घेतलेले नाही याचा अर्थ असा आहे की तुमच्यावर लक्ष्यित हल्ला अद्याप आयोजित केलेला नाही आणि तुम्ही वापरत असलेले संरक्षण उपाय, कदाचित ते माहीत नसतानाही (ऑपरेटिंग सिस्टीमची विविध अंगभूत संरक्षणे) पुरेशी आहेत. तुमच्यासाठी आणि तुमच्या क्लायंटसाठी प्रदान केलेल्या सेवेची अधोगती कमी केली जाईल याची खात्री करा.

अशी इंटरनेट संसाधने आहेत जी उपकरणे लॉगवर आधारित, वास्तविक वेळेत सुंदर आक्रमण नकाशे काढतात.

तो आहे तुम्ही त्यांच्या लिंक्स शोधू शकता.

माझे आवडते कार्ड चेकपॉईंट वरून.

DDOS/DOS विरूद्ध संरक्षण सहसा स्तरित असते. का हे समजून घेण्यासाठी, तुम्हाला कोणत्या प्रकारचे DOS/DDOS हल्ले अस्तित्वात आहेत हे समजून घेणे आवश्यक आहे (पहा, उदाहरणार्थ, येथे किंवा येथे)

म्हणजेच, आमच्याकडे तीन प्रकारचे हल्ले आहेत:

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

जर तुम्ही शेवटच्या दोन प्रकारच्या हल्ल्यांपासून स्वतःचे रक्षण करू शकत असाल, उदाहरणार्थ, फायरवॉल, तर तुम्ही तुमच्या अपलिंकला "जबरदस्त" करण्याच्या उद्देशाने होणाऱ्या हल्ल्यांपासून स्वतःचे संरक्षण करू शकत नाही (अर्थातच, तुमच्या इंटरनेट चॅनेलची एकूण क्षमता टेराबिटमध्ये मोजली जात नसल्यास, किंवा अजून चांगले, दहा टेराबिटमध्ये).

म्हणून, संरक्षणाची पहिली ओळ "व्हॉल्यूमेट्रिक" हल्ल्यांपासून संरक्षण आहे आणि तुमच्या प्रदात्याने किंवा प्रदात्याने तुम्हाला हे संरक्षण प्रदान करणे आवश्यक आहे. जर तुम्हाला हे अजून कळले नसेल, तर तुम्ही आत्तासाठी भाग्यवान आहात.

उदाहरण:

समजा तुमच्याकडे अनेक अपलिंक्स आहेत, परंतु प्रदात्यांपैकी फक्त एकच तुम्हाला हे संरक्षण देऊ शकतो. पण जर सर्व ट्रॅफिक एका प्रदात्याद्वारे जात असेल, तर आम्ही थोड्या आधी चर्चा केलेल्या कनेक्टिव्हिटीचे काय?

या प्रकरणात, आपल्याला हल्ल्यादरम्यान कनेक्टिव्हिटीचा अंशतः त्याग करावा लागेल. परंतु

• हे फक्त हल्ल्याच्या कालावधीसाठी आहे. हल्ला झाल्यास, तुम्ही मॅन्युअली किंवा आपोआप BGP पुन्हा कॉन्फिगर करू शकता जेणेकरून ट्रॅफिक फक्त तुम्हाला "छत्री" पुरवणाऱ्या प्रदात्यामार्फत जाईल. हल्ला संपल्यानंतर, तुम्ही राउटिंगला त्याच्या पूर्वीच्या स्थितीत परत करू शकता
• सर्व रहदारी हस्तांतरित करणे आवश्यक नाही. उदाहरणार्थ, तुम्हाला काही अपलिंक्स किंवा पीअरिंगद्वारे कोणतेही हल्ले होत नाहीत (किंवा रहदारी लक्षणीय नाही) असे दिसत असल्यास, तुम्ही या BGP शेजार्‍यांसाठी स्पर्धात्मक गुणधर्मांसह उपसर्गांची जाहिरात करणे सुरू ठेवू शकता.

तुम्ही तुमच्या भागीदारांना “प्रोटोकॉल हल्ला” आणि “अॅप्लिकेशन अटॅक” पासून संरक्षण देखील देऊ शकता.
येथे येथे तुम्ही चांगला अभ्यास वाचू शकता (हस्तांतरण). खरे आहे, लेख दोन वर्षांचा आहे, परंतु तो तुम्हाला डीडीओएस हल्ल्यांपासून स्वतःचे संरक्षण कसे करता येईल याची कल्पना देईल.

तत्वतः, आपण आपल्या संरक्षणास पूर्णपणे आऊटसोर्सिंग करून स्वत: ला मर्यादित करू शकता. या निर्णयाचे फायदे आहेत, परंतु एक स्पष्ट तोटा देखील आहे. वस्तुस्थिती अशी आहे की आम्ही व्यवसायाच्या अस्तित्वाबद्दल (पुन्हा, तुमची कंपनी काय करते यावर अवलंबून) बोलू शकतो. आणि अशा गोष्टींवर तृतीय पक्षांवर विश्वास ठेवा...

म्हणून, संरक्षणाची दुसरी आणि तिसरी ओळी कशी व्यवस्थापित करायची ते पाहू या (प्रदात्याच्या संरक्षणासाठी अतिरिक्त म्हणून).

तर, संरक्षणाची दुसरी ओळ म्हणजे फिल्टरिंग आणि ट्रॅफिक लिमिटर्स (पोलिसर्स) तुमच्या नेटवर्कच्या प्रवेशद्वारावर.

उदाहरणार्थ 1

चला असे गृहीत धरू की आपण प्रदात्यांपैकी एकाच्या मदतीने डीडीओएसच्या विरूद्ध छत्रीने स्वत: ला झाकले आहे. चला असे गृहीत धरू की हा प्रदाता त्याच्या नेटवर्कच्या काठावर रहदारी आणि फिल्टर फिल्टर करण्यासाठी आर्बर वापरतो.

आर्बर "प्रक्रिया" करू शकणारी बँडविड्थ मर्यादित आहे आणि प्रदाता अर्थातच, फिल्टरिंग उपकरणांद्वारे ही सेवा ऑर्डर करणार्‍या सर्व भागीदारांची रहदारी सतत पास करू शकत नाही. त्यामुळे, सामान्य परिस्थितीत, वाहतूक फिल्टर केली जात नाही.

SYN पूर हल्ला आहे असे गृहीत धरू. जरी आपण एखाद्या सेवेची ऑर्डर दिली असेल जी आक्रमण झाल्यास रहदारी स्वयंचलितपणे फिल्टरिंगवर स्विच करते, हे त्वरित होत नाही. एक मिनिट किंवा त्याहून अधिक काळ तुम्ही आक्रमणाखाली रहाल. आणि यामुळे तुमची उपकरणे अयशस्वी होऊ शकतात किंवा सेवेची निकृष्टता होऊ शकते. या प्रकरणात, एज रूटिंगवर रहदारी मर्यादित करणे, जरी या काळात काही टीसीपी सत्रे स्थापित केली जाणार नाहीत या वस्तुस्थितीला कारणीभूत ठरेल, परंतु आपल्या पायाभूत सुविधांना मोठ्या प्रमाणात समस्यांपासून वाचवेल.

उदाहरणार्थ 2

असामान्यपणे मोठ्या संख्येने SYN पॅकेट्स केवळ SYN पूर हल्ल्याचा परिणाम असू शकत नाहीत. समजा तुम्ही अशी सेवा प्रदान करता ज्यामध्ये तुमच्याकडे एकाच वेळी सुमारे 100 हजार TCP कनेक्शन असू शकतात (एका डेटा सेंटरला).

समजा तुमच्या मुख्य प्रदात्यांपैकी एकासह अल्प-मुदतीच्या समस्येचा परिणाम म्हणून, तुमची अर्धी सत्रे बंद झाली आहेत. जर तुमचा अर्ज अशा प्रकारे तयार केला गेला असेल की, दोनदा विचार न करता, तो लगेच (किंवा सर्व सत्रांसाठी समान असलेल्या काही कालावधीनंतर) कनेक्शन पुन्हा स्थापित करण्याचा प्रयत्न करत असेल, तर तुम्हाला अंदाजे किमान 50 हजार SYN पॅकेट्स मिळतील. एकाच वेळी

उदाहरणार्थ, जर तुम्हाला या सत्रांच्या शीर्षस्थानी ssl/tls हँडशेक चालवावा लागेल, ज्यामध्ये प्रमाणपत्रांची देवाणघेवाण समाविष्ट असेल, तर तुमच्या लोड बॅलन्सरसाठी संसाधने कमी करण्याच्या दृष्टिकोनातून, हे साध्यापेक्षा अधिक मजबूत "DDOS" असेल. SYN पूर. असे दिसते की समतोलकर्त्यांनी अशा घटना हाताळल्या पाहिजेत, परंतु ... दुर्दैवाने, आम्हाला अशा समस्येचा सामना करावा लागतो.

आणि, अर्थातच, एज राउटरवरील एक पोलिस या प्रकरणात देखील आपले उपकरण वाचवेल.

DDOS/DOS विरुद्ध संरक्षणाची तिसरी पातळी म्हणजे तुमची फायरवॉल सेटिंग्ज.

येथे तुम्ही दुसऱ्या आणि तिसऱ्या प्रकारचे दोन्ही हल्ले थांबवू शकता. सर्वसाधारणपणे, फायरवॉलपर्यंत पोहोचणारी प्रत्येक गोष्ट येथे फिल्टर केली जाऊ शकते.

टीप

फायरवॉलला शक्य तितके कमी काम देण्याचा प्रयत्न करा, संरक्षणाच्या पहिल्या दोन ओळींवर शक्य तितके फिल्टर करा. आणि म्हणूनच.

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

सर्वसाधारणपणे, मी म्हटल्याप्रमाणे, फायरवॉल ही एक जटिल गोष्ट आहे आणि ती ज्ञात असुरक्षा आणि चाचणी केलेल्या उपायांसह चांगले कार्य करते, परंतु जर तुम्ही काहीतरी असामान्य, फक्त काही कचरा किंवा चुकीच्या शीर्षलेखांसह पॅकेट पाठवले, तर तुम्ही काहींसोबत आहात, सोबत नाही. एवढी लहान संभाव्यता (माझ्या अनुभवावर आधारित), तुम्ही अगदी टॉप-एंड उपकरणे देखील स्तब्ध करू शकता. म्हणून, स्टेज 2 वर, नियमित ACLs वापरून (L3/L4 स्तरावर), फक्त तुमच्या नेटवर्कमध्ये ट्रॅफिकला परवानगी द्या जी तिथे जावी.

फायरवॉलवर रहदारी फिल्टर करणे

चला फायरवॉलबद्दल संभाषण सुरू ठेवूया. तुम्हाला हे समजून घेणे आवश्यक आहे की DOS/DDOS हल्ले हे फक्त एक प्रकारचे सायबर आक्रमण आहेत.

DOS/DDOS संरक्षणाव्यतिरिक्त, आमच्याकडे खालील वैशिष्ट्यांच्या सूचीसारखे काहीतरी देखील असू शकते:

• अनुप्रयोग फायरवॉलिंग
• धोका प्रतिबंध (अँटीव्हायरस, अँटी-स्पायवेअर आणि असुरक्षा)
• URL फिल्टरिंग
• डेटा फिल्टरिंग (सामग्री फिल्टरिंग)
• फाइल ब्लॉकिंग (फाइल प्रकार ब्लॉकिंग)

या सूचीमधून तुम्हाला काय हवे आहे हे ठरविणे तुमच्यावर अवलंबून आहे.

पुढे चालू

स्त्रोत: www.habr.com