هر زمان که برنامه‌ای یک اتصال رمزنگاری‌شده HTTPS برقرار می‌کند یا درخواستی به وب‌سرویس‌ها ارسال می‌نماید، بر پروتکل تبدیل نام دامنه‌ای تکیه دارد که در سال ۱۹۸۷ تدوین شده است. سیستم نام دامنه (DNS) که توسط Paul Mockapetris در استاندارد RFC 1035 معرفی شد، نام‌های متنی را به آدرس‌های عددی ۳۲ بیتی IPv4 یا ۱۲۸ بیتی IPv6 تبدیل می‌کند. به دلیل نیاز به بازدهی بالا در دوران آرپانت، DNS بر پایه پروتکل بدون اتصال UDP روی پورت ۵۳ راه‌اندازی شد.

این ساختار اولیه فاقد مکانیزم احراز هویت رمزنگاری درونی است. اگر مهاجمی بتواند پارامترهای پرس‌وجوی تحلیل‌گر بازگشتی (Recursive Resolver) را جعل یا پیش‌بینی کند، می‌تواند رکوردهای جعلی را مستقیماً وارد حافظه موقت آن نماید. این شیوه نفوذ مسموم‌سازی کش دی‌ان‌اس (DNS Cache Poisoning) نامیده می‌شود و موجب هدایت پنهانی کاربران شبکه به سمت سرورهای مخرب و سرقت اطلاعات هویتی می‌گردد.

[دستگاه کاربر] ─── (۱) پرس‌وجو: bank.example.com ───> [تحلیل‌گر بازگشتی]
                                                             │
                                             (۲) ارسال پرس‌وجو: bank.example.com
                                                 (شناسه تراکنش: 0x4A2F، پورت: ۵۳)
                                                             ▼
                                             [سرور معتبر دامنه‌دار]
                                                             ▲
                                                             │
                                             (۳) ارسال انبوه پاسخ‌های جعلی UDP
                                                 (تست شناسه: 0x0000 - 0xFFFF)
                                                 (آدرس جعلی: 198.51.100.25)
                                                             │
                                             [مهاجم شبکه / گره مرد میانی]

عملکرد روش سنتی مسموم‌سازی حافظه موقت

در روند متعارف، دستگاه کاربر درخواست خود را به تحلیل‌گر بازگشتی محلی ارسال می‌کند. اگر رکورد مورد نظر در حافظه موقت موجود نباشد، تحلیل‌گر بازگشتی به ترتیب سرورهای ریشه (.)، سرورهای پسوند دامنه (.com) و سرور معتبر نهایی (example.com) را فراخوانی می‌کند.

برای تطبیق پاسخ دریافتی UDP با درخواست باز، استاندارد RFC 1035 یک شناسه تراکنش ۱۶ بیتی (TXID) در سرآیند DNS تعیین کرده است. با رسیدن بسته پاسخ، تحلیل‌گر چهار مولفه را بررسی می‌کند:

  1. آدرس آی‌پی مبدا: باید دقیقاً با نشانی سرور معتبر دامنه یکسان باشد.
  2. پورت مقصد UDP: باید مطابق پورتی باشد که پرس‌وجو از آن ارسال شده است (پیش از ۲۰۰۸ همواره پورت ثابت ۵۳).
  3. بخش پرس‌وجو (Question): باید با نام دامنه و نوع رکورد درخواستی (A، AAAA، MX) مطابقت نماید.
  4. شناسه تراکنش TXID: باید با مقدار تصادفی ۱۶ بیتی ارسالی تحلیل‌گر منطبق باشد.

یک فیلد ۱۶ بیتی دقیقاً شامل ۶۵,۵۳۶ مقدار ممکن است ($2^{16}$). در روش کلاسیک پیش از ۲۰۰۸، نفوذگر درخواستی برای bank.example.com می‌فرستاد و هم‌زمان سیل عظیمی از پاسخ‌های جعلی UDP را با شناسه‌های مختلف تراکنش به سمت تحلیل‌گر روانه می‌کرد.

اما مانع اصلی این شیوه، طول عمر رکورد (TTL) بود. اگر پاسخ معتبر اصلی زودتر به تحلیل‌گر می‌رسید، مقدار درست برای مدت زمان TTL (معمولاً ۸۶,۴۰۰ ثانیه، معادل ۲۴ ساعت) در حافظه ثبت می‌شد و مهاجم ناچار بود برای آزمایش مجدد، یک شبانه‌روز کامل منتظر انقضای کش بماند.

نوآوری دن کامینسکی: فراخوانی زیردامنه‌های تصادفی

در ژوئیه سال ۲۰۰۸، پژوهشگری به نام Dan Kaminsky نقصی اساسی را برملا کرد که محدودیت زمانی TTL را کاملاً بی‌اثر ساخت. در این شیوه، مهاجم به جای دامنه‌ی اصلی، بی‌وقفه زیردامنه‌های تصادفی و ناموجود تولید می‌کند:

  • x01a9.bank.example.com
  • m47k2.bank.example.com
  • z99p8.bank.example.com

