VPN सर्भरमा आउने सूचना: अवलोकन बिन्दु पढ्नुहोस्

VPN पछाडिको सर्भरले आफ्ना सार्वजनिक सेवा-प्रविष्टिहरू राख्छ, र मानिसहरूले ती भेट्टाइरहन्छन्। सूचनाको लाममा आउने कुरा एउटा मात्र भेट होइन, तीन सम्भावित भेट हुन्, र तिनको अर्थ फरक हुन्छ। पहिलो काम भनेको खुला भएको सेवालाई खुला भएको लगइन विवरणबाट छुट्याउनु हो।

अवलोकन बिन्दुहरूलाई क्रमैसँग हेर्नुहोस्। प्रमाणले आफ्नो वर्ग परिवर्तन गरेपछि रोक्नुहोस्, किनकि अर्को चरणले फरक प्रश्नको उत्तर दिन्छ।

पहिलो चरण: क्याप्चरले वास्तवमा के देख्यो

प्याकेट क्याप्चरले बाटोमा आफ्नै बिन्दुमा देखिएको कुरा अभिलेख गर्छ। त्यो बिन्दु पछिको फिल्टरिङ निर्णयभन्दा अघि पर्न सक्छ। समातिएको प्याकेटले ट्राफिक त्यहाँ पुग्यो भन्ने प्रमाण दिन्छ। त्यसपछि के भयो भन्ने कुरामा यसले केही पनि प्रमाण दिँदैन।

इन्टरफेस पनि नोट गर्नुहोस्। सार्वजनिक एडाप्टरमा गरिएको क्याप्चर र सुरुङभित्र गरिएको क्याप्चरले फरक आगमन बिन्दु देखाउँछन्, र गलत बिन्दु उल्लेख गर्ने सूचनाले गलत निष्कर्षतिर डोर्याउँछ।

Windows ले स्ट्याकका धेरै तहमा फिल्टर गर्छ, त्यसैले क्याप्चर उपकरण दोस्रो तहमा र फायरवाल तेस्रो तहमा बस्छ भन्ने सफा मोडेल वास्तविक उत्पादनसँग भेटिँदा टिक्दैन। Windows Filtering Platform को अवलोकनले स्ट्याकका तहहरूभरि फिल्टरिङको वर्णन गर्छ, त्यसैले अवलोकनको क्रम अनुमान गर्नु होइन, स्थापित गर्नुपर्छ।

दोस्रो चरण: ड्रप अभिलेखले के स्थापित गर्छ

ड्रप अभिलेखले नीतिको सीमाले त्यो प्याकेट अस्वीकार गर्यो भन्छ। यो बलियो प्रमाण हो। यो साँघुरो पनि छ, किनकि यसले एउटा सीमामा एउटा निर्णय मात्र समेट्छ। स्ट्याकमा अरू केही पनि यसले वर्णन गर्दैन।

टुपल र समय-छापमा मिलाउनुहोस्। उही स्रोत, उही गन्तव्य, उही पोर्ट, उही सेकेन्डभित्र। त्यस्तो मिलान नभए अर्को लगमा देखिने समान घटना केवल अर्को घटना हो, र तिनलाई जोड्दा कसैले पनि रक्षा गर्न नसक्ने कथा बन्छ।

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

बन्द पोर्ट र अस्वीकार गरिएको प्याकेट बाहिरबाट उस्तै देखिन्छन् र यी दुई आउटपुटमा पूर्ण रूपमा फरक हुन्छन्। स्थानीय अभिलेख पढ्नुको पूरै कारण त्यही भिन्नता हो।

तेस्रो चरण: प्रमाणीकरण घटनाले के प्रमाण दिन्छ

प्रमाणीकरण घटनाले कुनै कम्पोनेन्टले नतिजा अभिलेख गर्नेसम्म अनुरोध प्रशोधन गर्यो भन्छ। तीन चरणमध्ये यसले मात्र पहिचानको कुरा गर्छ, र यसअघि कति प्याकेट आए भन्ने कुरा केही पनि बताउँदैन।

घटनाको वास्तविक सन्दर्भ पढ्नुहोस्। नभएको खाताको लागि असफल लगइन स्क्यानिङको हल्ला हो। विश्वसनीय स्रोतसहितको वास्तविक खाताको लागि असफल लगइन फरक प्राथमिकता हो। सफल सत्र पूर्ण रूपमा फरक घटना-वर्ग हो।

प्रोटोकलका नाम पनि हेर्नुहोस्। RPC र RDP फरक पोर्ट भएका छुट्टाछुट्टै सेवा हुन्। तीमध्ये एउटालाई मात्र हेर्ने डिटेक्टरले अर्कोलाई समेट्दैन। सञ्जाल गतिविधि संक्षेप गर्ने उपकरणहरूले घटना ती दुईमध्ये कसले उत्पन्न गर्यो भन्ने सधैं बताउँदैनन्।

एउटा मिलाइएको नमुना ड्यासबोर्डभन्दा बलियो

एउटा अधिकृत परीक्षण छान्नुहोस्, जानाजान चलाउनुहोस्, र सुरुदेखि अन्त्यसम्म पछ्याउनुहोस्: गन्तव्य ठेगाना र इन्टरफेस, वास्तविक स्रोत ठेगाना, सेवा पोर्ट, प्रभावकारी फायरवाल प्रोफाइल र नियम, र मिल्ने सेवा-नतिजा। त्यो शृंखलामा माथिल्लो तहको म्यापिङ वा क्लाउड फायरवाल पनि समावेश गर्नुहोस्, किनकि त्यहाँको अनुमति दिने नियमले सफा स्थानीय नियमलाई पन्छाउन सक्छ।

त्यसपछि दुई जिम्मेवारी छुट्याउनुहोस्। प्रशासन VPN मार्फत मात्र हुनुपर्ने हो भने सार्वजनिक र सुरुङ दुवै बाटोमा लागू गर्नुहोस् र स्वीकृत पुनःप्राप्ति बाटो राख्नुहोस्। अस्वीकार गरिएको प्रयास निगरानी गर्नु सर्भरले के स्वीकार्नुपर्छ भनी निर्णय गर्नुसँग एउटै काम होइन।

भौगोलिक नियम वा अवरुद्ध असम्बन्धित प्रोटोकलले अवलोकन गरिएको प्रविष्टि र त्यसले पाएको निर्णय खोज्ने विकल्प होइन। VPN पनि होइन: बाहिर जाने ट्राफिक सुरुङबाट पठाउनुले भित्र आउने अधिकारबारे केही पनि अभिलेख गर्दैन।