ردیابی حافظه نهان DNS: خطرات کاوش غیربازگشتی و ایمن‌سازی با تونل‌های VPN

حتی در شرایطی که ترافیک داده‌ها با پروتکل‌های نوین رمزنگاری لایه انتقال نظیر TLS 1.3 و HTTPS محافظت می‌شوند، فرآیند تحلیل نام دامنه اغلب فعالیت‌های وب کاربران را آشکار می‌سازد. سازمان‌ها و کاربران خانگی به طور مداوم از کارگزارهای بازگشتی مشترک (Shared Recursive Resolvers) که توسط ارائه‌دهندگان اینترنت (ISP)، خدمات‌دهندگان عمومی DNS یا مسیریاب‌های شبکه محلی عرضه می‌شوند، استفاده می‌کنند. اگرچه مکانیزم ذخیره‌سازی موقت (Cache) با نگهداری نشانی‌های IP قبلاً تحلیل‌شده موجب شتاب‌بخشی به بارگذاری صفحات می‌شود، اما وضعیت این حافظه نهان مشترک یک کانال جانبی خطرناک برای نظارت ایجاد می‌کند: حمله ردیابی حافظه نهان DNS (یا DNS Cache Snooping).

با ارسال درخواست‌های هدفمند غیربازگشتی به کارگزار مشترک یا با ثبت دقیق تغییرات در زمان رفت و برگشت بسته (RTT)، یک ناظر خارجی یا نفوذگر در شبکه محلی می‌تواند مشخص سازد که چه دامنه‌هایی به تازگی توسط کاربران دیگرِ همان کارگزار بازدید شده است. این شیوه نفوذ نیازمند استقرار تجهیزات میانی (Man-in-the-Middle)، نصب بدافزار روی سامانه‌های هدف یا رمزگشایی جریان‌های ارتباطی نیست.

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

تناقض حریم خصوصی در DNS: چرا رمزنگاری مسیر انتقال، کارگزارهای تحلیل را آسیب‌پذیر می‌گذارد

استانداردهای نوین امنیت تمرکز عمده خود را بر رمزنگاری داده‌ها در حال انتقال گذاشته‌اند. پروتکل HTTPS از محتوای پیام‌ها و سرآیندها محافظت می‌کند و راهکارهای DNS روی HTTPS (یا DoH، استاندارد RFC 8484) و DNS روی TLS (یا DoT، استاندارد RFC 7858) تبادل بسته‌ها میان کلاینت و کارگزار را رمزنگاری می‌کنند. با این حال، رمزگذاری مسیر انتقال هیچ تاثیری بر شیوه ذخیره‌سازی داده‌ها در حافظه موقت کارگزار بازگشتی ندارد.

یک کارگزار بازگشتی برای کاستن از ترافیک ارسالی به سرورهای معتبر اینترنت و کاهش زمان انتظار، رکوردهای منابع (نظیر A، AAAA، CNAME و TXT) را در رم نگهداری می‌کند. هنگامی که کاربری نام دامنه portal.example.org را درخواست می‌کند، کارگزار با سرورهای بالادست ارتباط برقرار کرده، پاسخ را به کاربر می‌دهد و رکورد را تا پایان یافتن مهلت زمان بقا (TTL) در حافظه خود نگه می‌دارد:

[ سامانه کاربر ] ---------> پرس‌وجو: example.org ---------> [ کارگزار مشترک ]
                                                                   |
                                                      (نبود در کش: جست‌وجوی بیرونی)
                                                                   |
                                                                   v
                                                        [ سرور معتبر DNS ]
                                                                   |
[ سامانه کاربر ] <--------- پاسخ (TTL = 300 ثانیه) <--------- [ کارگزار مشترک ]
                                                         (ذخیره در RAM: ۳۰۰ ثانیه)

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

کاربران می‌توانند از طریق بخش بررسی نشانی IP و نشت شبکه وضعیت درگاه خروجی و رفتار درخواست‌های عمومی خود را بررسی نمایند.

کالبدشکافی ردیابی حافظه نهان DNS: کاوش غیربازگشتی و شمارش معکوس TTL

