خبرمقالات

ترافیک DNS را چطور رمزنگاری کنیم؟

پروتکل سیستم نام دامنه (DNS[۱]) که وظیفه تبدیل نام دامنه به آدرس اینترنتی (IP) را بر عهده داشته و ستون فقرات اینترنت را تشکیل می‌دهد، در سال‌های اخیر دچار تغییرات و اصلاحات زیادی شده است.

عدم استفاده از سازوکارهای حفاظتی قوی در نسخه‌های اولیه DNS و همچنین شناسایی نقاط ضعف مختلف از جمله خطای Kaminsky که به مهاجمان سایبری امکان جعل آدرس‌های اینترنتی را می‌داد، موجب طراحی پروتکل‌های امنیتی سیستم نام دامنه (DNSSEC[۲]) در سال ۲۰۱۰ شد. هدف از طراحی DNSSEC ایجاد سازوکارهای حفاظتی از طریق امضاهای دیجیتال بود.

نحوه طراحی DNSSEC به صورتی است که کلاینت‌های DNS در سطح جهان می‌توانند بررسی‌های لازم برای تشخیص معتبر بودن پاسخ DNS که از یک سرور DNS مجاز ارسال شده است را انجام داده و مطمئن شوند که این پاسخ در مراحل انتقال دچار تغییر و دستکاری نشده باشد. با این حال، سؤالی که برای کاربران پیش می‌آید این است که اگر DNSSEC قادر به تأمین امنیت کامل است پس چه دلیلی برای شکل‌گیری پروتکل‌های «DNS بر روی HTTPS» و «DNS بر روی TLS» وجود دارد؟

نکته‌ای که وجود دارد این است که پروتکل‌های DNSSEC فقط بررسی می‌کنند آیا پاسخ‌های DNS امن بوده و همچنین جامعیت داده‌ها رعایت می شود یا خیر. البته آنها هیچ ضمانتی را برای حفاظت از حریم خصوصی ایجاد نمی‌کنند. در حالی که پروتکل‌هایی مثل DNS بر روی  HTTPُS یا DNS بر روی TLS، رمزنگاری سراسری را انجام می‌دهند. در واقع وظیفه اصلی آنها حفظ محرمانگی داده‌ها است. بنابراین ترافیک DNS کاربر از رمزنگاری سراسری، درست مثل ترافیک وب که بین سیستم او و سایت‌های HTTPS در جریان است، بهره‌مند می‌شود.

در ادمه این مطلب از فراست، پروتکل‌های DoH ،DoT و همچنین تفاوت‌های بین آنها را بررسی می‌کنیم.

پروتکل DNS بر روی HTTPS چیست؟

پروتکل DNS در حالت پیش فرض بر روی پروتکل داده‌نگار کاربر (UDP[۳]) که یک پروتکل مخصوص لایه انتقال است، قرار داشته و با استفاده از پورت ۵۳ کار می‌کند. علاوه‌ بر این کاربر می‌تواند از DNS بر روی پروتکل کنترل انتقال (TCP[۴]) نیز استفاده نماید.

پروتکل DoH آدرس دامنه درخواست‌های دریافتی را به آدرس آی‌پی تبدیل می‌کند. DoH این کار را از طریق پورت ۴۴۳ و با استفاده از پروتکل HTTPS انجام می‌دهد. همچنین DoH تمام درخواست‌های DNS کاربر را در ترافیک‌های معمول HTTPS که در تمام فایروال‌ها و شبکه‌ها ارسال می‌شود، به صورت رمزنگاری شده ارسال می‌کند.

بنابراین با توجه به اینکه با وجود DoH، تمام درخواست‌های DNS و همچنین پاسخ‌های آنها هر دو از طریق HTTPS منتقل شده و از پورت ۴۴۳ استفاده می‌کنند، پس امکان تشخیص این ترافیک از سایر ترافیک‌های HTTPS وب وجود ندارد.

