پروتکل داده‌گرام کاربر (User Datagram Protocol یا UDP) یک پروتکل لایه انتقال بدون اتصال است که با هدف کاهش سربار بسته و دستیابی به کمترین تاخیر زمانی طراحی شده است. از آنجا که UDP بدون فرایند دست‌تکانی سه‌مرحله‌ای (Three-way Handshake) عمل می‌کند و فاقد بررسی وضعیت رمزنگاری در لایه انتقال است، فیلد نشانی مبدا در سرآیند بسته IP اعتبارسنجی نمی‌شود. هر دستگاه متصل به شبکه‌ای که اعتبارسنجی نشانی مبدا را اجرا نکند، قادر است بسته‌های UDP با نشانی‌های فرستنده ساختگی و جعلی ارسال نماید.

این ویژگی بنیادین، پروتکل UDP را به بستر اصلی حملات توزیع‌شده منع سرویس بازتابی (DrDoS) تبدیل کرده است. در میان راهکارهای بازتابی، حملات تقویت DNS ( موسوم به DNS Amplification) از مخرب‌ترین و متداول‌ترین تهدیدها به شمار می‌روند. مهاجمان با سوءاستفاده از تحلیل‌کننده‌های بازگشتی عمومی دارای تنظیمات نادرست و افزونه‌های گسترش اندازه بسته، پهنای باند خانگی اندک را به طوفان‌های ترافیکی ویرانگر با حجم صدها گیگابیت بر ثانیه تبدیل می‌کنند.

درک سازوکار این تهدید نیازمند تحلیل دقیق ویژگی‌های پروتکل است که امکان تقویت بیش از ۷۰ برابری حجم داده را فراهم می‌سازند، همراه با بررسی تدابیر پالایش شبکه برای مهار حملات بازتابی.

سازوکار بازتاب DNS و ضریب تقویت در افزونه EDNS0

حمله تقویت DNS بر دو فرایند هماهنگ استوار است: بازتاب ترافیک (Reflection) و تقویت حجمی داده (Amplification).

مهاجم (جعل نشانی IP قربانی)
       |
       |  (درخواست بسیار کوچک ۴۵ بایتی)
       v
+-------------------------------+
|    تحلیل‌کننده بازگشتی DNS    |
+-------------------------------+
       |
       |  (پاسخ حجیم ۳۵۰۰ بایتی)
       v
مقصد هدف (میزبان / شبکه قربانی)

۱. اصل بازتاب ترافیک

در یک تبادل استاندارد، کلاینت درخواستی را از پورت مبدا به پورت ۵۳ سرور DNS ارسال می‌کند. سرور نشانی IP مبدا را از سرآیند IPv4 خوانده و پاسخ را به همان نشانی برمی‌گرداند.

مهاجم با دستکاری فیلدهای سرآیند، این سازوکار را مورد سوءاستفاده قرار می‌دهد:

  • نشانی مبدا (Source IP): روی نشانی IP عمومی قربانی تنظیم می‌شود.
  • نشانی مقصد (Destination IP): روی نشانی یک تحلیل‌کننده بازگشتی عمومی در اینترنت تنظیم می‌گردد.

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

۲. ضریب تقویت حجمی از طریق EDNS0 (استاندارد RFC 6891)

بر پایه استانداردهای اولیه RFC 1035، اندازه بار داده DNS بر بستر UDP دقیقا به ۵۱۲ بایت محدود بود. هر پاسخی که از این سقف فراتر می‌رفت، نیازمند فعال‌سازی پرچم برش (TC) بود تا کلاینت را به تکرار درخواست بر بستر اتصال TCP وادار کند.

برای پشتیبانی از امضاهای رمزنگاری نوین نظیر DNSSEC (استاندارد RFC 4034)، کارگروه IETF سازوکارهای افزونه برای سامانه نام دامنه (EDNS0) را در RFC 6891 استانداردسازی کرد. این افزونه با افزودن شبه‌رکورد OPT به بسته درخواست، به کلاینت اجازه می‌دهد ظرفیت بافر پذیرش بزرگ‌تری (معمولا ۴۰۹۶ بایت) اعلام کند.

