VPN সার্টিফিকেট LDAP অংশটিকে রক্ষা করে না

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

এই অসমতাই এমন একটি লগইনের পেছনের কৌশল, যা এনক্রিপ্টেড দেখায় এবং তবুও বাইন্ড পাসওয়ার্ড স্পষ্টভাবে পাঠায়।

দুটি সংযোগ, দুটি ট্রাস্ট সিদ্ধান্ত

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

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

StartTLS ও LDAPS, সচেতন পছন্দ

StartTLS সাধারণ LDAP হিসেবে খোলে এবং জায়গাতেই উন্নীত হয়, সাধারণত পোর্ট 389-এ। LDAPS সংযোগের সাথে সাথেই TLS শুরু করে, সাধারণত 636-এ। দুটোই বৈধ এবং অ্যাডাপ্টারকে ডিরেক্টরি যা দেয় তার সাথে মিলতে হবে। StartTLS বাধ্যতামূলক করা আর তা চেষ্টা করে উন্নয়ন ব্যর্থ হলে চালিয়ে যাওয়া এক নয়, এবং ঠিক সেই পার্থক্যেই বাইন্ড পাসওয়ার্ড বেরিয়ে যেতে পারে। কঠোর মোড কনফিগার করুন এবং পাসওয়ার্ড বাইন্ডের জন্য অসুরক্ষিত ফলব্যাক অনুমোদন করবেন না।

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

-ZZ ফ্ল্যাগটাই মূল বিষয়: কোয়েরিটি উন্নয়ন ছাড়া নীরবে এগিয়ে না গিয়ে ব্যর্থ হয়। ওই লাইনের নাম ও অ্যাকাউন্টগুলো উদাহরণ। OpenLDAP TLS ডকুমেন্টেশন এর পেছনের ট্রাস্ট সেটিংস কভার করে।

LDAP ক্লায়েন্ট কোন ট্রাস্ট স্টোর পড়ে?

OpenLDAP ক্লায়েন্ট লাইব্রেরি তার নিজস্ব ট্রাস্ট কনফিগারেশন পড়ে, সিস্টেম ফাইল থেকে হোক বা প্লাগইন-নির্দিষ্ট সেটিং থেকে। VPN-এর CA নির্দেশ VPN পিয়ারদের জন্য প্রযোজ্য এবং LDAP লাইব্রেরি একই ফাইল পড়ে তার প্রমাণ নয়। সার্টিফিকেট যে ডিরেক্টরি হোস্টনাম সত্যিই কভার করে সেটি ব্যবহার করুন, সাথে লাইব্রেরি যে ইস্যুয়িং চেইনে বিশ্বাস করে তা। Active Directory-তে প্রদর্শিত নাম থেকে অনুমান না করে সঠিক সার্ভার-প্রমাণীকরণ ব্যবহারসহ একটি ডিরেক্টরি-সার্ভিস সার্টিফিকেট স্থাপন করুন।

প্রতিটি ফেইলওভার গন্তব্যকে একই পরিচয় নীতি পূরণ করতে হবে। যে পরিবেশে প্রাথমিকটি যাচাইকৃত আর দ্বিতীয়টি নয়, তা ফেইলওভারহীন পরিবেশের চেয়েও খারাপ, কারণ দুর্বল পথটি কেবল বিভ্রাটের সময়েই ধরা পড়ে।

বাইন্ড অ্যাকাউন্ট আলাদা সমস্যা হয়েই থাকে

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

সার্টিফিকেটের অমিল দেখা দিলে সঠিক সার্টিফিকেট বা চেইন স্থাপন করুন। যাচাই বন্ধ করা একটি দৃশ্যমান অমিলকে অদৃশ্যে পরিণত করে এবং দ্বিতীয় ট্রাস্ট সম্পর্ককে অপরীক্ষিত রেখে দেয়।

দুটি সংযোগ, দুজন মালিক, দুটি নবায়নের তারিখ। ডকুমেন্টেশনে তাদের আলাদা রাখাই লগইনটিকে সৎ রাখে।