مثلاً کاربر با استفاده از سرویس DoH شرکت گوگل می‌تواند از طریق مرورگر خود آدرس دامنه سایت CSOOnline.com (که اطلاعات جامعی درباره نحوه حفاظت از داده‌ها می‌دهد) را به شماره‌های متناظر تبدیل کند. این در حالی است که روش تایپ آدرس‌های HTTPS در مرورگر برای تبدیل آنها به آی‌پی اصلی، مشابه با بازدید از هر وب سایت معمولی که از پروتکل‌های SSL یا TLS استفاده می‌کند، است.

سپس پاسخ DNS که توسط گوگل ایجاد می‌شود، آی‌پی سرور CSO (رکوردهای A) را نشان می‌دهد که همگی در قالب JSON (قالبی که جهت نقل و انتقال داده مورد استفاده قرار می‌گیرد) مرتب شده‌اند.

هر چند ممکن است مدیر شبکه در جریان باشد که شما از سرویس DoH گوگل استفاده می‌کنید اما با فرض اینکه بین شما و DoH شرکت گوگل یک پروکسی واسط ([۵]MitM) وجود نداشته باشد، هیچ شخصی قادر به تشخیص دامنه‌ای که شما در حال جستجوی آن هستید (CSO Online) و پاسخی که به درخواست شما داده شده (نتیجه ایجاد شده در قالب JSON) نیست. از این رو استفاده از DoH، جامعیت اطلاعات دریافتی و محرمانگی داده‌ها را تضمین می‌کند. در نتیجه امکان دستکاری پاسخ DNS در حین انتقال آن وجود ندارد.

البته تحویل DNS از طریق کانالی با رمزنگاری سراسری می‌تواند مشکل آفرین هم باشد. برای مثال پیش از این شاهد سوءاستفاده از سرویس‌های DNS بر روی HTTPS توسط مهاجمان سایبری برای مخفی کردن ترافیک های مخرب بوده‌ایم. مهاجمان می‌توانند دامنه‌های مخرب خودشان را از طریق سرویس‌های DoH گوگل یا هر شرکت دیگری تبدیل کنند. پیام رمزنگاری شده حاصل، حاوی رکوردهای TXT (یکی از انواع رکوردهای DNS است که امکان نسبت دادن یک متن دلخواه به یک دامنه را فراهم می‌کند) خواهد بود که برای دامنه تحت کنترل مهاجمان با پی لودهای مخرب رمزنگاری شده مورد استفاده قرار می‌گیرد. بدافزار مهاجمان نیز امکان تحلیل و تشخیص آن را دارد.

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

پروتکل DNS بر روی TLS چیست؟

DoT برای ارتباط از پروتکل TCP استفاده می‌کند و درخواست‌های DNS را به جای پروتکل HTTPS که در لایه کاربرد قرار دارد، بر روی پروتکل TLS رمزنگاری می‌کند. این پروتکل این اطمینان را ایجاد می‌کند که هیچ کدام از درخواست‌ها در حین انتقال تغییر نمی کنند.

این پروتکل از یک پورت کاملاً متفاوت یعنی ۸۵۳ استفاده می‌کند که از پورت‌های مورد استفاده توسط HTTPS (443) یا DNS ساده قدیمی (۵۳) مجزا است. همچنین با توجه به اینکه ارتباط‌های بین کلاینت DNS و تفکیک کننده آدرس بر روی پروتکل TLS انجام می‌شود بنابراین ترافیک DoT نیز از رمزنگاری سراسری استفاده می‌نماید.

کدام پروتکل DNS بهتر است؟

اینکه پروتکل DoH بهتر است یا DoT، جای بحث دارد. با توجه به انعطاف‌پذیری ایجاد شده توسط DoT برای نظارت بر درخواست‌های DNS ممکن است مدیران شبکه ترجیح دهند آن را انتخاب کنند. این ویژگی برای کارشناسان امنیت که به دنبال ایجاد انسداد در ترافیک DNS و شناسایی نشانه های نفوذ در شبکه هستند، مفید است.

