দুটি লগইন যাচাই মানে দুই ধরনের ফ্যাক্টর নয়: VPN ও RADIUS

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

দ্বিতীয় ব্যাকএন্ড আসলে কী প্রমাণ করে

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

এমন একটি বৈধ নকশা আছে যেখানে দুই সিস্টেমই অংশ নেয়। একটি কেন্দ্রীয় সেবা ব্যক্তিকে প্রমাণীকরণ করতে পারে, আর গেটওয়ে স্বাধীনভাবে যাচাই করে ওই অ্যাকাউন্টের এই টানেলে অধিকার আছে কি না। এটি প্রমাণীকরণের পাশে চলা অনুমোদন, এবং এটিকে দুই-ফ্যাক্টর বলা একটি নীতি যাচাইয়ের সঙ্গে দখলের প্রমাণ গুলিয়ে ফেলে।

RADIUS প্রকৃত দ্বিতীয় ফ্যাক্টর বহন করতে পারে যখন এটি এমন কিছু সামনে রাখে যা একটি যাচাই করে, যেমন পুশ অনুমোদন বা হার্ডওয়্যার টোকেন। খামটি বলে না ব্যবহারকারী কোন প্রমাণক দেখিয়েছে, তাই গেটওয়ের লেবেল নয়, ব্যাকএন্ড নীতি পড়ুন।

AND, OR ও ফলব্যাক আলাদা পণ্য

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

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

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

OpenVPN-এর দ্বৈত যাচাই একটি নির্দিষ্ট উদাহরণ

কমিউনিটি OpenVPN 2.6-এ দুটিই চালু থাকলে ক্লায়েন্ট সার্টিফিকেট এবং কনফিগার করা auth-user-pass-verify স্ক্রিপ্ট দুটিই লাগে। এটি সার্টিফিকেট যাচাই ও ক্রেডেনশিয়াল স্ক্রিপ্টের মধ্যে নথিভুক্ত AND, এবং সত্যিই দুটি যাচাই। তবে এটি স্বয়ংক্রিয়ভাবে দুই ধরনের ফ্যাক্টর নয়, কারণ স্ক্রিপ্ট কেবল পাসওয়ার্ড যাচাই করতে পারে।

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

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

অ্যাপ্লায়েন্স বিক্রেতারা নিজেদের নদীর-নালা বানায়, প্রায়ই ওয়েব কনসোলের পেছনে PAM মডিউল বা RADIUS প্লাগইন। কমিউনিটির আচরণ দ্বৈত যাচাই কেমন দেখায় তার রেফারেন্স, অ্যাপ্লায়েন্স কীভাবে সেগুলো মেলায় তার বিবরণ নয়।

আপনার গেটওয়েতে সমন্বয়টি পরীক্ষা করুন

কনসোল সারাংশে ভরসা করার আগে কনফিগারেশন পড়ুন। নীতি নির্ধারণকারী লাইনগুলো হলো সার্টিফিকেট মোড, ক্রেডেনশিয়াল স্ক্রিপ্ট ও প্লাগইন ক্রম।

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep দেখায় সার্টিফিকেট লাগে কি না এবং তার পরে কোন স্ক্রিপ্ট চলে, আর ক্রমটি নাম যতটা বোঝায় তার চেয়ে বেশি গুরুত্বপূর্ণ। সার্টিফিকেট ডাম্প গেটওয়ে যে পরিচয় দেখবে তা দেয়, যার মধ্যে সংযোগ ম্যাপের জন্য দরকারি CN ও সিরিয়াল আছে। RADIUS পরীক্ষা নেতিবাচক ক্ষেত্র: ভুল পাসওয়ার্ডে Access-Reject, সঠিকটিতে Access-Accept আসতে হবে। প্রত্যাখ্যাত ক্রেডেনশিয়াল যদি এখনও সেশন দেয়, তবে স্ক্রিপ্টটি প্রমাণীকরণ পথেই নেই।

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

প্রয়োজনটি নেতিবাচক ক্ষেত্র হিসেবে লিখুন

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

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

যেকোনো প্লাগইন বা ফার্মওয়্যার পরিবর্তনের পরে চারটি প্রত্যাখ্যান আবার চালান। এগুলো সস্তা, আর যে নীতি তারা রক্ষা করে সেটিই আক্রমণকারীর প্রথম পরীক্ষা।