مهاجمان از این ویژگی برای رساندن ضریب تقویت به حداکثر ممکن بهره می‌برند: ۱. مهاجم درخواستی برای رکوردهای ANY یا TXT یک دامنه دارای امضاهای طولانی DNSSEC ارسال می‌کند. ۲. اندازه بسته درخواست در شبکه فقط بین ۴۵ تا ۶۵ بایت است. ۳. سرور پاسخی شامل زنجیره گواهی‌ها، کلیدهای ناحیه و محتوای متنی با حجمی معادل ۳۰۰۰ تا ۴۲۰۰ بایت بازمی‌گرداند.

$$\text{ضریب تقویت} = \frac{\text{اندازه پاسخ (بایت)}}{\text{اندازه درخواست (بایت)}} = \frac{3200}{45} \approx 71.1$$

با ضریب تقویت بیش از ۷۰ برابر، مهاجم تنها با در اختیار داشتن پهنای باند بارگذاری ۱ گیگابیت بر ثانیه می‌تواند بیش از ۷۰ گیگابیت بر ثانیه ترافیک متمرکز به سمت قربانی هدایت کند.

پروتکل / بردار حمله اندازه معمول درخواست اندازه معمول پاسخ ضریب تقویت ترافیک
سامانه DNS استاندارد (رکورد A) ۴۵ بایت ۸۵ بایت حدود ۱.۹ برابر
افزونه DNS با EDNS0 و ANY ۴۵ تا ۶۵ بایت ۳۰۰۰ تا ۴۲۰۰ بایت ۵۰ تا ۷۰ برابر
حمله NTP Monlist (کد CVE-2013-5211) ۲۳۴ بایت ۴۸۰۰۰ بایت حدود ۲۰۰ برابر
پروتکل SSDP ۱۰۰ بایت ۳۰۰۰ بایت حدود ۳۰ برابر

استاندارد BCP 38 / RFC 2827: الزام پالایش ترافیک ورودی

ریشه اصلی حملات بازتابی در ضعف پروتکل DNS نیست، بلکه به کوتاهی ارائه‌دهندگان خدمات اینترنت (ISP) در اعتبارسنجی نشانی مبدا پیش از هدایت بسته‌ها به شبکه جهانی مربوط می‌شود.

دستورالعمل BCP 38 (منعکس در RFC 2827) که در سال ۲۰۰۰ توسط IETF تدوین گردید، سازوکار پالایش ترافیک ورودی شبکه (Network Ingress Filtering) را الزامی می‌کند:

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

اعتبارسنجی سخت‌گیرانه مسیر معکوس (Strict uRPF)

در هسته لینوکس و مسیریاب‌های شبکه، استاندارد BCP 38 عمدتا از طریق هدایت مسیر معکوس تک‌پخشی (uRPF طبق RFC 3704) پیاده‌سازی می‌شود. با ورود بسته به رابط شبکه، موتور مسیریابی جدول ارسال (FIB) را بررسی می‌کند تا مطمئن شود مسیر معتبر بازگشت به نشانی مبدا دقیقا از همان درگاه فیزیکی عبور می‌کند.

در حالت سخت‌گیرانه:

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

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

سخت‌سازی سامانه‌های لینوکس: مهار سرورهای بازگشتی و تنظیم هسته

مدیران زیرساخت باید اقدامات مشخصی را برای جلوگیری از تبدیل سرورهای خود به ابزار بازتاب حملات به کار بندند.

۱. محدودسازی پرس‌وجوی بازگشتی در Unbound و BIND

استاندارد RFC 5358 تاکید دارد که قابلیت بازگشتی فقط برای محدوده‌های مجاز آدرس‌های IP کلاینت‌ها فعال باشد.

در نرم‌افزار Unbound (/etc/unbound/unbound.conf)، دسترسی بازگشتی را به رابط‌های مورد اعتماد محدود نمایید:

server:
    # گوش دادن فقط روی رابط‌های امن مشخص‌شده
    interface: 127.0.0.1
    interface: 10.0.0.1

    # رد درخواست‌های بازگشتی از سراسر اینترنت عمومی
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: 10.0.0.0/24 allow

