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