آشنایی با پروتکل DNSSEC در ويندوز سرور

DNS فاقد روش مناسبی برای تایید هویت منابع اطلاعاتی که از طریق Query ها کسب می کند می باشد. از این روی نفوذگران می تواند از روش هایی همانند DNS Cache Poisoning جهت دادن اطلاعات جعلی به کلاینت ها می توانند استفاده کنند و ترافیک را به آدرس های جعلی منتقل کنند. RFC 3833 برخی از تهدیدات که به دلیل ضعف امنیتی پروتکل DNS است را مشروح کرده است. DNSSEC جهت برطرف کردن مشکلات امنیتی DNS از زیرساخت امضای دیجیتال استفاده می کند. به صورت پیش فرض، DNSSEC سرویسی برای Confidentiality ارائه نمی کند و همچنین مستقیما دارای مکانیزمی برای مقابله حملات DoS نیست، با این وجود سرویس Authentication سبب می گردد تا پاسخ های دریافت شده identical باشد. DNSSEC دارای Record Type های جدیدی در مقایسه با DNS است. در شبکه های ویندوزی، DNSSEC به عنوان یک پروتکل server-to-server پیاده سازی شده است و پاسخ ها را از طرف کلاینت های + windows 7 تایید اعتبار می کند. Windows از Stub Resolver برای DNSSEC استفاده می کند. Stub Resolver درخواست خود را به یک Server می دهد و از طریق Recursive Name Resolution پاسخ Query به آن بازگردانده می شود. از یک بیت اطلاعات به نام ADbit یاAuthenticated Data bit برای آنکه معین گردد آیا در تمام مسیر یافتن پاسخ، پاسخ ها Validate شده است در پاسخ استفاده می گردد.

رمزنگاری نامتقارن

در رمزنگاری نامتقارن (asymmetric encryption ) از دو کلید استفاده می گردد که به کلید عمومی (Public Key ) و کلید خصوصی (Private Key ) مشهور اند. هر کدام از این دو کلید می توانند برای رمزنگاری یک عبارت به کار گرفته شوند، اما تنها به کلید دیگر قابل رمزگشایی هستند. همانطور که نام کلید ها گویا است، کلید عمومی در اختیار همگان می تواند قرار گیرد اما کلید خصوصی محرمانه است و انحصارا در اختیار دارنده ی آن است. در Windows Server 2008 R2 این زوج کلید توسط dnscmd قابل تولید است و کلید عمومی در سراسر DNS Zone توزیع می گردد. کلید خصوصی در Local Certificate Store نگه داری می شود که موارد قابل توجه در نگه داری کلید لازم است روی آن کلید نیز صورت گیرد.

امضای دیجیتال

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

روابط Trust در DNSSEC

DNSSEC در + Windows Server 2008 R2 این امکان را ایجاد می کند تا سرور از طرف کلاینت پاسخ را تایید اعتبار کند. به عبارت دیگر؛ زمانی که یک DNS Server یک Query که امکان Resolve آن را استفاده از اطلاعات خود ندارد دریافت می کند، ابتدا با DNS Server های دیگر جهت یافتن پاسخ برای Query ارتباط برقرار می کند و پیش از پاسخ گویی به کلاینت، صحت امضای دیجیتال روی پاسخ را بررسی می کند. با این وجود، امضای دیجیتال به تنهایی جهت تایید اعتبار داده های دریافتی از DNS Server های دیگر کافی نمی باشد. یک DNS Server جعلی می تواند با استفاده از امضای دیجیتال خود، پاسخ های جعلی به DNS Server که Query را ارسال کرده باز گرداند و کلید عمومی را ارائه دهد که ادعا می کند مربوط به منابع دیگری می باشد. بنابراین؛ خود Public Key لازم است توسط DNS Server های دیگری با استفاده از Trust Relationship بین DNS Server ها به صورت مستقیم یا غیر مستقیم تایید اعتبار گردد. Trust Anchor در DNSSEC جهت برقراری Trust Relationship به کار گرفته شده است. یک Trust Anchor در واقع Public Key یک DNS Server است که قابل اعتماد (Trusted ) است و می تواند پاسخ های DNSSEC فراهم آورد.

