محمد نصیری
بنیانگذار انجمن تخصصی فناوری اطلاعات ایران ، هکر کلاه خاکستری ، کارشناس امنیت اطلاعات و ارتباطات

TGT چیست؟ بررسی Ticket Granting Ticket یا تیکت احراز هویت

همانطور که می دانید و قبلا هم برای شما در ITPRO گفته ام، ساختار احراز هویت اکتیودایرکتوری بصورت پیشفرض بر اساس معیاری به نام Ticket پایه گذاری شده است. Ticket به معنی مجوز یا بلیط است و برای مثال اگر شما بخواهید از یک سرویس استفاده کنید بایستی یک Ticket یا بلیط استفاده از این محصول را تهیه کرده باشید. همین فاکتور در احراز هویت اکتیودایرکتوری نیز وجود دارد. پروتکل اصلی احراز هویت در اکتیودایرکتوری Kerberos است.

دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران

زمانیکه قرار است شما با استفاده از Kerberos در اکتیودایرکتوری احراز هویت بشوید یک Authentication Ticket که به آن Ticket Granting Ticket گفته می شود در مدل احراز هویت Kerberos ایجاد می شود و برای احراز هویت در سرویس مورد نظر به شما ارائه داده می شود، TGT در واقع اطلاعات رمزنگاری شده احراز هویتی است که توسط سرور Kerberos برای انجام شدن فرآیند احراز هویت صادر می شود.

زمانیکه یک کلاینت در شبکه اکتیودایرکتوری یک Authentication Ticket دریافت می کند، کلاینت Ticket دریافت شده را به همراه یک سری اطلاعات هویتی برای سرور باز می گرداند تا هویت اصلی کلاینت توسط سرور شناسایی شود. بعد از این مرحله سرور برای کلاین یک Service Ticket به همراه یک Session Key که چیزی شبیه به رمز عبور است را صادر می کند و فرآیند احراز هویت و صدور مجوزهای دسترسی صادر می شود.

Kerberos Policy چیست و شامل چه مواردی می شود

در ساختار احراز هویت Kerberos هر Ticket ای که ثبت می شود برای خودش دارای یک محدودیت زمانی است و در اصطلاح فنی Ticket های ما در Kerberos بصورت Time-Stamped ایجاد می شوند. از این Ticket ها فقط در وهله های زمانی معینی می توانید استفاده کنید و بعد از آن منقضی می شوند. این نوع تولید و نگهداری Ticket ها باعث می شود خط هک شدن و کرک شدن پسورد و اطلاعات رمزنگاری شده کاهش پیدا کند.

امروزه تقریبا هیچ هکری نمی تواند در مدت زمان تعریف شده پیشفرضی که Ticket اعتبار دارد پسورد ها را کرک کند. این تکنیک امنیتی که بر اساس زمان تعریف می شود از بروز حملات Replay جلوگیری می کند. Authentication Ticket ها بصورت خاص برای هر Session ایجاد می شوند و طبیعی است که با پایان یافتن یک Session این Authentication Ticket نیز از بین می رود و درجه امنیتی ما بسیار بالا می رود ، در واقع TGT ما فقط در مدت زمان شروع و پایان یک Session معتبر است. در خصوص پروتکل Kerberos دوستان مقاله های زیادی در ITPRO نوشته اند که می توانید به لینک های زیر مراجعه کنید :

همانطور که گفتیم برای هر TGT یک مدت زمان حیات یا اعتبار وجود دارد که ما آن را به عنوان Ticket Lifetime می شناسیم ، وجود چنین مکانیزیمی همانطور که قبلا هم اشاره کردیم بسیار در امنیت احراز هویت های Kerberos مهم است. شما می توانید Lifetime یک Ticket را مشخص کنید و خودتان بصورت دستی در شبکه سازمان این مدت زمان را کم و زیاد کنید. Lifetime های TGT ها باید آنقدر کوتاه باشند تا فرصت کرک کردن و حملات رمزگشایی را به هکرها ندهند تا اطلاعات احراز هویتی ذخیره شده در TGT افشاء نشود.

اما به این موضوع هم باید توجه کنید که هر چقدر Lifetime ما کوتاه تر باشد تعداد درخواست هایی که از Domain Controller و Kerberos در خصوص صدور TGT داده می شود بالا می رود و Overload کاری سرور بالا می رود. از طرفی هر چقدر مدت زمان Lifetime را بالاتر ببریم درخواست هایی که به سمت سرور ارسال می شوند کمتر می شود و سرعت و Overload کاری سرور نیز کاهش پیدا می کند که این امر می تواند کارایی سرور را بالا ببرد در کنار اینکه امنیت ما را نیز پایین می آورد.

به همین دلیل شما می توانید تنظیمات مروبط به Ticket Expiration Policy که همین زمان را مشخص می کند را تغییر بدهید. تنظیمات مربوط به Ticket Expiration Policy در اکتیودایرکتوری بصورت پیشفرض از طریق GPO ها قابل تغییر هستند. تنظیمات زیر برای تعیین کردن این مقادیر برای Kerberos در شبکه می باشند :

