اشاره :
همان‌گونه كه در قسمت قبلی این مقاله در شماره 46 اشاره شد، برای برقراری امنیت در شبكه‌ها چندین پروتكل امنیتی ساخته شده‌اند كه یكی از آن‌ها كربروس می‌باشد. در قسمت اول با مفاهیم اولیه پروتكل تشخیص هویت و نحوه كاركرد كربروس آشنا شدید و نسخه 4 این پروتكل مورد بررسی قرار گرفت. در این قسمت نسخه‌های جدیدتر كربروس را به تفضیل بررسی می‌كنیم.

 
نسخه 5 كربروس
در نسخه 5 بیشتر مشكلات نسخه‌های قبلی حل شده است به طوری كه الگوریتم رمز مورد استفاده و پروتكل آدرس‌دهی لایه شبكه با استفاده از Flagهایی در پیام‌ها مشخص می‌شوند و لذا به راحتی قابل تغییرند. طول عمر بلیط هم به صورت صریح به شكلِ زمان تولد و مرگ بلیط در پیام‌ها بیان می‌شود. البته غیر از رفع مشكلات نسخه 4، قابلیت‌های خاصی نیز در این نسخه اضافه شده است. گفت‌وگوی كربروس نسخه 5 به صورت جدول 2  می‌باشد. 

همان‌طور كه مشاهده می‌كنید باز هم گفت‌وگوها در سه مرحله انجام می‌شود و هدف گفت‌وگو‌های هر مرحله هم همان است كه در نسخه 4 گفته شد. فقط داده‌های خاصی در پیام‌ها اضافه شده كه این داده‌ها به شرح زیر هستند:

Times: كلاینت، این داده را ارسال می‌كند تا درخواست كند كه از خصوصیات زمانی خاصی (time setting) توسط سرور استفاده شود (مثلاً زمان شروع و فرمت زمان)

Nonce: در دو پیام اول و سوم، كلاینت یك مقدار تصادفی به نام Nonce را تولید كرده و به سرور تشخیص هویت در پیام اول و به TGS در پیام دوم ارسال می‌كند و سپس انتظار دارد كه در پاسخ‌هایی كه دریافت می‌كند همان Nonce قرار داده شده باشد، البته به صورت رمز شده. به این ترتیب گام دیگری جهت جلوگیری از حمله تكرار و اطمینان از تازه بودن داده‌های دریافتی بر می‌دارد.

Options: در این داده، كلاینت درخواست می‌كند كه بلیط ویژگی‌های خاصی را داشته باشد.

Flags: ویژگی‌های خواسته شده در داده Options توسط كلاینت، در فیلد Flag بلیط نگهداری می‌شود. به عبارت دیگر flags خصوصیات و حالات خاصی را كه یك بلیط می‌تواند داشته باشد نشان می‌دهد. به عنوان مثال یكی از مقادیری كه flags  می‌تواند داشته باشد RENEWABLE است. بلیطی كه در فیلد flags آن، این قابلیت set شده باشد یعنی TGS،‌ در صورتی كه عمر بلیط تمام شود می‌تواند با دادن این بلیط به AS  بلیط جدیدی را دریافت كند و كلاینت درگیر دریافت بلیط مجدد ازAS ، نشود. توجه كنید كه در غیر این‌صورت لازم است كلاینت، مرحله اول گفت‌وگوی كربروس را انجام دهد و بلیط دیگری را دریافت كند.

Subkey: كلید دیگری می‌باشد كه كلاینت انتخاب كرده و در هر نشست به سرور ارسال می‌كند تا ارتباطات این نشست با این كلید رمز شود. البته این فیلد اختیاری است و در صورتی كه كلاینت آن را ارسال نكند، از همان كلید به اشتراك گذاشته شده در پیام 3 و 4 یعنی kc،v استفاده می‌شود.

Seq: شماره ترتیب پكت‌ها می‌باشد. كلاینت درAuthenticator شماره آغازی را به سرور ارسال می‌كند و سرور در هر بسته‌ای كه به كلاینت ارسال می‌كند یك رقم به این شماره اضافه می‌كند. استفاده از این فیلد جهت اطمینان از اصالت پیام‌ها می‌باشد. به این صورت كه در هر بسته می‌بایستی یك واحد به seq اضافه شده باشد و در صورتی كه seq مقدار مورد انتظار را نداشته باشد كلاینت آن را بسته معتبر نمی‌داند.

