অবিশ্বস্ত VPN তিনটি আলাদা সীমা, এক নয়
দূরবর্তী সহকর্মী, পথের মধ্যে অপারেটর এবং আপনার হোস্টে থাকা ক্লায়েন্ট তিনটি আলাদা হুমকি। একটি ফায়ারওয়াল নিয়ম কেবল তাদের প্রথমটির উত্তর দেয়।
«আমি এই VPN-এ বিশ্বাস করি না» সাধারণত একটি বাক্যে সাজানো তিনটি বিবৃতি। ওই নেটওয়ার্কের দূরবর্তী সহকর্মীরা আপনার হোস্টের সেবাগুলোতে পৌঁছাতে পারে, টানেল চালানো অপারেটর তার মধ্য দিয়ে যাওয়া ট্রাফিক দেখতে পারে, আর আপনি যে ক্লায়েন্ট সফটওয়্যার ইনস্টল করেছেন তা আপনার মেশিনের নেটওয়ার্ক নীতি বদলাতে পারে। যে বিশ্বাসটি সংশোধন করা দরকার তা হলো—একটি ফায়ারওয়াল নিয়ম, একটি ভার্চুয়াল মেশিন বা সতর্ক অপারেটিং সিস্টেম নির্বাচন তিনটিরই উত্তর দেয়। প্রতিটি ব্যবস্থা ঠিক একটির উত্তর দেয়।
মিথ: একটি নিয়ন্ত্রণ পুরো ঝুঁকি ঢেকে দেয়
সাধারণ ধারণা হলো, অবিশ্বস্ত নেটওয়ার্কে যুক্ত হওয়া একটি একক প্রশমনসহ একক সিদ্ধান্ত। মানুষ যে নিয়ন্ত্রণে ইতিমধ্যে আস্থা রাখে তা বেছে নেয়, প্রয়োগ করে এবং ঝুঁকিকে নিষ্পত্তিকৃত মনে করে: ফায়ারওয়াল চালু, কর্মক্ষেত্র নিষ্পত্তিযোগ্য, ক্লায়েন্ট প্রতিষ্ঠিত সরবরাহকারীর।
এই নিয়ন্ত্রণগুলো ধারণাটি যেভাবে ইঙ্গিত দেয় সেভাবে একে অপরকে ছেয়ে যায় না। হোস্ট ফায়ারওয়াল সীমিত করে দূরবর্তী সহকর্মী কী পর্যন্ত পৌঁছাতে পারে, আর আপনার TLS সমাপ্তকারী অপারেটরের বিরুদ্ধে এটি কিছুই করে না। ভার্চুয়াল মেশিন কর্মক্ষেত্রকে আপনার হোস্ট ফাইল থেকে আলাদা করে, আর উভয়ের নিচের নেটওয়ার্ক স্ট্যাক পুনরায় কনফিগার করার অনুমতি পাওয়া ক্লায়েন্ট উপাদানের বিরুদ্ধে এটি কিছুই করে না। প্রতিটি নিয়ন্ত্রণ আসলে যে সীমা তৈরি করে তার নাম দেওয়াই পুরো অনুশীলন।
সেগুলো আলাদা করলে এটাও বোঝা যায় আপনি কোন ঝুঁকি গ্রহণ করতে বেছেছেন। বাস্তব সিদ্ধান্তগুলোর বেশিরভাগই একটি সীমা প্রশমিত করে আর অন্যটি সহ্য করে, যা ঠিক আছে যতক্ষণ পরিবর্তনের নথি বলে দেয় কোনটি কোনটি।
দূরবর্তী সহকর্মী আসলে কী পর্যন্ত পৌঁছাতে পারে
শ্রবণকারী সেবা দিয়ে শুরু করুন। প্যাকেটগুলো এনক্রিপ্ট হয়ে এসেছে বলে যে টানেল ইন্টারফেসকে ব্যাপকভাবে বিশ্বস্ত ধরা হয়, সেটিই সাধারণ ভুল, আর এটি প্রতিটি স্থানীয় শ্রবণকারীকে ওই নেটওয়ার্কের অন্যদের জন্য সম্ভাব্য লক্ষ্যে পরিণত করে। এনক্রিপশন দুটি প্রান্তের মধ্যের তার রক্ষা করে; অন্যপ্রান্তের সহকর্মীর উদ্দেশ্য সম্পর্কে এটি কিছুই বলে না।
ss -tulpn sudo nft list ruleset ip -br addr
সেবাগুলোকে প্রতিটি ইন্টারফেসে নয়, বরং যে ঠিকানায় তাদের দরকার সেখানে বাঁধুন, এবং অনুমোদিত কাজ যে কাজগুলো দাবি করে কেবল সেগুলোই অনুমতি দিন। ফরওয়ার্ডিং, ব্রিজিং ও অ্যাপ্লিকেশন প্রক্সি স্পষ্ট রাখুন, কারণ দুটি নেটওয়ার্ক সংযুক্তি নিজে থেকে ট্রানজিট পথ তৈরি করে না, কিন্তু প্রক্সি নিয়ম নিশ্চিতভাবে করতে পারে।
অনুমোদিত নিষ্পত্তিযোগ্য কর্মক্ষেত্র দূরবর্তী নেটওয়ার্ক কী পর্যন্ত পৌঁছাতে পারে তা কমায়, কিন্তু কেবল যখন তার শেয়ারিং কনফিগারেশন দাবিটির সঙ্গে মেলে। শেয়ার করা ফোল্ডার, ক্লিপবোর্ড একীকরণ, ক্রেডেনশিয়াল এজেন্ট এবং ব্যবস্থাপনা চ্যানেল—সবই কর্মক্ষেত্র যে সীমা তৈরি করার কথা ছিল তা অতিক্রম করে। কর্মক্ষেত্রের লেবেল এর কোনটি খোলা তা প্রমাণ করে না।
NIST-এর শূন্য-বিশ্বাস স্থাপত্য এর পেছনের নীতিটি বলে: কেবল নেটওয়ার্ক অবস্থান অন্তর্নিহিত বিশ্বাস দেয় না। টানেল গৃহীত হওয়ার পরেও সম্পদ প্রমাণীকরণের কাজ থাকে, আর থাকে ওই নেটওয়ার্কে আর কে শামিল সেই প্রশ্নও।
পথের মধ্যে অপারেটর কী দেখতে পারে
একটি VPN আপনার ট্রাফিককে পথের ভিন্ন জায়গায় নিয়ে যায়; এটি অ্যাপ্লিকেশন এনক্রিপশন যোগ করে না। যদি সরবরাহকারী আপনার TLS সমাপ্ত করে, সরবরাহকারী আপনার ব্রাউজার যা অন্যথায় রক্ষা করত তা পড়তে পারে, আর কোনো স্থানীয় ফায়ারওয়াল নিয়ম তা বদলায় না।
প্রকৃত গন্তব্যের জন্য স্বাভাবিক শংসাপত্র যাচাই রাখুন এবং রিজলভার ও মেটাডেটা পথ বুঝুন, কারণ একটি DNS কোয়েরি তার আগে যাওয়া পেলোডের চেয়ে বেশি প্রকাশ করতে পারে। কেবল মেটাডেটা, অর্থাৎ আপনি কোন ঠিকানায় কখন যোগাযোগ করেছেন, প্রায়ই বিষয়বস্তু না পড়েই অপারেটরের প্রশ্নের উত্তর দেয়। এজন্যই «ট্রাফিক এনক্রিপ্টেড» আর «ট্রাফিক ব্যক্তিগত» ভিন্ন দাবি।
যদি ওই দৃশ্যমানতা কাজের জন্য অগ্রহণযোগ্য হয়, উত্তর হলো আরও স্থানীয় ফিল্টারিং নয়, বরং ভিন্ন একটি অনুমোদিত স্থাপত্য। স্থানীয় ফিল্টারিং এমন পথ থেকে পর্যবেক্ষক সরাতে পারে না যেখানে সে তখনও বসে আছে।
স্থানীয় ক্লায়েন্ট কী পরিবর্তন করতে পারে
এই সীমাটিই মানুষ মিস করে, আর এটিই অন্য দুটিকে অর্থহীন করে তোলে। লিনাক্সে CAP_NET_ADMIN তার নেটওয়ার্ক প্রসঙ্গে ইন্টারফেস কনফিগারেশন, ফায়ারওয়াল প্রশাসন ও রুট পরিবর্তন ঢেকে দেয়। ওই ক্ষমতা থাকা সফটওয়্যার আপনি এইমাত্র লেখা নীতিটি আবার লিখতে পারে।
getcap /usr/sbin/openvpn systemd-analyze security vpn-client.service ip netns list
নেটওয়ার্ক নেমস্পেস নেটওয়ার্ক অবস্থার জন্য সত্যিকারের সীমা আর বাকি সবকিছুর জন্য দুর্বল: এটি ফাইলসিস্টেম বা ক্রেডেনশিয়াল ভান্ডার আলাদা করে না। এটিকে পুরো সমস্যার কনটেইনার নয়, বরং একটি স্তর হিসেবে দেখুন।
ক্লায়েন্ট ও তার কনফিগারেশন রক্ষণাবেক্ষণাধীন উৎস থেকে নিন, এটি যে কর্তৃত্ব চায় তা পর্যালোচনা করুন, আর বিশেষাধিকারী উপাদান প্রশাসকের নিয়ন্ত্রণে রাখুন। মূল্যবান ক্রেডেনশিয়ালের পাশে অস্পষ্ট ইনস্টলার চালানোর অনুমতি না হয়েও একটি ভার্চুয়াল মেশিন যোগ্য মূল্যায়ন সীমার অংশ হতে পারে। ইনস্টলার আপনি যে কর্তৃত্ব দেন তা নিয়েই চলে, আর সেই কর্তৃত্বই সীমা।
আপনি কোন সীমা গ্রহণ করেছেন তা লিখে রাখুন
চারটি জিনিসের নাম নিয়ে একটি বাক্যে শেষ করুন: বিশ্বস্ত স্থানীয় কোড, অনুমোদিত দূরবর্তী প্রবেশাধিকার, সুরক্ষিত অ্যাপ্লিকেশন ডেটা এবং যে অপারেটর সম্পর্ক টিকে থাকে। ওই বাক্যটি একটি VM, একটি অপারেটিং সিস্টেম বা একটি অ্যান্টিভাইরাস পণ্য শত্রুপূর্ণ নেটওয়ার্ককে নিরাপদ করেছে—এই সার্বিক দাবির চেয়ে বেশি মূল্যবান।
তারপর নিশ্চিত করুন সংকীর্ণ কাজটি চলে এবং দাবিকৃত প্রতিরোধ এখনও টেকে, টানেল পড়ে যাওয়ার পরেও। যে সীমা কেবল টানেল চালু থাকা অবস্থায় থাকে, তা আপনার নথিভুক্ত সীমা নয়।
কোনো পরীক্ষা প্রমাণ করে না সব দুর্বলতা অনুপস্থিত, আর অন্যথা দাবি করা পর্যালোচনা অতিরিক্ত দাবি করে। সৎ ফলাফল অবশিষ্ট ঝুঁকি ও তা গ্রহণকারীর নাম বলে।