حداکثر Lifetime یک Ticket Granting Ticket یا Maximum lifetime for user ticket

این تنظیم در Group Policy همانطور که از نامش هم پیداست حداکثر مدت زمان یا Lifetime ای است که یک Ticket قبل از منقضی شدن قابل استفاده است. یکی از پشنهاداتی که در این خصوص می شود این است که این Lifetime را به اندازه میانگین زمان کاری که کاربران شما از شبکه در طی روز استفاده می کنند قرار بدهید. در Default Domain Group Policy این مقدار بصورت پیشفرض 10 ساعت در نظر گرفته شده است. بعد از اینکه Lifetime مربوط به Ticket تمام شد ، کاربر یک Ticket جدید دریافت می کند و یا Ticket فعلی خودش را Renew می کند.

این فرآیند بصورت کاملا نامحسوس در پس زمینه انجام می شود و کاربر به هیچ عنوان در جریان چنین اتفاقی قرار نمی گیرد. تنها کاری که در این میان اتفاق می افتد رد و بدل شدن Ticket جدید و ایجاد شدن آن توسط سرور می باشد که کمی Load کاری سرور را بالا می برد. همانطور که قبلا گفتیم اگر این زمان را کاهش بدهید ، امنیت شما بالا می رود اما در همین حین کارایی سرور شما کاهش پیدا می کند. برعکس این مورد هم صادق است ، اگر زمان را بسیار زیاد در نظر بگیرید ، امنیت شما کاهش پیدا می کند ، Policy مربوط به این فرآیند در مسیر زیر قرار گرفته است :

Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy

حداکثر Lifetime برای یک Service Ticker یا Maximum lifetime for service ticket

همانطور که از نام این تنظیم هم مشخص است شما می توانید Ticket هایی که برای یک سرویس ارائه می شوند را بصورت جداگانه ای تنظیم کنید و Lifetime این Ticket ها را متفاوت بدهید. برای اینکه بهتر درک کنید این تنظیم چه کاری انجام می دهد یک مثال می زنیم ، فرض کنید که شما یک کامپیوتر دارید که طی روز نیاز به یک TGT با Lifetime 10 ساعت دارد که بتواند فرآیند Login شما را انجام بدهید اما شما یک فرآیند Backup گیری دارید که بصورت زمانبندی شده در سیستم فعال می شود .

برای انجام کار خودش هم نیاز به احراز هویت دارد در چنین مواقعی شما می توانید Lifetime مربوط به این سرویس را بصورت جداگانه و بیشتر از مدت زمانی که TGT فعلی برای Login استفاده می شود تعریف کنید. البته معمولا Job هایی برای اینکار تعریف می شوند در همان وهله زمانی تعین شده TGT کارشان را می توانند انجام بدهند و به همین خاطر مدت زمانی که شما باید برای این تنظیم بدهید معمولا نیازی نیست که تفاوت فاحشی با مقدار اصلیTGT داشته باشد.

Maximum Lifetime for service ticket معمولا 10 دقیقه بیشتر ، 10 دقیقه کمتر و یا مساوی زمان Maximum Lifetime for User Ticket است. بصورت پیشفرض این مقدار برابر با 600 دقیقه یا همان 10 ساعت است که در Default Domain Group Policy تعریف شده است. Policy مورد نظر در مسیر زیر قرار گرفته است :

Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy

حداکثر زمان فرآیند تازه سازی Ticket یا Maximum lifetime for user ticket renewal

همانطور که اعلام کردیم TGT ما هر روز تازه سازی می شود و یک فرآیند Renewal برایش انجام می شود. این تنظیم در Policy ها مدت زمانی که TGT ما می تواند Renew شود را نشان می دهد که با واحد روز در نظر گرفته می شود. بصورت پیشفرض این مدت زمان در Default Domain Group Policy هفت روز است. اگر مدت زمان این Policy را کمتر کنیم ، کاربران سریعتر به دنبال تازه سازی کلیدهای خود می روند و به همین دلیل امنیت نیز افزایش پیدا می کند ، هرگاه احساس کردیم که ممکن است مشکل امنیتی در سیستم برای احراز هویت کاربران به وجود بیاید این زمان را کاهش می دهیم. امیدوارم مورد توجه شما قرار گرفته باشد.


محمد نصیری
محمد نصیری

بنیانگذار انجمن تخصصی فناوری اطلاعات ایران ، هکر کلاه خاکستری ، کارشناس امنیت اطلاعات و ارتباطات

محمد نصیری هستم ، هکر قانونمند و کارشناس امنیت سایبری ، سابقه همکاری با بیش از 50 سازمان دولتی ، خصوصی ، نظامی و انتظامی در قالب مشاور ، مدرس و مدیر پروژه ، مدرس دوره های تخصص شبکه ، امنیت ، هک و نفوذ ، در حال حاضر در ایران دیگه رسما فعالیتی غیر از مشاوره انجام نمیدم و مقیم کشور ترکیه هستم ، عاشق آموزش و تدریس هستم و به همین دلیل دوره های آموزشی که ضبط می کنم در دنیا بی نظیر هستند.

نظرات