مفهوم DNSSEC و اهمیت آن

خلاصه مقاله:

افزونه‌ امنیتی CESSND مجموعه‌ای از مشخصات برنامه‌نویسی توسط کارگروه مهندسی اینترنت (FTEI) برای ایمن سازی داده‌های مبادله شده در سیستم نام دامنه (SND) در شبکه‌های آی پی (PI) است. این پروتکل احراز هویت رمزنگاری داده‌ها، انکار احراز هویت، و یکپارچگی داده‌ها را فراهم می‌کند.

اگر علاقه مند به یادگیری در مورد DNSSEC هستید تا انتهای این مقاله با ما باشید.

شرح مختصری از نحوه کار DNS:

برای درک بهتر Domain Name System Security Extensions (DNSSEC)  داشتن درک اولیه ازDomain Name System (DNS) کمک خواهد کرد.

عملکرد صحیح اینترنت به شدت به DNS وابسته است. هر صفحه وب بازدید شده، هر ایمیل ارسال شده، هر تصویر بازیابی شده از یک رسانه اجتماعی: همه آن تعاملات از DNS برای ترجمه نام های دامنه انسان پسند (مانند icann.org).  سرورها، روترها و سایر دستگاه های شبکه برای هدایت ترافیک در سراسر اینترنت به مقصد نیاز به دانستن آدرس آی پی  دارند. به عنوان مثال (192.0.43.7 و یا 2001:500:88:200::7)

استفاده از اینترنت در هر دستگاهی با DNS شروع می شود. به عنوان مثال، زمانی را در نظر بگیرید که کاربر نام یک وب سایت را در مرورگر گوشی خود وارد می کند. مرورگر از مترجم محلی(stub resolver)، که بخشی از سیستم عامل دستگاه است، برای شروع فرآیند ترجمه نام دامنه وب سایت به آدرس آی پی (IP) استفاده می کند.

 stub resolver یک سرویس گیرنده DNS بسیار ساده است که درخواست یک برنامه کاربردی برای داده های DNS را به یک کلاینت DNS پیچیده تر به نام Recursive ارسال می کند. بسیاری از اپراتورهای شبکه،مترجم های بازگشتی را برای رسیدگی به درخواست‌های DNS، یا پرس‌وجوهایی که توسط دستگاه‌های موجود در شبکه‌شان ارسال می‌شود، اجرا می‌کنند. (اپراتورها و سازمان‌های کوچک‌تر گاهی اوقات از مترجم های بازگشتی در شبکه‌های دیگر، از جمله مترجم بازگشتی که به عنوان یک سرویس برای عموم استفاده می‌شوند، مانند Google Public DNS، OpenDNS و Quad9 استفاده می‌کنند.)

مترجم بازگشتی پاسخ درخواست های DNS ارسال شده توسط stub را ردیابی یا ترجمه می‌کند. این فرآیند ترجمه به مترجم بازگشتی نیاز دارد تا درخواست های DNS خود را به چندین dns server معتبر مختلف ارسال کند. اطلاعات DNS برای هر نام دامنه در یک سرور dns معتبر در جایی در اینترنت ذخیره می شود. اطلاعات DNS برای یک دامنه، Zone نامیده می شود.

برخی از سازمان ها برای انتشار Zone های خود از نیم سرورهای خود استفاده می کنند، اما معمولاً سازمان ها این عملکرد را به اشخاص ثالث برون سپاری می کنند. انواع مختلفی از سازمان‌ها وجود دارند که DNS ZONE را از طرف دیگران میزبانی می‌کنند، از جمله ثبت‌کننده‌ها، رجیستری‌ها، شرکت‌های میزبانی وب، ارائه‌دهندگان سرور شبکه.

DNS به تنهایی امن نمیباشد!!

DNS در دهه 1980 طراحی شد، زمانی که اینترنت بسیار کوچکتر بود و امنیت در طراحی آن اولویت اول نبود. در نتیجه، هنگامی که یک مترجم دامنه  بازگشتی یک درخواست را به یک دی ان اس سرور معتبر ارسال می‌کند، مترجم راهی برای تأیید صحت پاسخ ندارد. مترجم فقط می‌تواند بررسی کند که پاسخ از همان آدرس IP است که مترجم درخواست اصلی را ارسال کرده است. اما تکیه بر آدرس IP منبع یک پاسخ، مکانیزم احراز هویت قوی نیست، زیرا آدرس IP یک بسته پاسخ DNS را می توان به راحتی جعل یا دستکاری کرد.

همانطور که DNS در ابتدا طراحی شده بود، یک مترجم نمی تواند به راحتی یک پاسخ جعلی به یکی از درخواست های خود را تشخیص دهد. یک مهاجم به راحتی می تواند به عنوان سرور معتبری که یک مترجم در ابتدا با جعل پاسخی که به نظر می رسد از آن سرور معتبر آمده است،درخواست کند. به عبارت دیگر، مهاجم می تواند بدون اینکه کاربر متوجه شود کاربر را به یک سایت مخرب هدایت کند.

