الخلاصة

  • كان العميل يفتح تدفق HTTP/2 ثم يرسل RST_STREAM فوراً تقريباً. يخرج التدفق من حد التزامن، لكن الوكيل أو التطبيق قد يواصل تنفيذ العمل الذي بدأه الطلب.
  • لذلك انتقلت الاستجابة الفاعلة إلى سلوك الوصلة المتراكم: اكتشاف الدورة غير الطبيعية، ثم إرسال GOAWAY أو إغلاق الوصلة، مع إبقاء الإلغاء المشروع متاحاً للمستخدم العادي.

مغلق في البروتوكول، حي داخل الآلة

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

يحد البروتوكول عدد التدفقات النشطة في اللحظة نفسها. لكن التدفق المغلق لا يعود محسوباً ضمن هذا الحد. في Rapid Reset كان المهاجم يرسل HEADERS ثم يلغي التدفق مباشرة. تتحرر خانة في العداد، فينشئ تدفقاً جديداً على الوصلة نفسها. بالنسبة إلى آلة حالات البروتوكول انتهى التدفق؛ أما التوجيه وفك الضغط والتسجيل واستدعاء التطبيق أو قاعدة البيانات فقد تكون بدأت للتو.

لم يكن الدين الحقيقي ظاهراً في عدد التدفقات المفتوحة. كان الدين هو العمل الذي بدأ ولم يُلغَ فعلياً ولم يكتمل بعد. سمحت الفجوة لوصلة واحدة بأن تولّد العمل أسرع من قدرة البنية على استرداد الموارد.

ثلاث قمم لا يجوز جمعها

أعلن Google عن هجوم تجاوز 398 مليون طلب في الثانية. وسجلت Cloudflare ذروة تجاوزت 201 مليون طلب في الثانية من شبكة آلية قُدرت بنحو عشرين ألف جهاز. ووصفت AWS أحداثاً تجاوزت 155 مليون طلب في الثانية يومي 28 و29 أغسطس.

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

ولا تثبت الإفصاحات أن كل تطبيقات HTTP/2 تأثرت بالطريقة نفسها. تختلف نقاط الإنهاء وسلاسل الوكلاء والطوابير وسياسات الإلغاء. الدرس عالمي، لكن مسار الضرر والعلاج محليان.

عدّاد يجيب عن السؤال الخطأ

يسأل حد التزامن: كم تدفقاً مفتوحاً الآن؟ أما الأسئلة التشغيلية فهي: كم تدفقاً أنشأت هذه الوصلة عبر عمرها؟ كم واحداً أُلغي فوراً؟ ما العمل الذي بقي بعد الإلغاء؟ ومتى عادت المعالج والذاكرة وقدرة الخلفية إلى الخدمة؟

تكشف تجربة Cloudflare عند خفض MAX_CONCURRENT_STREAMS إلى 64 خطر الحل ذي البعد الواحد. افترض بعض العملاء المشروعين مئة تدفق بصورة متفائلة قبل تلقي إعدادات الخادم. تفاعلت عمليات reset التي أرسلها الخادم للتدفقات الزائدة مع حماية سابقة تعتمد عدّها، فظهرت أعطال في الصفحات. أعادت الشركة القيمة إلى مئة.

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

الوصلة تصبح وحدة المسؤولية

وصف Google اكتشاف النمط سريعاً على مستوى الوصلة، ثم إرسال GOAWAY أو إغلاقها. وأضافت Cloudflare كشف عمليات reset الصادرة عن العميل والعمل على الطوابير والجدولة والإلغاء والتسجيل، إلى جانب تخفيف سابق في وكيل TLS. المبدأ المشترك أهم من التفاصيل: قد تكون رسالة reset واحدة مشروعة، لكن تسلسلها المتراكم قد يثبت الإساءة.

إغلاق الوصلة يغير اقتصاد الهجوم. يفقد المهاجم القناة الرخيصة التي تسمح بفتح التدفقات ومحوها باستمرار. إنشاء وصلة جديدة يحتاج حالة جديدة ويوفر فرصة أخرى للتصنيف. يظل المستخدم العادي قادراً على الإلغاء العرضي؛ الذي يُسحب هو حق التكرار غير المحدود عندما يتزايد العمل الباقي.

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

ما يقوله المعيار وما لا يقوله

تحدد RFC 9113 حالات التدفق وRST_STREAM وGOAWAY وحد التزامن. لكنها لا تعد بأن كل أثر داخلي يختفي لحظة وصول reset. ما إذا كان العمل مستمراً في وكيل أو خدمة أو قاعدة بيانات سؤال لا تجيب عنه إلا المنظومة الفعلية.

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

ينبغي للمواصفة الدنيا أن تحفظ المعنى المشترك والتشغيل البيني. وعلى التنفيذ المحلي أن يقيس كلفته ويقرر متى لم تعد المشاركة آمنة. الخلط بين المستويين إما يطلب من المعيار التحكم في طوابير لا يراها، أو يفرض دفاعاً محلياً واسعاً يكسر عملاء مشروعين.

ما الذي يثبته جرد التصحيح

عبارة «تم تثبيت التصحيح» لا تكفي. يجب تحديد موضع انتهاء HTTP/2، وإلى أين ينتقل الطلب، وأين يوقف الإلغاء العمل فعلاً. قد يكون موازن الحمل محدثاً بينما يستمر وكيل داخلي في قبول عمل يتيم بلا سقف.

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

حدود الأدلة

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

الخلاصة الأضيق والأقوى هي أن نهاية كائن بروتوكولي لا تعني بالضرورة نهاية كلفته. يجب على الأنظمة متعددة الإرسال أن تنسب الدين الباقي إلى القناة التي أنشأته.

المصادر

  1. Cloudflare، “HTTP/2 Rapid Reset: deconstructing the record-breaking attack”: https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
  2. Google Cloud، “How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack”: https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack?hl=en
  3. Google Cloud، “Google mitigated the largest DDoS attack to date”: https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps
  4. AWS Security Blog، “How AWS protects customers from DDoS events”: https://aws.amazon.com/blogs/security/how-aws-protects-customers-from-ddos-events/
  5. AWS Security Bulletin AWS-2023-011: https://aws.amazon.com/security/security-bulletins/AWS-2023-011/
  6. IETF، RFC 9113، “HTTP/2”: https://www.rfc-editor.org/rfc/rfc9113.html
  7. IETF Internet-Draft، “Cumulative Stream Limits for HTTP/2”: https://datatracker.ietf.org/doc/html/draft-thomson-httpbis-h2-stream-limits-00
  8. Heng Lu، “Running-Code Primary”: https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  9. Heng Lu، “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”: https://heng.lu/minimum-initial-specification-localized-future-decision-and-voluntary-adoption-for-internet-coordination-systems/