VPN সার্ভারে আগমনকারী সতর্কতা: পর্যবেক্ষণ বিন্দুটি পড়ুন

VPN-এর পেছনের একটি সার্ভার তার সার্বজনীন সেবা-এন্ট্রিগুলো ধরে রাখে, আর মানুষ সেগুলো খুঁজে চলেছে। সতর্কতার সারিতে যা আসে তা একটি অনুসন্ধান নয়, তিনটি সম্ভাব্য অনুসন্ধান, এবং তাদের অর্থ আলাদা। প্রথম কাজ হলো প্রকাশিত সেবাকে প্রকাশিত প্রমাণপত্র থেকে আলাদা করা।

পর্যবেক্ষণ বিন্দুগুলো ক্রমানুসারে কাজ করুন। প্রমাণ যখন শ্রেণি বদলায় তখনই থামুন, কারণ পরের ধাপটি অন্য প্রশ্নের উত্তর দেয়।

প্রথম ধাপ: ক্যাপচার আসলে কী দেখল

প্যাকেট ক্যাপচার তার নিজের বিন্দুতে পথে যা দৃশ্যমান ছিল তা রেকর্ড করে। সেই বিন্দুটি পরবর্তী ফিল্টারিং সিদ্ধান্তের আগে থাকতে পারে। ধৃত প্যাকেট প্রমাণ করে ট্রাফিক সেখানে পৌঁছেছিল। এরপর কী ঘটেছে সে সম্পর্কে এটি কিছুই প্রমাণ করে না।

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

Windows স্ট্যাকের বেশ কয়েকটি স্তরে ফিল্টার করে, তাই ক্যাপচার সরঞ্জাম দ্বিতীয় স্তরে আর ফায়ারওয়াল তৃতীয় স্তরে এই পরিচ্ছন্ন মডেলটি বাস্তব পণ্যের সংস্পর্শে টেকে না। Windows Filtering Platform-এর সংক্ষিপ্ত বিবরণ স্ট্যাক স্তরজুড়ে ফিল্টারিং বর্ণনা করে, এবং সে কারণেই পর্যবেক্ষণের ক্রম অনুমান না করে প্রতিষ্ঠা করতে হয়।

দ্বিতীয় ধাপ: ড্রপ রেকর্ড কী প্রতিষ্ঠা করে

ড্রপ রেকর্ড বলে যে একটি নীতি-সীমানা ওই প্যাকেট প্রত্যাখ্যান করেছে। এটি জোরালো প্রমাণ। এটি সংকীর্ণ প্রমাণও, কারণ এটি একটি সীমানায় একটি সিদ্ধান্ত কভার করে। স্ট্যাকের আর কিছুই এর দ্বারা বর্ণিত হয় না।

টিউপল ও টাইমস্ট্যাম্পে মিলিয়ে দেখুন। একই উৎস, একই গন্তব্য, একই পোর্ট, একই সেকেন্ডের মধ্যে। সেই মিল ছাড়া অন্য লগে অনুরূপ দেখতে একটি ঘটনা কেবল আরেকটি ঘটনা, আর তাদের জোড়া দিলে এমন গল্প দাঁড়ায় যা কেউ রক্ষা করতে পারে না।

# what did the firewall actually drop, and when?
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, LogAllowed, LogBlocked
Get-Content "$env:systemroot\System32\LogFiles\Firewall\pfirewall.log" | Select-String 'DROP'

# correlate with a listening service on the same port
Get-NetTCPConnection -LocalPort 3389 -State Listen | Select-Object LocalAddress, OwningProcess

বন্ধ পোর্ট আর বাতিল করা প্যাকেট বাইরে থেকে একই রকম দেখায়, কিন্তু এই দুটি আউটপুটে সম্পূর্ণ আলাদা। সেই পার্থক্যই স্থানীয় রেকর্ড পড়ার পুরো কারণ।

তৃতীয় ধাপ: প্রমাণীকরণ ঘটনা কী প্রমাণ করে

প্রমাণীকরণ ঘটনা বলে যে একটি উপাদান অনুরোধটি ফলাফল রেকর্ড করার মতো যথেষ্ট প্রক্রিয়া করেছে। তিনটি ধাপের মধ্যে কেবল এটিই পরিচয় সম্পর্কে বলে, আর এর আগে কত প্যাকেট এসেছে সে সম্পর্কে কিছু বলে না।

ঘটনার প্রকৃত প্রসঙ্গ পড়ুন। যে অ্যাকাউন্টের অস্তিত্ব নেই তার জন্য ব্যর্থ লগইন স্ক্যানিংয়ের কোলাহল। প্রকৃত অ্যাকাউন্টের জন্য বিশ্বাসযোগ্য উৎস থেকে ব্যর্থ লগইন ভিন্ন অগ্রাধিকার। সফল সেশন সম্পূর্ণ ভিন্ন ঘটনা-শ্রেণি।

প্রোটোকলের নামগুলোও লক্ষ করুন। RPC ও RDP আলাদা পোর্টের আলাদা সেবা। যেটি একটিকে দেখে সেটি অন্যটিকে ঢাকে না। নেটওয়ার্ক কার্যকলাপ সংক্ষেপ করে দেখানো সরঞ্জাম সবসময় বলে না দুটির মধ্যে কোনটি ঘটনাটি তৈরি করেছে।

একটি মিলিত নমুনা একটি ড্যাশবোর্ডকে হারায়

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

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

ভৌগোলিক নিয়ম বা অবরুদ্ধ অসম্পর্কিত প্রোটোকল পর্যবেক্ষিত এন্ট্রি এবং তা যে সিদ্ধান্ত পেয়েছে তা খুঁজে বের করার বিকল্প নয়। VPN-ও নয়: টানেল দিয়ে বহির্গামী ট্রাফিক পাঠানো আগমনকারী অনুমোদন সম্পর্কে কিছুই নথিভুক্ত করে না।