در اواخر سال ۲۰۲۳، زیرساخت‌های اینترنت جهانی با یکی از سنگین‌ترین امواج حملات منع سرویس توزیع‌شده در تاریخ مواجه شدند که ناشی از سوءاستفاده از آسیب‌پذیری CVE-2023-44487 موسوم به حمله HTTP/2 Rapid Reset بود. این حمله با ثبت رکوردی بالغ بر ۳۹۸ میلیون درخواست در هر ثانیه — حجمی فراتر از کل درخواست‌های شبکه جهانی وب در یک لحظه معمول — وب‌سرورها، پروکسی‌های معکوس و ارائه‌دهندگان خدمات ابری را در سراسر جهان با اختلالات عمیق روبرو کرد.

برخلاف حملات سنتی متکی بر پر کردن پهنای باند با سیل داده‌های خام UDP یا ICMP، حمله Rapid Reset یکی از قابلیت‌های ساختاری بنیادین در پروتکل HTTP/2 را هدف قرار داد: تسهیم چندگانه جریان‌ها (Multiplexing) و امکان لغو درخواست از جانب کلاینت. مهاجمان با ارسال همزمان هزاران درخواست و لغو آنی آن‌ها از طریق فریم‌های RST_STREAM، بار پردازشی ویرانگری بر سرور تحمیل کردند، در حالی که ترافیک خروجی بسیار ناچیزی از سمت مهاجم مصرف می‌شد.

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

الگوی تسهیم چندگانه در HTTP/2: جریان‌های همزمان و انتقال حالت‌ها

به منظور رفع مشکل مسدودسازی سرخط (Head-of-Line Blocking) که در خط لوله‌های HTTP/1.1 وجود داشت، کارگروه IETF پروتکل HTTP/2 (استاندارد RFC 9113) را بر پایه فریم‌بندی دودویی و تسهیم دوطرفه بر بستر یک اتصال پایدار TCP پیاده‌سازی کرد.

در HTTP/2، تبادلات کلاینت و سرور در قالب کانال‌های منطقی مستقل با عنوان جریان (Stream) ساماندهی می‌شوند. هر جریان از یک ماشین حالت معین پیروی می‌کند:

                                +--------+
                        send PP |        | recv PP
                       ,--------|  idle  |--------.
                      /         |        |         \
                     v          +--------+          v
              +----------+                      +----------+
              | reserved |                      | reserved |
              | (local)  |                      | (remote) |
              +----------+                      +----------+
                     \                              /
                      \ send H / recv H            /
                       \                          /
                        v                        v
                        +------------------------+
                        |          open          |
                        +------------------------+
                       /          |      \        \
              recv ES /           |       \        \ send ES
                     v            |        v        v
              +----------+        |     +----------+
              |  half-   |        |     |  half-   |
              |  closed  |        |     |  closed  |
              | (remote) |        |     | (local)  |
              +----------+        |     +----------+
                     \            |            /
              send ES \           | recv RST  / recv ES
                       \          v          /
                        +--------------------+
                        |       closed       |
                        +--------------------+

در فرایند کاری عادی:

  1. کلاینت با ارسال فریم HEADERS همراه با یک شناسه فرد، جریان جدیدی را باز می‌کند.
  2. سرور حافظه لازم را تخصیص می‌دهد، فرایندهای پردازشی را آغاز می‌کند و پاسخ را در قالب فریم‌های DATA با پرچم خاتمه END_STREAM (ES) بازمی‌گرداند.
  3. در نهایت جریان به حالت بسته (closed) تغییر وضعیت می‌دهد.

برای جلوگیری از مصرف بی‌رویه منابع سرور، استاندارد RFC 9113 به سرور اجازه می‌دهد پارامتر SETTINGS_MAX_CONCURRENT_STREAMS را اعلام کند (که معمولاً روی ۱۰۰ تنظیم می‌شود). کلاینت متعهد می‌شود که تعداد جریان‌های فعال همزمان را از این حد فراتر نبرد.

