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 टनल प्रॉक्सी को गंतव्य और मात्रा देती है, उसके भीतर के पृष्ठ पथ नहीं। नेटवर्क तक प्रशासनिक पहुँच अनुप्रयोग के विश्वास मॉडल को चुपचाप बदलने का लाइसेंस नहीं है।

किसी व्यक्ति का नाम लेने से पहले पहचान और समय जोड़ें

आंतरिक स्रोत पता वाला प्रवाह रिकॉर्ड तब तक कुछ नहीं कहता जब तक वह पता उसी समय किसी सत्र से न जुड़ जाए। पते दोबारा उपयोग होते हैं, और वही पता एक घंटा पहले किसी दूसरे सत्र का हो सकता है। स्थिर आवंटन संबंध बनाए रखने का एक तरीका है, एकमात्र नहीं।

अनुवाद सीमाएँ जोड़ को और कमज़ोर करती हैं। यदि कई डिवाइस आपके अवलोकन बिंदु से पहले ही एक स्रोत पता साझा कर रहे थे, तो आप जो सबसे अच्छा पहचान सकते हैं वह एक डिवाइस नहीं बल्कि साझा गेटवे सत्र है। कई लोगों द्वारा उपयोग किया जाने वाला प्रमाणपत्र या खाता भी वही प्रभाव रखता है।

समय क्षेत्र, घड़ी के स्रोत, अवलोकन बिंदु और हर अनुवाद चरण दर्ज करें। गुम रिकॉर्ड का अर्थ हो सकता है कि कोई प्रवाह प्रविष्टि पुरानी हो गई, कोई सेंसर बचा लिया गया या कोई अनुप्रयोग लॉग बंद था। अनुपस्थिति इस बात का प्रमाण नहीं है कि कुछ नहीं हुआ।

फिर घोषित उद्देश्य के लिए न्यूनतम फ़ील्ड, अनुमत पाठक और प्रतिधारण अवधि परिभाषित करें। सहसंबंध और गलत आरोपण बाद की सोच नहीं बल्कि डिज़ाइन के प्रश्न हैं, और लोगों की पहचान करने वाला मेटाडेटा उस पहचान मैपिंग जितनी ही सुरक्षा का हकदार है जिस पर वह निर्भर है।

अपने नियंत्रण वाली गतिविधि से ऑडिट जाँचें

अनुमत ट्रैफ़िक उत्पन्न करें जिसका सत्र और अनुप्रयोग आप पहले से जानते हैं, फिर देखें कि हर रिकॉर्ड ने वास्तव में क्या कैद किया। पृष्ठ लोड किए बिना खोज करें, कैश से पृष्ठ लोड करें और प्रॉक्सी के माध्यम से कनेक्शन खोलें, और देखें कौन-सी घटनाएँ दिखती हैं।

जिस घटना को प्रमाण सहारा देते हैं उसकी रिपोर्ट करें और बताएँ कि वह क्या कवर नहीं करती। घोषित दायरे वाला साधारण रिकॉर्ड समीक्षा में टिकता है; अनुमानों से बना महत्वाकांक्षी ब्राउज़िंग इतिहास नहीं टिकता।