আপনার VPN গেটওয়ে আক্রান্ত: আসলে কী উন্মোচিত হয়
হ্যাক হওয়া VPN গেটওয়ে নিজের টানেলের ভেতর দেখে, কিন্তু এর মানে প্রতিটি সেশন দখল নয়। পুনরুদ্ধারের আগে ট্রাফিক, নাগাল ও সংরক্ষিত গোপনীয়তা আলাদা করুন।
একটি VPN গেটওয়ে যে টানেলকে সুরক্ষা দেয় তার শেষ প্রান্তে বসে, অর্থাৎ এটি সেই এনক্রিপশন নিজেই সমাপ্ত করে, পার করে দেয় না। কোনো আক্রমণকারী যদি হোস্টটি নিয়ন্ত্রণ করে, বাইরে থেকে টানেল তখনও সুস্থ দেখায়, অথচ মাঝখানের মেশিনটি আর বিশ্বাসযোগ্য নয়। কাজের প্রশ্নটি এই নয় যে সবকিছু ডিক্রিপ্ট হয় কি না। প্রশ্নটি হলো সেই হোস্টটি কী দেখতে পারত, কোথায় পৌঁছাতে পারত, আর কোন গোপনীয়তা প্রকৃতপক্ষে তার উপর সংরক্ষিত ছিল। এই তিনটি উত্তর খুব আলাদা, আর প্রতিক্রিয়াও তার সঙ্গে আলাদা হয়।
গেটওয়ে টানেল সমাপ্ত করে, তাই ভেতরটা দেখে
VPN-এ এনক্রিপশন হপ ধরে ধরে চলে, আর গেটওয়ে হলো সেই হপ। এটি বাইরের স্তর খুলে ফেলে, নীতি প্রয়োগ করে এবং ভেতরের প্যাকেটটি এগিয়ে পাঠায়, তাই প্রতিটি বহন করা প্যাকেট কোনো এক সময়ে সেই হোস্টের মেমরিতে পাঠযোগ্য রূপে থাকে। এটি ত্রুটি নয়, নকশা। এ কারণেই গেটওয়ে আক্রান্ত হওয়া টানেলের ক্রিপ্টোগ্রাফি আক্রান্ত হওয়ার চেয়ে আলাদা ঘটনা।
আক্রমণকারী প্রথমে যা পায় তা হলো অবস্থান: বহন করা ট্রাফিক পর্যবেক্ষণ, ফরওয়ার্ডিং বদলানো, বা কোনো ব্যাকএন্ডের জায়গায় উত্তর দেওয়ার ক্ষমতা। এরপর কী পাবে তা হোস্টের উপর নির্ভর করে, আর এখানেই লোকে অতিরিক্ত অনুমান করে। শুধু গেটওয়েতে প্রবেশ করলে ব্রাউজারের TLS সেশন কী হাতে আসে না, কারণ সেগুলো কখনোই গেটওয়েতে ছিল না।
তিনটি প্রকাশ, যাদের আকার সমান নয়
প্রশ্নটিকে বহন করা ট্রাফিক, পৌঁছানো যায় এমন সিস্টেম ও সংরক্ষিত গোপনীয়তায় ভাগ করুন, তারপর প্রতিটির উত্তর আলাদা করে দিন।
| Exposure | What the attacker gains | What does not follow |
|---|---|---|
| Carried traffic | Plaintext of whatever the tunnel forwards without its own encryption | Keys for TLS sessions that terminate at the application |
| Reachable systems | Whatever the backends accept from the gateway's address | Control of every connected client endpoint |
| Stored secrets | The specific keys, tokens and accounts present on that host | Possession of every client certificate or of a CA key |
মাঝের সারিটিই সবচেয়ে বেশি এড়িয়ে যাওয়া হয়। গেটওয়ের সাধারণত ব্যক্তিগত নেটওয়ার্কে যাওয়ার রুট থাকে এবং এমন উৎস ঠিকানা থাকে যা ব্যাকএন্ডরা আগেই বিশ্বাস করে, তাই মজার প্রশ্ন হলো সেই ব্যাকএন্ডগুলো ওই ঠিকানা থেকে কী অনুমোদন করে। সংকীর্ণ ক্লায়েন্ট-অ্যাক্সেস নীতি ভালো নিয়ন্ত্রণ, কিন্তু হোস্টে থাকা আক্রমণকারী সাধারণ ক্লায়েন্ট যে ইন্টারফেস ব্যবহার করত তার মধ্যে সীমাবদ্ধ নয়।
নিচের সারি ঠিক করে ঘটনাটি কত দিন চলবে। সার্ভার কী আর CA কী-এর বিস্তার সম্পূর্ণ আলাদা, আর তেমনি স্থানীয় অ্যাডমিন অ্যাকাউন্ট আর কেবল-পড়ার মনিটরিং টোকেনের।
টানেলের ভেতরের HTTPS এখনও HTTPS
অ্যাপ্লিকেশনের TLS অ্যাপ্লিকেশনেই সমাপ্ত হয়, VPN গেটওয়েতে নয়, তাই আক্রান্ত গেটওয়ে ওই প্রবাহগুলোর জন্য শুধু সাইফারটেক্সট দেখে। এটা আক্রমণকারী যা পায় তার একটি বাস্তব সীমা, এবং এটা স্পষ্টভাবে বলা উচিত, কারণ উল্টো দাবি আতঙ্ক ও খারাপ সিদ্ধান্ত ছড়ায়। দুটি শর্ত এটি ভাঙে। যদি পথে বিশ্বস্ত সার্টিফিকেটধারী কোনো পরিদর্শন উপাদান থাকে, গেটওয়ে নকশা অনুযায়ী সাধারণ টেক্সট দেখতে পারে। আর যদি অ্যাপ্লিকেশনের নিজের প্রান্তবিন্দুই আক্রান্ত হয়, টানেল অপ্রাসঙ্গিক।
তাই তারা কী দেখেছে তার উত্তর শর্তসাপেক্ষ, এবং এটি রায় হিসেবে ঘোষণা না করে শর্ত হিসেবে লিখে রাখা উচিত।
আবার ভরসা করার আগে কী বদলাতে হবে
হোস্ট পুনর্নির্মাণ প্রয়োজনীয়, আর খুব কম ক্ষেত্রেই যথেষ্ট। যে আক্রমণকারীর হাতে এখনো একটি ব্যবস্থাপনা অ্যাকাউন্ট, ডিপ্লয়মেন্ট ক্রেডেনশিয়াল বা সাইনিং কী আছে, সে হোস্টটিকে নিজের মতো করে ফিরিয়ে আনতে পারে। পুনরুদ্ধার শুরু করতে হবে এমন একটি প্রশাসনিক পথ থেকে যা আক্রান্ত মেশিনের উপর নির্ভর করে না।
কী ঘোরাবেন তা ঠিক করার আগে তালিকা করুন সেখানে কী ছিল। কী, সার্ভিস অ্যাকাউন্ট, API টোকেন, স্থানীয় ব্যবহারকারী, নির্ধারিত কাজ, বিশ্বাসের সম্পর্ক এবং ডিপ্লয়মেন্ট পাইপলাইন সবই প্রার্থী, আর প্রত্যেকের একজন মালিক আছে যে এটি নিশ্চিত করবে।
ss -lntup
getent passwd
crontab -l
ip route show table allএই তালিকাই দ্রুততম উপায় দেখতে, হোস্টটি কী দিচ্ছিল আর কোথায় পৌঁছাতে পারত। প্রথমে প্রমাণ সংরক্ষণ করুন, প্রতিক্রিয়া মালিকের প্রক্রিয়া অনুসারে, কারণ পুনর্নির্মাণ ঠিক সেই জিনিসটাই নষ্ট করে যা তদন্তের দরকার। NIST SP 800-61 সংশোধনী 3 প্রস্তুতি, শনাক্তকরণ, প্রতিক্রিয়া ও পুনরুদ্ধারকে একটি ঝুঁকি প্রক্রিয়ার অংশ হিসেবে দেখে, রিস্টার্ট নির্দেশনা হিসেবে নয়।
যে সীমানা পরের ঘটনাটিকে সস্তা করে
চারটি সীমানা দরকার হওয়ার আগেই গড়ে তোলা উচিত। এমন একটি স্বাধীন পুনরুদ্ধার পথ রাখুন যা গেটওয়ে দিয়ে প্রমাণায়ন করে না। সাইনিং কর্তৃত্ব ট্রাফিক পরিবেশনকারী হোস্ট থেকে আলাদা রাখুন। গেটওয়ে কোথায় পৌঁছাতে পারে তা সীমিত করুন, যাতে আক্রান্ত গেটওয়ে স্বয়ংক্রিয়ভাবে আক্রান্ত ব্যবস্থাপনা নেটওয়ার্ক না হয়। আর লিখে রাখুন কোন ক্রেডেনশিয়াল কার, যাতে ঘোরানো প্রত্নতত্ত্ব প্রকল্প নয়, একটি ফোন কল হয়।
এর কোনোটিই আক্রান্ত হওয়া ঠেকায় না। এগুলো তা সীমাবদ্ধ করে, আর খারাপ এক সপ্তাহ ও খারাপ এক ত্রৈমাসিকের তফাত গড়ে দেয়।