तुमचा VPN गेटवे तड्यात आहे: प्रत्यक्षात काय उघड आहे
हॅक झालेला VPN गेटवे स्वतःच्या बोगद्यात पाहतो, पण याचा अर्थ प्रत्येक सत्रावर ताबा नाही. पुनर्प्राप्तीपूर्वी रहदारी, पोहोच आणि साठवलेली रहस्ये वेगळी करा.
VPN गेटवे ज्या बोगद्याचे तो संरक्षण करतो त्याच्या शेवटी असतो, म्हणजे तो ते एन्क्रिप्शन संपवतो, पुढे जाऊ देत नाही. जर हल्लेखोराने होस्ट नियंत्रित केला, तर बोगदा बाहेरून निरोगी दिसत राहतो, पण मधली मशीन आता विश्वासार्ह नाही. उपयुक्त प्रश्न हा नाही की सर्व काही डिक्रिप्ट होते का. प्रश्न असा आहे की त्या होस्टला काय दिसू शकले, तो कुठपर्यंत पोहोचू शकला, आणि कोणती रहस्ये खरोखर त्यावर साठवलेली होती. ही तीन उत्तरे खूप वेगळी आहेत, आणि प्रतिसादही त्यांच्यासोबत वेगळा असतो.
गेटवे बोगदा संपवतो, म्हणून आत पाहतो
VPN मध्ये एन्क्रिप्शन हॉपमागून हॉप होते, आणि गेटवे तो हॉप आहे. तो बाहेरील थर काढतो, धोरण लागू करतो आणि आतील पॅकेट पुढे पाठवतो, त्यामुळे वाहून नेलेले प्रत्येक पॅकेट कधीतरी त्या होस्टच्या स्मृतीत वाचनीय स्वरूपात असते. हा दोष नाही, रचना आहे. त्यामुळेच गेटवे तड्यात जाणे ही बोगद्याच्या क्रिप्टोग्राफीच्या तड्यापेक्षा वेगळी घटना आहे.
हल्लेखोराला प्रथम जे मिळते ते म्हणजे स्थान: वाहून नेलेल्या रहदारीचे निरीक्षण करणे, पाठवण्याची पद्धत बदलणे, किंवा बॅकएंडऐवजी उत्तर देण्याची क्षमता. पुढे त्याला काय मिळते ते होस्टवर अवलंबून असते, आणि इथेच लोक जास्त अंदाज लावतात. फक्त गेटवेपर्यंत प्रवेश ब्राउझरच्या TLS सत्र किल्ल्या देत नाही, कारण त्या कधीच गेटवेवर नव्हत्या.
समान आकाराच्या नसलेल्या तीन उघडी
प्रश्नाचे वाहून नेलेली रहदारी, पोहोचण्यायोग्य प्रणाली आणि साठवलेली रहस्ये असे विभाजन करा, नंतर प्रत्येकाला स्वतंत्रपणे उत्तर द्या.
| Exposure | What the attacker gains | What does not follow |
|---|---|---|
| Carried traffic | Plaintext of whatever the tunnel forwards without its own encryption | Keys for TLS sessions that terminate at the application |
| Reachable systems | Whatever the backends accept from the gateway's address | Control of every connected client endpoint |
| Stored secrets | The specific keys, tokens and accounts present on that host | Possession of every client certificate or of a CA key |
मधली ओळच वगळली जाते. गेटवेकडे सामान्यतः खाजगी नेटवर्कमध्ये जाणारा मार्ग आणि बॅकएंड आधीच विश्वास ठेवत असलेला स्रोत पत्ता असतो, त्यामुळे मनोरंजक प्रश्न असा आहे की ते बॅकएंड त्या पत्त्यावरून काय परवानगी देतात. अरुंद क्लायंट-प्रवेश धोरण चांगले नियंत्रण आहे, पण होस्टवरील हल्लेखोर सामान्य क्लायंट वापरेल त्या इंटरफेसपुरता मर्यादित नाही.
खालची ओळ घटना किती काळ टिकेल हे ठरवते. सर्व्हर किल्ली आणि CA किल्लीचा प्रभावव्याप्ती पूर्णपणे वेगळा आहे, आणि तसाच स्थानिक प्रशासक खाते आणि फक्त-वाचन देखरेख टोकनचाही.
बोगद्यातील HTTPS अजूनही HTTPS आहे
अॅप्लिकेशनचे TLS अॅप्लिकेशनमध्ये संपते, VPN गेटवेवर नाही, त्यामुळे तड्यात गेलेला गेटवे त्या प्रवाहांसाठी फक्त सायफरटेक्स्ट पाहतो. हल्लेखोराला काय मिळते यावर ही खरी मर्यादा आहे, आणि ती स्पष्टपणे सांगण्यासारखी आहे, कारण उलटा दावा भीती आणि वाईट निर्णय पसरवतो. दोन अटी हे तोडतात. जर मार्गात विश्वासार्ह प्रमाणपत्र असलेला तपासणी घटक असेल, तर गेटवे रचनेनुसार साधा मजकूर पाहू शकतो. जर अॅप्लिकेशनचा शेवटचा बिंदूच तड्यात गेला असेल, तर बोगदा अप्रासंगिक आहे.
म्हणून त्यांनी काय पाहिले याचे उत्तर सशर्त आहे, आणि ते निवाडा म्हणून जाहीर करण्याऐवजी अटी म्हणून लिहावे.
पुन्हा विश्वास ठेवण्यापूर्वी काय बदलले पाहिजे
होस्ट पुन्हा बांधणे आवश्यक आहे आणि क्वचितच पुरेसे. ज्या हल्लेखोराकडे अजूनही व्यवस्थापन खाते, तैनाती क्रेडेन्शियल किंवा स्वाक्षरी किल्ली आहे तो होस्ट आपल्या इच्छेप्रमाणे परत आणू शकतो. पुनर्प्राप्ती अशा प्रशासकीय मार्गाने सुरू झाली पाहिजे जो तड्यात गेलेल्या मशीनवर अवलंबून नाही.
काय फिरवायचे हे ठरवण्यापूर्वी त्यावर काय होते याची यादी करा. किल्ल्या, सेवा खाती, API टोकन, स्थानिक वापरकर्ते, नियोजित कामे, विश्वास संबंध आणि तैनाती पाइपलाइन सर्व उमेदवार आहेत, आणि प्रत्येकाचा एक मालक आहे ज्याने ते पुष्टी केली पाहिजे.
ss -lntup
getent passwd
crontab -l
ip route show table allती यादी होस्ट काय देत होता आणि कुठपर्यंत पोहोचू शकत होता हे पाहण्याचा सर्वात वेगवान मार्ग आहे. प्रथम पुरावे जतन करा, प्रतिसाद मालकाच्या प्रक्रियेनुसार, कारण पुनर्बांधणी तपासणीला आवश्यक असलेलेच नष्ट करते. NIST SP 800-61 सुधारणा 3 तयारी, शोध, प्रतिसाद आणि पुनर्प्राप्ती यांना पुन्हा सुरू करण्याच्या सूचनेऐवजी एका जोखीम प्रक्रियेचे भाग मानते.
पुढील घटना स्वस्त करणाऱ्या सीमा
चार सीमा गरजेपूर्वी बांधणे योग्य आहे. गेटवेमार्फत प्रमाणीकरण न करणारा स्वतंत्र पुनर्प्राप्ती मार्ग ठेवा. स्वाक्षरी अधिकार रहदारी सेवा देणाऱ्या होस्टपासून वेगळा ठेवा. गेटवे कुठपर्यंत पोहोचू शकतो हे मर्यादित करा, जेणेकरून तड्यात गेलेला गेटवे आपोआप तड्यात गेलेले व्यवस्थापन नेटवर्क होणार नाही. आणि प्रत्येक क्रेडेन्शियल कोणाचे आहे ते नोंदवा, जेणेकरून फिरवणे पुरातत्व प्रकल्प नाही तर एक फोन कॉल होईल.
यापैकी काहीही तडा रोखत नाही. ते त्याला मर्यादित करतात, आणि वाईट आठवडा आणि वाईट तिमाही यातील फरक करतात.