تکنیک ردیابی حافظه نهان DNS بر پایه دو راهبرد بنیادین عمل می‌کند: کاوش مستقیم به وسیله پرس‌وجوهای غیربازگشتی و تحلیل مقایسه‌ای زمان تاخیر. هر دو روش داده‌های خود را از محتوای فرار حافظه رم کارگزار استخراج می‌کنند.

سازوکار پرس‌وجوی غیربازگشتی: بیت RD و بازیابی اطلاعات کش

در سرآیند پروتکل DNS بیتی با عنوان تمایل به بازگشت‌پذیری یا Recursion Desired (RD) در اسناد RFC 1034 و RFC 1035 مشخص شده است. وقتی مقدار این بیت 1 باشد، کلاینت از کارگزار می‌خواهد در صورت نبود پاسخ در حافظه، جست‌وجوی کامل سلسله‌مراتبی را پیگیری کند. اما اگر مقدار RD برابر 0 تنظیم گردد، از کارگزار خواسته می‌شود تنها در صورتی که رکورد از پیش در حافظه نهان محلی وجود دارد، آن را تحویل دهد:

+-------------------------------------------------------------------------+
|                               سرآیند بسته DNS                           |
+------------------+------------------+-----------------+-----------------+
|      ID (16)     | QR | Opcode (4)  | AA | TC | RD(0) | RA | Z | RCODE(4)|
+------------------+------------------+-----------------+-----------------+

هنگامی که مهاجم درخواستی با بیت RD = 0 مخابره می‌کند:

1. انطباق با حافظه نهان (Cache Hit): اگر دامنه‌ای اخیراً توسط کاربران شبکه بازدید شده باشد، کارگزار در کسری از میلی‌ثانیه بخش Answer را به همراه رکورد و مهلت TTL باقی‌مانده بازمی‌گرداند.
2. عدم انطباق با حافظه (Cache Miss): اگر دامنه مورد نظر درخواست نشده باشد، کارگزار فرآیند جست‌وجو را آغاز نکرده و بخش Answer را خالی بازمی‌گرداند، یا نشانی سرورهای ریشه را در بخش Authority می‌فرستد و یا خطای SERVFAIL یا REFUSED اعلام می‌کند.

این تمایز رفتاری، اطلاعاتی قطعی در خصوص پیشینه بازدید از دامنه هدف در اختیار مهاجم می‌گذارد.

تحلیل تغییرات زمانی: سنجش نوسانات RTT برای شناسایی دامنه‌های ذخیره‌شده

برخی مدیران شبکه کارگزارهای خود را به گونه‌ای تنظیم می‌کنند که درخواست‌های دارای بیت RD = 0 از سوی آدرس‌های خارج از شبکه رد شوند. مهاجمان برای مواجهه با این تدبیر، درخواست‌های بازگشتی عادی (RD = 1) می‌فرستند و زمان پاسخگویی رفت و برگشت بسته (RTT) را با دقت بالا محاسبه می‌کنند:

+-----------------------+------------------------+------------------------+
| وضعیت رکورد در حافظه  | تاخیر معمول پاسخ (RTT) | علت فیزیکی زمان صرف‌شده|
+-----------------------+------------------------+------------------------+
| موجود در رم (Hit)     | ۱ میلی‌ثانیه تا ۵      | خواندن بی‌واسطه از رم  |
| غایب در کش (Miss)     | ۴۵ میلی‌ثانیه تا ۲۵۰   | جست‌وجو در سرورهای جهان|
+-----------------------+------------------------+------------------------+

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

نظارت و شناسایی شبکه: نشت چه اطلاعاتی در اختیار مهاجمان قرار می‌گیرد

کاوش در محتوای ذخیره‌شده DNS پیامدهای امنیتی متعددی را به دنبال دارد:

