کیا 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 میں رازداری کا ماڈل باہمی تعلق، غلط نسبت اور غیر ضروری جمع آوری کو بعد کی سوچ نہیں بلکہ ڈیزائن کے مسائل قرار دیتا ہے۔
نقشہ اور ریکارڈ کو ایک ہی شے کے طور پر بچائیں، کیونکہ ہر ایک اکیلا جوڑی سے کہیں کم حساس ہے۔ پھر ڈیزائن کو اُس سرگرمی کے خلاف جانچیں جسے پیدا کرنے کی آپ کو اجازت ہے اور جسے آپ پہلے ہی سمجھتے ہیں، وہ سب سے چھوٹا استفسار استعمال کرتے ہوئے جس پر رپورٹ کا انحصار ہوگا۔ معلوم واقعے کو دوبارہ پیدا نہ کر سکنے والی پائپ لائن نامعلوم واقعے کو بھی دوبارہ پیدا نہیں کرے گی۔ ثبوت جس واقعے کی تائید کرتا ہے وہی واقعہ، ثبوت کے دیے گئے الفاظ میں بیان کریں، اور بڑا نتیجہ قاری خود نکالنے دیں۔
نتیجے کے ساتھ حدود لکھیں: کیا جوڑا گیا، کیا ترجمہ ہوا، اور کون سا لاگ خاموش رہا۔ اپنی حدود بیان کرنے والا نتیجہ وہ جائزہ برداشت کرتا ہے جو خود اعتماد خلاصہ برداشت نہیں کر سکتا۔ ثبوت اور ثبوت کے بارے میں کہانی کا فرق یہی ہے۔