Realm: به مجموعه یك AS و TGS و سرورهای مربوطه و كلاینت‌هایی كه از AS استفاده می‌كنند یك قلمرو كربروس
(kerberos realm) می‌گویند. در پیام اول، كلاینت در داده Realmc مشخص می‌كند كه TGS موردنظر او در چه قلمرویی قرار دارد. در بلیط‌ها، Realm مشخص كننده قلمرویی است كه بلیط در آن اعتبار دارد. در داخل Authenticator هم كلاینت مشخص می‌كند كه خود او جزء كدام قلمرو است.
برای درك بیشتر به شكل 1  توجه كنید كه در آن كلاینت موجود در قلمرو A  می‌خواهد از سروری در قلمرو B  استفاده كند. لذا از TGS مربوط به قلمرو خود (A) درخواست بلیط استفاده از TGS قلمرو B را می‌كند و سپس از TGS قلمرو B  بلیط استفاده از سرور را می‌گیرد.
همان‌طور كه قبلاً نیز اشاره شد، طراحان كربروس این پروتكل را برای محیط خاصی طراحی نكرده‌اند و لذا این پروتكل توسط شركت‌های مختلف به صورت‌های گوناگونی پیاده‌سازی شده است. آن‌چه كه تا این‌جا شرح داده شد استاندارد اصلی كربروس (RFC 1510) بود، در ادامه چگونگی پیاده‌سازی كربروس در ویندوز 2000 را بررسی می‌كنیم.

كربروس در ویندوز 2000
 
شكل 1
 
یكی از مفاهیمی كه در دنیای امنیت مطرح می‌شود این است كه زیر ساخت‌های امنیتی تا جایی كه امكان دارد از دید كاربر نهایی پنهان یا شفاف (transparent) باشد. به عبارت دیگر، كاربر نهایی جز در مواقع لزوم، درگیر مسایل امنیتی شبكه نشود (درگیر نشدن كاربر نهایی با مسایل امنیتی امتیاز بزرگی است ولی متأسفانه در اغلب موارد برنامه‌نویسان (developers) هم به صورت كاربر نهایی با مسایل امنیتی برخورد می‌كنند و هم در سطح حرفه‌ای از (1) SSPI استفاده می‌كنند حال این‌كه SSPI  واسطی است برای درگیر نشدن با جزییات زیرساخت‌های امنیتی!) مایكروسافت این امر را در سیستم‌های خود كاملاً رعایت كرده است به طوری كه شاید تعجب كنید اگر بشنوید كه وقتی یك Domain ویندوز 2000 راه‌اندازی می‌كنید در واقع یك قلمرو كربروس هم ایجاد كرده‌اید كه شامل Domain Controller و كلاینت‌‌های متصل به آن می‌باشد، به عبارت دیگر Domain و قلمرو كربروس به یك مفهوم می‌باشند و در دنیای مایكروسافت به قلمرو كربروس نام Domain اطلاق می‌شود. در یك قلمرو كربروس، دو سرور وجود داشتند كه یكی سرور تشخیص هویت (AS) و دیگری سرور اعطا‌كننده بلیط (LTGS) بود. مایكروسافت این دو سرور را در یك سرور قرار داده كه همان Domain Controller شبكه است. یعنی Domain Controller وظیفه تشخیص هویت و صدور بلیط TGT (مانند AS)  و نیز صدور بلیط برای استفاده از سرورهای موجود در شبكه (مانند TGS) را به عهده دارد. اگر تاكنون به ساختار ویندوز 2000 توجه كرده باشید متوجه شده‌اید كه زیرساخت و سرویس‌های امنیتی ویندوز2000 در نقطه خاصی از ساختار سیستم‌عامل قرار ندارد و در كلِ ساختار این سیستم‌عامل پراكنده شده‌اند كه كربروس هم از این قاعده مستثنی نیست. لذا درك چگونگی كاركرد كربروس شاید كمی پیچیده به نظر برسد. در ادامه به صورت جزیی‌تر ساختار كربروس در ویندوز 2000 را بررسی می‌كنیم.

