VPN लॉग ब्राउझिंग इतिहास दाखवू शकतो का? पुरावा काय सिद्ध करतो
सेशन लॉग, रिझॉल्व्हर क्वेरी आणि फ्लो रेकॉर्ड वेगवेगळ्या गोष्टी सिद्ध करतात. प्रश्न निवडा, ओळख आणि वेळ जोडा, आणि फक्त जे दिसले तेच सांगा.
दोन ऑडिट प्रश्न सारखे वाटतात पण त्यांना वेगवेगळ्या प्रकारचा पुरावा लागतो. हा पत्ता कोणत्या सेशनने संपर्क केला हे कनेक्शन आणि फ्लो रेकॉर्डवरून सांगता येते. हे पान कोणत्या व्यक्तीने उघडले हे मात्र सहसा सांगता येत नाही, किमान त्या रेकॉर्डवरून तरी नाही. प्रश्न निवडण्यापूर्वी संग्राहक निवडणे म्हणजे नेटवर्क टीम शेवटी होस्टनाव ब्राउझिंग इतिहास म्हणून सादर करते असे होते.
ऑडिटने ज्या घटनेचा पुरावा द्यायचा आहे तेथून सुरुवात करा
विषय, क्रियापद आणि वेळ असलेल्या वाक्यात प्रश्न लिहा. या एका शिस्तीमुळेच सेशन रेकॉर्ड आणि पान पाहणे यातील अंतर उघड होते. सेशन लॉग हे सिद्ध करतो की एका ओळखीला, ठराविक कालावधीसाठी, नोंदवलेल्या धोरणाखाली दिलेल्या पत्त्यासह स्वीकारले गेले; पण कोणी कोणते पान वाचले हे तो सिद्ध करू शकत नाही, कारण त्याने विनंती कधीच पाहिली नाही.
संग्रहाची रचना करण्यापूर्वी निरीक्षणाला योग्य नाव द्या. पाहिलेल्या साइटचे नाव असलेले फील्ड प्रत्यक्षात रिझॉल्व्ह झालेले नाव साठवत असेल, तर ती सोय नव्हे तर भविष्यातील चूक ठरते. फील्डची नावे ती निवडणाऱ्या लोकांपेक्षा जास्त काळ टिकतात, म्हणून निष्कर्षाऐवजी पुराव्याचे वर्णन करणारी नावे निवडा.
प्रत्येक रेकॉर्ड काय सांगू शकतो आणि काय नाही
जवळपास प्रत्येक ऑडिट रचनेत चार प्रकारचे रेकॉर्ड दिसतात आणि प्रत्येक वेगळ्या प्रश्नाचे उत्तर देतो. अहवालातही आणि पाइपलाइनमध्येही ते वेगळे ठेवा, कारण ते मिसळल्यामुळेच टिकाऊ निष्कर्ष लाजिरवाणा बनतो.
| The question being asked | Record that can answer it | What that record proves | What still needs a join |
|---|---|---|---|
| Was this address contacted? | Flow record | The connection five-tuple and when it was seen | Which session held the address at that moment |
| Which account held that address? | Session log | Which identity authenticated and the tunnel address it received | Which device or person used that account |
| Was this name looked up? | Resolver query | That this resolver was asked for this name | Whether a page was fetched, and by whom |
| Was this page viewed? | Proxy or application transaction | The request and identity recorded inside that application's scope | Traffic outside that application's visibility |
| Who was the person? | None of the four on its own | An account in use, at best | A named human, whenever accounts are shared |
शेवटचा स्तंभ मधल्याइतकाच काळजीपूर्वक वाचा. फ्लो रेकॉर्ड पत्ते आणि पोर्टचे वर्णन करतो, आणि पत्त्याचा रिव्हर्स लुकअप ब्राउझरने वापरलेले नाव पुन्हा तयार करत नाही, कारण एका पत्त्यावर अनेक असंबंधित साइट्स असू शकतात. रिझॉल्व्हर क्वेरी हे सिद्ध करते की प्रश्न विचारला गेला, पान दाखवले गेले हे नाही. TLS चर्चेदरम्यान दिसणारे होस्टनाव हाही कूटबद्ध विनंती मार्ग नाही.
यापैकी प्रत्येक खरे निरीक्षण आहे आणि त्यातले एकही लोक गृहीत धरतात ते निरीक्षण नाही. स्वतःच्या कूटबद्ध रिझॉल्व्हरवर ठाम असणारा ब्राउझर देखरेखीच्या व्याप्तीबाहेर असतो, आणि लॉगिंगने जे पाहिले नाही ते विश्लेषण पुन्हा मिळवू शकत नाही. ही तफावत अहवालात तळटीप नव्हे तर स्पष्ट मर्यादा म्हणून नोंदवली पाहिजे.
अंदाजित लुकअप आणि कॅशेमधील उत्तरे
ब्राउझर आधीच नावे रिझॉल्व्ह करतात, कधीकधी काहीही लोड न करताही. ते कॅशेतून उत्तर देतात आणि तुम्ही पाहत असलेल्या रिझॉल्व्हरकडे नवीन क्वेरी पाठवत नाहीत, म्हणजे क्वेरी नसणे म्हणजे भेट नसणे असे नाही. या दोन्ही वर्तनांमुळे DNS लॉग आणि ब्राउझिंग इतिहास यातील साधे समीकरण कोसळते.
DNS over HTTPS ही दुसरी सीमा जोडते: स्वतःचा रिझॉल्व्हर असलेला ब्राउझर किंवा पाहुणे ॲप्लिकेशन संस्थेच्या लॉगरला काहीही विचारत नाही. नेमकी व्यवहारे फक्त ॲप्लिकेशनच्या स्वतःच्या इव्हेंटमधून किंवा तुम्ही स्पष्टपणे समर्थन देता अशा लॉगिंग असलेल्या प्रॉक्सीमधून मिळतात. साधा HTTPS CONNECT बोगदा प्रॉक्सीला आतल्या पान मार्गांची कोणतीही झलक देत नाही. नेटवर्कचे मालकी हक्क म्हणजे ॲप्लिकेशनचे विश्वास मॉडेल गुपचूप बदलण्याची परवानगी नाही.
पत्ता सेशनचा असतो, व्यक्तीचा नाही
बोगदा-श्रेणीतील पत्ता असलेला फ्लो रेकॉर्ड उत्तर नव्हे तर प्रारंभबिंदू आहे. तो पत्ता आणि वेळेची नोंद त्या क्षणी सक्रिय असलेल्या सेशन नेमणुकीशी जोडा, कारण तोच पत्ता तासाभरानंतर दुसऱ्या सेशनला दिला जाऊ शकतो. स्थिर पत्ते हा तो संबंध टिकवण्याचा एक मार्ग आहे, एकमेव नाही.
जेथे भाषांतराची पायरी सेन्सरच्या वरच्या बाजूला अनेक उपकरणांना एकाच स्रोत पत्त्यात आणते, तेथे जोडणी फक्त सामायिक गेटवे सेशनचे नाव सांगू शकते. सामायिक खाते किंवा अनेक लोक वापरत असलेले प्रमाणपत्र नेटवर्क डेटा कितीही पूर्ण दिसला तरी श्रेय नेमकेपणा मर्यादित करते. दोन्ही अहवालात नंतरच्या सूचना नव्हे तर मर्यादा म्हणून नोंदवा.
वेळ क्षेत्र, घड्याळाचा स्रोत, निरीक्षण बिंदू आणि त्या दरम्यानची प्रत्येक भाषांतर सीमा नोंदवा. अनुपस्थितीकडेही उपस्थितीइतकीच काळजी द्या, कारण रेकॉर्ड नसणे म्हणजे फ्लो नोंद कालबाह्य झाली, सेन्सरने पॅकेट पाहिलेच नाही किंवा ॲप्लिकेशन लॉग बंद होता असे असू शकते.
घोषित हेतूपुरते डिझाइन करा, नंतर पाइपलाइन सिद्ध करा
प्रश्न निश्चित झाल्यावर कोणती फील्डे आवश्यक आहेत, कोण वाचू शकतो आणि किती काळ साठवले जातात हे ठरवा. साठवण सस्ते आहे म्हणून जास्त गोळा करणे हे तपासणीपेक्षा जास्त काळ टिकणारे दायित्व निर्माण करते. RFC 6973 मधील गोपनीयता प्रतिमान सहसंबंध, चुकीचे श्रेय आणि अनावश्यक संग्रह यांना नंतरचे विचार नव्हे तर रचनेचे प्रश्न मानते.
मॅपिंग आणि रेकॉर्ड एकाच वस्तूसारखे सांभाळा, कारण प्रत्येकजण स्वतंत्रपणे जोडीपेक्षा खूपच कमी संवेदनशील असतो. नंतर तुम्हाला परवानगी असलेल्या आणि आधीच समजलेल्या क्रियाकलापावर रचना तपासा, अहवाल अवलंबून राहणार या सर्वात लहान क्वेरीचा वापर करून. ज्ञात घटना पुन्हा निर्माण करू न शकणारी पाइपलाइन अज्ञात घटनाही पुन्हा निर्माण करणार नाही. पुरावा ज्या घटनेला समर्थन देतो तीच घटना, पुरावा ज्या शब्दांना परवानगी देतो त्या शब्दांत नोंदवा, आणि मोठा निष्कर्ष वाचकाने स्वतः काढू द्या.
निष्कर्षाच्या शेजारी मर्यादा लिहा: काय जोडले गेले, काय भाषांतरित झाले आणि कोणता लॉग शांत राहिला. स्वतःच्या सीमा सांगणारा निष्कर्ष आत्मविश्वासू सारांश टिकू न शकणारी चाचणी टिकतो. पुरावा आणि पुराव्याविषयीची गोष्ट यातील हाच फरक आहे.