مترجم بازگشتی(Recursive resolvers)، داده‌های DNS را که از دی ان اس سرورهای معتبر دریافت می‌کنند، ذخیره می‌کنند تا فرآیند تفکیک را تسریع کنند. اگر stub resolver، داده‌های DNS را که مترجم بازگشتی در حافظه پنهان خود دارد، بخواهد، مترجم بازگشتی می‌تواند فوراً بدون تأخیر با درخواست اول از یک یا چند سرور معتبر پاسخ دهد. این اتکا به کش یک جنبه منفی دارد، با این حال: اگر یک مهاجم یک پاسخ DNS جعلی را ارسال کند که توسط یک مترجم بازگشتی پذیرفته شده است، مهاجم حافظه کش مترجم بازگشتی را آلوده کرده است. سپس مترجم به بازگرداندن داده‌های جعلی DNS به سایر دستگاه‌هایی که برای آن درخواست می‌کنند، ادامه می‌دهد.

به عنوان مثالی از تهدید ناشی از حمله آلوده بودن کش، در نظر بگیرید که وقتی کاربر از وب سایت بانک خود بازدید می کند چه اتفاقی می افتد. دستگاه کاربر سرور نام بازگشتی پیکربندی شده خود را برای آدرس IP وب سایت بانک جستجو می کند. اما یک مهاجم می‌تواند مترجم دی ان اس را با یک آدرس IP که نه به سایت قانونی، بلکه به وب‌سایتی که توسط مهاجم ایجاد شده است، آلوده کند. این وب‌سایت جعلی جعل هویت وب‌سایت بانک است و ظاهری مشابه دارد. کاربر ناآگاه طبق معمول نام و رمز عبور خود را وارد می کرد. متأسفانه، کاربر به طور ناخواسته اعتبار بانکی خود را در اختیار مهاجم قرار داده است، او سپس می تواند به عنوان آن کاربر در وب سایت قانونی بانک برای انتقال وجه یا انجام سایر اقدامات غیرمجاز وارد سیستم شود.

افزونه های امنیتی DNS (DNSSEC):

مهندسان در گروه  Internet Engineering Task Force (IETF)، سازمانی که مسئول استانداردهای پروتکل DNS است، مدت‌ها متوجه شده‌اند که عدم احراز هویت قوی‌تر در DNS یک مشکل است. کار بر روی یک راه حل در دهه 1990 آغاز شد و نتیجه آن DNSSEC Security Extensions (DNSSEC) بود.

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

هر DNS ZONE دارای یک جفت کلید عمومی/خصوصی است. مالک منطقه از کلید خصوصی zone برای امضای داده های DNS در Zone و تولید امضای دیجیتال روی آن داده ها استفاده می کند. همانطور که از نام "کلید خصوصی" پیداست، این کلید توسط مالک منطقه مخفی نگه داشته می شود. با این حال، کلید عمومی Zone در خود Zone منتشر شده است تا هر کسی بتواند آن را بازیابی کند. هر مترجم بازگشتی که داده‌ها را در Zone جستجو می‌کند، کلید عمومی Zone را نیز بازیابی می‌کند، که از آن برای تأیید صحت داده‌های DNS استفاده می‌کند. مترجم تأیید می‌کند که امضای دیجیتال روی داده‌های DNS بازیابی شده معتبر است. در این صورت، داده های DNS قانونی هستند و به کاربر بازگردانده می شوند. اگر امضا تایید نشود، حل‌کننده حمله را فرض می‌کند، داده‌ها را دور می‌اندازد و یک خطا را به کاربر برمی‌گرداند.

DNSSEC دو ویژگی مهم را به پروتکل DNS اضافه می کند:

+ احراز هویت مبدا اطلاعات به یک مترجم اجازه می‌دهد تا به صورت رمزنگاری تأیید کند که اطلاعات دریافتی واقعاً از zone آمده است که ادعا  میکند داده‌ها از آنجا منشأ گرفته‌اند.

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

اعتماد به کلیدهای DNSSEC

هر zone کلید عمومی خود را منتشر می کند، که یک مترجم  بازگشتی(Recursive resolvers) آن را برای اعتبارسنجی داده ها در zone بازیابی می کند. اما چگونه یک مترجم می‌تواند از معتبر بودن کلید عمومی zoneاطمینان حاصل کند؟

کلید عمومی یک zone، درست مانند سایر داده های موجود در zone، امضا شده است. با این حال، کلید عمومی توسط کلید خصوصی zoneامضا نمی شود، بلکه توسط کلید خصوصی zone والد امضا می شود. به عنوان مثال، کلید عمومی icann.org zone توسط org zone امضا شده است. همانطور که والد یک DNS zone مسئول انتشار لیست سرورهای نام معتبر یک منطقه فرزند است، والدین یک منطقه نیز مسئول تضمین صحت کلید عمومی zone فرزند خود هستند. کلید عمومی هر zone توسط zone والد آن امضا می شود، به جز zone ریشه، هیچ والدی برای امضای کلید خود ندارد.

بنابراین، کلید عمومی zone ریشه یک نقطه شروع مهم برای اعتبارسنجی داده های DNS است. اگر یک مترجم به کلید عمومی zone ریشه اعتماد کند، می‌تواند به کلیدهای عمومی مناطق سطح بالا که توسط کلید خصوصی ریشه امضا شده‌اند، مانند کلید عمومی zone سازمان اعتماد کند. و از آنجا که حل‌کننده می‌تواند به کلید عمومی org zone اعتماد کند، می‌تواند به کلیدهای عمومی که توسط کلید خصوصی مربوطه امضا شده‌اند، مانند کلید عمومی icann.org اعتماد کند. (در عمل، منطقه والد کلید منطقه فرزند را مستقیماً امضا نمی‌کند - مکانیسم واقعی پیچیده‌تر است - اما اثر همان است که اگر والدین کلید کودک را امضا کرده باشند.)