پروتکل DNSSEC چیست و چگونه معماری DNS Spoofing را خنثی می کند؟

سیستم نام دامنه یا DNS در معماری اولیه خود فاقد هر گونه مکانیزم احراز هویت بود و صرفا به عنوان یک سیستم توزیع شده و مقیاس پذیر طراحی شد. این ضعف ساختاری بنیادین، ترافیک متنی روی پورت ۵۳ را در برابر حملات جعل هویت از جمله DNS Spoofing و آلودگی حافظه نهان یا Cache Poisoning به شدت آسیب پذیر کرده است. سازمان مهندسی اینترنت یا IETF برای برطرف کردن این نقص حیاتی، مجموعه افزونه های امنیتی سیستم نام دامنه یا DNSSEC را در قالب استاندارد های پایه ای RFC 4033، RFC 4034 و RFC 4035 معرفی کرد که امروزه بهترین تجربیات پیاده سازی آن در سند BCP 237 یا RFC 9364 تجمیع شده است.

هدف غایی DNSSEC، ارائه احراز هویت مبدا داده ها ( Data Origin Authentication ) و تضمین یکپارچگی داده ها ( Data Integrity ) از طریق امضا های دیجیتال مبتنی بر الگوریتم های کلید عمومی است. این پروتکل ترافیک را رمزنگاری نمی کند، بلکه اصالت داده های موجود در پاسخ ها را به صورت قطعی اثبات می کند.

معماری نا امن DNS و مکانیک حمله DNS Spoofing

در زیر ساخت سنتی، پرس و جو های DNS بر روی بستر پروتکل UDP ارسال می شوند. از آن جا که این بسته ها هیچ امضای دیجیتالی ندارند، مهاجمان سایبری می توانند با استراق سمع ترافیک یا تکنیک های حدس شناسه تراکنش ( Transaction ID )، پیش از رسیدن پاسخ سرور اصلی، یک پاسخ جعلی به سرور حل کننده یا Resolver ارسال کنند.

ورود این رکورد های مخرب به درون کش ( Cache ) سرور حل کننده، منجر به حمله DNS Cache Poisoning می شود. در این سناریو، تمامی کاربرانی که قصد دسترسی به یک وب سایت مشروع را دارند، بدون آگاهی به سرور های تحت کنترل مهاجم هدایت می شوند. این تغییر مسیر مخفیانه، زمینه ساز حملات فیشینگ پیچیده، رهگیری ترافیک، توزیع باج افزار و سرقت اعتبارنامه های بانکی می گردد.

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

شالوده رمزنگاری DNSSEC و نهاد های ساختاری

پروتکل DNSSEC برای تامین امنیت پاسخ ها، از امضای مجموعه ای از رکورد های هم نوع ( RRset ) استفاده می کند. این معماری به جای تغییر در ساختار پیام های قدیمی، چهار موجودیت و رکورد جدید را به پایگاه داده DNS اضافه می کند:

1. رکورد RRSIG ( Resource Record Signature ): این رکورد حاوی امضای رمزنگاری شده برای یک مجموعه رکورد خاص است. هنگامی که یک کلاینت، رکوردی مانند A یا MX را درخواست می کند، سرور معتبر علاوه بر پاسخ اصلی، رکورد RRSIG مربوط به آن را نیز ارسال می کند تا امکان اعتبارسنجی فراهم شود.

2. رکورد DNSKEY: این رکورد در بر دارنده کلید عمومی زون ( Zone ) است که کلاینت ها برای باز کردن و تایید امضای درون RRSIG از آن استفاده می کنند. مهندسی امنیت ایجاب می کند که این موجودیت به دو کلید با وظایف مجزا تقسیم شود:

   • کلید ZSK ( Zone Signing Key ): این کلید برای امضای رکورد های عادی درون زون استفاده می شود. به دلیل استفاده مداوم، این کلید عمر کوتاه تری دارد و عملیات تعویض کلید ( Key Rollover ) برای آن به صورت ماهانه یا فصلی انجام می پذیرد.

   • کلید KSK ( Key Signing Key ): یک کلید بسیار قدرتمند و بلند مدت است که وظیفه آن صرفا امضا کردن مجموعه رکورد های DNSKEY ( شامل خود KSK و ZSK ) است. این کلید نقطه اتصال امنیتی به زون والد محسوب می شود و معمولا به صورت آفلاین یا درون ماژول های امنیتی سخت افزاری نگهداری می شود.

