مقدمه
در عصر جدید همه مردم و به ویژه کسب‌و‌کارها خواهان یک ارتباطات امن هستند. هر روز به تعداد سازمان‌هایی که ترجیح می‌دهند از زیرساخت‌های شبکه برای انجام فعالیت‌های تجاری خود استفاده کنند افزوده میشود. عامل اصلی برای ایمن‌سازی ارتباطات در زیرساخت‌های توزیع شده، احراز هویت و حصول اطمینان از این مسئله است
دانشمندان علوم کامپیوتر دانشگاه MIT، اولین پژوهشگرانی بودند که از واژه Kerberos (یکی از قهرمان اساطیر یونانی) برای نام‌گذاری یک پروتکل احراز هویتی استفاده کردند که درون شبکه‌های کامپیوتری استفاده میشود. کربروس (Kerberos) یک پروتکل تحت شبکه است که در سطحی گسترده برای حل مشکل احراز هویت استفاده میشود. کربروس از رمزنگاری کلید متقارن و یک مرکز توزیع کلید KDC سرنام Key Distribution Center استفاده میکند و برای تایید هویت کاربر به مجوز ثالث مورد اعتماد نیاز دارد. کربروس به 3 عنصر مجزا برای احراز هویت نیاز دارد و از یک سیستم رهگیری و نظارتی قدرتمند برای امن‌تر نگه داشتن محاسبات استفاده میکند.
کربروس چیست؟
احراز هویت کربروس در حال حاضر فناوری احراز هویت پیش‌فرض ویندوز مایکروسافت است، اما پیاده‌سازی کربروس در یونیکس، لینوکس Apple OS و FreeBSD امکان‌پذیر است. مایکروسافت نسخه کربروس خود را همراه با ویندوز 2000 معرفی کرد. همچنین این فناوری به یک استاندارد برای وبسایت‌ها و احراز هویت شناسایی یگانه (Single Sign-On) در پلتفرم‌های مختلف تبدیل شده است. لازم به توضیح است که کنسرسیوم کربروس این فناوری را به عنوان یک پروژه منبع‌باز نگهداری میکند. کربروس به نسبت فناوری‌های احراز هویت قبل از خود پیشرفت چشم‌گيری داشته است. رمزنگاری قدرتمند و توکن احراز هویت ثالث باعث میشوند تا نفوذ به شبکه توسط مجرمان سایبری با دشواری زیادی همراه باشد. این فناوری همانند سایر نمونه‌های مشابه در بخش‌هایی آسیب‌پذیر است که اگر درباره این آسیب‌پذیرها اطلاع کافی داشته باشید، دفاع در برابر هکرها امکان‌پذیر میشود. کربروس اینترنت را به محیطی امن‌تر تبدیل کرد و این امکان را برای کاربران فراهم کرد تا فارغ از نگران‌های امنیتی و بدون نگرانی از بابت مشکلات امنیتی در دفتر کار خود با اینترنت کار کنند.
چه تفاوتی بین کربروس و NTLM وجود دارد؟
قبل از کربروس مایکروسافت از یک فناوری احراز هویت به‌نام NTLM (NT Lan Manager ) استفاده می‌کرد که یک پروتکل احراز هویت چالش-پاسخ بود. کامپیوتر یا کنترل‌کننده دامنه گذرواژه‌ها را بررسی و هش گذرواژه را برای استفاده مداوم ذخیره می‌کرد. بزرگ‌ترین تفاوت این دو سیستم در احراز هویت ثالث و توانایی رمزنگاری قدرتمندتر کربروس است. کربروس در مقایسه با NTLM از یک لایه امنیتی اضافی در فرآیند احراز هویت استفاده میکند. این روزها سیستم‌های مبتنی بر NTLM را می‌توان در عرض چند ساعت هک کرد. به بیان ساده NTLM یک فناوری قدیمی و به تعبیری منسوخ شده است که نباید برای محافظت از داده‌های حساس از آن استفاده کرد.
نحوه کار کردن Kerberos V5
در ابتدا باید به این نکته اشاره کنم که در این مقاله درباره نحوه کار کردن پروتکل امنیتی Kerberos v5 صحبت میکنیم. نوشتن این مقاله بیشتر برای دوستانی هست که متخصص سرویس های مایکروسافتی هستند و خُب قطعا پایه ای ترین سرویس مایکروسافتی یعنی Active Directory. دیگه زیاد حرف نمیزنم بریم سراغ اصل مطلب، امیدوارم لذت ببرید و براتون مفید باشه.
توضیح درمورد خود Kerberos
این کلمه که ریشه یونانی هم داره، به معنای سگ سه سر نگهبان هست. اما این سه سر در مایکروسافت به چه شکل هست؟
۱- Client
۲- Server(Application)
۳- KDC(Key Distribution Center)
در اینجا KDC درواقع Trusted بقیه اجزا هست یعنی Server, Client بهش اعتماد دارن.
Kerberos در مایکروسافت
خُب دوستان همونطور که شما بهتر از من اطلاع دارید، این پروتکل فقط مُختص مایکروسافت نیست و تو برند های دیگه مثل لینوکس، مک و یونیکس هم استفاده میشه.
اما در پیاده سازی که مایکروسافت انجام داده، این پروتکل رو تحت دو عنوان ارائه میکنه :
۱- Microsoft SSP(Security Support Provider)
۲- DLL(Dynamic-Link Library)
اما از اونجایی که شاید خیلی از شما با DLL آشناییت داشته باشید یا به گوشتون خورده باشه ما بیشتر درمورد SSP صحبت میکنیم. چون در اکثر موارد پروتکل Kerberos تحت عنوان SSP مطرح میشه.
حالا این سوال پیش میاد که SPP چی هست و آیا در SSP فقط پروتکل Kerberos وجود دارد یا خیر.
SSP چیه؟
درواقع SSP یک قسمتی از ویندوز هست که وظیفه انجام امور امنیتی را داره، مثل Authentication یا همان اهراز هویت. که این کار رو با استفاده از SSPI انجام میده.
SSPI چی هست؟!
SSPI یا Security Support Provider Interface، همونطور که از اسمش پیدا هست یک رابط بین SSP و اون Application هست که نیاز به مثلا Authentication داره. به عکس زیر دقت کنید :
SSP هایی که در ویندوز وجود دارند :
۱- Kerberos
۲- NTLM
۳- Digest
۴- Schannel
۵- Negotiate
۶- SSP های دیگری که میتوانند با SSPI تعامل داشته باشند.
نقش LSA(Local Security Authority) چیه؟
دوستان وظیفه LSA اینه که بستری امن فراهم کنه برای ارتباط بین SSP و SSPI و اون Application که نیاز به Authentication داره. به عکس زیر دقت کنید :
Shared-Secret Keys
درواقع Kerberos برای Authentication شدیدا به قابلیت Shared-Secret Keys متکی هست.
درکل اگر بخوام درمورد Shared-Secret Keys صحبت کنم، باید بگم این قابلیت به این صورت است که برای مثال شما فکر کنید میلاد و علی یک رمز برای اینکه از یکدیگر مطمئن شوند دارند و این دو نفر با استفاده از این رمز میتوانند همدیگر رو اهراز هویت کنن.
دقیقا این همون اتفاقی هست که در Kerberos رخ میده. حالا برای اینکه، این کار در پروتکل Kerberos درست عمل بکنه باید Symmetric یا همون متقارن باشه. متقارن یعنی با اون تک کلید هم عملیات Encrypt و هم عملیات Decrypt انجام بشه.
در Kerberos برای اینکه هردو طرف همدیگر رو Authenticate کنن، یکی باید با اون Share-Secret key درخواست رو Encrypt کنه و طرف مقابل هم باید اگر اون کلید رو داشته بتونه Decrypt کنه و محتوا درخواست رو ببینه.
انواع Kerberos Keys
۱- Long-term symmetric keys
۲- Long-term asymmetric keys
۳- Short-term symmetric keys
پایین تر درمورد هر کدوم از این ها صحبت میکنیم.
۱- Long-term symmetric keys:
برای User, System, Service و Inter Realm keys به این صورت هستند. این کلید ها از Password ها بدست میان. به این صورت که از یک تابع رمزنگاری بوجود میان.(Cryptographic Function)
User Keys :
Long-term key از پسورد یوزر بدست میاد. این کلید به عنوان یک آبجکت در AD نگهداری میشه. User key زمانی که یوزر لاگین میکنه ساخته میشه.
System Keys :
وقتی سیستمی جوین دامین میشه، یک پسورد بهش داده میشه. از این پسورد برای ساخت Long-term key استفاده میشه.
Service Keys :
سرویس از کلید User Account استفاده میکنه که با اون استارت میشه برای مثال اگر Service A با یوزر Milad ران میشه، از Long-term key همون یوزر استفاده میکنه.
نکته مهم : تمامیه KDC ها در یک Realm(Domain) از یک Long-term Key استفاده میکنن. برای اینکه همه KDC ها از یوزر krbtgt استفاده میکنن.
Inter-Realm Keys :
برای اینکه بین دامین ها Authentication رخ بده باید KDC هایی که در دامین های متفاوت هستند، Inter-Realm Key داشته باشن تا برای ارتباط با یکدیگر بین دامین استفاده کنن. این Inter-Real Key درواقع مبنای Transitive Trust در Forest هست. اگر Shortcut Trust ایجاد کنیم، این به این معناست که اون دو دامین Inter-Realm Key مختص خودشون رو با هم Share میکنن.
Long-term asymmetric keys
درواقع همون Certificate و مبنای استفاده از Public , Private Keys هست.
Short-term symmetric keys
در Session Keys ها استفاده میشه. بعدا کاملا درمورد Session keyها توضیح میدم.
:Kerberos components
همونطور که در جدول مشاهده می کنید، Kerberos client برای گرفتن TGT باید به سرویس AS وصل شود و برای درخواست Service Ticket باید به سرویس TGS وصل شود.فرآیند درخواست TGT
TGT چیست؟
زمانی که کلاینت بعد از روشن شدن،ریستارت و یا Log off میخواهد Log in کند وقتی یوزر و پسورد را وارد میکند از KDC این TGT را دریافت میکند.
TGT فقط برای درخواست دادن Service Ticket استفاده می شود.
چه کسی میتواند داخل TGT را ببیند؟
کلاینت نمیتواند داخل TGT را ببیند. TGT با استفاده از KDC Shared-secret key انکریپت می شود. پس فقط KDC ها میتوانند اطلاعات درون TGT را ببینند.
Session Key چیست؟
وقتی کلاینت از KDC تیکت TGT را میگیرد، KDC به کلاینت یک Session key میدهد، که کلاینت از آن Session key برای انکریپت کردن درخواست های بعدی خود استفاده میکند. برای مثال وقتی میخواهد به فایل سرور که یک سرویس در شبکه هست وصل شود، با استفاده از Session key درخواست خود را انکریپت میکند.
آیا Session key در TGT وجود دارد؟
همونطور که در بالاتر توضیح دادم KDC به همراه TGT یک Session key هم برای کلاینت ارسال میکند. اما نکته ای که وجود دارد اینست که KDC این session key با استفاده از User’s long-term key انکریپت میکند تا فقط کلاینت بتواند آن را با کلیدی که فقط بین او و KDC به اشتراک گزاشته شده است دیکریپت کند. اما درون خود TGT نیز یک session key برای خود KDC وجود دارد و همانطور که گفتم کل TGT هم با استفاده از KDC Key انکریپت شده است تا فقط خود KDC ها که در یک Realm(Domain) هستند بتوانند محتویات آن را ببینند.
نکته : از دید کلاینت TGT فقط یک تیکت معمولی هست که برای درخواست Service ticket به آن نیاز دارد. کلاینت اطلاعاتی از محتویات TGT ندارد.
دید KDC نسبت به TGT چیست؟
از نظر KDC تیکت TGT بهش این قابلیت رو میده تا هر دفعه که کلاینت درخواست میده نیاز نباشه از کلید یوزر استفاده و هر دفعه دنبال Long-term key یوزر بگرده. KDC فقط یکبار سراغ Long-term key یوزر میره اونم زمانیه که کلاینت میخواد Log in کنه.
دید KDC نسبت به TGT چیست؟
از نظر KDC تیکت TGT بهش این قابلیت رو میده تا هر دفعه که کلاینت درخواست میده نیاز نباشه از کلید یوزر استفاده و هر دفعه دنبال Long-term key یوزر بگرده. KDC فقط یکبار سراغ Long-term key یوزر میره اونم زمانیه که کلاینت میخواد Log in کند.
:Service Ticket
در ابتدا کلاینت credential cache خودش رو چک میکنه برای اینکه Service ticket مورد نظرش رو پیدا کنداگر نباشه دنبال TGT خودش میگردد بعد Session key که باید برای ارتباط با KDC استفاده کند رو پیدا میکنه بعد با استفاده از Session key، Authenticator رو آماده میکنه.(درمورد Authenticator صحبت میشه)بعد درخواست Service ticket رو به همراه TGT و Authenticator میفرسته به KDC.
فرآیند درخواست Service Ticket
Service ticket برای چه موردی استفاده میشه؟
Service Ticket این اجازه رو به سرویس TGS(Ticket Granting Service) میده تا بتونه بصورت امن، Credential یوزر درخواست کننده رو انتقال بدهد به سرور مقصد.
TGS چه جوابی به درخواست Service Ticket میده؟
در جواب، سرویس TGS دو عدد Session key رو به همراه Service ticket برای کلاینت ارسال میکنه. Session key که برای کلاینت هست رو با استفاده از Long-term Key خود کلاینت encrypt میکند و Session key که برای اون سرویس مدنظر هست رو، داخل Service Ticket قرار میده و کل Service Ticket رو هم با کلیدی که فقط بین KDC و اون سرویس به اشتراک گزاشته شده encrypt میکنه. پس داخل این Service Ticket رو فقط KDC و اون سرویس میتوانند ببینند.البته این Service Ticket به کلاینت سپرده میشه، تا زمانی که بهش نیاز دارد ازش استفاده بکنه و بفرسته برای سرویس مورد نظر.
چطور کلاینت از Service ticket استفاده میکند؟
به Target service یک پیام میفرسته که شامل Service ticket و Authenticator هست. Service ticket هم که با کلیدی که بین KDC و Target service شِیر هست، encrypt می شود. Authenticator هم با Session Key که بین کلاینت و Target service استفاده میشود، encrypt میشود.
مزایای Service ticket؟
نیازی نیست Target service، همه Session key ها رو داشته باشه و رو سیستم خودش ذخیره کنه. هرموقع Service ticket ارسال بشه، Target service اون Session key رو از داخل Service ticket پیدا و استفاده میکند . کلاینت هم نیازی نیست، هر دفعه سراغ KDC بره و درخواست Service ticket بده. میتونه از یک Service ticket بی نهایت استفاده کنه تا زمانی که اون تیکت منقضی بشه.
یک تیکت تا چه مدت معتبر است؟
بستگی به پالیسی Realm(Domain) داره. زمانی هم که یوزر Log off کند، تمامیه Credential cache پاک میشود.
داخل یک تیکت چه اطلاعاتی هست؟
به غیر از ۳ قسمت اول، بقیه اطلاعات انکریپت میشوند.
یکی از مهمترین قسمت ها، Authorization Data هست.
Authorization Data برای Windows Client ها:
در این قسمت اطلاعاتی مربوط به SID و Group Relative(RID) یوزر در آن قرار میگیرد و این اطلاعات توسط KDC و در هنگام درخواست Service ticket و یا TGT بوجود می آید که این اطلاعات میتواند توسط یک چیزی به اسم PAC(Privilege Attribute Certificate) هم ارائه بشه.
PAC چیه؟
هر بار که کلاینت برای درخواست TGT یا Service ticket سراغ KDC میره، KDC این PAC رو میسازه.
داخل PAC اطلاعاتی از کاربر مثل :
SID و Group Relative(RID) یوزر در آن قرار میگیرد.
اطلاعاتی درمورد User Profile. مانند Home directory و Log on script در آن قرار دارد.
Password Credential هایی که در طول فرآیند استفاده از Smart card صورت میگیرد.
کلاینت چه اطلاعاتی درمورد Ticket داره؟
وقتی KDC برای کلاینت Session key میفرسته، در اون پیامی که داره Session key رو میفرسته اطلاعاتی از خود تیکت رو در اون قرار میده. برای اینکه کلاینت بتونه این تیکت هارو Manage کند.
اطلاعاتی مثل :
Authentication Time , Start Time, End Time, Renew Till
Authenticator چیست؟
Authenticator نشون دهنده اینه که کلاینت واقعا خودش این درخواست رو داده.هروقت کلاینت بخواد درخواستی ارسال کند، فرقی نداره به KDC یا یه سرویس تو شبکه باشد. باید یک Authenticator به همراه درخواستش بفرسته.
چه ضرورتی تو ارسال Authenticator هست؟
اون target service میتونه اعتماد بکنه به Service ticket به این دلیل که اون تیکت با کلیدی که فقط بین اون و KDC شِیر هست، encrypt شده و مطمئن هست.اما نمیتونه اعتماد بکنه که اون کلاینتی که صاحب این Service ticket هست، خودش این رو فرستاده. یعنی امکان داره این Service ticket توسط یک فرستنده دیگه ارسال شده باشه.
این Authenticator چطور کار میکنه؟
۱- اول از همه Authenticator با استفاده از Session key که فقط کلاینت و Target service اون رو دارن، Encrypt میشه. پس فقط اون target service و کلاینت از این session key خبر دارن و میتونن پیام های همدیگر رو با اون encrypt و decrypt کنند.
۲- خب، بعد target service از Session key خودش، که داخل Service ticket بوده استفاده میکنه و اون Authenticator رو decrypt کنه.
۳- اگر بتونه decrypt بکنه، میتونه به اون فرستده Service ticket اعتماد کند.
Timestamp که داخل Authenticator هست چیه؟
مهمترین قسمت Authenticator همین Timestamp هست و وقتی کلاینت داره درخواست میده و Authenticator رو میسازه، زمان سیستم خودش رو هم داخل اون data structure قرار میدهد، حالا اگر Target service به اون timestamp نگاه کندو متوجه شودکه بیشتر از چند دقیقه با زمانسیستم خودش فاصله داره درخواست کاربر رو رد میکند و این چند دقیقه رو ما تو پالیسی ها تعریف میکنیم و یا خود سرویس تشخیص میدهد که چقدر باید رو اون Timestamp حساس باشه.
دوستان این تازه قسمتی از کار KDC بود و خیلی نکات گفته نشد، امیدوارم تو مقاله های بعدی بتونم نکات بیشتر و کاربردی تری رو ارائه بدم.
منبع:
Docs.Microsoft.com : How Kerberos V5 Works
2 پاسخ به “Kerberos چیست و چطور کار میکند؟”
Eileen Brazeale 1402-12-25 از 16:07
I have been surfing online greater than 3 hours as of late, yet I
never discovered any fascinating article like yours.
It is pretty price sufficient for me. Personally, if all website owners and
bloggers made just right content material as you did, the internet will probably be much more useful than ever before.
Nancy Nanninga 1402-12-29 از 02:57
It is the best time to make a few plans
for the long run and it is time to be happy. I’ve read this put up and
if I may just I desire to suggest you few fascinating
issues or suggestions. Maybe you could write next articles regarding this article.
I wish to read even more issues approximately it!