زمانی که یک Local DNS Server با یک Trust Anchor برای یک Remote DNS Server تنظیم می گردد، Local DNS Server می تواند تمام اطلاعات روی Zone های Remote DNS Server را Validate کند. همچنین با یک زنجیره از روابط Trust می توان، اطلاعات روی Subdomain های آن را نیز Validate کرد. در تصویر زیر، با ذکر مثالی این مسئله معین شده است.
آشنایی با پروتکل DNSSEC

DNSSEC Name Resolution

در پیاده سازی مایکروسافت از DNSSEC یک کلاینت اطلاعات دریافتی از Local DNS Server خود را Validate نمی کند. یک کلاینت می تواند در خواست DNSSEC از DNS Server کند و DNS Server تنها پاسخ هایی را که از DNS Server های دیگر دریافت می کند را Validate می کند. کلاینت هایی که از DNSSEC پشتیبانی می کنند می توانند توسط Name Resolution Policy Table یا به اختصار NRPT در Group Policy تنظیم گردند. NRPT قابلیت هایی همانند تخصیص Suffix, Prefix, FQDN و Reverse Lookup subnetsرا فراهم می آورد. با استفاده از NRPT همچنین می توان وجود ارتباط IPSec بین Local DNS Server و DNS Client را اجباری کرد. استفاده از این قابلیت اکیدا توصیه می گردد زیرا علاوه بر آنکه امکان Authentication فراهم می آید از حملاتی همانند man-in-the-middle جلوگیری به عمل می آید. در ادامه با استفاده از مثالی مراحل Name Resolution برای یک کلاینت Windows 7 به نام client1.nwtraders.com توضیح داده شده است. این کلاینت یک Query برای www.ny.contoso.com ارسال می کند و با استفاده از DNSSEC عناصر در چهار سطح تایید هویت می گردند. در ابتدا، کلاینت ابتدا با بررسی NRPT از نوع Query که لازم است ارسال نماید آگاه می گردد. در NRPT یکی از موارد معین شده، Suffix با مقدار contoso.com است، بنابراین Query با درخواست DNSSEC ارسال می گردد. در تصاویر، شماره ها معرف مراحل عملیات هستند.

آموزش آشنایی با پروتکل DNSSEC ويندوز سرور

سپس، Local DNS Server در ns1.nwtraders.com یک Trust Anchor روی Contoso.com می یابد که Parent Doamin برای ny.contoso.com است. مشابه با روند عادی Name Resolution ، درخواست برای Contoso.com ارسال می گردد. این آدرس به عنوان Conditional Forwarder برای آن دامین تعریف شده است و با توجه به آنکه از ns1.contoso.com از DNSSEC پشتیبانی به عمل می آورد و NS1.nwtraders.com دارای Trust Anchor است، از دیدگاه DNSSEC با چالشی رو به رو نمی شویم. در ادامه مشابه به روند عادی Name Resolution ، ابتدا ns.contoso.com اطلاعات DNS Server ای که برای دامین ny.contoso.com معتبر است را ارسال می کند که در واقع شامل یک رکورد ns و یک رکورد A است. در این مرحله با توجه به آنکه از DNSSEC استفاده می گردد، دو رکورد دیگر نیز به ns1.nwtraders.com داده می شود. یک رکورد DS یا Delegation Signer و یک رکورد RRSIG یا Resource Record Signature . رکورد DS شامل یک Public Key که در Subdomain مورد استفاده قرار گرفته است می باشد که با استفاده از SHA-1 یا SHA-256 به صورت hash شده است و همچنین با DNSSEC سازگار شده است. DS رکورد حاوی یک Public Key ویژه به نام Key Signing Key یا به اختصار KSK از ny.contoso.com است. این عبارت در آینده جهت تایید هویت KSK ای که مستقیما از ny.contoso.com به دست می آید مورد استفاده قرار می گیرد. Zone هایی که دارای امضای دیجیتال هستند دارای دو زوج کلید مختلف می باشند، بنابراین دارای دو Public Key متمایز برای هر Zone می باشیم. یکی از آن ها KSK است که به ندرت update می شود و در Zone های دیگر تحت یک رکورد DS یا Trust Anchor نگه داری می شود. کلید عمومی دیگر، Zone Signing Key یا به اختصار ZSK نام دارد. ZSK بارها Update می شود و برای validate کردن Resource Record های روی Zone به کار می رود. KSK برای Validate کردن ZSK به کار گرفته می شود. RRSIG Record یک امضای دیجیتال از DS Record است که در اینجا توسط Contoso.com امضا می گردد تا هویت DS Record تعیین گردد و مشخص شود که ویرایشی روی آن صورت نگرفته است.