در كلاینت‌‌هایی كه عضو Domain ویندوز2000 هستند كتابخانه‌ای به نام Kerberos.dll وجود دارد كه دو مجموعه از توابع را ارایه می‌كند:
1- توابع لازم جهت ساختن پیام‌هایی كه سیستم كلاینت در پروتكل كربروس ارسال می‌كند استفاده  می‌شود.
2- توابعی كه پاسخ‌های سرور را گرفته و اصالت پاسخ را بررسی كرده و نیز قسمت‌های لازم مانند بلیط را از پاسخ دریافتی جدا می‌كنند.
(كتابخانه‌ها یا dll‌ها، برنامه‌هایی هستند كه مانند سایر برنامه‌ها نوشته می‌شوند ولی معمولاً دارای فرم و دیالوگ نیستند و خودشان به تنهایی كاری  انجام نمی‌دهند، بلكه لازم است برنامه دیگری نوشته شود كه از توابع داخل این كتابخانه‌ها استفاده كند). با استفاده از این كتابخانه سیستم كلاینت وقتی می‌خواهد پیام اولی را كه در ساختار پروتكل كربروس توضیح داده شد ارسال كند، یكی از توابع كتابخانه kerberos.dll را فراخوانی می‌كند و اطلاعات لازم برای ساختن پیام اول را (نام DC، نام كاربر، كلمه عبور، nonce) در اختیار این تابع قرار می‌دهد و این تابع پیام را ساخته و به كلاینت می‌دهد تا به سمت سرور ارسال كند. همچنین هنگام دریافت پاسخ سرور، بسته پاسخ را در اختیار یكی دیگر از توابع این كتابخانه قرار می‌دهد تا صحت بسته دریافتی را كنترل كند و بلیط را از بقیه داده‌ها جدا كند. كتابخانه‌ای هم با نام Kerberos key distribution Center service) kdcsvs.dll) روی سرور وجود دارد كه كاری مشابه Kerberos.dll  به عهده دارد با این تفاوت كه توابع لازم جهت دریافت بسته‌های ارسالی از كلاینت و بررسی اصالت بسته و ساختن پاسخ مناسب در جواب به درخواست كلاینت را در خود دارد.
همان‌طور كه گفته شد، كتابخانه‌ها به تنهایی قابل استفاده نیستند و لازم است برنامه دیگری از توابع كتابخانه استفاده كند. كتابخانه‌های سمت سرور و كلاینت كربروس نیز توسط برنامه دیگری فراخوانی شده و مورد استفاده قرار می‌گیرند.  برنامه‌ای كه از كتابخانه‌ها استفاده می‌كند خود یك برنامه دو بخشی است. (فرض كنید دو فایل .exe  كه از توابع همدیگر استفاده می‌كنند) یك بخش از این برنامه Security reference monitor) srm) نام دارد كه جزء قسمت Executive ویندوز 2000 است (قسمت Executive  ویندوز 2000 شامل برنامه‌ها و ماژول‌های سیستمی است كه دارای حقوق ویژه‌ای جهت دسترسی به تمام منابع سخت‌افزاری و نرم‌افزاری سیستم می‌باشند) قسمت دوم این برنامه local security authority subsystem) lsass.exe) نام دارد كه جزء قسمت Usermode ویندوز 2000 می‌باشد كه با حق دسترسی كمتری نسبت به srm  اجرا می‌شود و شما می‌توانید آن را در task manager  مشاهده كنید. توجه داشته باشید كه srm  و lsass  فقط جهت پیاده‌سازی پروتكل كربروس در ویندوز 2000  قرار نگرفته‌اند بلكه این دو برنامه لایه‌ای را فراهم می‌كنند كه ویندوز2000 بتواند بدون هیچ‌گونه تنظیمات اضافی، در صورتی كه لازم باشد از پروتكل‌های دیگری (كتابخانه‌های امنیتی دیگری كه در سیستم وجود دارد) جهت تشخیص هویت استفاده كند. LSASS دارای دو سرویس با نام‌های winlogon و netlogon است كه توسط آن‌ها اطلاعات هویتی كاربر را می‌گیرد. WINLOGON سرویسی است كه فرم welcome و پس از فشردن Alt+Ctrl+Del فرم درخواست نام كاربری و كلمه عبور و نام Domain را نشان می‌دهد.

حال كه ساختار كلی كربروس را متوجه شدید قدم به قدم سناریویی كه ویندوز 2000 در هر بار ورود به Domain   اجرا می‌كند را دنبال می‌كنیم:
‌? ‌winlogon  پس از دریافت Alt+Ctrl+Del  فرم ورود به ویندوز (Domain) را نشان می‌دهد.

? نام كاربری، كلمه عبور،  نام Domain را وارد می‌كنید و دكمه OK را كلیك می‌كنید.

? ‌winlogon اطلاعات وارد شده توسط شما را  گرفته و به lsass  می‌دهد. LSASS با استفاده از توابع موجود در كتابخانه kerberos.dll  كلمه عبور وارد شده را با توابع درهم‌سازی (5 MD) از حالت عادی خارج می‌كند و متن عادی كلمه عبور به سرعت از بین می‌رود.

? چنانچه شما نام Domain را وارد نكرده باشید روال تشخیص هویت توسط winlogon ادامه پیدا می‌كند، ولی در این‌جا فرض می‌كنیم كه می‌خواهیم وارد Domain شویم، لذا ادامه روال تشخیص هویت به netlogon منتقل می‌شود. netlogon با استفاده از كتابخانه كربروس درخواست كلاینت را می‌سازد. این درخواست شامل: آدرس IP  كلاینت، نام DC  موردنظر، logon ID name و یك عدد تصادفی به نام nonce  كه با استفاده از مقداری كه در مرحله قبل با  اعمال توابع درهم‌سازی روی كلمه عبور كاربر توسط winlogon  به دست آمده بود رمز شده است. كلاینت انتظار دارد سرور بتواند آن را (nonce)  از رمز خارج كرده و مجدداً به كلاینت ارسال كند. البته باز هم به شكل رمز شده، و لذا هویت سرور به كلاینت اثبات می‌شود. ضمناً سرور هم انتظار دارد كه با استفاده از كلید خصوصی كلاینت كه در Active Directory  نگهداری می‌شود، بتواند آن را از رمز خارج كند. Active Directory  یك بانك اطلاعاتی (DB) برای نگهداری موجودیت‌های یك شبكه می‌باشد.

