आपका 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 तैयारी, पहचान, प्रतिक्रिया और रिकवरी को एक जोखिम प्रक्रिया के भाग मानता है, रीस्टार्ट निर्देश के रूप में नहीं।
ऐसी सीमाएँ जो अगली घटना को सस्ता बनाएँ
चार सीमाएँ ज़रूरत पड़ने से पहले बनाना उचित है। ऐसा स्वतंत्र रिकवरी मार्ग रखें जो गेटवे से प्रमाणीकरण न करे। साइनिंग अधिकार को ट्रैफ़िक परोसने वाले होस्ट से अलग रखें। सीमित करें कि गेटवे कहाँ तक पहुँच सकता है, ताकि समझौते में आया गेटवे अपने आप समझौते में आया प्रबंधन नेटवर्क न बने। और दर्ज करें कि हर क्रेडेंशियल किसका है, ताकि घुमाना पुरातत्व परियोजना नहीं, एक फ़ोन कॉल हो।
इनमें से कोई भी समझौते को नहीं रोकता। ये उसे सीमित करते हैं, और खराब सप्ताह तथा खराब तिमाही के बीच अंतर बनाते हैं।