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

पॅकेट डिक्रिप्शननंतर काढा, आधी नाही

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

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

  1. दूरस्थ क्लायंट: टनेल तयार करणारे वापरकर्त्याचे उपकरण.
  2. किनारा धोरण: बाह्य वाहतूक सार्वजनिक लिसनरकडे स्वीकारणारा नियमसंच.
  3. संपवणारे उपकरण: पॅकेट डीकॅप्स्युलेट करून सामान्य IP ला देणारा VPN अंतिम टप्पा.
  4. अंतर्गत फिल्टर: क्लायंटपासून सेवेपर्यंतची वाहतूक मर्यादित करणारा फॉरवर्डिंग किंवा सुरक्षा-गट नियमसंच.
  5. अनुप्रयोग होस्ट: डिक्रिप्ट केलेली विनंती घेणारी सेवा.

दोन धोरणे, दोन मालक

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

प्रमाणपत्रे आणि बहु-घटक प्रमाणीकरण यांसारखे प्रवेश नियंत्रण ओळखीचे उत्तर देतात आणि दुसरे काही नाही. ते स्थान ठरवत नाहीत, आणि वापरकर्ता आत आल्यानंतर संसाधनानुसार परवानगी देत नाहीत.

स्थान ठरवते की विनंती कोणती सीमा ओलांडते

तीन स्थाने सामान्य आहेत, आणि प्रत्येक डिक्रिप्ट केलेली विनंती कोणती सीमा ओलांडते हे बदलते. तिथे काय संपते, काय स्पष्ट मजकूर पाहू शकते, कोणते नियंत्रण अजूनही विनंती नाकारू शकते, आणि उपकरणासोबत काय अयशस्वी होते यावर आधारित त्यांची तुलना करा. खालील तक्ता सामान्य प्रश्नाऐवजी ते चार स्तंभ वापरतो, कारण प्रत्येक उत्तर स्वतंत्र रचना निर्णय आहे.

PlacementWhat terminates thereWhat sees plaintextWhich control can still denyFailure domain
Termination in a dedicated segmentA dedicated VPN endpointThe endpoint and anything on its segmentThe filter between that segment and the applicationThe segment path can bypass the filter if no rule sits on it
Termination on the edge firewallThe firewall's public listenerThe firewall, after decapsulationThe firewall's inner rule setAdmission and inspection fail together
Termination on the protected LANThe appliance's LAN legEvery host on the protected LANOnly a host control or a downstream gatewayThe appliance and the protected hosts fail together

तिसरे स्थान हेच अंमलबजावणी शांतपणे काढून टाकते, कारण संरक्षित विभागावरील भाग उपकरणाला आकृती दाखवणार नाही अशी थेट वाट देतो. चित्राऐवजी इंटरफेस आणि मार्ग तपासा: ip route get 10.20.5.10 पॅकेट कोणत्या इंटरफेसने बाहेर पडेल हे सांगतो, आणि उत्तर बहुतेक वेळा रचनेने गृहीत धरलेले नसते. पोस्चरमधील वाहतूक नियंत्रित करण्याची फायरवॉलची पारंपरिक भूमिका, खालील दस्तऐवजात वर्णन केल्याप्रमाणे,NIST SP 800-41 येथे उपयुक्त चाचणी आहे, कारण संरक्षित नेटवर्ककडे अमर्यादित भाग असलेले उपकरण फारसे नियंत्रित करत नाही. मार्ग शोध हा सादरीकरणातील आकृतीपेक्षा अधिक प्रामाणिक आकृती आहे.

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

भाषांतर बदलते की खालील नियम काय पाहू शकतात

स्रोत भाषांतर सोयीचे आहे आणि ते माहिती नष्ट करते. masquerade नंतर प्रत्येक क्लायंट उपकरणासारखा दिसतो, त्यामुळे वापरकर्ते वेगळे करण्यासाठी लिहिलेला खालील नियम आता ते करू शकत नाही. ही केवळ लॉगिंगची समस्या नाही, ही धोरणाची समस्या आहे: क्लायंट पत्त्यावर किल्ली केलेला नियम शांतपणे गेटवेवर किल्ली केलेला नियम बनतो. वापरकर्तानिहाय धोरण महत्त्वाचे असल्यास, स्रोत जपा किंवा भाषांतरापूर्वी धोरण लागू करा.

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

sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTING

परवानगी दिलेली आणि नाकारलेली क्रिया स्वीकारा

व्यवस्थापन होस्टऐवजी खऱ्या दूरस्थ क्लायंटवरून चाचणी करा, कारण व्यवस्थापन होस्ट सहसा वापरकर्ता कधीही न जाणार्या ठिकाणी बसतो. एक परवानगी दिलेली क्रिया मार्ग कार्यरत असल्याचे सिद्ध करते, आणि एक नाकारलेली क्रिया धोरण अजिबात काहीतरी करत असल्याचे सिद्ध करते. प्रत्येक स्थान बदलानंतर दोन्ही चालवा, आणि वापरलेली स्रोत ओळख व गंतव्य नोंदवा. केवळ यश सिद्ध करणारी चाचणी योग्य नियमाला गहाळ नियमापासून वेगळे करू शकत नाही.

नंतर स्थिती बदलणारी प्रकरणे तपासा: पुन्हा कनेक्ट होणे, किल्ली फिरण्यापुढे टिकणारे सत्र, आणि उपकरणाचाच बिघाड. अद्ययावत, क्षमता आणि पुनर्प्राप्ती यांची त्याच मांडणीचा भाग म्हणून तुलना करा, कारण अनेक तार्किक नियंत्रणे वाहणारे एक उपकरण अनेक लेबल असलेले एकच अयशस्वी क्षेत्र आहे. सामायिक प्रशासकीय क्रेडेन्शियल किंवा अमर्यादित मार्गाने तयार करायच्या सीमेचा पराभव केल्यास दुसरे बॉक्सही स्वतंत्र नाही.

अंतिम टप्पा, डिक्रिप्ट केलेला मार्ग आणि तो मर्यादित करणारे नियंत्रण यांचे दस्तऐवजीकरण करा. त्या तीन ओळी अंमलबजावणीला काहीही नाव दिले तरी अर्थपूर्ण राहतात.

संबंधित लेख