3. رکورد DS ( Delegation Signer ): این رکورد در زون والد ( Parent Zone ) قرار می گیرد و شامل هش رمزنگاری شده کلید KSK متعلق به زون فرزند است. رکورد DS حلقه اتصال میان دامنه ها است و تایید می کند که دامنه فرزند به درستی کلید های خود را تولید کرده است.

زنجیره اعتماد ( Chain of Trust ) و لنگر اعتماد ( Trust Anchor )

مکانیسم DNSSEC بر یک معماری سلسله مراتبی به نام زنجیره اعتماد بنا شده است. سرور های حل کننده یا Resolvers، فرآیند اعتبارسنجی را از راس هرم اینترنت یعنی منطقه ریشه ( Root Zone ) آغاز می کنند. کلید عمومی ریشه اینترنت به عنوان لنگر اعتماد یا Trust Anchor شناخته می شود و به صورت پیش فرض در تمامی سیستم عامل ها و نرم افزار های شبکه تعبیه شده است.

اعتبارسنجی با تطبیق پیوسته امضا ها میان رکورد های DS و DNSKEY از ریشه به سمت دامنه های سطح بالا ( TLD ) و سپس دامنه هدف پیش می رود. اگر در این زنجیره، امضایی مخدوش باشد یا تطابق نداشته باشد، سرور وضعیت را نامعتبر ( Bogus ) تشخیص داده و با ارسال پیام خطای SERVFAIL ارتباط را مسدود می کند. این اقدام قاطعانه مانع از موفقیت حملات DNS Spoofing می شود.

اثبات عدم وجود با NSEC و NSEC3

جلوگیری از جعل پاسخ برای دامنه هایی که وجود خارجی ندارند ( NXDOMAIN )، یکی از چالش های امنیتی بود. برای حل این مشکل، رکورد های NSEC طراحی شدند که محدوده الفبایی بین دو نام موجود در زون را مشخص می کنند. با این حال، رکورد های NSEC به هکر ها اجازه می دادند تا کل ساختار یک زون را پیمایش کرده و نقشه سرور ها را استخراج کنند ( Zone Enumeration ). برای رفع این نقص، استاندارد RFC 5155 رکورد های NSEC3 را معرفی کرد. در NSEC3 به جای نام های واقعی، هش رمزنگاری شده نام ها بازگردانده می شود که ضمن تایید عدم وجود دامنه، از افشای ساختار شبکه جلوگیری می کند.

الزامات لایه انتقال: پروتکل EDNS0 و بیت DO

پیاده سازی DNSSEC نیازمند تغییراتی در بستر ارتباطی شبکه است. پروتکل قدیمی DNS سایز بسته های مبتنی بر UDP را به ۵۱۲ بایت محدود می کرد. رکورد های رمزنگاری شده نظیر DNSKEY و RRSIG به فضایی بسیار بیشتر نیاز دارند. از این رو، پشتیبانی از مکانیزم های توسعه یافته سیستم نام دامنه یا EDNS0 ( بر اساس استاندارد RFC 6891 ) اجباری است. این استاندارد اجازه می دهد حجم بسته های UDP تا ۴۰۹۶ بایت افزایش یابد تا از سرریز شدن داده ها به پروتکل کند تر TCP جلوگیری شود.

علاوه بر این، برای این که یک کلاینت اعلام کند که از امکانات امنیتی پشتیبانی می کند، باید بیت DO ( مخفف DNSSEC OK ) را در سرآیند درخواستی خود فعال کند. این بیت که در استاندارد RFC 3225 تعریف شده است، به سرور های معتبر دستور می دهد تا رکورد های امنیتی را در کنار پاسخ اصلی ارسال کنند.