سازوکار آسیب‌پذیری CVE-2023-44487: چرخه نامتقارن لغو جریان

نقص بنیادین در آسیب‌پذیری CVE-2023-44487 ناشی از نحوه تعریف فرایند لغو در مشخصات RFC 9113 است. هنگامی که کلاینت تمایل دارد دریافت یک پاسخ در حال انجام را متوقف کند، یک فریم RST_STREAM با کد خطای CANCEL (0x8) یا REFUSED_STREAM (0x7) ارسال می‌کند.

با دریافت RST_STREAM، سرور موظف است بلافاصله وضعیت جریان مربوطه را به closed تغییر دهد. نکته کلیدی اینجاست که جریان بسته شده دیگر در سقف مجاز SETTINGS_MAX_CONCURRENT_STREAMS محاسبه نمی‌شود.

+-------------------------------------------------------------------------+
|                  HTTP/2 Rapid Reset Attack Cycle                        |
+-------------------------------------------------------------------------+
| توالی فریم‌های ارسالی کلاینت (بر بستر یک لوله اتصال TCP)               |
|                                                                         |
| جریان ۱: [ فریم HEADERS (درخواست سنگین) ] ---> تخصیص نخ پردازشی سرور   |
| جریان ۱: [ فریم RST_STREAM (دستور لغو)  ] ---> بازنشانی شمارنده به ۰   |
|                                                                         |
| جریان ۳: [ فریم HEADERS (درخواست سنگین) ] ---> تخصیص نخ پردازشی سرور   |
| جریان ۳: [ فریم RST_STREAM (دستور لغو)  ] ---> بازنشانی شمارنده به ۰   |
|                                                                         |
| جریان ۵: [ فریم HEADERS (درخواست سنگین) ] ---> تخصیص نخ پردازشی سرور   |
| جریان ۵: [ فریم RST_STREAM (دستور لغو)  ] ---> بازنشانی شمارنده به ۰   |
+-------------------------------------------------------------------------+
                                    |
                                    v (نابرابری شدید بار محاسباتی)
+-------------------------------------------------------------------------+
| سمت سرور: درگیری شدید نخ‌ها، رمزگشایی فشرده‌سازی HPACK، قفل شدن حافظه   |
| سمت کلاینت: مصرف پهنای باند بسیار اندک، تکرار مداوم چرخه لغو فریم‌ها    |
+-------------------------------------------------------------------------+

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

عدم تقارن پروتکل: چرایی ناکارآمدی راهکارهای سنتی لایه ۷

فایروال‌های وب سنتی (WAF) و سیستم‌های تحلیل ناهنجاری لایه کاربرد در مواجهه اولیه با حمله Rapid Reset کاملاً ناتوان بودند، چرا که این حمله فرضیات پایه‌ای ارزیابی تراکنش‌ها را دور می‌زد.

بی‌اثر ساختن معیارهای متداول سنجش تکمیل درخواست

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

همچنین سامانه‌های ارزیابی اعتبار IP که بر مبنای نرخ خطاهای تولیدی (نظیر کدهای وضعیت HTTP 429 یا 503) عمل می‌کنند، هیچ داده غیرعادی ثبت نمی‌کردند، زیرا سرور اصولاً فرصتی برای صدور کدهای خطا در قبال جریان‌های متوقف‌شده پیدا نمی‌کرد.

کمبود منابع نخ‌های پردازشی و سرریز بافرهای TLS

