সেই দুর্বলতার ফলাফলটি কোন VPN প্রক্রিয়ায় পড়ে?

একটি স্ক্যানার ফলাফল একটি ঠিকানা, একটি পোর্ট এবং সেখানে কী নিয়ে আলোচনা হয়েছে তা উল্লেখ করে। এটি সেই সকেটের পিছনের প্রক্রিয়াটির নাম বলে না, আর একটি VPN হোস্টে একাধিক প্রক্রিয়া মেশিনটি ভাগ করতে পারে, যদিও তাদের মধ্যে কেবল একটি টানেল। পাশের কোনো ইউটিলিটি থেকে সংস্করণ স্ট্রিং পড়া বা ডিস্কে লাইব্রেরি ফাইল খুঁজে পাওয়া হোস্ট সম্পর্কে প্রমাণ যোগ করে, শ্রোতা সম্পর্কে নয়। ফলাফলটি কেবল তখনই কার্যকর হয় যখন এটি একটি চলমান উপাদানের সঙ্গে যুক্ত হয় এবং তারপর একটি সতর্কবার্তা যে পরিধি বলে তার সঙ্গে মেলানো হয়।

ক্রমটি গুরুত্বপূর্ণ: প্রথমে উপাদান, দ্বিতীয়ত সতর্কবার্তা, তৃতীয়ত প্রতিকার।

প্রতিবেদনটি পোর্টের নাম বলে, প্রোগ্রামের নয়

যে এন্ডপয়েন্টটি সত্যিই মূল্যায়ন করা হয়েছিল সেখান থেকে শুরু করুন। HTTPS প্রশাসন পোর্টের বিরুদ্ধে একটি প্রোব ওয়েব সেবা, তার TLS স্ট্যাক এবং তার সামনে থাকা যে কোনো প্রক্সি পরিমাপ করেছে; ভিন্ন পোর্টের OpenVPN বা WireGuard শ্রোতা সম্পর্কে এটি কিছুই জানেনি। রিভার্স প্রক্সি ও ব্যবস্থাপনা এজেন্টরা এটিকে আরও খারাপ করে, কারণ সার্টিফিকেট ও ব্যানার সামনের অংশের হতে পারে, আর দুর্বল লাইব্রেরিটি পিছনের প্রক্রিয়ায় তার পিছনে থাকে।

ফলাফলের সঙ্গে গন্তব্য, পরিবহন, পোর্ট ও সেবার নাম লিখে রাখুন, যাতে পরিধিটি ফলাফলের সঙ্গে চলে।

চলমান বিল্ডটি আসলে কী

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

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

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

বিল্ডটিকে সতর্কবার্তার পরিধির সঙ্গে মেলানো

সতর্কবার্তাগুলো পণ্য, সংস্করণ এবং কখনও কখনও প্রয়োজনীয় শর্ত বর্ণনা করে, আর এই তিনটি ক্ষেত্র সবসময় প্যাকেজ সংস্করণের সঙ্গে মেলে না। OpenVPN-এর এপ্রিল 2014-এর Heartbleed সতর্কবার্তা একটি উপকারী ঐতিহাসিক উদাহরণ, কারণ এটি ক্ষতিগ্রস্ত Access Server সংস্করণগুলোকে ওয়েব সেবা ও VPN ডেমন থেকে আলাদা করে, যাদের এক্সপোজার ভিন্ন ছিল। শিক্ষাটি হলো পাঠ্যটি কোন উপাদানকে ঢেকে রাখে তা পড়া, OpenSSL শব্দটি প্যাটার্ন-ম্যাচ করার বদলে।

সেই সতর্কবার্তাটিও পুরোনো। এর প্যাচ করা রিলিজ নম্বরগুলো এখন ইনস্টলেশন পরামর্শ নয়, এবং 2014 সালে ঠিক করা একটি ত্রুটি আজ আপনি যে শাখা চালান তাতে পরবর্তী সমস্যা সম্পর্কে কিছুই বলে না।

মতবিরোধ মেটানো, তারপর এক্সপোজার বন্ধ করা

ইনভেন্টরি ও মূল্যায়ন যখন অসঙ্গত হয়, দেখুন দুটিই একই এন্ডপয়েন্ট ও রানটাইম বর্ণনা করে কি না: অন্য ঠিকানা, একটি ফ্রন্ট-এন্ড প্রক্সি, দ্বিতীয় সেবা, পোর্টে এখনও বাঁধা একটি পুরোনো প্রক্রিয়া, অথবা প্যাকেজ ম্যানেজার কখনও দেখেনি এমন একটি বান্ডল করা লাইব্রেরি। প্রতিবেদন পুনর্লিখনের আগে সীমানায় এটি মিটিয়ে নিন।

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

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