1. جمع‌آوری داده برای فیشینگ هدفمند (Spear-Phishing): مهاجمان کارگزار سازمان را برای کشف نرم‌افزارهای ابری (نظیر Jira، سامانه اداری Workday یا پرتال‌های بانکی) وارسی می‌کنند. اطلاع از سرویس‌های فعال به مهاجمان امکان می‌دهد پیام‌های جعلی با شباهت فوق‌العاده به ابزارهای مورد استفاده کارکنان ایجاد کنند.
2. پی بردن به بررسی‌های تیم‌های امنیتی: هنگام تحلیل تهدیدها و دامنه‌های فرماندهی بدافزار (C2)، تیم‌های دفاعی درخواست‌های تحلیلی می‌فرستند. مهاجمی که کش کارگزار سازمانی را رصد می‌کند، به سرعت متوجه شناسایی زیرساخت مخرب خود شده و پیش از تکمیل ارزیابی‌ها، ردپای خود را پاک می‌کند.
3. تحلیل الگوهای رفتاری کاربران: در وای‌فای‌های عمومی یا مجتمع‌های مسکونی، بررسی مراجعات به درگاه‌های خدمات پزشکی، حقوقی یا مالی به مهاجمان امکان می‌دهد علایق و رفتارهای اشخاص را شناسایی کنند.
4. تخمین دقیق زمان دسترسی به کمک TTL: از آنجا که رکوردهای معتبر با مقادیر اولیه ثابتی در TTL (مانند ۳۶۰۰ ثانیه) صادر می‌شوند، کم کردن رقم دریافتی از مقدار پایه، زمان دقیق گذشته از آخرین بازدید را نشان می‌دهد:

$$ ext{زمان سپری‌شده} = ext{مقدار اولیه TTL} - ext{مقدار TTL پاسخ}$$

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

خطرات امنیتی مرتبط با DNS در لایه‌های مختلف و با سازوکارهای متفاوتی نمود می‌یابند:

بر خلاف شیوه‌های تهاجمی تغییر داده‌ها که در مبحث مسموم‌سازی حافظه نهان DNS و حملات کامینسکی ارزیابی شده است، روش ردیابی کش هیچ رکوردی را دستکاری نمی‌کند، بلکه کارکرد رسمی کارگزار را علیه حریم خصوصی کاربران به کار می‌گیرد.

مخاطرات پیکربندی کارگزار: بازگشت‌پذیری عمومی و نقص فهرست‌های دسترسی

اصلی‌ترین محرک فراگیری این نوع آسیب‌پذیری در مقیاس وسیع، کارگزارهای باز (Open Resolvers) هستند؛ سامانه‌هایی که به درگاه ۵۳ روی رابط متصل به اینترنت اجازه می‌دهند به تقاضای هر نشانی دلخواه در جهان پاسخ دهد.

مطالعات شبکه‌ای نشان می‌دهند میلیون‌ها مودم خانگی و کارگزار سازمانی پورت ۵۳ را روی اینترنت باز گذاشته‌اند. همراه شدن این نقص با تنظیمات پیش‌فرضی که به درخواست‌های غیربازگشتی پاسخ می‌دهند، به هر مهاجم دوری امکان می‌دهد سوابق مرورگر سامانه‌های آن شبکه را تفتیش کند.

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

مقاوم‌سازی کارگزار: راهکارهای بخش‌بندی حافظه نهان در BIND و Unbound

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

1. کنترل دسترسی و تفکیک نماها در BIND 9: در تنظیمات BIND 9، پردازش بازگشتی و دسترسی به کش باید صرفاً به زیرشبکه‌های داخلی محدود شود:

acl "trusted_lan" {
    127.0.0.1;
    10.0.0.0/8;
    192.168.1.0/24;
};

options {
    recursion yes;
    allow-recursion { trusted_lan; };
    allow-query { trusted_lan; };
    allow-query-cache { trusted_lan; };
    version none;
    hostname none;
};

تنظیم دقیق allow-query-cache مانع از دریافت رکوردهای موقت توسط کاربران تاییدنشده می‌گردد.

2. ایمن‌سازی و کمینه‌سازی دامنه‌ها در Unbound: نرم‌افزار Unbound ابزارهای موثری برای مهار این درز اطلاعاتی فراهم می‌کند:

server:
    access-control: 127.0.0.1/32 allow
    access-control: 10.200.0.0/16 allow
    access-control: 0.0.0.0/0 refuse
    hide-identity: yes
    hide-version: yes
    qname-minimisation: yes
    minimal-responses: yes

فعال‌سازی qname-minimisation (مطابق RFC 7816) داده‌های ارسالی به سرورهای واسط را محدود ساخته و پارامتر access-control نیز درخواست‌های ناآشنا را بی‌پاسخ می‌گذارد.

کارگزارهای اختصاصی RiceGuard: حذف خطرات حافظه نهان مشترک با تونل‌های VPN

