একটি 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 টানেল প্রক্সিকে গন্তব্য ও আয়তন দেয়, ভেতরের পৃষ্ঠা পথ নয়। নেটওয়ার্কে প্রশাসনিক প্রবেশাধিকার অ্যাপ্লিকেশনের বিশ্বাস মডেল নীরবে বদলানোর লাইসেন্স নয়।

কাউকে নাম দেওয়ার আগে পরিচয় ও সময় জুড়ুন

অভ্যন্তরীণ উৎস ঠিকানা বহনকারী ফ্লো রেকর্ডের কোনো মানে নেই যতক্ষণ সেই ঠিকানাটি একই সময়ে একটি সেশনের সঙ্গে যুক্ত না হয়। ঠিকানা পুনরায় ব্যবহৃত হয়, আর একই ঠিকানা এক ঘণ্টা আগে ভিন্ন সেশনের হতে পারত। স্থির বরাদ্দ সংযোগটি ধরে রাখার একটি উপায়, একমাত্র উপায় নয়।

অনুবাদের সীমা সংযোগ আরও দুর্বল করে। যদি আপনার পর্যবেক্ষণ বিন্দুর আগেই কয়েকটি ডিভাইস একটি উৎস ঠিকানা ভাগ করে থাকে, তবে আপনি সবচেয়ে ভালো যা শনাক্ত করতে পারেন তা একটি একক ডিভাইস নয়, বরং ভাগ করা গেটওয়ে সেশন। কয়েকজন মানুষের ব্যবহৃত একটি সার্টিফিকেট বা অ্যাকাউন্টেরও একই প্রভাব।

সময় অঞ্চল, ঘড়ির উৎস, পর্যবেক্ষণ বিন্দু এবং প্রতিটি অনুবাদ ধাপ লিখে রাখুন। অনুপস্থিত রেকর্ড মানে হতে পারে একটি ফ্লো এন্ট্রি পুরোনো হয়ে গেছে, একটি সেন্সর এড়িয়ে যাওয়া হয়েছে বা একটি অ্যাপ্লিকেশন লগ বন্ধ ছিল। অনুপস্থিতি কিছু ঘটেনি এর প্রমাণ নয়।

তারপর ঘোষিত উদ্দেশ্যের জন্য ন্যূনতম ক্ষেত্র, অনুমোদিত পাঠক ও সংরক্ষণের সময়কাল নির্ধারণ করুন। সম্পর্ক-নির্ণয় ও ভুল আরোপ পরবর্তী চিন্তা নয়, নকশার বিষয়, আর মানুষ চিহ্নিত করে এমন মেটাডেটা যে পরিচয়-মানচিত্রের ওপর নির্ভর করে তার সমান সুরক্ষা পাওয়ার যোগ্য।

আপনার নিয়ন্ত্রণাধীন কাজ দিয়ে অডিট পরীক্ষা করুন

অনুমোদিত ট্রাফিক তৈরি করুন যার সেশন ও অ্যাপ্লিকেশন আপনি আগেই জানেন, তারপর দেখুন প্রতিটি রেকর্ড আসলে কী ধরেছে। পৃষ্ঠা না লোড করে একটি অনুসন্ধান চালান, ক্যাশ থেকে একটি পৃষ্ঠা লোড করুন এবং প্রক্সির মাধ্যমে একটি সংযোগ খুলুন, আর দেখুন কোন ঘটনা দেখা যায়।

প্রমাণ যেই ঘটনাটি সমর্থন করে তা রিপোর্ট করুন এবং এটি কী ঢাকে না তা বলুন। ঘোষিত পরিধিসহ বিনয়ী রেকর্ড পর্যালোচনায় টিকে থাকে; অনুমান থেকে জোড়া লোভনীয় ব্রাউজিং হিস্ট্রি টেকে না।