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 লগ আর ব্রাউজিং ইতিহাসের মধ্যেকার সরল সমীকরণ ভেঙে দেয়।
HTTPS-এর ওপর DNS একটি দ্বিতীয় সীমা যোগ করে: নিজের রিজলভারসহ ব্রাউজার বা অতিথি অ্যাপ্লিকেশন সংগঠনের লগারকে কিছুই জিজ্ঞাসা করে না। নিখুঁত লেনদেন আসে কেবল অ্যাপ্লিকেশনের নিজের ইভেন্ট থেকে, বা এমন প্রক্সি থেকে যার লগিং আপনি স্পষ্টভাবে সমর্থন করেন। সাধারণ HTTPS CONNECT টানেল প্রক্সিকে ভেতরের পৃষ্ঠা পাথগুলোর কোনো দৃশ্য দেয় না। নেটওয়ার্কের মালিকানা অ্যাপ্লিকেশনের বিশ্বাস মডেল চুপচাপ বদলে দেওয়ার অনুমতি নয়।
ঠিকানাটি একটি সেশনের, কোনো ব্যক্তির নয়
টানেল-পরিসরের ঠিকানা বহনকারী ফ্লো রেকর্ড উত্তর নয়, শুরুর বিন্দু। ওই ঠিকানা ও টাইমস্ট্যাম্প সেই মুহূর্তে সক্রিয় সেশন বরাদ্দের সঙ্গে মিলিয়ে দেখুন, কারণ এক ঘণ্টা পরে ওই ঠিকানা অন্য সেশনে পুনর্বরাদ্দ হতে পারে। স্ট্যাটিক অ্যাড্রেসিং ওই সম্পর্ক ধরে রাখার একটি উপায়, একমাত্র উপায় নয়।
যেখানে একটি অনুবাদ ধাপ সেন্সরের উজানে কয়েকটি ডিভাইসকে একটি উৎস ঠিকানায় নামিয়ে আনে, সেখানে সংযোগ কেবল ভাগ করা গেটওয়ে সেশনটির নাম বলতে পারে। ভাগ করা অ্যাকাউন্ট বা একাধিক ব্যক্তির ব্যবহৃত সার্টিফিকেট নেটওয়ার্ক ডেটা যত পূর্ণই দেখাক, অ্যাট্রিবিউশন সীমিত করে। দুটোই প্রতিবেদনে পরে বলার বিষয় নয়, সীমাবদ্ধতা হিসেবে থাকা উচিত।
টাইম জোন, ঘড়ির উৎস, পর্যবেক্ষণ বিন্দু এবং তার মাঝের প্রতিটি অনুবাদ সীমা লিখে রাখুন। অনুপস্থিতিও উপস্থিতির মতোই যত্ন পাওয়ার যোগ্য, কারণ একটি হারানো রেকর্ড মানে হতে পারে একটি ফ্লো এন্ট্রি পুরনো হয়ে গেছে, কোনো সেন্সর প্যাকেটটি কখনো দেখেনি, বা কোনো অ্যাপ্লিকেশন লগ বন্ধ ছিল।
ঘোষিত উদ্দেশ্যের জন্য নকশা করুন, তারপর পাইপলাইন প্রমাণ করুন
প্রশ্ন নির্ধারিত হলে কোন ফিল্ড দরকার, কে সেগুলো পড়তে পারবে এবং কতদিন রাখা হবে তা ঠিক করুন। স্টোরেজ সস্তা বলে বেশি সংগ্রহ করা তদন্তের চেয়ে বেশি দিন টিকে থাকা দায় তৈরি করে। RFC 6973-এ বর্ণিত গোপনীয়তা মডেল সম্পর্ক, ভুল অ্যাট্রিবিউশন ও অপ্রয়োজনীয় সংগ্রহকে পরবর্তী ভাবনা নয়, নকশার সমস্যা হিসেবে দেখে।
ম্যাপিং ও রেকর্ডগুলোকে এক বস্তু হিসেবে রক্ষা করুন, কারণ প্রতিটি আলাদাভাবে জোড়ার চেয়ে অনেক কম সংবেদনশীল। তারপর নকশাটি এমন কার্যকলাপের বিপরীতে যাচাই করুন যা তৈরি করার অনুমতি আপনার আছে এবং আপনি ইতিমধ্যেই বোঝেন, প্রতিবেদন যে সবচেয়ে ছোট কোয়েরির ওপর নির্ভর করবে তা দিয়েই। যে পাইপলাইন পরিচিত কোনো ঘটনা পুনরুৎপাদন করতে পারে না, সেটি অপরিচিত ঘটনাও পারবে না। প্রমাণ যা সমর্থন করে সেই ঘটনা, প্রমাণ যে ভাষা দেয় সেই ভাষায় প্রতিবেদন করুন, এবং বড় সিদ্ধান্তে পৌঁছানোর কাজ পাঠকের জন্য রাখুন।
অনুসন্ধানের পাশেই সীমাগুলো লিখুন: কী মিলানো হলো, কী অনুবাদ হলো, আর কোন লগ চুপ ছিল। যে অনুসন্ধান নিজের সীমানা বলে, তা এমন পর্যালোচনা পেরোয় যা একটি আত্মবিশ্বাসী সারাংশ পারে না। প্রমাণ আর প্রমাণের গল্পের মধ্যেকার পার্থক্য এটাই।