آموزش آشنایی با پروتکل DNSSEC ويندوز سرور

در گام بعدی، (گام ششم) مراحل verify کردن امضای دیجتالی DS Record که در مرحله ۵ کسب شد صورت می گیرد. با استفاده از Public Key که در Trust Anchor روی ns1.nwtraders.com برای ns1.contoso.com وجود دارد برای رمزگشایی رکورد RRSIG مورد استفاده قرار می گیرد و سپس با DS Record مقایسه می گردد تا DS Record تایید اعتبار شود.

آموزش آشنایی با پروتکل DNSSEC ويندوز سرور

سپس، Local DNS Server یعنی ns1.nwtraders.com با DNS Server ای که از ns1.contoso.com دریافت کرده است، ارتباط برقرار می کند تا پاسخ Query دریافت شده را بیابد. ابتدا از ns1.ny.contoso.com درخواست KSK می کند که در DS Record دریافت شده از مرحله قبل آن را دارد. سپس ns1.ny.contoso.com با استفاده از ارسال یک رکورد DNSKey پاسخ می دهد. این رکورد حاوی Public Key می باشد.

آموزش آشنایی با پروتکل DNSSEC ويندوز سرور

در مراحل بعدی، DNSKEY دریافت شده، با DS Record دریافت شده در مرحله پیشین مقایسه می گردد. ابتدا الگوریتم Hash روی DNSKey اعمال می شود. اگر هر دو عبارت hash شده، یعنی DNSKey و DS Record یکسان باشد، KSK مربوط به ny.contoso.com دارای اعتبار است.

آموزش آشنایی با پروتکل DNSSEC ويندوز سرور

در گام بعدی ns1.nwtraders.com با ns1.ny.contoso.com جهت دریافت ZSK ارتباط برقرار می کند. ns1.ny.contoso.com در رکورد ZSK و RRSIG را در پاسخ باز می گرداند.

آموزش آشنایی با پروتکل DNSSEC ويندوز سرور

سپس ZSK دریافت شده لازم است Verify گردد. با استفاده از KSK دریافت شده در مراحل ۹ تا ۱۱، برای رمزگشایی ZSK به کار گرفته می شود. در مرحله ۱۵، امضای دیجیتال رمزگشایی شده با ZSK مقایسه می شود تا ZSK تایید اعتبار شود.

آموزش آشنایی با پروتکل DNSSEC ويندوز سرور

اکنون با توجه به آنکه یک ZSK دارای اعتبار به دست آمده می توان یک Query به ns1.ny.contoso.com برای www.ny.contoso.com ارسال کرد. پاسخ ارسال شده از ns1.ny.contoso.com حاوی یک A record و RRSIG می باشد. لازم به ذکر است حتی اگر بیش از یک A Record در پاسخ باز گردد، تنها یک RRSIG در پاسخ وجود خواهد داشت. RRSIG حاوی Resource Record های رمز شده است تا بتوان A record های دریافتی را تایید اعتبار کرد.

آموزش آشنایی با پروتکل DNSSEC ويندوز سرور

در گام بعدی با استفاده از RRSIG کسب شده در مرحله قبل، A Record های دریافتی تایید اعتبار می گردند. با استفاده از ZSK که Validate شده بود، RRSIG که در مرحله ۱۷ به دست آمد، رمزگشایی می گردد و سپس، با A Record های کسب شده در مرحله ۱۷ مقایسه می شود.

آموزش آشنایی با پروتکل DNSSEC ويندوز سرور

اکنون پاسخ Query دریافت شده از کلاینت به دست آمده است. این پاسخ با یک A Record ساده به کاربر داده می شود. همانطور که مشاهده می کنید، بهتر است برای این ارتباط در مرحله ۲۰ از IPSec استفاده گردد از این روی، استفاده از IPSec بین Client ها و local DNS Server ها در شبکه های ویندوزی اکیدا توصیه می گردد.

