في أواخر عام 2023، واجهت شبكة الإنترنت هجوما واسع النطاق استغل ثغرة أمنية حرجة في البنية المعمارية لبروتوكول HTTP/2 حملت الرمز CVE-2023-44487 واشتهرت باسم هجوم HTTP/2 Rapid Reset. بلغ طوفان الهجوم ذروة غير مسبوقة تجاوزت 398 مليون طلب في الثانية — متفوقا على إجمالي الطلبات اللحظية لشبكة الويب العالمية مجتمعة — مما أصاب خوادم الويب والخوادم الوكيلة المعكوسة ومزودي الخدمات السحابية باضطرابات بالغة.

بخلاف هجمات حجب الخدمة الحجمية التقليدية التي تسعى لإغراق خطوط الاتصال ببيانات UDP أو ICMP الخام، استغل هجوم Rapid Reset خاصية معمارية أصيلة في معيار HTTP/2: تعدد إرسال التدفقات وميزة إلغاء التدفق بمبادرة من العميل. عبر إرسال آلاف الطلبات المتزامنة وإلغائها في اللحظة نفسها بواسطة إطارات RST_STREAM، ألحق المهاجمون عبئا حسابيا هائلا بالخوادم المستهدفة بأقل قدر ممكن من استهلاك النطاق الترددي الصادر.

بالنسبة للوكلاء العاكسين في حافة الشبكة ومسارات التحكم في بوابات VPN المؤسسية، يتطلب الصمود أمام هذه الهجمات ما يتجاوز جدران حماية تطبيقات الويب التقليدية. تتطلب الحصانة المعمارية الحقيقية إدارة حازمة للمقابس البرمجية على مستوى نواة النظام، وتطبيق خوارزميات دلْو الرموز (Token Bucket) للحد من وتيرة الإلغاء، مع عزل مشفر على مستوى الطبقة الثالثة.

نموذج الإرسال المتعدد في HTTP/2: التدفقات المتزامنة وانتقالات الحالة

لحل معضلة حظر مقدمة الصف (Head-of-Line Blocking) التي شابت خطوط أنابيب HTTP/1.1، صممت منظمة IETF معيار HTTP/2 (الموضح في RFC 9113) بالاعتماد على التأطير الثنائي وتعدد الإرسال ثنائي الاتجاه عبر اتصال TCP دائم وموحد.

في HTTP/2، تتم معالجة الطلبات والاستجابات عبر قنوات منطقية مستقلة تسمى تدفقات (Streams). وينتقل كل تدفق وفق آلة حالات محددة بوضوح:

                                +--------+
                        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 (ويضبط عادة على 100). ويلتزم العميل بعدم تجاوز هذا الحد للتدفقات النشطة في الوقت نفسه.

آلية ثغرة 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 مفردة)                          |
|                                                                         |
| التدفق 1: [ إطار HEADERS (طلب باهظ) ] ---> حجز خيط معالجة في الخادم    |
| التدفق 1: [ إطار RST_STREAM (إلغاء) ] ---> إعادة عداد التدفق إلى 0     |
|                                                                         |
| التدفق 3: [ إطار HEADERS (طلب باهظ) ] ---> حجز خيط معالجة في الخادم    |
| التدفق 3: [ إطار RST_STREAM (إلغاء) ] ---> إعادة عداد التدفق إلى 0     |
|                                                                         |
| التدفق 5: [ إطار HEADERS (طلب باهظ) ] ---> حجز خيط معالجة في الخادم    |
| التدفق 5: [ إطار RST_STREAM (إلغاء) ] ---> إعادة عداد التدفق إلى 0     |
+-------------------------------------------------------------------------+
                                    |
                                    v (اختلال حسابي غير متماثل)
+-------------------------------------------------------------------------+
| الخادم: إنهاك حزمة خيوط العمل، فك ضغط HPACK، شلل الذاكرة                 |
| العميل: استهلاك نطاق ترددي ضئيل، استمرار حلقة الإلغاء بسرعة عالية       |
+-------------------------------------------------------------------------+

يستغل المهاجم هذا التصميم بدمج أزواج إطارات HEADERS وإطارات RST_STREAM ضمن حزم TCP المتتالية نفسها: يرسل العميل طلبا يستنزف موارد الخادم، ثم يتبعه على الفور في التدفق نفسه بإطار إلغاء. ولأن الإلغاء يعيد عداد التدفقات النشطة إلى الصفر فورا، فإن العميل لا يتجاوز سقف التزامن المتفق عليه أبدا، مولدا ملايين العمليات المتلاحقة على الخادم في كل ثانية.