استراتژی های رمزنگاری و به روز رسانی کلید ها

انتخاب الگوریتم مناسب برای تولید امضا های دیجیتال تاثیر مستقیمی بر امنیت شبکه دارد. بر اساس رهنمود های به روز رسانی شده در استاندارد RFC 8624، استفاده از الگوریتم های مبتنی بر RSA و SHA-1 به دلیل ضعف های پردازشی اکیدا منسوخ شده است.

امروزه صنعت به سمت رمزنگاری منحنی بیضوی ( Elliptic Curve Cryptography ) حرکت کرده است. الگوریتم های ECDSA ( به ویژه الگوریتم شماره ۱۳ یا P-256 ) و الگوریتم پیشرفته Ed25519 کاملا توصیه می شوند. این الگوریتم ها سایز کلید و امضا را به شدت کاهش می دهند که این امر به نوبه خود خطر حملات سایبری منع سرویس توزیع شده ( DDoS Amplification ) را تقلیل می دهد.

همچنین، فرآیند چرخش کلید ها ( Key Rollover ) برای حفظ امنیت سیستم حیاتی است. مدیران شبکه باید از روش هایی نظیر انتشار پیشاپیش ( Pre-publish ) برای تعویض کلید های ZSK و روش امضای دوگانه ( Double Signature ) برای تعویض کلید های KSK استفاده کنند تا از قطعی موقت سرویس جلوگیری شود.

یکپارچه سازی با زیر ساخت کلید عمومی اینترنت ( DANE )

زمانی که یک دامنه از طریق DNSSEC ایمن می شود، می تواند به عنوان یک پایه مستحکم برای سایر فناوری های هویتی عمل کند. پروتکل DANE ( احراز هویت موجودیت های نام گذاری شده ) که در استاندارد RFC 6698 تعریف شده است، برجسته ترین نمونه این کاربرد است.

فناوری DANE به مدیران سیستم اجازه می دهد تا گواهینامه های TLS سرور های خود را مستقیما درون پایگاه داده DNS و در قالب رکورد های TLSA منتشر کنند. از آن جا که رکورد های TLSA توسط مکانیزم DNSSEC محافظت می شوند، نرم افزار ها می توانند بدون نیاز به اتکای مطلق به مراجع صدور گواهینامه تجاری ( Certificate Authorities )، هویت یک سرور را اثبات کنند. این فناوری خطر حملات مرد میانی ( Man-in-the-Middle ) ناشی از هک شدن مراجع صدور را به صفر می رساند و در امنیت ارتباطات سرور های ایمیل ( SMTP ) نقش تحول آفرینی ایفا کرده است.

مقایسه استراتژیک DNSSEC در برابر DoH و DoT

در بسیاری از مباحث امنیتی، این سه فناوری به اشتباه به عنوان جایگزین یکدیگر در نظر گرفته می شوند. جدول زیر تفاوت های ساختاری آن ها را به دقت تشریح می کند:

این پروتکل ها در حقیقت مکمل یکدیگر هستند. برای رسیدن به بالاترین سطح امنیت شبکه، سازمان ها باید DNSSEC را برای حفاظت از زیر ساخت ریشه ای داده های خود پیاده سازی کرده و به صورت هم زمان از DoH یا DoT برای محافظت از حریم خصوصی کلاینت های نهایی استفاده کنند.

نتیجه گیری راهبردی

استقرار معماری DNSSEC فراتر از یک افزونه ساده است؛ این پروتکل پایه های اعتماد را در سراسر اینترنت بازسازی می کند. با بهره گیری از زنجیره های اعتماد قدرتمند، استفاده هوشمندانه از کلید های دوگانه KSK و ZSK، و تکیه بر گسترش دهنده هایی نظیر EDNS0، مهندسان می توانند هر گونه تلاش برای جعل هویت در سطح زیر ساخت را خنثی کنند.

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