VPN लॉग ब्राउझिंगबद्दल काय सिद्ध करू शकतो आणि काय करू शकत नाही

लॉग संग्राहक निवडण्यापूर्वी ऑडिटने कोणती घटना प्रस्थापित करायची आहे ते ठरवा। कोणत्या VPN सत्राने गंतव्य पत्त्याशी संपर्क साधला हे विचारणे, कोणत्या व्यक्तीने विशिष्ट पृष्ठ उघडले हे विचारण्यापेक्षा वेगळा प्रश्न आहे। दोन्हींना वेगळ्या नोंदी, वेगळ्या जोडण्या आणि वेगळ्या स्तराचा विश्वास लागतो। OpenVPN कनेक्शन लॉग पहिल्याचे उत्तर देतो आणि दुसऱ्याचे देऊ शकत नाही।

संग्राहक निवडण्यापूर्वी घटनेला नाव द्या

सत्र नोंद स्वीकारलेली ओळख, सुरुवात व शेवटची वेळ आणि सर्व्हरने स्वतःच्या धोरणानुसार दिलेला पत्ता दाखवते। रिसॉल्व्हर लॉग त्या रिसॉल्व्हरवर नाव विचारले गेले हे दाखवतो। प्रवाह नोंद पत्ते, पोर्ट, प्रोटोकॉल आणि वेळ दाखवते, आणि अनुप्रयोग लॉग त्या अनुप्रयोगाने प्रत्यक्षात हाताळलेला व्यवहार दाखवतो। या चारपैकी कोणतीही दुसऱ्याची जागा घेत नाही।

त्यातील प्रत्येक एक घटना प्रस्थापित करते आणि उर्वरित उघडी ठेवते। प्रश्न आधी लिहून ठेवल्यास डेटा पुरवठा करू शकत नाही अशी कथा रचण्यापासून तुम्ही थांबता।

journalctl -u [email protected] --since today | grep -i 'peer info\|assigned'
cat /etc/openvpn/server/openvpn-status.log | head -20
conntrack -L -p tcp --dport 443 2>/dev/null | head -20

पहिला आदेश सेवा जर्नलमधून सत्र घटना दाखवतो। दुसरा वाटप केलेल्या पत्त्यांसह सध्याची क्लायंट यादी छापतो, हेच ते मॅपिंग आहे ज्यावर ऑडिट जोडणी अवलंबून असते। तिसरा कनेक्शन अस्तित्वात असेपर्यंतच उपयुक्त असलेली थेट प्रवाह स्थिती दाखवतो।

शोध ही भेट नाही

ब्राउझर नावे अनुमानाने सोडवतो, उत्तरे कॅशे करतो आणि देखरेखीखालील रिसॉल्व्हरला पुन्हा न विचारता त्यांचा पुनर्वापर करतो। त्यामुळे रिसॉल्व्हर लॉगमधील नाव शोध सिद्ध करते, भेट नाही। HTTPS वरून DNS हे अंतर वाढवते, कारण त्यासाठी संरचित केलेला ब्राउझर त्याचे प्रश्न तुमचा नेहमीचा लॉगर कधीही न पाहणाऱ्या ठिकाणी पाठवतो।

गंतव्य पत्ते स्वतःहून चांगले नसतात। एक पत्ता अनेक असंबंधित साइट्स होस्ट करू शकतो, रिव्हर्स DNS पुनर्रचना नाही तर अंदाज आहे, आणि TLS हातमिळवणीदरम्यान दिसणारे होस्टनाव एन्क्रिप्टेड सत्रातील विनंती मार्ग नाही।

अचूक व्यवहारांसाठी तुम्हाला अनुप्रयोगाच्या स्वतःच्या घटना नोंदी किंवा लॉगिंगसाठी स्पष्टपणे समर्थित प्रॉक्सी रचना लागते। CONNECT बोगदा प्रॉक्सीला गंतव्य आणि आकारमान देतो, आतील पृष्ठ मार्ग नाही। नेटवर्कवर प्रशासकीय प्रवेश हा अनुप्रयोगाचे विश्वास मॉडेल गुपचूप बदलण्याचा परवाना नाही।

व्यक्तीचे नाव घेण्यापूर्वी ओळख आणि वेळ जोडा

अंतर्गत स्रोत पत्ता असलेली प्रवाह नोंद त्या पत्त्याची त्याच वेळी सत्राशी जोडणी होईपर्यंत काहीही अर्थ देत नाही। पत्ते पुन्हा वापरले जातात, आणि तोच पत्ता एका तासापूर्वी वेगळ्या सत्राचा असू शकतो। स्थिर वाटप हा संबंध टिकवण्याचा एक मार्ग आहे, एकमेव नाही।

भाषांतराच्या सीमा जोडणी अधिक कमकुवत करतात। जर अनेक उपकरणांनी तुमच्या निरीक्षण बिंदूपूर्वीच एक स्रोत पत्ता सामायिक केला असेल, तर तुम्ही ओळखू शकता ती सर्वोत्तम गोष्ट एक उपकरण नाही तर सामायिक गेटवे सत्र आहे। अनेक लोक वापरत असलेले प्रमाणपत्र किंवा खातेही तोच परिणाम करते।

वेळ क्षेत्रे, घड्याळाचे स्रोत, निरीक्षण बिंदू आणि प्रत्येक भाषांतर पायरी नोंदवा। गहाळ नोंदींचा अर्थ प्रवाह नोंद जुनी झाली, सेन्सर टाळला गेला किंवा अनुप्रयोग लॉग बंद होता असा असू शकतो। अनुपस्थिती हा काहीच घडले नाही याचा पुरावा नाही।

नंतर जाहीर केलेल्या उद्देशासाठी किमान क्षेत्रे, परवानगी असलेले वाचक आणि धारण कालावधी परिभाषित करा। सहसंबंध आणि चुकीचे आरोपण हे नंतरची विचारसरणी नाही तर रचनेचे प्रश्न आहेत, आणि लोकांची ओळख करणारा मेटाडेटा ज्या ओळख मॅपिंगवर तो अवलंबून आहे त्याइतकेच संरक्षणास पात्र आहे।

तुम्ही नियंत्रित करता त्या कृतीने ऑडिट तपासा

ज्यांचे सत्र आणि अनुप्रयोग तुम्हाला आधीच माहीत आहे अशी परवानगी असलेली रहदारी तयार करा, नंतर प्रत्येक नोंदीने प्रत्यक्षात काय टिपले हे तपासा। पृष्ठ न लोड करता शोध करा, कॅशेतून पृष्ठ लोड करा आणि प्रॉक्सीमधून कनेक्शन उघडा, आणि कोणत्या घटना दिसतात ते पहा।

पुरावे ज्या घटनेला पाठबळ देतात ती नोंदवा आणि ते काय व्यापत नाहीत ते सांगा। जाहीर केलेल्या व्याप्तीसह साधी नोंद पुनरावलोकनात टिकते; अंदाजांतून रचलेला महत्त्वाकांक्षी ब्राउझिंग इतिहास टिकत नाही।