DNS SEC– قسمت اول

DNS هیچ روش مناسبی برای تایید هویت منابع اطلاعاتی که از طریق Query ها کسب می کند، ندارد. از این روی نفوذگران می تواند از روش هایی همانند DNS Cache Poisoning جهت دادن اطلاعات جعلی به کلاینت استفاده کنند و ترافیک را به آدرس های جعلی منتقل کنند. DNSSEC جهت برطرف کردن این مشکل از زیرساخت امضای دیجیتال استفاده می کند. در شبکه های ویندوزی، 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 نگه داری می شود که موارد قابل توجه در نگه داری کلید لازم است روی آن کلید نیز صورت گیرد.

image

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

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

image

روابط 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 کرد. در تصویر زیر، با ذکر مثالی این مسئله معین شده است.

image

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 ارسال می گردد. در تصاویر، شماره ها معرف مراحل عملیات هستند.

image

سپس، 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 با چالشی رو به رو نمی شویم.

image

در ادامه مشابه به روند عادی 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 تعیین گردد و مشخص شود که ویرایشی روی آن صورت نگرفته است.

image

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

image

سپس، 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 می باشد.

image

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

image

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

image

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

اکنون با توجه به آنکه یک 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 های دریافتی را تایید اعتبار کرد.

image

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

image

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

image

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 گردد.

پروتکل DNSSEC دارای Extention های بیشتری برای برقراری Security نیز می باشد که در اینجا به آن ها اشاره نشد.

یک دیدگاه در “DNS SEC– قسمت اول

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *