আপনি যদি অ্যাক্টিভ ডিরেক্টরি (Active Directory) হ্যাকিং বা ডিফেন্স নিয়ে একটুও ঘাঁটাঘাঁটি করে থাকেন, তবে Kerberos Delegation শব্দটার মুখোমুখি আপনাকে হতেই হয়েছে। বেশিরভাগ টেক্সটবুক বা বইগুলোতে এটি এমন সব কঠিন তীর চিহ্ন আর টেক্সটের পাহাড় দিয়ে বোঝানো হয়, যা দেখে মনে হয় জিনিসটা বুঝি দুনিয়ার সবচেয়ে জটিল কোনো বিষয়।
চলুন সব কর্পোরেট কঠিন ভাষা বাদ দিয়ে একদম সহজ বাংলায় বোঝা যাক ডেলিগেশন আসলে কী, বাস্তব দুনিয়ায় এটি কীভাবে কাজ করে এবং কেন এটি অ্যাটাকার বা হ্যাকারদের জন্য একটি সোনার খনি।
মূল বিষয়: ডেলিগেশন (Delegation) আসলে কী?
মনে করুন আপনার প্রিয় কোনো ট্রাভেল বুকিং ওয়েবসাইটের কথা। আপনি সেখানে লগইন করলেন, একটি হোটেল পছন্দ করলেন এবং পেমেন্ট বাটনে ক্লিক করলেন। আপনার বুকিংটি কনফার্ম করার জন্য ওই ওয়েবসাইটটিকে ব্যাকএন্ডে থাকা একটি ডাটাবেজ সার্ভারের সাথে যোগাযোগ করতে হবে, যাতে সে খালি রুম আছে কিনা তা দেখতে পারে এবং তথ্য আপডেট করতে পারে।
ডাটাবেজ কিন্তু এই ওয়েব সার্ভারটিকে অন্ধের মতো বিশ্বাস করতে পারে না। যদি করত, তবে কোনো হ্যাকার ওয়েব সার্ভার হ্যাক করে যেকোনো ইউজারের ডাটা বদলে দিতে পারত। তাই ডাটাবেজের জানা প্রয়োজন ঠিক কে এই রিকোয়েস্ট বা অনুরোধটি করছে।
এখন প্রতিবার ডাটাবেজে ডাটা পাঠানোর জন্য আপনার স্ক্রিনে নতুন লগইন বক্স পপ-আপ করে পাসওয়ার্ড চাওয়ার তো কোনো মানে হয় না। তাই ওয়েব সার্ভার ডাটাবেজকে বলে: “হে ডাটাবেজ, এই ইউজারটি এইমাত্র আমার এখানে লগইন করেছে এবং সে আমাকে তার পক্ষে কাজ করার অনুমতি দিয়েছে।”
ডিজিটাল পাওয়ার অফ অ্যাটর্নি (Power of Attorney) বা ওকালতনামার মতো নিজের পরিচয় বা পারমিশন এভাবে অন্যের কাছে পাস করে দেওয়াকেই বলা হয় ডেলিগেশন (Delegation)। অ্যাক্টিভ ডিরেক্টরিতে এটি মূলত তিনটি ভিন্ন উপায়ে কাজ করে।
১. আনকনস্ট্রেইন্ড ডেলিগেশন (Unconstrained Delegation): উন্মুক্ত টেক্সাস
এটি ডেলিগেশনের সবচেয়ে পুরোনো সংস্করণ এবং সিকিউরিটির দিক থেকে এটি একটি আস্ত হরর শো বা দুঃস্বপ্ন।
যখন একজন অ্যাডমিনিস্ট্রেটর কোনো সার্ভারে Unconstrained Delegation অপশনটি চালু করেন, তখন তারা মূলত অ্যাক্টিভ ডিরেক্টরিকে বলছেন: “আমি এই মেশিনটিকে নেটওয়ার্কের যেকোনো জায়গায়, যেকোনো সার্ভিসের কাছে, যেকোনো ইউজারের রূপ ধারণ করার (Impersonate) জন্য চোখ বন্ধ করে বিশ্বাস করি।”
এটি যেভাবে কাজ করে:
কেরবেরস (Kerberos) পাসওয়ার্ডের বদলে ডিজিটাল পাসের মতো টিকিট (Tickets) ব্যবহার করে। আপনি যখন এমন কোনো সার্ভারে কানেক্ট হবেন যেখানে আনকনস্ট্রেইন্ড ডেলিগেশন চালু আছে, তখন আপনার কম্পিউটার আক্ষরিক অর্থেই আপনার মেইন আইডি কার্ডের (যার টেকনিক্যাল নাম TGT - Ticket Granting Ticket) একটি কপি তৈরি করে ওই সার্ভারকে দিয়ে দেয়।
সার্ভারটি আপনার সেই আইডি কার্ড নিয়ে সরাসরি তার লোকাল মেমোরিতে (RAM) ক্যাশ করে রেখে দেয় যাতে পরে ব্যবহার করতে পারে।
হ্যাকারের স্বপ্ন: একজন হ্যাকার যদি কোনোভাবে এই আনকনস্ট্রেইন্ড ডেলিগেশন সার্ভারের অ্যাডমিন রাইটস পেয়ে যায়, তবে তাকে আর কিছুই করতে হবে না। সে কেবল চুপচাপ বসে অপেক্ষা করবে। যখনই কোনো ডোমেন অ্যাডমিনিস্ট্রেটর (Domain Administrator) কোনো সাধারণ কাজের জন্য ওই সার্ভারে কানেক্ট হবে, তখনই তার হাই-প্রিভিলেজড TGT টিকিটটি মেমোরিতে জমা হবে। হ্যাকার মেমোরি থেকে সেটি চুরি করে নেবে এবং মুহূর্তের মধ্যেই পুরো ডোমেন বা নেটওয়ার্কের মালিক হয়ে যাবে।
২. কনস্ট্রেইন্ড ডেলিগেশন (Constrained Delegation): অনুমোদিত তালিকা
মাইক্রোসফট খুব দ্রুতই বুঝতে পেরেছিল যে সার্ভারগুলোর কাছে সবার মাস্টার কি (Master Key) বা মূল চাবি জমা রাখাটা অত্যন্ত বিপজ্জনক আইডিয়া। তাই তারা নিয়ে এলো Constrained Delegation।
এখানে ওয়েব সার্ভারটিকে যেকোনো জায়গায় আপনার রূপ ধারণ করার ক্ষমতা দেওয়ার বদলে, একজন অ্যাডমিন একটি নির্দিষ্ট, আগে থেকে অনুমোদিত ব্যাকএন্ড সার্ভিসের তালিকা (Approved List) তৈরি করে দেন, যার বাইরে ওয়েব সার্ভারটি আর কোথাও যেতে পারে না।
এটি যেভাবে কাজ করে:
এই পদ্ধতিতে ওয়েব সার্ভার আর আপনার মূল আইডি কার্ডের (TGT) কপি পায় না। এর পরিবর্তে, যখন তার আপনার পক্ষ থেকে ডাটাবেজের সাথে কথা বলার প্রয়োজন হয়, তখন সে ডোমেন কন্ট্রোলারের (Domain Controller) কাছে গিয়ে বলে: “আমার SQL ডাটাবেজের জন্য একটি সার্ভিস টিকিট লাগবে এবং আমি এটি অ্যালিস (Alice) এর পক্ষ থেকে অনুরোধ করছি।”
ডোমেন কন্ট্রোলার তখন ওয়েব সার্ভারের অ্যাকাউন্টের একটি বিশেষ অ্যাট্রিবিউট চেক করে, যার নাম msDS-AllowedToDelegateTo। যদি ওই ডাটাবেজটি এই নির্দিষ্ট তালিকায় থাকে, তবেই সে টিকিটটি ইস্যু করে। ওয়েব সার্ভার কেবল সেখানেই যেতে পারে যেখানে তাকে স্পষ্টভাবে অনুমতি দেওয়া হয়েছে।
৩. রিসোর্স-বেসড কনস্ট্রেইন্ড ডেলিগেশন বা আরবিসিডি (Resource-Based Constrained Delegation - RBCD)
ঐতিহ্যগত বা ট্র্যাডিশনাল কনস্ট্রেইন্ড ডেলিগেশন ভালো কাজ করলেও এটি সিস্টেম অ্যাডমিনদের জন্য একটি বড় মাথাব্যথার কারণ ছিল। কারণ, ফ্রন্ট-এন্ড ওয়েব সার্ভারকে নিজের কাছে তালিকা রাখতে হতো যে সে কোথায় কোথায় যেতে পারবে। এখন ডাটাবেজ টিম যদি নতুন কোনো ডাটাবেজ সার্ভার তৈরি করে, তবে তাদের ওয়েব সার্ভার টিমের কাছে টিকিট ওপেন করে বসে থাকতে হতো যাতে তারা ম্যানুয়ালি সার্ভারের অ্যাট্রিবিউট আপডেট করে দেয়।
Resource-Based Constrained Delegation (RBCD) এই পুরো নিয়মটাকে উল্টে দেয়।
এখানে ওয়েব সার্ভার নিজে তালিকা রাখার বদলে, ব্যাকএন্ড ডাটাবেজ নিজেই গেস্ট লিস্ট হাতে থাকা একজন বাউন্সার (Bouncer) হিসেবে কাজ করে। ডাটাবেজ নিজেই সিদ্ধান্ত নেয় কোন কোন ফ্রন্ট-এন্ড সার্ভারকে সে তার ইউজারদের রূপ ধারণ করতে দেবে। এতে ডেটা সুরক্ষার দায়িত্ব ও নিয়ন্ত্রণ সরাসরি সেই ডেটার মালিক বা ব্যাকএন্ড টিমের কাছে চলে আসে, যা নেটওয়ার্ক ম্যানেজমেন্টকে অনেক সহজ ও গোছানো করে তোলে।
পর্দার আড়ালে: S4U2Self এবং S4U2Proxy
এই কনস্ট্রেইন্ড ডেলিগেশনকে বাস্তবে সচল করার জন্য অ্যাক্টিভ ডিরেক্টরি ব্যাকগ্রাউন্ডে দুটি এক্সটেনশনের ওপর নির্ভর করে। এদের নাম শুনতে কিছুটা রোবটের মতো লাগলেও, এদের কাজের ধরন বেশ সহজ।
S4U2Proxy (টিকিট পাস করা)
এটি হলো ঠিক সেই স্বাভাবিক প্রক্রিয়া যা আমরা একটু আগে আলোচনা করলাম। একটি সার্ভিস কোনো ইউজারের কেরবেরস আইডেন্টিটি বা পরিচয়পত্রটি নেয় এবং নিরাপদে সেটিকে ব্যাকএন্ড রিসোর্সের কাছে পাস করে দেয়।
S4U2Self (প্রোটোকল ট্রানজিশন)
ধরুন, কোনো ইউজার কেরবেরস ব্যবহার না করে পুরোনো কোনো প্রোটোকল (যেমন NTLM) বা কোনো ওয়েব ফর্মের মাধ্যমে ওয়েব সার্ভারে লগইন করল। তাহলে তো ওয়েব সার্ভারের কাছে ডাটাবেজে পাঠানোর মতো কোনো কেরবেরস টিকিটই থাকবে না!
ঠিক এই জায়গাতেই S4U2Self উদ্ধারকর্তা হিসেবে কাজ করে, যার টেকনিক্যাল নাম Protocol Transition:
- ওয়েব সার্ভার ডোমেন কন্ট্রোলারকে বলে: “হে ডোমেন কন্ট্রোলার, বব (Bob) আমার সাইটে NTLM দিয়ে লগইন করেছে। আপনি কি দয়া করে তার জন্য একটি বৈধ কেরবেরস টিকিট তৈরি করে দিতে পারেন, যাতে আমি সেটি ব্যবহার করতে পারি?”
- ডোমেন কন্ট্রোলার তখন ববের জন্য একটি ফরওয়ার্ডেবল (Forwardable) কেরবেরস টিকিট তৈরি করে ওয়েব সার্ভারের হাতে দেয়।
কনস্ট্রেইন্ড ডেলিগেশন কনফিগার করার সময় একজন অ্যাডমিন চাইলে “Use Kerberos only” (যা এই সুবিধাটি বন্ধ করে দেয়) অথবা “Use any authentication protocol” (যা S4U2Self চালু করে) বেছে নিতে পারেন।
কোনো হ্যাকার যদি এমন কোনো সার্ভিস অ্যাকাউন্ট হ্যাক করতে পারে যার “Use any authentication protocol” সুবিধাটি চালু আছে, তবে সে S4U2Self এর অপব্যবহার করে ডোমেন কন্ট্রোলারের কাছ থেকে যেকোনো অ্যাডমিনিস্ট্রেটরের টিকিট একদম শূন্য থেকে (Out of thin air) বানিয়ে নিতে পারে। ইন্টারনেটে আপনারা যে সমস্ত অ্যাটাক স্ক্রিপ্ট বা হ্যাকিং টিউটোরিয়াল দেখেন, সেগুলো মূলত এভাবেই কাজ করে।