از طرفی دیگر با توجه به اینکه درخواست‌های DNS با ترافیک HTTPS ترکیب شده و مدیر شبکه قادر به تشخیص اینکه چه دامنه‌هایی تبدیل شده (توسط سیستم نام دامنه) یا DNS چه پاسخ‌هایی را ایجاد می‌کند نیست بنابراین DoH امنیت بیشتری را برای کاربران نهایی تأمین می‌کند. این شرایط باعث می‌شود که مسدود کردن DoH بدون تأثیر گذاشتن بر ارتباط‌های تجاری مجاز برای مدیران شبکه سخت‌تر شود.

برای مثال راهبر فایروال سازمانی به راحتی می‌تواند آن را به نحوی پیکربندی نموده و قانونی در آن ایجاد کند که تمام ترافیک‌های در جریان با پورت ۸۵۳ را مسدود کند (جهت مسدود کردن DoT). در حالی که انسداد DoH از طریق مسدود کردن پورت ۴۴۳ امکان‌پذیر نیست زیرا این کار باعث مسدود شدن ترافیک مجاز وب هم می‌شود.

نکته مهم دیگری که وجود دارد این است که چون DoT روی لایه انتقال قرار می‌گیرد به همین خاطر سبک وزن‌تر است. DoH از HTTPS استفاده می‌کند که بر روی لایه کاربرد مستقر می‌شود. با توجه به اینکه هر چقدر لایه‌های بیشتری دخیل باشند، اندازه بسته‌ها نیز کوچکتر شده و سطح کارایی کمی بیشتر می‌شود پس بسته‌های DoT سبک‌تر بوده و در نتیجه تأخیر کمتری ایجاد می شود.

البته رقابت بین پروتکل‌های رمزنگاری DoT و DoH به همین جا ختم نمی‌شود. برای مثال شرکت‌های زیرساخت شبکه مثل کلاودفلیر (Cloudflare) بسته‌های DNS را به صورتی ارتقا داده‌اند که با پروتکل‌های جدید و جالبی مثل DNS بر روی توئیتر، DNS بر روی تور، DNS بر روی تلگرام یا DNS بر روی ایمیل همخوانی داشته باشند.

کلاودفلیر یک سرویس پیازی (Onion service) دارد که به بازدیدکنندگان وب سایت‌های مشتریانش امکان استفاده از شبکه تور را می‌دهد. نسخه ۱.۱.۱.۱ که تفکیک کننده آدرس کلاودفلیر است از DoH و DoT پشتیبانی کرده و از طریق سرویس پیازی کلاودفلیر قابل دسترس است.

به گفته نیک سالیوان، مدیر تحقیقات شرکت کلاودفلیر، «ما این سرویس را DNS بر روی تور نامیده ایم. علاوه ‌بر این ما یک ربات توئیتر هم داریم که توئیت‌هایی با قالب خاص را برای آدرس @۱۱۱۱Resolver دریافت کرده، آنها را به درخواست DNS تبدیل نموده، این درخواست‌ها را با آدرس ۱.۱.۱.۱ تحلیل و نتیجه را برمی‌گرداند».

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

برای مثال مسدود کردن DNS بر روی توئیتر می‌تواند توئیتر را به طور کلی مسدود کند مگر اینکه از یک راهکار پیچیده برای حل این مشکل استفاده شود. از طرفی دیگر استفاده از چنین راهکارهایی (مثل یک پروکسی MitM سازمانی) ممکن است بسیاری از سازوکارهای حفاظتی ارایه ‌شده توسط DoH را برای حفظ حریم خصوصی و محرمانگی ناکارآمد کند.

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

 

[۱] Domain Name System

[۲] Domain Name System Security Extensions

[۳] User Datagram Protocol

[۴] Transmission Control Protocol

[۵] Man-in-the-Middle

 

منبع: csoonline

نمایش بیشتر

نوشته های مشابه

دیدگاهتان را بنویسید

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

نه − دو =

0
سبد خرید
  • هیچ محصولی در سبدخرید نیست.