802.1X Supplicant কী? ক্লায়েন্টের ধরন এবং ডিভাইস কনফিগারেশন

একজন সিনিয়র নেটওয়ার্ক সিকিউরিটি কনসালট্যান্ট যেভাবে ক্লায়েন্টকে ব্রিফিং দেন, ঠিক সেই রকম একটি আত্মবিশ্বাসী, কর্তৃত্বপূর্ণ এবং কথোপকথনের সুরে ব্রিটিশ ইংরেজিতে কথা বলুন। পরিমিত গতি, স্পষ্ট উচ্চারণ, পেশাদার কিন্তু খুব বেশি আনুষ্ঠানিক নয়। জোর দেওয়ার জন্য মাঝে মাঝে স্বাভাবিক বিরতি: Purple টেকনিক্যাল ব্রিফিং সিরিজে আপনাকে স্বাগত। আজকে আমরা এমন একটি বিষয় নিয়ে আলোচনা করছি যা এন্টারপ্রাইজ WiFi সিকিউরিটির একদম কেন্দ্রবিন্দুতে রয়েছে - 802.1X supplicant। যদি আপনি কখনও ভেবে থাকেন যে কেন কিছু ডিভাইস পাসওয়ার্ডের প্রম্পট ছাড়াই আপনার কর্পোরেট নেটওয়ার্কের সাথে সংযুক্ত হয়ে যায়, অথচ অন্যান্য ডিভাইসগুলোতে সার্টিফিকেট ত্রুটি এবং হেল্পডেস্ক টিকিট দেখায়, তবে এই পর্বটি আপনার জন্যই। [medium pause] চলুন একদম প্রাথমিক বিষয়গুলো দিয়ে শুরু করা যাক। 802.1X supplicant হলো একটি ক্লায়েন্ট ডিভাইসের (যেমন ল্যাপটপ, স্মার্টফোন, ট্যাবলেট) সফটওয়্যার উপাদান, যা ডিভাইসটি IEEE 802.1X দ্বারা সুরক্ষিত কোনো নেটওয়ার্কে যুক্ত হওয়ার চেষ্টা করলে অথেন্টিকেশন হ্যান্ডশেক পরিচালনা করে। এটিকে ডিভাইসের আইডি কার্ড প্রদর্শনকারী হিসেবে বিবেচনা করতে পারেন। নেটওয়ার্ক কেবল যে কাউকে প্রবেশ করতে দেয় না। এটি ক্রেডেনশিয়াল বা প্রমাণপত্র চায়। supplicant হলো সেই জিনিস যা সামনে এগিয়ে আসে এবং বলে: এই যে আমি কে, এই আমার সার্টিফিকেট, আমাকে প্রবেশ করতে দিন। এই স্ট্যান্ডার্ডটি নিজে - IEEE 802.1X - পোর্ট-ভিত্তিক নেটওয়ার্ক অ্যাক্সেস কন্ট্রোল নির্ধারণ করে। অথেন্টিকেশন সফল হওয়ার আগে, অ্যাক্সেস পয়েন্ট বা সুইচ কেবল একটি খুব সীমিত ধরণের ট্র্যাফিক পার হওয়ার অনুমতি দেয়: EAPOL ফ্রেম, যার পূর্ণরূপ হলো Extensible Authentication Protocol over LAN। বাকি সবকিছু ব্লক বা অবরুদ্ধ থাকে। supplicant যখন authenticator-এর মাধ্যমে RADIUS সার্ভারে নিজের পরিচয় প্রমাণ করে, তখন পোর্টটি খুলে যায় এবং সাধারণ ট্র্যাফিক চলাচল শুরু হয়। [medium pause] এবার, এই খেলায় তিনটি প্রধান পক্ষ রয়েছে। প্রথমত, supplicant - যা হলো ক্লায়েন্ট ডিভাইস। দ্বিতীয়ত, authenticator - আপনার অ্যাক্সেস পয়েন্ট বা সুইচ, যেমন Cisco Meraki, HPE Aruba, Ruckus, অথবা Juniper Mist-এর মতো হার্ডওয়্যার। তৃতীয়ত, অথেন্টিকেশন সার্ভার - যা সাধারণত প্রায় সবসময়ই একটি RADIUS সার্ভার হয়ে থাকে, যা Microsoft Entra ID বা Okta-এর মতো ডিরেক্টরির সাথে ক্রেডেনশিয়াল যাচাই করে। supplicant একটি EAPOL-Start মেসেজ পাঠানোর মাধ্যমে প্রক্রিয়াটি শুরু করে। authenticator পরিচয়ের জন্য একটি EAP-Request দিয়ে সাড়া দেয়। supplicant নিজের পরিচয় দিয়ে উত্তর দেয়। সেই পরিচয়টি RADIUS সার্ভারে পাঠানো হয়, যা এরপর নির্ধারিত EAP পদ্ধতির মাধ্যমে supplicant-কে যাচাই করে। সবকিছু ঠিকঠাক থাকলে, RADIUS সার্ভার একটি Access-Accept পাঠায়, পোর্টটি খুলে যায় এবং ডিভাইসটি সঠিক VLAN-এ স্থান পায়। [medium pause] চলুন EAP পদ্ধতিগুলো নিয়ে কথা বলা যাক, কারণ এখানেই বেশিরভাগ ডেপ্লয়মেন্টের সিদ্ধান্ত নেওয়া হয়।EAP-TLS - অর্থাৎ Transport Layer Security সহ Extensible Authentication Protocol - হলো গোল্ড স্ট্যান্ডার্ড। এর জন্য ক্লায়েন্ট এবং সার্ভার উভয়কেই সার্টিফিকেট প্রদর্শন করতে হয়। পারস্পরিক প্রমাণীকরণ (Mutual authentication)। কোনো পাসওয়ার্ডের প্রয়োজন নেই। ক্লায়েন্ট সার্টিফিকেট ডিভাইসের পরিচয় প্রমাণ করে; সার্ভার সার্টিফিকেট প্রমাণ করে যে নেটওয়ার্কটি বৈধ, যা ইভিল টুইন (evil twin) আক্রমণ থেকে রক্ষা করে যেখানে একটি প্রতারক অ্যাক্সেস পয়েন্ট ক্রেডেনশিয়াল হাতিয়ে নেওয়ার চেষ্টা করে। EAP-TLS বারোটি ধাপে সম্পন্ন হয় এবং সর্বত্র পাবলিক-প্রাইভেট কী ক্রিপ্টোগ্রাফি ব্যবহার করে। এটি WPA3-Enterprise-এর সর্বোচ্চ সিকিউরিটি মোডের জন্য প্রয়োজনীয় পদ্ধতি, এবং এটি ডিভাইস আইডি ভেরিফিকেশনের জন্য NIST SP 800-171-এর প্রয়োজনীয়তাগুলির সাথে সামঞ্জস্যপূর্ণ। PEAP - Protected EAP - হলো সেইসব প্রতিষ্ঠানের জন্য আরও সাধারণ প্রারম্ভিক বিন্দু যাদের এখনও সম্পূর্ণ PKI নেই। PEAP একটি পাসওয়ার্ড-ভিত্তিক অভ্যন্তরীণ পদ্ধতিকে (সাধারণত MSCHAPv2) একটি TLS টানেলের মধ্যে আবৃত করে। সার্ভার একটি সার্টিফিকেট প্রদর্শন করে; ক্লায়েন্ট করে না। এর মানে হলো ডেপ্লয়মেন্ট সহজতর - আপনাকে ক্লায়েন্ট সার্টিফিকেট প্রদান করতে হবে না - তবে এটি কম সুরক্ষিত। MSCHAPv2 MD4 হ্যাশিং ব্যবহার করে, যা ১৯৯৫ সাল থেকে আপোষহীন (compromised) বলে বিবেচিত হয়ে আসছে। কোনো ব্যবহারকারী যদি একটি প্রতারক অ্যাক্সেস পয়েন্টের সাথে সংযোগ করে যা দেখতে বিশ্বস্ত এমন একটি সার্টিফিকেট প্রদর্শন করে, তবে তাদের ক্রেডেনশিয়াল চুরি হয়ে যেতে পারে। তাই PEAP চালানোর সময় ক্লায়েন্ট সাইডে সার্ভার সার্টিফিকেট যাচাইকরণ (validation) আবশ্যক। [medium pause] এখন আসুন সাপ্লিক্যান্ট সম্পর্কে বিস্তারিত জানা যাক - বিশেষ করে নেটিভ OS সাপ্লিক্যান্ট এবং থার্ড-পার্টি ক্লায়েন্ট সফ্টওয়্যারের মধ্যকার নির্বাচন। প্রতিটি প্রধান অপারেটিং সিস্টেম একটি বিল্ট-ইন 802.1X সাপ্লিক্যান্টের সাথে আসে। Windows-এ XP থেকে শুরু করে Wireless AutoConfig এবং Wired AutoConfig সার্ভিসের মাধ্যমে এটি নেটিভভাবে সমর্থিত। macOS এবং iOS তাদের নেটওয়ার্ক কনফিগারেশন প্রোফাইলের মাধ্যমে 802.1X পরিচালনা করে। Android এটি WiFi সেটিংস প্যানেলের মাধ্যমে সমর্থন করে। এই নেটিভ সাপ্লিক্যান্টগুলি বর্তমান সমস্ত প্ল্যাটফর্মে EAP-TLS এবং PEAP-MSCHAPv2 কভার করে। নেটিভ সাপ্লিক্যান্টের সুবিধা স্পষ্ট: কোনো অতিরিক্ত সফ্টওয়্যার ডেপ্লয় করার প্রয়োজন নেই, কোনো লাইসেন্সিং খরচ নেই, স্বয়ংক্রিয় OS সিকিউরিটি আপডেট এবং অপারেটিং সিস্টেমের সার্টিফিকেট স্টোরের সাথে নিবিড় একীকরণ। পরিচালিত ডিভাইস ফ্লিটের জন্য - যেমন Microsoft Intune-এ নথিভুক্ত Windows মেশিন, Jamf-এর মাধ্যমে পরিচালিত Mac - আপনি MDM-এর মাধ্যমে ব্যাকগ্রাউন্ডে নীরবে 802.1X কনফিগারেশন প্রোফাইল পুশ করতে পারেন, এবং ব্যবহারকারীরা কখনই কোনো প্রম্পট দেখতে পাবেন না। ডিভাইসটি প্রতিবার পরিসীমার মধ্যে আসার সাথে সাথে স্বয়ংক্রিয়ভাবে প্রমাণীকৃত হয়। নির্দিষ্ট কিছু ক্ষেত্রে থার্ড-পার্টি সাপ্লিক্যান্টের প্রয়োজন হয়। আপনি যদি Cisco ইনফ্রাস্ট্রাকচার ব্যবহার করেন এবং EAP-FAST — যা Cisco-র নিজস্ব EAP পদ্ধতি — ব্যবহার করতে চান, তবে আপনার Cisco-র ক্লায়েন্ট সফ্টওয়্যার প্রয়োজন হবে, যা ঐতিহাসিকভাবে Secure Services Client বা AnyConnect Network Access Manager নামে পরিচিত। আপনার যদি একটি মিশ্র-OS এস্টেট জুড়ে সামঞ্জস্যপূর্ণ কনফিগারেশন পরিচালনার প্রয়োজন হয় এবং আপনি সাপ্লিক্যান্ট সেটিংস লক ডাউন করতে চান যাতে ব্যবহারকারীরা ভুলবশত সেগুলি ভুল কনফিগার করতে না পারেন, তবে একটি থার্ড-পার্টি ক্লায়েন্ট আপনাকে সেই নিয়ন্ত্রণ দেয়। SecureW2-এর JoinNow সুইটের মতো টুলগুলো অনবোর্ডিং এজেন্ট হিসেবেও কাজ করে — এগুলো নেটিভ সাপ্লিক্যান্টকে প্রতিস্থাপন করার পরিবর্তে কনফিগার করে এবং ব্যবহারকারীদের সার্টিফিকেট এনরোলমেন্ট ও প্রোফাইল ইনস্টলেশনের ধাপগুলো বুঝিয়ে দেয়। [medium pause] বিষয়টি আরও স্পষ্ট করতে আমি আপনাকে দুটি বাস্তব উদাহরণ বা সিনারিও বুঝিয়ে বলছি। প্রথমত, একটি ৪০০ রুমের হোটেল। বর্তমানে হোটেলটির স্টাফ নেটওয়ার্ক WPA2-Enterprise ও PEAP-MSCHAPv2-এর মাধ্যমে পরিচালিত হচ্ছে। পাসওয়ার্ড-ভিত্তিক প্রমাণীকরণ বাদ দিতে এবং ক্রেডেনশিয়াল চুরির ঝুঁকি কমাতে আইটি টিম EAP-TLS-এ মাইগ্রেট করতে চায়। চ্যালেঞ্জটি হলো: স্টাফদের ডিভাইসগুলোর মধ্যে রয়েছে Intune-এর মাধ্যমে পরিচালিত Windows ল্যাপটপ, প্রোপার্টি ম্যানেজমেন্ট সফ্টওয়্যারের জন্য ব্যবহৃত ব্যক্তিগত Android ফোন এবং ব্যাক-অফিসে থাকা কয়েকটি পুরোনো Windows 7 কম্পিউটার। এখানে পর্যায়ভিত্তিক পদ্ধতি অনুসরণ করা হয়েছে। পরিচালিত Windows ডিভাইসগুলো দিয়ে শুরু করুন। এমন একটি Intune কনফিগারেশন প্রোফাইল পুশ করুন যা RADIUS সার্ভারের রুট CA সার্টিফিকেট ইনস্টল করে, EAP-TLS-এর জন্য WiFi প্রোফাইল কনফিগার করে এবং অভ্যন্তরীণ PKI থেকে SCEP-ভিত্তিক সার্টিফিকেট এনরোলমেন্ট চালু করে। ওই ডিভাইসগুলো প্রথম দিন থেকেই স্বয়ংক্রিয়ভাবে প্রমাণীকরণ সম্পন্ন করবে। Android BYOD ডিভাইসগুলোর জন্য একটি সেলফ-সার্ভিস অনবোর্ডিং পোর্টাল স্থাপন করুন — ব্যবহারকারীরা একটি URL ভিজিট করবেন, একটি কনফিগারেশন প্রোফাইল ডাউনলোড করবেন এবং তাদের জন্য সাপ্লিক্যান্ট কনফিগার হয়ে যাবে। পুরোনো Windows 7 মেশিনগুলো নিষ্ক্রিয় করার আগ পর্যন্ত সেগুলোকে কঠোর সার্ভার সার্টিফিকেট ভ্যালিডেশন সহ PEAP-এর অধীনে রাখা হবে এবং সীমিত অ্যাক্সেস সহ একটি পৃথক VLAN-এ আইসোলেট করে রাখা হবে। [medium pause] দ্বিতীয় সিনারিও: ২০০টি স্টোর বিশিষ্ট একটি বড় রিটেল চেইন। প্রতিটি স্টোরে পয়েন্ট-অফ-সেল (POS) টার্মিনাল, স্টাফদের ট্যাবলেট এবং একটি গেস্ট WiFi নেটওয়ার্ক রয়েছে। PCI DSS-এর নিয়ম অনুযায়ী কার্ডধারীদের ডেটা এনভায়রনমেন্ট অন্যান্য নেটওয়ার্ক সেগমেন্ট থেকে সম্পূর্ণ আলাদা (isolated) রাখা আবশ্যক। রিটেইলার স্টাফ এবং POS নেটওয়ার্কে 802.1X ব্যবহার করে, যেখানে সার্টিফিকেট অ্যাট্রিবিউট অনুযায়ী VLAN নির্ধারণ করা হয়। একটি POS টার্মিনাল যখন "POS" অর্গানাইজেশনাল ইউনিট সহ একটি ডিভাইস সার্টিফিকেট পেশ করে, তখন RADIUS পলিসি সেটিকে PCI VLAN-এ অ্যাসাইন করে। আর একজন স্টাফের ট্যাবলেট যখন "Staff" সার্টিফিকেট পেশ করে, তখন সেটি স্টাফ VLAN-এ যুক্ত হয়। গেস্ট ডিভাইসগুলো সম্পূর্ণ আলাদা একটি SSID-এর সাথে সংযুক্ত হয়, যা একটি Captive Portal সমাধানের মাধ্যমে পরিচালিত হয়। POS টার্মিনালগুলোর সাপ্লিক্যান্ট কনফিগারেশন MDM-এর মাধ্যমে লক ডাউন করা থাকে। কোনো ব্যবহারকারীর ইন্টারঅ্যাকশনের প্রয়োজন হয় না। টার্মিনালগুলো বুট করার সময় নিঃশব্দে প্রমাণীকরণ সম্পন্ন করে। SCEP-এর মাধ্যমে সার্টিফিকেট রিনিউয়াল স্বয়ংক্রিয়ভাবে সম্পন্ন হয়, তাই সার্টিফিকেটের মেয়াদ শেষ হয়ে গেলে কোনো ম্যানুয়াল হস্তক্ষেপের প্রয়োজন হয় না। [medium pause] এবার ইমপ্লিমেন্টেশনের সাধারণ ভুলত্রুটিগুলো দেখা যাক। আমি আপনাদের সবচেয়ে সাধারণ চারটি ভুলের কথা বলছি। এক নম্বর: PEAP ডেপ্লয়মেন্টে সার্ভার সার্টিফিকেট ভ্যালিডেশন অনুপস্থিত থাকা। আপনি যদি RADIUS সার্ভারের সার্টিফিকেট ভ্যালিডেট করতে এবং সার্ভারের নাম চেক করতে supplicant কনফিগার না করেন, তবে ব্যবহারকারীরা একটি ক্ষতিকারক অ্যাক্সেস পয়েন্টের সাথে সংযুক্ত হওয়ার ঝুঁকিতে থাকবেন। সর্বদা supplicant প্রোফাইলে বিশ্বস্ত রুট CA এবং সার্ভারের নাম উল্লেখ করুন। দুই নম্বর: সার্টিফিকেটের মেয়াদ শেষ হওয়ার কারণে ব্যাপক অথেন্টিকেশন ব্যর্থতা। ক্লায়েন্ট সার্টিফিকেটের একটি মেয়াদকাল থাকে। আপনার যদি SCEP বা NDES-এর মাধ্যমে স্বয়ংক্রিয় রিনিউয়াল ব্যবস্থা না থাকে, তবে আপনি এমন একটি চরম পরিস্থিতির সম্মুখীন হবেন যেখানে শত শত ডিভাইস একসাথে অথেন্টিকেশন করা বন্ধ করে দেবে। লাইভ করার আগে রিনিউয়াল অটোমেশন তৈরি করুন। তিন নম্বর: অসঙ্গতিপূর্ণ supplicant আচরণ সহ BYOD ডিভাইস। বিশেষ করে Android-এ বিভিন্ন নির্মাতাদের মধ্যে 802.1X সমর্থন খণ্ডিত। কিছু সংস্করণে WiFi প্রোফাইলটি গ্রহণ করার আগে ব্যবহারকারীকে ম্যানুয়ালি CA সার্টিফিকেট ইনস্টল করতে হয়। একটি অনবোর্ডিং পোর্টাল যা এই ধাপটি পরিচালনা করে তা হেল্পডেস্কের কাজের চাপ উল্লেখযোগ্যভাবে হ্রাস করে। চার নম্বর: Windows 11-এর ফিচার আপডেট supplicant কনফিগারেশন নষ্ট করে দেয়। মাইক্রোসফট বেশ কয়েকটি Windows 11 আপডেটে 802.1X আচরণ পরিবর্তন করেছে। বিশেষত, 24H2 আপডেটটি নেটিভ supplicant কীভাবে EAP-TLS ফলব্যাক পরিচালনা করে তাতে পরিবর্তন এনেছে। প্রোডাকশনে রোল আউট করার আগে নতুন OS সংস্করণের সাথে আপনার supplicant প্রোফাইলগুলো পরীক্ষা করুন। [medium pause] এখন দ্রুত কিছু প্রশ্ন ও উত্তর। IoT ডিভাইস কি 802.1X সমর্থন করতে পারে? বেশিরভাগই পারে না। IoT ডিভাইসে সাধারণত কোনো supplicant থাকে না। এর বিকল্প বা ফলব্যাক হলো MAC Authentication Bypass - MAB - যেখানে RADIUS সার্ভার ডিভাইসের MAC অ্যাড্রেসের ভিত্তিতে ডিভাইসটিকে অথেন্টিকেট করে। MAC অ্যাড্রেস স্পুফ করা যেতে পারে, তাই MAB ডিভাইসগুলোকে সর্বদা কঠোর ফায়ারওয়াল নিয়ম সহ একটি আইসোলেটেড IoT VLAN-এ রাখা উচিত। 802.1X চালানোর জন্য কি আমার একটি PKI প্রয়োজন? PEAP-এর জন্য, না - আপনার কেবল RADIUS সার্ভারে একটি সার্ভার সার্টিফিকেট প্রয়োজন। EAP-TLS-এর জন্য, হ্যাঁ - ক্লায়েন্ট সার্টিফিকেট ইস্যু করার জন্য আপনার একটি PKI প্রয়োজন। ক্লাউড-ভিত্তিক PKI পরিষেবাগুলো অবকাঠামোগত খরচ এবং জটিলতা উল্লেখযোগ্যভাবে হ্রাস করে। 802.1X কীভাবে Purple-এর নেটওয়ার্ক অ্যাক্সেস প্ল্যাটফর্মের সাথে কাজ করে? Purple আপনার বিদ্যমান হার্ডওয়্যার - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist এবং অন্যান্যগুলির উপরে একটি ক্লাউড ওভারলে হিসাবে কাজ করে। স্টাফদের WiFi নেটওয়ার্কগুলোতে, Purple-এর SecurePass অ্যাড-অন আপনার আইডেন্টিটি প্রোভাইডার - Microsoft Entra ID, Okta, বা Google Workspace-এর সাথে যুক্ত হয়ে 802.1X অথেন্টিকেশন প্রয়োগ করে এবং অন-প্রিমিস RADIUS অবকাঠামোর প্রয়োজন ছাড়াই প্রতি-ব্যবহারকারী VLAN নীতি প্রয়োগ করে। [medium pause] সংক্ষেপে: 802.1X supplicant হলো ডিভাইস-সাইড এজেন্ট যা পোর্ট-ভিত্তিক নেটওয়ার্ক অ্যাক্সেস নিয়ন্ত্রণকে কার্যকর করে। আপনার EAP পদ্ধতির পছন্দ - সর্বাধিক সুরক্ষার জন্য EAP-TLS, ট্রানজিশনাল অপশন হিসাবে PEAP - আপনার PKI প্রয়োজনীয়তা এবং আপনার supplicant কনফিগারেশন পদ্ধতি নির্ধারণ করে। MDM-এর মাধ্যমে ডেপ্লয় করা হলে নেটিভ OS supplicantগুলো বেশিরভাগ ম্যানেজড ডিভাইস সিনারিও কভার করে। থার্ড-পার্টি ক্লায়েন্টগুলো নির্দিষ্ট ক্ষেত্রে অতিরিক্ত সুবিধা যোগ করে: প্রোপ্রাইটরি EAP পদ্ধতি, সামঞ্জস্যপূর্ণ কনফিগারেশন প্রয়োজন এমন মিশ্র-OS এস্টেট, বা সেলফ-সার্ভিস BYOD অনবোর্ডিং। মনে রাখার মতো তিনটি বিষয়: প্রতিটি supplicant প্রোফাইলে আপনার RADIUS সার্ভার সার্টিফিকেট যাচাই করুন, বড় পরিসরে EAP-TLS স্থাপন করার আগে সার্টিফিকেট নবায়ন প্রক্রিয়াটি স্বয়ংক্রিয় করুন, এবং 802.1X সমর্থন করতে পারে না এমন ডিভাইসগুলোকে — IoT, পুরোনো হার্ডওয়্যার — ব্যাকআপ হিসেবে MAC Authentication Bypass সহ ডেডিকেটেড VLANs-এ আলাদা করুন। আপনার নেটওয়ার্ক অ্যাক্সেস আর্কিটেকচারের সাথে Purple কীভাবে যুক্ত হয় সে সম্পর্কে আরও জানতে, purple dot ai ভিজিট করুন। শোনার জন্য ধন্যবাদ।