چون این اسامی در حافظه تحلیل‌گر وجود ندارند، سرور ناچار است برای هر درخواست، پرس‌وجوی جدیدی به سرور معتبر بفرستد. مهاجم نیز بسته‌های جعلی UDP را برای هر زیردامنه ارسال می‌کند، اما در بخش‌های Authority و Additional بسته‌های جعلی، رکوردهای واگذاری نام را جاسازی می‌نماید:

;; QUESTION SECTION:
x01a9.bank.example.com.    IN    A

;; ANSWER SECTION:
x01a9.bank.example.com.    IN    A    198.51.100.99

;; AUTHORITY SECTION:
bank.example.com.          IN    NS   ns.attacker-domain.org.

;; ADDITIONAL SECTION:
ns.attacker-domain.org.    IN    A    198.51.100.66

طبق اصول پذیرش واگذاری در DNS، سرور بازگشتی تغییرات کارگزاران نام را برای دامنه‌ی مربوطه می‌پذیرد. اگر تنها یکی از پاسخ‌های ساختگی پیش از پاسخ اصلی با شناسه ۱۶ بیتی هماهنگ شود، تحلیل‌گر نه تنها زیردامنه جعلی را ثبت می‌کند، بلکه سرور معتبر bank.example.com را با نشانی سرور مهاجم یعنی ns.attacker-domain.org بازنویسی می‌نماید!

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

بررسی آنتروپی ریاضی و تفکیک تصادفی پورت مبدا (RFC 5452)

علت آسیب‌پذیری در روش کامینسکی، محدودیت فضای جست‌وجو بود. فضای ۱۶ بیتی ($N = 65,536$) با بهره‌گیری از اصل تناقض روز تولد (Birthday Attack) و بسته‌های متراکم UDP به آسانی شکسته می‌شود.

کارگروه مهندسی اینترنت (IETF) برای حل این نقص استاندارد RFC 5452 را تصویب کرد. این قاعده تصادفی‌سازی پورت مبدا (SPR) را الزامی می‌کند. به جای استفاده از پورت ثابت ۵۳، تحلیل‌گر یک پورت موقت UDP را به صورت تصادفی از میان ۵۰,۰۰۰ پورت در دسترس (در بازه ۱۰۲۴ تا ۶۵۵۳۵ یا ۴۹۱۵۲ تا ۶۵۵۳۵) برمی‌گزیند.

مولفه امنیتی استاندارد پایه RFC 1035 تصادفی‌سازی پورت RFC 5452 اعتبارسنجی با امضای DNSSEC
آنتروپی شناسه تراکنش ۱۶ بیت ($2^{16} = 65,536$) ۱۶ بیت ($2^{16} = 65,536$) ۱۶ بیت ($2^{16} = 65,536$)
آنتروپی پورت مبدا ۰ بیت (پورت ثابت ۵۳) حدود ۱۵.۶ بیت (نزدیک ۵۰,۰۰۰ پورت) حدود ۱۵.۶ بیت (نزدیک ۵۰,۰۰۰ پورت)
کل فضای احتمالات ۶۵,۵۳۶ حالت حدود $3.27 imes 10^9$ حالت حدود $3.27 imes 10^9$ حالت
بسته‌های لازم برای شانس ۵۰٪ حدود ۳۰۰ بسته حدود ۲,۰۰۰,۰۰۰ بسته بسته‌های فاقد امضا فوراً رد می‌شوند
ماهیت مهار تهدید محاسبات آماری و احتمالی محاسبات آماری و احتمالی امضای رقومی نامتقارن (RSA/ECDSA)

با ترکیب فیلد ۱۶ بیتی TXID با پورت مبدا تصادفی، مهاجم باید هر دو متغیر را هم‌زمان حدس بزند:

$$ ext{مجموع احتمالات} = 2^{16} imes pprox 50,000 pprox 3,276,800,000$$

تلاش برای جعل بیش از ۳.۲ میلیارد ترکیب، پهنای باند را مسدود کرده و سامانه‌های امنیتی شبکه را پیش از نتیجه‌گیری به اخطار وامی‌دارد.

راهکار ساختاری پایدار: زنجیره اعتماد DNSSEC

اگرچه تصادفی‌سازی پورت طبق RFC 5452 هزینه حمله را به شدت بالا می‌برد، اما در نهایت یک سازوکار آماری است. دروازه‌های NAT و فایروال‌ها گاهی پورت‌های UDP را به بازه‌ای کوچک و ثابت محدود می‌کنند و آنتروپی را تقلیل می‌دهند.

پاسخ بنیادین، پیاده‌سازی افزونه‌های امنیتی DNS یا همان DNSSEC بر مبنای استانداردهای RFC 4033 و RFC 4034 و RFC 4035 است. این ساختار امضای دیجیتال با کلید عمومی را به رکوردهای نام دامنه می‌افزاید:

