سامانه نام دامنه (Domain Name System یا DNS) شالوده اصلی مسیریابی در اینترنت است. از آنجا که تقریبا تمامی سرویس‌های تحت شبکه به تبدیل نام‌های خوانا به نشانی‌های IP وابسته‌اند، دیواره‌های آتش سازمانی معمولا ترافیک خروجی UDP و TCP روی پورت ۵۳ را با کمترین میزان نظارت عبور می‌دهند. حتی فایروال‌های پیشرفته با بررسی وضعیت که ترافیک پروتکل‌های وب (HTTP/HTTPS) را به دقت پالایش کرده یا خروجی مستقیم را مسدود می‌سازند، عموما درخواست‌های بازگشتی DNS را بدون مانع به تحلیل‌کننده‌های داخلی یا عمومی هدایت می‌کنند.

گروه‌های تهدیدات پیشرفته و مستمر (APT) و بدافزارهای نوین از این اعتماد ساختاری از طریق روش تونل‌سازی DNS (موسوم به DNS Tunneling) سوءاستفاده می‌نمایند. مهاجمان با کدگذاری داده‌های دودویی دلخواه درون برچسب‌های پرس‌وجو و رکوردهای پاسخ، کانال‌های پنهانی دوطرفه فرماندهی و کنترل (C2) ایجاد می‌کنند و اطلاعات حساس را بدون نیاز به ارتباط مستقیم IP با سرورهای خارجی از شبکه‌های منزوی خارج می‌سازند.

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

سازوکار کانال‌های پنهان DNS

تونل‌سازی DNS کاملا بر ساختار سلسله‌مراتبی و واگذاری اختیارات دامنه طبق استاندارد RFC 1035 تکیه دارد. میزبان آلوده به جای ارتباط مستقیم با سرور مهاجم، پیام‌ها را از طریق تحلیل‌کننده‌های بازگشتی واسط ارسال می‌کند.

+--------------------+
|  میزبان آلوده شده  |  (کدگذاری بخش‌های داده در برچسب پرس‌وجو)
+--------------------+
          |
          |  درخواست UDP/53: "a1b2c3d4e5f6.data.tunnel.attacker.com"
          v
+--------------------+
| تحلیل‌کننده محلی   |  (هدایت پرس‌وجوی بازگشتی به سمت بالا)
| DNS در سازمان      |
+--------------------+
          |
          v
+--------------------+
| سرورهای ریشه و     |  (واگذاری دامنه به سرور نام میزبان مهاجم)
| دامنه‌های سطح بالا  |
+--------------------+
          |
          v
+--------------------+
| سرور نام معتبر     |  (رمزگشایی داده‌های دریافتی از برچسب؛
| تحت کنترل مهاجم    |   قراردادن دستورات C2 در پاسخ TXT)
+--------------------+

۱. خروج داده‌ها به سمت بیرون از طریق برچسب‌های پرس‌وجو

طبق استاندارد RFC 1035، طول یک نام دامنه کاملا مشخص (FQDN) حداکثر می‌تواند ۲۵۳ بایت باشد و هر برچسب جداشده با نقطه نیز حداکثر از ۶۳ بایت تشکیل می‌شود:

$$\text{حداکثر طول برچسب} = ۶۳\text{ بایت}, \quad \text{حداکثر طول FQDN} = ۲۵۳\text{ بایت}$$

برای ارسال داده به بیرون از شبکه محافظت‌شده: ۱. بدافزار فایل‌های محرمانه (نظیر کلیدهای رمزنگاری یا اطلاعات پایگاه‌داده) را به قطعات دودویی کوچک تقسیم می‌کند. ۲. داده‌ها با الگوریتم‌های Base32، فرمت امن Base64 یا نویسه‌های هگزادسیمال کدگذاری می‌شوند. ۳. رشته کدگذاری‌شده به عنوان زیردامنه به دامنه‌ای که در اختیار مهاجم است پیوند می‌خورد:

78696e66696c747261746564.session1.c2.attacker.com

۴. کلاینت یک پرس‌وجوی استاندارد از نوع A یا AAAA صادر می‌نماید. ۵. سرور محلی با خالی بودن حافظه نهان، درخواست را تا سرور نام معتبر مهاجم هدایت می‌کند. ۶. سرور مهاجم با دریافت برچسب، پسوند را حذف کرده و داده‌های ارسالی را بازسازی می‌نماید.

