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 भी नहीं: सुरंग से बाहर जाने वाला ट्रैफ़िक भेजना आने वाले प्राधिकरण के बारे में कुछ दस्तावेज़ित नहीं करता।