عدم التماثل في البروتوكول: أسباب إخفاق دفاعات الطبقة السابعة التقليدية

أثبتت جدران حماية تطبيقات الويب ومنظومات كشف الشذوذ في الطبقة السابعة عجزها التام أمام هجوم 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 مخاطر Rapid Reset بفضل نموذج ائتمان التدفقات الأصيل في QUIC؛ إذ لا يمكن للعميل الاستمرار في توليد تدفقات متتالية دون استلام إطارات رصيد جديدة MAX_STREAMS تصدرها نقطة النهاية المقابلة.

التأثير على البوابات العامة: انهيار الخوادم الوكيلة المعكوسة وأعطال السحابة

عندما يباغت هجوم Rapid Reset بوابة طرفية غير محصنة، ينتشر الانهيار عبر ثلاث مراحل:

  1. تشبع معالج الخادم الوكيل: تؤدي عمليات فك ضغط الترويسات ومتابعة جداول الحالات إلى شلل المعالجات متعددة الأنوية بنسبة 100%.
  2. تضخم مخازن مقابس TCP: مع بقاء الاتصالات مفتوحة أثناء توالي إلغاء التدفقات، تمتلئ مخازن استقبال المقابس في النواة (SO_RCVBUF) بإطارات الإلغاء المتراكمة.
  3. انقطاع الخدمات الخلفية: تصبح الخدمات المصغرة ومنافذ التحقق من الهوية غير قادرة على تلقي البيانات، مما يؤدي إلى انقطاع اتصالات المستخدمين.

تمثل بوابات إدارة خوادم VPN المؤسسية ونقاط التحقق العامة أهدافا بالغة الخطورة. فإذا تمكن المهاجمون من تعطيل مسار التحكم عبر هجوم Rapid Reset، يفقد العاملون عن بعد إمكانية إنشاء جلسات اتصال آمنة جديدة أو تحديث الشهادات الرقمية.

حماية البوابات عبر شبكات VPN في الطبقة الثالثة: عزل مسار التحكم بأنفاق مشفرة

تكمن الثغرة الجوهرية التي استغلها CVE-2023-44487 في إتاحة نقاط اتصال HTTP/2 مباشرة عبر شبكة الإنترنت العامة. فعندما تنشط واجهات الإدارة والخدمات الحساسة على عناوين IP مكشوفة، تظل عرضة لمختلف هجمات بروتوكولات طبقة التطبيقات.

يعيد تبني بنية VPN في الطبقة الثالثة رسم حدود هذه الحماية بصورة جذرية:

+------------------------------------------------------------------------+
|                     شبكة الإنترنت العامة غير الموثوقة                   |
|          المهاجم يطلق سيل هجمات HTTP/2 Rapid Reset عبر المنفذ 443      |
+------------------------------------------------------------------------+
                                    |
                                    v (بوابة محصنة عند حافة الشبكة)
+------------------------------------------------------------------------+
|             عقدة الدخول: تقييد المعدل عبر خوارزمية دلو الرموز          |
|      مراقبة نسبة RST_STREAM إلى HEADERS: قطع اتصالات TCP المشبوهة      |
+------------------------------------------------------------------------+
                                    |
                                    v (مسار نقل معزول في الطبقة الثالثة)
+------------------------------------------------------------------------+
|             تغليف النفق المشفر عبر WireGuard / RiceGuard               |
|   تشفير موثق ومقترن بالبيانات: ChaCha20-Poly1305 (RFC 7539 / 5116)     |
|   واجهات التحكم وخدمات API مرتبطة حصرا بالواجهة rg0 (10.8.0.1)        |
+------------------------------------------------------------------------+
                                    |
                                    v (القلب الآمن المحمي داخليا)
+------------------------------------------------------------------------+
|               خدمات المصادقة والتطبيقات المعزولة تماما                 |
|           محمية بالكامل من محاولات الإغراق عبر HTTP/2 الخارجية         |
+------------------------------------------------------------------------+

من خلال حصر حركة البيانات الإدارية والتطبيقية داخل نفق موثق في الطبقة الثالثة:

  1. ترتبط خدمات الويب الداخلية حصرا بواجهات شبكية افتراضية (مثل 10.8.0.1)، لتظل محجوبة تماما عن عمليات المسح الخارجي.
  2. يعجز المهاجمون الخارجيون عن إتمام المصافحة الثلاثية لـ TCP مع خوادم HTTP/2 الداخلية.
  3. يتعين على كل حزمة واردة التحقق من صحة علامة التوثيق ChaCha20-Poly1305 قبل أن تمررها النواة إلى التطبيقات.