[ناحیه ریشه / Root Zone (.)]
  └─ امضای کلید KSK روی ZSK ──> امضای رکورد DS برای ناحیه .com
                                      │
                                      ▼
[ناحیه دامنه سطح بالا .com]
  └─ امضای کلید KSK روی ZSK ──> امضای رکورد DS برای example.com
                                      │
                                      ▼
[ناحیه معتبر دامنه‌دار example.com]
  └─ امضای کلید KSK روی ZSK ──> ایجاد امضای RRSIG برای bank.example.com
  1. امضای دیجیتال رکورد (RRSIG): امضای رمزنگاری‌شده همراه با داده‌های دامنه توسط الگوریتم‌های RSA یا ECDSA.
  2. کلید عمومی دامنه (DNSKEY): کلید مورد نیاز برای ارزیابی صحت امضای RRSIG.
  3. امضاکننده تفویض (DS): مقدار هش SHA-256 کلید ناحیه فرزند در ناحیه والد، پیونددهنده زنجیره تا ریشه اصلی شبکه.

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

خطرات شبکه‌های محلی و مهار تهدید در تونل لایه ۳

در شبکه‌های وای‌فای عمومی، نفوذگر هم‌مسیر نیازی به تخمین احتمالات ندارد:

  • شنود بدون واسطه: بسته‌های عادی DNS به صورت متن ساده مبادله می‌شوند و مهاجم شناسه تراکنش و پورت مبدا را در دم استخراج می‌کند.
  • ارسال پیش‌دستانه پاسخ: با توجه به مسافت کم در شبکه محلی، پاسخ تقلبی چند میلی‌ثانیه پیش از سرور خارجی به دستگاه قربانی می‌رسد.
[برنامه‌های سیستم کاربر]
           │ (درگاه داخلی: 127.0.0.1)
           ▼
[رابط شبکه مجازی: wg0 / tun0]
   رمزنگاری پیشرفته ChaCha20-Poly1305 (لایه شبکه ۳)
           │
           ▼
[پیوند فیزیکی وای‌فای / کابل شبکه]
   تنها جریان رمزنگاری‌شده پروتکل‌های WireGuard / RiceGuard قابل رویت است
   اطلاعات دامنه‌ها، شناسه تراکنش و پورت ۵۳ کاملاً از دید مهاجم پنهان است
           │
           ▼
[تحلیل‌گرهای بازگشتی امن VPNRice]
   اعمال کامل استاندارد پورت RFC 5452 و اعتبارسنجی جامع DNSSEC
   عدم ذخیره گزارش پرس‌وجو، تحلیل بازگشتی مستقیم روی بستر Anycast

برای خنثی‌سازی کامل این مخاطرات، سرویس VPNRice تمامی بسته‌های پرس‌وجوی DNS را درون تونل رمزنگاری‌شده لایه ۳ هدایت می‌کند. بر پایه پروتکل RiceGuard:

  • درخواست‌ها پیش از ورود به کارت شبکه در بسته‌های ChaCha20-Poly1305 همراه با تگ اصالت ۱۲۸ بیتی محافظت می‌شوند.
  • در بستر وای‌فای فقط داده‌های رمزنگاری‌شده غیرقابل خوانش جابه‌جا می‌شوند و استخراج فیلدهای شناسایی ناممکن می‌گردد.
  • تحلیل نام‌ها مستقیماً بر عهده سرورهای امن VPNRice با فعال‌سازی کامل سازوکارهای RFC 5452 و امضای رقومی DNSSEC خواهد بود.

روش‌های آزمایش سلامت تحلیل‌گر نام دامنه

کارشناسان و مدیران شبکه می‌توانند وضعیت پایداری و درستی اعتبارسنجی DNSSEC را با دستورات زیر ارزیابی کنند:

# ۱. استعلام دامنه با درخواست اعتبارسنجی امضاهای DNSSEC
dig +dnssec bank.example.com @127.0.0.1

# ۲. اطمینان از درج پرچم ad (داده تاییدشده) در سرآیند پاسخ
# flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

# ۳. ارزیابی ناحیه دارای امضای معیوب عمدی (باید خطای SERVFAIL برگرداند)
dig sigfail.verteiltesysteme.net @127.0.0.1

# ۴. بررسی سلسله‌مراتب اعتماد با دستور delv
delv @127.0.0.1 bank.example.com
  • فعال‌سازی بررسی DNSSEC: در تنظیمات سیستم‌عامل (systemd-resolved یا کارگزاران مشابه) گزینه DNSSEC=yes را فعال نگه دارید.
  • انتقال درخواست‌ها در بستر تونل اختصاصی: در اماکن عمومی همواره از ارتباط امن پروتکل‌های WireGuard یا RiceGuard بهره بگیرید.
  • مسدودسازی پاسخ‌های نامعتبر: در صورت بروز خطای SERVFAIL ارتباط را متوقف کنید و از بازگشت به درخواست‌های رمزنگاری‌نشده بپرهیزید.