آموزش آشنایی با پروتکل DNSSEC ويندوز سرور

NSEC Record

این رکورد در صورتی مورد استفاده قرار می گیرد که authoritative DNS Server (در مثال فوق: ns1.ny.contoso.com ) دارای هیچ A Record ای برای پاسخ به Query نباشد و جهت Validate شدن این امر، یک پاسخ دارای دو رکورد NSEC و RRSIG به منبع صادر کننده Query (در مثال فوق: ns1.nwtraders.com ) باز گردانده می شود. از آنجایی که در Zone ها، رکورد ها بر اساس ترتیب الفبا مرتب می گردند و آخرین رکورد نام Zone است، برای هر فاصله بین آن ها یک رکورد NSEC توسط DNS SERVER تولید می گردد. به عنوان مثال اگر Contoso.com دارای دو رکورد به نام های Boston ، Phonix باشد و رکورد contoso.com ، آخرین رکورد Zone باشد، سه NSCE Record برای پوشش فضای بین این رکورد ها تولید می گردد. یعنی یک رکورد برای فاصله بین Boston تا Phonix ، یک رکورد برای فاصله ی Phonix تا Contoso.com و یک رکورد دیگر برای فاصله ی Contoso.com تا Boston . اگر Query دریافت شده، در Zone موجود نباشد، DNS Server یک پاسخ با یکی از NSEC Record های موجود که در فاصله معین است می دهد. این امر سبب می گردد تا عدم وجود رکورد نیز Validate گردد.

NSEC3 Record

NSEC3 Record یک جایگزین برای NSEC است که از مسئله Zone Walking ممانعت ایجاد می کند. Zone Walking فرآیندی است که در آن مهاجم با تکرار NSEC Query ها می تواند تمام نام ها در Zone را بازیابی کرد.

Zone Signing

زمانی که یک Zone با استفاده از DNSSEC امضا می گردد، در واقع تمام(Resource Record (RR مربوطه به صورت تکی رمز می گردند. لذا امکان ویرایش، حذف و اضافه رکورد ها وجود خواهد داشت. DNS Server ها در ویندوز Server 2012 از هر دو رکورد NSEC3 و NSEC پشتیبانی می کنند و یک Zone تنها می تواند توسط یکی از آن دو رکورد Sign شود. برای تنظیم DNSSEC ابتدا لازم است، Zone را آماده سازی کنید، تهیه نسخه backup ، تعبیه یک روش rollover ، ساخت کلید ها، Sign کردن Zone ، تنظیم Trust Anchor ها و در نهایت تنظیم Client ها روند عمومی پیکربندی DNSSEC است.

Trust Anchor

همانطور که پیش تر گفته شد، جهت انجام Validation ، یک DNS Server باید با یک یا بیشتر Trust Anchor دیگر تنظیم گردد. اگر DNS Server روی یک Domain Controller اجرا گردد، Trust Anchor ها در Application Partition قرار می گیرند و بین تمام Domain Controller ها Replicate می شوند. در Standalone DNS Server ها در فایل TrustAnchors.dns ذخیره می گردد. Trust Anchor ها در کنسول DNS در قسمت Trust Points نمایش داده می شوند و امکان ویرایش آن ها نیز وجود دارد.

Key Master

Key Master یک DNS Server است که وظیفه تولید و مدیریت کلید ها برای یک Zone را بر عهده دارد. هر کدام از DNS Server هایی که کپی Primary از Zone را دارند می توانند به عنوان Key Master انتخاب شوند. توجه داشته باشید که در Active Directory Integrated Zone این امکان وجود دارد که نسخه DNS به صورت فقط خواندنی یا نوشتنی-خواندنی باشد. یک Server می تواند نقش key Master را برای چند Zone مختلف داشته باشد. امکان انتقال نقش Key Master پس از Sign شدن Zone وجود دارد، با این وجود در اولین Sign کردن لازم است Key Master معین گردد. این ویژگی در Windows Server 2012 ایجاد شده است. پروتکل DNSSEC دارای Extention های بیشتری برای برقراری Security نیز می باشد که در اینجا به آن ها اشاره نشد.

دیدگاه

آدرس ایمیل شما منتشر نخواهد شد.