هرچند ایمن‌سازی سرورهای داخلی از دفاتر ثابت حراست می‌کند، ولی کاربران سیار در اتصال به شبکه‌های عمومی با کارگزارهای مشترک ناامن مواجه می‌شوند. VPNRice با بهره‌گیری از معماری اختصاصی RiceGuard این ضعف را به شکل ریشه‌ای برطرف می‌سازد:

[ برنامه کاربردی سامانه ]
             |
             v
[ کارگزار محلی روی رابط لوپ‌بک (127.0.0.1:53) ]
             | (هدایت امن درخواست‌ها)
             v
+-------------------------------------------------------+
| تونل رمزنگاری‌شده لایه ۳ RiceGuard (هسته WireGuard)   |
+-------------------------------------------------------+
             |
             | (بسته‌های رمزگذاری‌شده UDP در بستر عمومی)
             v
+-------------------------------------------------------+
| کارگزارهای بازگشتی تفکیک‌شده (حافظه رم مجزا برای هر نشست)|
+-------------------------------------------------------+
             |
             v (ارسال درخواست بازگشتی با حداقل نام دامنه)
[ سرورهای معتبر DNS در بستر اینترنت ]

1. تفکیک فضای کش برای هر تونل: سامانه RiceGuard به جای ذخیره همه داده‌ها در یک مخزن مشترک، برای هر اتصال رمزگذاری‌شده یک فضای مستقل در حافظه ایجاد می‌کند. این جداسازی فیزیکی در رم، امکان هر نوع کاوش متقابل را به صفر می‌رساند.
2. انتقال الزامی در کانال رمزگذاری‌شده: تمامی پیام‌های DNS مستقیماً به بستر امن تونل لایه ۳ فرستاده می‌شوند. افراد حاضر در همان شبکه محلی فقط بسته‌های مبهم داده را مشاهده می‌کنند.
3. تحلیل نام بدون ثبت هویت ارتباطی: با بهره‌گیری از اصول شرح‌داده‌شده در بررسی معماری ارتباطی محرمانه Oblivious DNS روی HTTPS، کارگزار پردازشگر نمی‌تواند هویت آی‌پی کلاینت را با دامنه درخواستی پیوند دهد.

برای جلوگیری از رهگیری رفتار اینترنتی از طریق DNSهای اشتراکی، می‌توانید اقدام به دریافت VPNRice فرمایید.

ارزیابی‌های تجربی: تاخیر پاسخ، دقت شناسایی و ضریب افشای حریم خصوصی

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

این داده‌ها آشکار می‌سازند که بستن بیت RD = 0 به تنهایی بازدارنده نیست و تنها جداسازی کامل حافظه نهان برای هر کاربر، امنیت واقعی را تضمین می‌کند.

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

مدیران زیرساخت می‌توانند پیکربندی سرورهای خود را با ابزارهای سیستمی ارزیابی نمایند.

پیکربندی کنترل دسترسی و کمینه‌سازی QNAME در Unbound

نمونه ساختار امن برای درج در پرونده unbound.conf:

server:
    interface: 10.200.0.1
    port: 53
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # مهار دسترسی: صرفاً کاربران درون تونل
    access-control: 10.200.0.0/24 allow
    access-control: 0.0.0.0/0 refuse

    # تدابیر حفظ حریم خصوصی
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: yes
    qname-minimisation: yes

ارزیابی آسیب‌پذیری حافظه نهان DNS با ابزار تشخیصی Dig

بررسی واکنش کارگزار در مواجهه با پرسش‌های غیربازگشتی:

# آزمون ۱: ارسال پرس‌وجوی غیربازگشتی برای دامنه معین
dig +norecurse @10.200.0.1 example.org A

# ارزیابی پاسخ:
# - در صورت بازگشت بخش Answer به همراه TTL: کارگزار آسیب‌پذیر است
# - در صورت دریافت وضعیت REFUSED یا خالی بودن بخش Answer: کاوش غیربازگشتی مسدود است

# آزمون ۲: مقایسه زمان بازگشت برای دامنه‌های تکراری و تصادفی
dig +noall +stats @10.200.0.1 example.org
dig +noall +stats @10.200.0.1 unvisited-random-domain-74921.org

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