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 सुद्धा नाही: बाहेर जाणारी रहदारी टनेलमधून वळवणे आत येण्याच्या अधिकृततेबद्दल काहीही नोंदवत नाही।