با اینکه جریان پس از دریافت RST_STREAM از نظر منطقی بسته می‌شود، پاکسازی منابع در هسته وب‌سرورها عملیاتی بسیار سنگین است:

  • جداول فشرده‌سازی HPACK: هر درخواست جدول فشرده‌سازی پویا را تغییر می‌دهد. سرور مجبور است ابتدا سربرگ‌ها را رمزگشایی کند تا بتواند دستور لغو را اجرا کند.
  • تخصیص نخ‌های اجرایی: سامانه‌های نامتقارن (Envoy، Nginx و Go net/http) درخواست‌ها را میان نخ‌های پردازشی تقسیم می‌کنند. انتشار سیگنال لغو به لایه‌های دیتابیس و سرویس‌های پشتی بار هماهنگ‌سازی عظیمی ایجاد می‌کند.
  • سربار محاسباتی TLS: رمزگشایی بلادرنگ رکوردهای TLS و پردازش ساختار فریم‌ها تمام هسته‌های پردازنده را درگیر حلقه‌های سنگین می‌کند و سبب قطع اتصال کاربران معتبر می‌شود.

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

مقایسه معماری: خط لوله HTTP/1.1، آسیب‌پذیری Rapid Reset و پروتکل HTTP/3 QUIC

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

ویژگی معماری خط لوله HTTP/1.1 آسیب‌پذیری HTTP/2 Rapid Reset پروتکل HTTP/3 بر بستر QUIC
قالب فریم‌بندی متنی ساده ASCII فریم‌های دودویی ساختاریافته کپسوله‌سازی فریم‌های باینری
سازوکار تسهیم پردازش ترتیبی (انسداد سرخط) تسهیم همزمان روی تک اتصال TCP جریان‌های مستقل روی بسته‌های UDP
سازوکار لغو جریان سیگنال TCP FIN / RST (قطع کل اتصال) فریم RST_STREAM (جریان مجزا) فریم‌های RESET_STREAM و STOP_SENDING
کنترل همزمانی پردازش ترتیبی سخت‌گیرانه SETTINGS_MAX_CONCURRENT_STREAMS فریم‌های سهمیه جریان (MAX_STREAMS)
آسیب‌پذیری Rapid Reset مصون (نیازمند بستن کامل اتصال) بسیار آسیب‌پذیر (چرخه نامتقارن) مقاوم (سهمیه جریان مانع چرخه تکرارشونده)
پروتکل انتقال TCP (لایه ۴) TCP (لایه ۴) دیتاگرام‌های UDP با رمزنگاری AEAD

پروتکل HTTP/3 به لطف معماری مدیریت سهمیه جریان در پروتکل QUIC، از بروز حملات Rapid Reset پی‌درپی جلوگیری می‌کند. یک کلاینت نمی‌تواند بدون دریافت فریم‌های اعتباری جدید MAX_STREAMS از جانب سرور، جریان‌های مکرر باز کند.

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

هنگامی که حمله Rapid Reset درگاه‌های لبه عمومی را هدف می‌گیرد، زنجیره فروپاشی در سه مرحله گسترش می‌یابد:

  1. اشباع کامل پردازنده پروکسی: فرآیند مداوم بازگشایی سربرگ‌ها و ثبت جداول حالت جریان‌ها، هسته‌های چندگانه CPU را در سطح ۱۰۰ درصد قفل می‌کند.
  2. سرریز بافرهای سوکت TCP: از آنجا که اتصالات با وجود لغو مداوم جریان‌ها باز می‌مانند، بافرهای دریافت سیستم‌عامل (SO_RCVBUF) با فریم‌های بلاتکلیف انباشته می‌شوند.
  3. قطعی زنجیره‌ای سرویس‌های پشتیبان: میکروسرویس‌ها و سامانه‌های احراز هویت داخلی به علت اختلال شبکه دچار وقفه می‌شوند و دسترسی کاربران قطع می‌گردد.

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

حفاظت از درگاه با VPN لایه ۳: ایزوله‌سازی صفحه کنترل در تونل‌های رمزنگاری‌شده

ریشه آسیب‌پذیری CVE-2023-44487 در دسترس بودن مستقیم نقاط پایانی HTTP/2 از طریق اینترنت عمومی است. هنگامی که رابط‌های مدیریتی و سرویس‌های کنترلی بر روی آدرس‌های IP عمومی فعالیت می‌کنند، در برابر حملات لایه کاربرد بی‌پناه می‌مانند.