۲. دریافت دستورات فرماندهی از طریق رکوردهای پاسخ

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

  • رکوردهای TXT: استاندارد RFC 1035 امکان حمل رشته‌های متنی تا ۲۵۵ بایت در هر رکورد و گنجاندن چندین رکورد را در یک پاسخ فراهم می‌سازد. با اتکا به سازوکار EDNS0، یک پاسخ ساده می‌تواند چند کیلوبایت دستورات اجرایی یا کد شل را منتقل کند.
  • رکوردهای NULL: این رکوردها که در RFC 1035 برای داده‌های دودویی آزاد تعریف شده‌اند (تا سقف ۶۵,۵۳۵ بایت در بستر TCP)، از محدودیت‌های پردازش متن در دروازه‌های قدیمی مصون هستند.
  • رکوردهای CNAME: استفاده از زنجیره‌ای از نام‌های مستعار CNAME می‌تواند تکه‌های داده را در نام‌های میانی جای دهد.

از آنجا که مبدا تمامی بسته‌ها از درون شبکه است، این ترافیک بدون مانع از سد تجهیزات NAT و فایروال‌های لبه عبور می‌نماید.

ویژگی کانال ارتباطی ترافیک وب استاندارد (HTTPS) کانال تونل‌سازی DNS
پورت و پروتکل TCP 443 UDP / TCP 53
اطمینان در تحویل تایید دریافت در سطح پروتکل TCP پنجره لغزان سفارشی روی پروتکل UDP
الگوی اتصال ارتباط مستقیم کلاینت با سرور عبور ترافیک از تحلیل‌کننده محلی
پهنای باند قابل استفاده بسیار بالا (ده‌ها یا صدها مگابیت) پایین (۱ تا ۱۰۰ کیلوبیت بر ثانیه)
سطح پایش امنیتی بررسی عمیق گواهی و SNI غالبا در ترافیک بازگشتی بررسی نمی‌شود

مهندسی شناسایی: تحلیل‌های آماری و نشانه‌های رفتاری

مسدود کردن تمام ترافیک پورت ۵۳ شبکه را از کار می‌اندازد؛ بنابراین تیم‌های امنیتی به مدل‌های ارزیابی آماری و تحلیل رفتار روی می‌آورند.

۱. محاسبه آنتروپی اطلاعاتی شانون

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

$$H(X) = -\sum_{i=1}^{n} P(x_i) \log_2 P(x_i)$$

که در آن $P(x_i)$ احتمال تکرار نویسه $x_i$ در رشته برچسب است:

  • زیردامنه‌های معتبر اداری (مانند auth.service.internal.corp) معمولا نمره آنتروپی بین ۲.۲ تا ۳.۴ دارند.
  • برچسب‌های دارای داده‌های Base32 یا Base64 همواره آنتروپی معادل ۴.۲ تا ۴.۸ نشان می‌دهند.

ابزارهای تحلیل ترافیک (نظیر Zeek یا Suricata) با ارزیابی مداوم نرخ آنتروپی دامنه‌های خروجی، موارد مشکوک را شناسایی می‌کنند.

۲. ناهنجاری‌های ساختاری و حجمی

افزون بر آشفتگی نویسه‌ها، الگوهای دیگری نیز وجود دارند:

  • حجم غیرعادی درخواست‌های یکتا: صدور هزاران درخواست برای زیردامنه‌های تصادفی تحت یک دامنه اصلی از سوی یک میزبان در بازه کوتاه.
  • افزایش شدید نسبت درخواست‌های TXT/NULL: ترافیک روزمره غالبا شامل رکوردهای A و AAAA است؛ افزایش ناگهانی رکوردهای TXT گواهی بر انتقال مخفیانه داده‌هاست.
  • طول غیرمعمول برچسب‌ها: مواردی که طول رشته‌ها مداوما به سقف ۶۳ بایتی مجاز نزدیک می‌شود.
  • زمان حیات (TTL) بسیار کوتاه: سرورهای نام مهاجمان TTL را صفر یا نزدیک صفر تعیین می‌کنند تا از ذخیره پاسخ‌ها جلوگیری کرده و کلاینت را به ارسال مکرر درخواست وادار سازند.

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

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

۱. محدودسازی ارتباط مستقیم روی پورت ۵۳

دستگاه‌های کاربران و سرورها نباید به نشانی‌های ناشناس بیرونی روی پورت ۵۳ متصل شوند. تنظیمات دیواره آتش باید ارسال درخواست را مهار کند:

# مجاز دانستن ارتباط پرس‌وجو تنها با سرور رسمی مورد تایید
sudo iptables -A OUTPUT -p udp --dport 53 -d 10.0.0.2 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 53 -d 10.0.0.2 -j ACCEPT