? ‌netlogon  پس از ساختن پیام با استفاده از DNS  موجود در شبكه IP  آدرس كامپیوتر Domain controller  را به دست می‌آورد و پیام ساخته شده را ارسال می‌كند و سپس منتظر پاسخ می‌شود.

? سرویس netlogon موجود روی سرور، درخواست بلیط tgt  كلاینت را می‌گیرد و آن را به lsass می‌دهد. lsass با استفاده از كتابخانه kdcsvc.dll  موجود روی سرور نام كاربر را در Active Directory  جستجو می‌كند، چنانچه نام پیدا شود با استفاده از كلمه عبور آن كاربر كه در Active Directory  ثبت شدهnonce  را از رمز خارج می‌كند و در ادامه پس از تشخیص اصالت پیام، DC در پاسخ به درخواست كلاینت، داده‌های زیر را به آن ارسال می‌كند.
1- فلگر مشخص‌كننده نوع پیام (بلیطTGT) 
2- داده‌هایی كه با استفاده از كلید كلاینت رمز شده كه شامل:
1- كلید نشست،  تاریخ انقضای كلید، تاریخ تشخیص هویت،  زمان شروع و پایان استفاده از بلیط، نام Domain  كه بلیط در آن معتبر است و nonce  می‌باشد.
3- بلیط TGT (كه توسط كلیدی كه در اختیارDC و سرورهای موجود در شبكه member servers می‌باشد، رمز شده است

?‌ سرویس كربروسِ سمت كلاینت، پیام را دریافت كرده و پس از بررسی‌های لازم و تشخیص اصالت پیام، شما وارد Domain می‌شوید.
نتیجه این روال تشخیص هویت، ورود شما به Domain و به دست آوردن بلیط TGT می‌باشد و در هر بار كه وارد Domain  ویندوز2000 می‌شوید این روال طی می‌شود.
بدیهی است وقتی شما می‌خواهید به سروری كه در Domain  قرار دارد دسترسی پیدا كنید و از منابع آن استفاده كنید، روالی كه در پروتكل كربروس شرح داده شده با استفاده ازlsass و كتابخانه‌های كربروس طی می‌شود (پیام‌های 3 و 4 با DC و 5 و 6 با سرور موردنظر تبادل می‌شوند) كه در این‌جا به شرح مجدد آن‌ها نمی‌پردازیم.
پروتكل كربروس پروتكل پیش‌فرض تشخیص هویت در ویندوز 2000 می‌باشد و برای استفاده از آن هیچ‌گونه تنظیماتی را نیاز نداریم. با این وجود در قسمت سیاست‌های امنیتی (Domain Policy console)  قسمتی با نام Policy Kerberos  وجود دارد كه از طریق آن می‌توانید برخی از مشخصات بلیط‌ها و به‌طور كلی پروتكل را تغییر دهید. به عنوان مثال طول مدت عمر بلیط، proxiable  بودن بلیط كه مشخص می‌كند سیستمی به نمایندگی از صاحب اصلی بلیط، بلیط را استفاده می‌كند (كلاینت A  به سرور B  دسترسی پیدا می‌كند و در حین استفاده از B  حالتی پیش می‌آید كه B  برای پاسخ به A  لازم است از سرور C استفاده كند در چنین حالتی B  از بلیط A  استفاده كرده و به C وصل می‌شود) و برخی دیگر از مشخصات بلیط‌ها كه قابلیت تنظیم دارند. توجه داشته باشید كه این تنظیمات به صورت پیش‌فرض تماماً مقادیری كه در استاندارد 1510RFC  كربروس آمده است نیستند و مایكروسافت با توجه به پیاده‌سازی خود، آن‌ها را تنظیم كرده است. همچنین ملاحظه كردید كه در بسیاری از موارد دیگر هم پیاده‌سازی مایكروسافت با استاندارد ارایه شده متفاوت است از جمله یكی دیگر از این تفاوت‌های مهم این است كه در استاندارد ارایه شده از پروتكل udp  استفاده می‌شود ولی در ویندوز 2000 ازtcp استفاده می‌گردد.

منابع:
1- Cryptography and network security
By: William Stallings
2- Inside windows 0002 server 
by: William Boswell
3- windows 2000 network security design 
by: Roberta Bragg، MCSE، MCT

پی‌نوشت:
(1) Security Service Provider Interface یا Security Support Provider Interface