به کارگیری معماری شبکه اختصاصی در لایه ۳ این مرزبندی امنیتی را بازتعریف می‌کند:

+------------------------------------------------------------------------+
|                     محیط ناامن اینترنت عمومی                           |
|        مهاجم امواج حمله HTTP/2 Rapid Reset را به درگاه هدایت می‌کند    |
+------------------------------------------------------------------------+
                                    |
                                    v (درگاه مرزی مقاوم‌سازی شده)
+------------------------------------------------------------------------+
|             گره ورودی: محدودسازی نرخ بر اساس سطل نشانه‌ها              |
|      پایش نسبت فریم‌های لغو به درخواست: قطع اتصال‌های مشکوک TCP       |
+------------------------------------------------------------------------+
                                    |
                                    v (انتقال ایزوله در لایه ۳)
+------------------------------------------------------------------------+
|             کپسوله‌سازی تونل امن WireGuard / RiceGuard                 |
|   رمزنگاری احراز هویت شده: ChaCha20-Poly1305 (RFC 7539 / RFC 5116)     |
|   اتصال خدمات داخلی و صفحه کنترل صرفاً به رابط rg0 (10.8.0.1)          |
+------------------------------------------------------------------------+
                                    |
                                    v (هسته محافظت‌شده داخلی)
+------------------------------------------------------------------------+
|               سرویس‌های احراز هویت و برنامه‌های ایزوله                 |
|           مصونیت کامل از امواج نفوذ پروتکل HTTP/2 از اینترنت عمومی     |
+------------------------------------------------------------------------+

با محصور ساختن ترافیک در قالب یک تونل معتبر لایه ۳:

  1. سرویس‌های تحت وب تنها بر روی رابط‌های شبکه مجازی (نظیر 10.8.0.1) فعال بوده و در برابر پویش‌های عمومی پنهان می‌مانند.
  2. مهاجمان خارجی امکان تکمیل دست‌دهی سه‌مرحله‌ای TCP با وب‌سرورهای داخلی را نخواهند داشت.
  3. تمام بسته‌های ورودی پیش از تحویل به نرم‌افزار، ملزم به تایید تگ اعتبارسنجی ChaCha20-Poly1305 در لایه هسته سیستم‌عامل هستند.

راهکارهای حفاظتی پیرامونی مشابهی برای مصون‌سازی زیرساخت‌های مسیریابی در برابر حملات نیمه‌باز به کار می‌روند که در مقاله اختصاصی مقابله با حملات TCP SYN Flood و مکانیزم کوکی‌های WireGuard شرح داده شده‌اند.

پدافند انتقال RiceGuard: مقاوم‌سازی زیرساخت درگاه در برابر امواج سیل‌آسا

سرویس VPNRice از پروتکل بهینه‌سازی‌شده RiceGuard بهره می‌برد تا پایداری درگاه‌های شبکه را تضمین نماید:

  1. انقیاد سخت‌گیرانه در سطح هسته سیستم‌عامل: RiceGuard ترافیک مدیریتی و سرویس‌های تحلیل DNS را در پشت رابط مجازی rg0 ایزوله می‌سازد. بسته‌های عمومی از کارت شبکه فیزیکی eth0 امکان نفوذ به پردازش‌های داخلی HTTP/2 را ندارند.
  2. بسته‌های داده با ساختار ثابت: پروتکل WireGuard بر بستر UDP با سربرگ‌های فشرده و مشخص تبادل داده می‌کند و پیچیدگی‌های ساختار حالت‌های چندگانه HTTP/2 را به طور کامل از لایه بیرونی حذف می‌نماید.
  3. معماری درگاه پنهان: گره‌های RiceGuard تنها به بسته‌هایی پاسخ می‌دهند که دارای امضای معتبر با کلیدهای عمومی موقت باشند. کاوش‌های ناشناس هیچ‌گونه پاسخی دریافت نکرده و بستری برای سوءاستفاده مهاجم فراهم نمی‌شود.

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

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

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