# قطع درخواست‌های ارسالی مستقیم از سیستم‌های کاربری
sudo iptables -A OUTPUT -p udp --dport 53 -j REJECT --reject-with icmp-port-unreachable
sudo iptables -A OUTPUT -p tcp --dport 53 -j REJECT --reject-with tcp-reset

۲. فعال‌سازی نواحی خط‌مشی پاسخ (RPZ) در Unbound

سامانه‌های بازگشتی مدرن می‌توانند از دامنه‌های مشکوک با استفاده از سازوکار Response Policy Zones پیشگیری نمایند:

در فایل پیکربندی Unbound (/etc/unbound/unbound.conf)، تنظیمات کنترل نرخ به مهار این کانال‌ها کمک می‌کند:

server:
    # تعیین سقف بافر UDP برای محدودسازی بار داده ارسالی
    msg-buffer-size: 8192
    
    # کنترل نرخ پرس‌وجوها برای دفع رفتارهای جهشی
    ratelimit: 100
    ratelimit-factor: 10
    
    # ثبت رخدادها برای بازرسی‌های امنیتی بعدی
    log-queries: yes
    log-replies: yes

# مسدودسازی دامنه‌های مرتبط با ابزارهای تونل‌سازی
response-policy:
    zone:
        name: "tunnel-blocklist.rpz"
        zonefile: "/etc/unbound/zones/rpz-blocked.zone"

ایزولاسیون ساختاری داده‌ها با WireGuard و معماری VPNRice

اگرچه تنظیمات فایروال نظارت را افزایش می‌دهد، انتقال تمامی داده‌ها درون تونل‌های رمزنگاری‌شده ایمن‌ترین رویکرد برای مهار کانال‌های مخفی به شمار می‌آید.

تغییر مسیر همه‌جانبه ترافیک DNS

در یک محیط محلی ساده، بدافزار ممکن است از تنظیمات ارائه‌شده توسط DHCP بهره برده یا مستقیما به یک سرور ناامن وصل شود.

فناوری‌های لایه سه متکی بر WireGuard با بازنویسی جدول مسیریابی سیستم‌عامل، امکان هرگونه تخطی را ناممکن می‌سازند:

+---------------------------------------------------------------+
|                       دستگاه کلاینت                           |
|                                                               |
|  رابط فیزیکی (eth0)   ---> بسته‌های کدگذاری‌شده UDP            |
|  رابط WireGuard (wg0) ---> AllowedIPs = 0.0.0.0/0, ::/0       |
|  تنظیمات DNS          ---> 10.8.0.1 (درون تونل امن)           |
+---------------------------------------------------------------+

با فعال‌سازی اتصال WireGuard: ۱. هسته سیستم‌عامل تمام مسیرهای 0.0.0.0/0 و ::/0 را منحصرا به رابط مجازی (wg0) هدایت می‌کند. ۲. نقطه پردازش DNS سیستم روی نشانی درگاه داخلی تونل (10.8.0.1) تثبیت می‌گردد. ۳. حتی اگر یک بدافزار تلاش کند بسته خام UDP را به پورت ۵۳ سروری در اینترنت ارسال نماید، این بسته فورا توسط پشته شبکه ضبط، با ChaCha20-Poly1305 رمزگذاری و به داخل تونل هدایت می‌شود.

ناظران شبکه محلی یا مدیران نقاط دسترسی Wi-Fi عمومی نمی‌توانند بسته‌های شفاف را بازبینی کرده یا داده‌های پنهان‌شده را استخراج نمایند.

تدابیر دفاعی در ساختار VPNRice

در زیرساخت یکپارچه VPNRice تدابیر محافظتی چندگانه‌ای تعبیه شده است:

۱. تحلیل‌کننده‌های اختصاصی Anycast: تمامی پرس‌وجوها توسط سرورهای داخلی ایزوله پاسخ داده می‌شوند که ترافیک را به سرورهای ناشناخته هدایت نمی‌کنند. ۲. پایش رفتاری و آنتروپی در لحظه: دروازه‌های شبکه به طور خودکار آنتروپی دامنه‌ها و بسامد پرس‌وجوها را ارزیابی کرده و پیش از ارسال بسته، فعالیت‌های غیرعادی را مهار می‌کنند. ۳. اعتبارسنجی قطعی کلیدها: پروتکل RiceGuard ارتباط میان نشانی‌های درون تونل و کلیدهای عمومی را تایید نموده و از انحراف مسیر بسته‌ها جلوگیری به عمل می‌آورد.

ترکیب ارزیابی آنتروپی شانون و رمزنگاری سراسری داده‌ها، امکان برقراری کانال‌های سرقت اطلاعات را از بین برده و ایمنی داده‌ها را تامین می‌کند.