EC2 साठी फक्त-VPN नियम: जोडलेल्या प्रत्येक सुरक्षा गटाने सहमती द्यायला हवी

तुम्ही VPN क्लायंट पूलसाठी एक इनबाउंड नियम जोडता, काहीही काढत नाही, तरीही सेवा इंटरनेटवरून पोहोचण्यायोग्य आहे. काहीही तुटलेले नाही. सुरक्षा गटात अशी कोणतीही ओव्हरराइड, प्राधान्य किंवा अंतिम नकार नाही ज्यावर अरुंद नियम जिंकू शकेल. इन्स्टन्सला जोडलेला प्रत्येक गट आपल्या परवानग्या एका एकत्रित संचात जोडतो, आणि तुम्ही विसरलेला व्यापक नियम अजूनही त्या संचात आहे. इन्स्टन्सला फक्त-VPN करणे म्हणजे सर्वांचे ऑडिट करणे, एकात चांगला वाटणारा नियम जोडणे नाही.

नियम लिहिण्यापूर्वी सेवा लिहा

अचूक गंतव्य, प्रोटोकॉल आणि पोर्टपासून सुरुवात करा, आणि सेवा प्रत्यक्षात ज्या नेटवर्क इंटरफेसवर ऐकते त्या इंटरफेसपासूनही. अनेक इंटरफेस किंवा एका पोर्टवर अनेक सेवा असलेल्या इन्स्टन्ससाठी प्रत्येक इंटरफेससाठी ऑडिट आवश्यक आहे, कारण जोडलेले गट वेगळे असू शकतात. नंतर ठरवा तो इंटरफेस VPN वापरकर्त्यासाठी प्रत्यक्षात कोणता स्रोत पत्ता घेतो, क्लायंट त्याच्या स्वतःच्या कनेक्शन विंडोमध्ये दाखवतो तो पत्ता नाही.

भाषांतर आणि राउटिंग सामील झाल्यावर हे दोन पत्ते लोक अपेक्षा करतात त्यापेक्षा जास्त वेळा वेगळे होतात.

तीन स्रोत मॉडेल, तीन वेगळे नियम

खाजगी राउटेड प्रवेशासह, मार्ग कसा राउट आणि भाषांतरित होतो यावर अवलंबून इन्स्टन्सला क्लायंट पूल किंवा कॉर्पोरेट श्रेणी मिळते. कॉर्पोरेट एग्रेसद्वारे पोहोचल्या जाणाऱ्या सार्वजनिक एंडपॉइंटवर, इन्स्टन्स त्याऐवजी कॉर्पोरेट NAT पत्ता पाहतो, आणि ते गंतव्य प्रत्यक्षात VPN मार्ग वापरत असेल तरच, कारण स्प्लिट टनेलिंग ते घरच्या कनेक्शनवर ठेवू शकते. व्यवस्थापित Client VPN एंडपॉइंटवर, दस्तऐवजीकृत असोसिएशन आणि लक्ष्य-नेटवर्क मॉडेल लागू होते, आणि क्लायंट पत्ता कॉन्फिगर केलेल्या क्लायंट CIDR मधून येतो.

जे चालत नाही ते म्हणजे VPN गेटवे सुरक्षा गटाचा स्रोत म्हणून संदर्भित करणे. गट संदर्भ VPC किंवा पीअर केलेल्या नेटवर्कमधील लवचिक नेटवर्क इंटरफेसशी जुळतात, आणि पॅकेट पुढे पाठवणारा गेटवे त्यापैकी एक नाही.

प्रत्येक जोडलेल्या गटातील संघ वाचा

इन्स्टन्स उघडा, त्याचा नेटवर्क इंटरफेस शोधा, आणि त्याला जोडलेला प्रत्येक सुरक्षा गट सूचीबद्ध करा. प्रत्येकासाठी, तुमचा प्रोटोकॉल आणि पोर्ट व्यापणारा प्रत्येक नियम तपासा, विस्तृत पोर्ट श्रेणी आणि दोन्ही पत्ता कुटुंबांसह. 0.0.0.0/0 वरून IPv4 नियम तुम्हाला ::/0 तपासण्यापासून सूट देत नाही, आणि सर्व रहदारीला परवानगी देणारा नियम पोर्टचा प्रश्न पूर्णपणे लपवतो. या यादीनंतरच सेवेसाठी प्रभावी परवानगी काय आहे हे तुम्ही सांगू शकता.

AWS नियम संदर्भ सुरक्षा गटांना फक्त-परवानगी देणारे असे वर्णन करतो आणि सांगतो की सर्व जोडलेल्या गटांचे नियम एकत्रित केले जातात, आणि हाच या अपयशामागील संपूर्ण यंत्रणा आहे.

नेटवर्क ACL ही क्रमबद्ध परवानगी आणि नकार नोंदी असलेली स्वतंत्र, स्थितीहीन धोरणे आहेत, आणि त्यांचे मूल्यांकन इन्स्टन्सवर नाही तर सबनेटवर होते.

नकाराच्या भिंतीने उत्तर देऊ नका

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

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

नवीन सत्रासह चाचणी करा आणि आत येण्याचा मार्ग ठेवा

कोणतीही विद्यमान परवानगी काढून टाकण्यापूर्वी मंजूर स्वतंत्र प्रशासकीय मार्ग निश्चित करा, कारण तुम्ही हटवणार असलेला नियम हाच तुमच्या सत्र पुनर्प्राप्तीचा आधार असू शकतो. नंतर VPN वरून नवीन परवानगी दिलेले कनेक्शन आणि मंजूर बिगर-VPN चाचणी मार्गावरून नवीन नाकारलेले कनेक्शन तपासा. विद्यमान ट्रॅक केलेली सत्रे नियम बदल सहन करतात अशा प्रकारे की जुनी उघडी शेल स्वीकृतीचा पुरावा म्हणून निरुपयोगी होतात.

शेवटी, अनुप्रयोगाचे स्वतःचे अधिकृतता तिच्या जागी ठेवा. भाषांतरित कॉर्पोरेट एग्रेस शेकडो लोकांचे प्रतिनिधित्व करू शकतो, आणि नेटवर्क प्रवेशाने कधीही वैयक्तिक वापरकर्ता किंवा त्याचे डिव्हाइस ओळखले नाही.