بار این آزمون معادل ۲،۵۰۰،۰۰۰ فریم لغو جریان در هر ثانیه بر بستر ۱۲۸ اتصال همزمان TCP بود.

شاخص عملکردی پروکسی HTTP/2 بدون وصله پروکسی لبه تقویت‌شده درگاه تحت حفاظت RiceGuard
اشباع هسته‌های پردازنده ۹۹.۴٪ (قفل شدن کامل) ۲۸.۶٪ (بار مدیریت‌شده) ۴.۲٪ (هدایت رمزنگاری سبک)
افزایش حافظه مصرفی ۳.۴+ گیگابایت (سرریز بافر) ۱۴۰+ مگابایت (محدوده مهارشده) ۱۲+ مگابایت (بدون درگیری جریان)
تاخیر درخواست‌های معتبر اتمام مهلت زمانی (۳۰،۰۰۰+ میلی‌ثانیه) ۴۲ میلی‌ثانیه (نوسان ۱۸+ میلی‌ثانیه) ۱.۸ میلی‌ثانیه (سرعت خط شبکه)
اتصالات قطع‌شده معتبر ۸۸.۲٪ انقطاع کامل ۰.۴٪ قطعی جزئی ۰٪ (حفظ کامل تمام نشست‌ها)
دفع اتصال مهاجم ناموفق (تداوم چرخه مخرب) مسدودسازی ظرف ۱۲ میلی‌ثانیه رد فوری در فیلتر تونل هسته

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

در مقابل، در ساختار RiceGuard به دلیل تفکیک سرورهای HTTP/2 از فضای اینترنت، درگاه بسته‌های رمزنگاری‌شده را در حداکثر سرعت سخت‌افزاری و بدون ایجاد تاخیر محسوس هدایت کرد.

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

مدیران سامانه‌های مبتنی بر HTTP/2 می‌توانند با اعمال تدابیر لایه‌ای در سطح پروکسی معکوس و سیستم‌عامل، مقاومت شبکه را ارتقا دهند.

پیکربندی آستانه فریم‌های لغو در پروکسی معکوس

در وب‌سرورهای Nginx، کاهش سقف جریان‌های همزمان و تنظیم سهمیه‌های مناسب ضروری است:

# /etc/nginx/nginx.conf - تنظیمات مقاوم‌سازی پروتکل HTTP/2

http {
    # محدودسازی جریان‌های همزمان در هر اتصال TCP
    http2_max_concurrent_streams 64;

    # اعمال نرخ پردازش درخواست‌ها
    limit_req_zone $binary_remote_addr zone = api_limit:20m rate=100r/s;

    server {
        listen 443 ssl http2;
        server_name api.enterprise-core.internal;

        keepalive_requests 1000;
        client_header_timeout 5s;
        client_body_timeout 5s;

        location / {
            limit_req zone = api_limit burst=200 nodelay;
            proxy_pass http://backend_cluster;
        }
    }
}

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

frontend https_in
    bind :443 ssl crt /etc/ssl/certs/gateway.pem alpn h2,http/1.1
    tune.h2.max-concurrent-streams 64
    tune.h2.initial-window-size 65535

تحلیل نسبت فریم‌های HTTP/2 با ابزارهای بازرسی شبکه

نظارت بر کارت‌های شبکه جهت تشخیص زودهنگام جهش در فریم‌های RST_STREAM:

# پایش و شمارش فریم‌های HTTP/2 RST_STREAM با استفاده از tshark
sudo tshark -i eth0 -f "tcp port 443" -Y "http2.type == 3" -T fields -e ip.src -e http2.streamid

# بررسی وضعیت تخصیص سوکت‌های TCP و حافظه در هسته
ss -t -i -a | grep -E "ESTAB|wscale"

# رصد وضعیت صف‌های سرریز بر روی کارت شبکه فیزیکی
netstat -s | grep -i "listen overflows"

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

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