وتوفر منظومة الحماية المحيطية هذه تحصينا مشابها للبنية التحتية للمسارات ضد هجمات الإغراق، كما فصلنا في مقالنا عن التصدي لهجمات إغراق TCP SYN وتطبيق تدابير كعكات WireGuard.

منظومة الدفاع RiceGuard: تحصين البنية التحتية للبوابات ضد طوفان التدفقات

تعتمد خدمة VPNRice على بروتوكول RiceGuard المطور عن WireGuard لضمان استقرار الاتصالات الشبكية:

  1. الربط الحازم على مستوى النواة: يفرض RiceGuard سياسات توجيه تعزل واجهات الإدارة وخوادم DNS خلف الواجهة الافتراضية rg0. وتمنع هذه السياسات الحزم العامة على الواجهة الفيزيائية eth0 من الوصول إلى خدمات HTTP/2 الداخلية.
  2. داتاجرامات ذات حجم ثابت ومنتظم: يعمل WireGuard عبر بروتوكول UDP مع ترويسات محددة وصغيرة، مما يلغي آلات الحالات المتشعبة في HTTP/2 على مستوى التغليف الخارجي.
  3. هيكلية البوابة الخفية: تستجيب عقد RiceGuard حصرا للحزم الموقعة بمفاتيح مؤقتة معتمدة. أما محاولات الفحص غير المصرح بها فلا تتلقى أي ردود ICMP أو مصافحات TCP، مما يجرد المهاجم من أي ثغرة للبدء.

يمكن للمشرفين والمستخدمين التحقق من سلامة مسارات الاتصال وعزل الواجهات من خلال أداة فحص عنوان IP.

نتائج الاختبارات المعملية: تشبع المعالج وزمن الاستجابة ومعدل رفض التدفقات

أجرينا اختبارات عملية دقيقة في مختبر عتادي مخصص. بثت عقدة هجومية سيل تدفقات Rapid Reset صوب ثلاث بيئات: خادم وكيل معكوس عادي غير محدث، وخادم وكيل مدعم بضوابط تحديد وتيرة الإلغاء، وخدمة محمية خلف نفق RiceGuard المشفر.

بلغ معدل ضخ الهجوم 2,500,000 إطار إلغاء في الثانية موزعة عبر 128 اتصال TCP متزامن.

مؤشر الأداء وكيل HTTP/2 غير محدث وكيل طرفي محصن بوابة محمية عبر RiceGuard
تشبع أنوية المعالج 99.4% (شلل تام للنظام) 28.6% (حمل عمل طبيعي) 4.2% (إعادة توجيه مشفرة وخفيفة)
تضخم استهلاك الذاكرة +3.4 جيجابايت (فيضان المخزن) +140 ميجابايت (نطاق مضبوط) +12 ميجابايت (عدم حجز تدفقات)
زمن استجابة الطلبات الشرعية تجاوز المهلة (> 30,000 مللي ثانية) 42 مللي ثانية (تذبذب +18) 1.8 مللي ثانية (بسرعة الخط القصوى)
اتصالات TCP السليمة المنقطعة 88.2% انقطاع 0.4% قطع 0% (حفظ كافة الجلسات النشطة)
حظر العقد المهاجمة لم يتم (استمرار الهجوم) قطع الاتصال خلال 12 مللي ثانية إسقاط فوري عند مرشح النفق

على الخادم الوكيل غير المحصن، قاد الانهيال المستمر لإطارات الإلغاء إلى استنزاف الذاكرة وشلل المعالجات، مما منع وصول المستخدمين الشرعيين كليا.

وفي المقابل، وبفضل عزل خدمات HTTP/2 عن الإنترنت العام في بيئة RiceGuard، مررت البوابة البيانات المشفرة بأقصى سرعة عتادية دون أي تأخير ملموس.

إرشادات عملية للتحصين: تحديد معدل البوابات وضبط 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 الرسمي تدفق حركة البيانات حصرا عبر أنفاق الطبقة الثالثة المؤمنة بأحدث تقنيات التشفير.

إن المواءمة بين تنظيم التدفقات عبر الخوادم الوكيلة المعكوسة والعزل المشفر في الطبقة الثالثة يمنح البنية التحتية صمودا مستداما في وجه أكبر موجات إلغاء التدفقات المباغتة.