در نرم‌افزار BIND 9 (named.conf.options)، قابلیت بازگشتی عمومی را غیرفعال کرده و محدودیت نرخ پاسخ (RRL) را فعال کنید:

options {
    recursion yes;
    allow-recursion { 127.0.0.1; 10.0.0.0/24; };
    allow-query { any; };
    
    # فعال‌سازی محدودیت نرخ پاسخ (Response Rate Limiting)
    rate-limit {
        responses-per-second 10;
        window 5;
    };
};

۲. فعال‌سازی فیلترینگ سخت‌گیرانه مسیر معکوس در هسته لینوکس

برای مسدودسازی بسته‌های حاوی نشانی جعلی در هسته لینوکس، فایل /etc/sysctl.d/99-urpf-anti-spoofing.conf را پیکربندی نمایید:

# اعمال فیلترینگ سخت‌گیرانه مسیر معکوس روی تمام رابط‌های IPv4
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# نادیده گرفتن درخواست‌های پژواک همگانی ICMP برای جلوگیری از حملات Smurf
net.ipv4.icmp_echo_ignore_broadcasts = 1

# ثبت لاگ بسته‌های حاوی نشانی مبدا نامعتبر
net.ipv4.conf.all.log_martians = 1

اعمال فوری تنظیمات در پشته شبکه لینوکس:

sudo sysctl --system

مهار ساختاری جعل نشانی با WireGuard و معماری VPNRice

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

مسیریابی کلید رمزنگاری (Cryptokey Routing)

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

پروتکل WireGuard با جدول Cryptokey Routing این آسیب‌پذیری را به طور ساختاری از بین برده است. هر نقطه اتصال به یک کلید عمومی اختصاصی و فهرستی معین از پیشوندهای مجاز (AllowedIPs) متصل است:

+---------------------------------------------------------------+
|                       درگاه WireGuard                         |
|                                                               |
|  نقطه اتصال A (کلید عمومی A) <---> AllowedIPs = 10.8.0.2/32   |
|  نقطه اتصال B (کلید عمومی B) <---> AllowedIPs = 10.8.0.3/32   |
+---------------------------------------------------------------+

هنگام رسیدن بسته رمزشده از نقطه اتصال A: ۱. هسته لینوکس داده‌ها را با استفاده از الگوریتم ChaCha20-Poly1305 اعتبارسنجی و رمزگشایی می‌کند. ۲. درایور نشانی مبدا درون بسته را بررسی می‌کند. ۳. اگر نشانی درونی در فهرست AllowedIPs نقطه اتصال A موجود نباشد، هسته بدون درنگ بسته را حذف می‌نماید.

هیچ بسته‌ای با نشانی مبدا جعلی قادر به خروج از رابط WireGuard نیست. سازوکار Cryptokey Routing پیاده‌سازی سخت‌افزاری و قطعی الزامات BCP 38 به شمار می‌آید.

راهکارهای حفاظتی زیرساخت RiceGuard

در شبکه اختصاصی VPNRice، امنیت داده‌ها در دو جهت ورودی و خروجی مدیریت می‌شود:

۱. پیوند قطعی رمزنگاری: هر اتصال RiceGuard مشخصه کلاینت را به نشانی IP خصوصی معینی پیوند می‌دهد و امکان ارسال بسته‌های جعلی را سلب می‌نماید. ۲. تحلیل‌کننده‌های اختصاصی Anycast: پرس‌وجوهای نام دامنه فقط از طریق سرورهای داخلی ایزوله پردازش می‌شوند که خارج از دسترس عموم هستند و با کنترل نرخ پاسخ (RRL) در بستری امن تبادل اطلاعات می‌کنند. ۳. پالایش ترافیک در دروازه‌های اصلی: در نقاط اتصال خارجی، VPNRice با قواعد BGP Flowspec و فیلترهای پیشرفته eBPF ترافیک بازتابی را پیش از ایجاد اختلال مهار می‌نماید.

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