في الساعة الثالثة من صباح ذلك اليوم، استيقظت على رسالة نصية تنبيهية مستمرة - منحنى حركة المرور التجارية المباشرة ارتفع فجأة إلى عمود، وانخفض تدفق دفع RTMP باستمرار، وتظهر الخلفية أن عنوان IP معين في الجنون يرسل رأس حزمة FLV وحشيًا. إن زملائي هم من يتشاجرون.
قذفت إلى الفجر أخيرًا قمع الهجوم أخيرًا، حدقت في خريطة المراقبة وتوصلت إلى فكرة: في هذه الأيام للمشاركة في البث المباشر، لا يوجد دعم بروتوكول RTMP لشبكة CDN عالية الدفاع يساوي الركض عاريًا. لكن مزودي الخدمة في السوق تحت شعار “الدعم الكامل” هل يمكن لمزودي الخدمة في السوق أن يصمدوا حقًا أمام الضربات المخصصة لعصابات الابتزاز؟
بروتوكول RTMP هو الشريان غير المرئي في مجال البث المباشر
يعتقد العديد من الناس أن HTTP-FLV و HLS قد سيطروا على مساحة البث المباشر، ولكن عندما يتعلق الأمر بتسليم البث المباشر فعليًا، لا يزال RTMP هو الخيار الأول لمعظم بائعي برامج التشفير. لماذا؟ لانخفاض زمن الوصول، وطول مدة الاتصال، والتوافق مع نظام Adobe البيئي لهذه المزايا المبتذلة، ناهيك عن أن المفتاح هو أنه مثل الوعاء الدموي بعمق سلسلة أدوات الإنتاج - OBS، FFmpeg، Wirecast وهو ليس مخرج RTMP الافتراضي؟ لقد وجدتُ أن استخدام RTMP لدفع البث بدلاً من بروتوكول SRT لتوفير ما لا يقل عن 30% من استخدام وحدة المعالجة المركزية، والتي تتطلب وقتًا طويلاً لتعليق الأنشطة المباشرة هي ببساطة ميزة منقذة للحياة.
ولكن إليك المشكلة: اتصالات RTMP الطويلة القائمة على TCP تجعلها هدفًا مثاليًا لهجمات DDoS. يمكن للمهاجمين استنفاد موارد الخادم بسهولة عن طريق محاكاة تدفق دفع عادي لإنشاء اتصال ثم إرسال بيانات غير مرغوب فيها ببطء. في العام الماضي، تعطلت إحدى منصات بث الألعاب لمدة 12 ساعة بسبب اختراق خدمة RTMP بسبب هجوم بطيء.
شبكات CDN عالية الدفاعات ليست محكمة الدفاعات
لا تصدق تلك “الحماية غير المحدودة” في المنشورات الترويجية. لقد اختبرت ثلاثة من مزودي الخدمة السائدة: حماية CDN5 RTMP رائعة حقًا، لكن السعر يكفي لشراء سيارة رياضية للمبتدئين؛ CDN07 عقدة تنظيف CDN07 غالبًا ما تقتل حزم الوسائط العادية عن طريق الخطأ؛ 08Host رخيص، لكن هجمات CC تعود مباشرة إلى المصدر - نفس الهجوم الذي يؤدي إلى خادم العميل.
يجب أن تكون شبكة CDN عالية الدفاع الموثوق بها حقًا مثل سكين الجيش السويسري: دعم بروتوكول RTMP هو الشفرة الأساسية، ويجب أن يكون هناك أيضًا أجهزة استشعار تحدد بدقة حركة المرور غير الطبيعية. على سبيل المثال، إذا اكتشفت أن معرّف تدفق دفع معين ينشئ مئات الاتصالات في غضون 10 ثوانٍ، فيجب أن تقوم تلقائيًا بتشغيل التحقق البشري بدلاً من مجرد حظر عنوان IP.
انظر إلى استراتيجية الحماية في التكوين الفعلي (استنادًا إلى وحدة NGINX النمطية):
لقد ساعدتني هذه المجموعة من القواعد في منع ثلاث هجمات يوم الصفر على الأقل. في إحداها، حاول المهاجم إرسال حزمة onMetadata متلاعب بها مما تسبب في تعطل محلل الخادم، وذلك بفضل قواعد WAF التي تشم الحقل الشاذ مسبقًا.
دعم الاتفاقية هو الحل الأمثل
والآن نعود إلى الموضوع الرئيسي: هل تدعم شبكات CDN عالية الدفاع المباشر RTMP أم لا؟ الإجابة هي أن مزودي الخدمة الرئيسيين مدعومون، ولكن جودة الدعم تختلف اختلافًا كبيرًا. لقد قمت بتجميع جدول مقارنة (بيانات من الربع الثاني 2024):
CDN5: تأخير تدفق دفع RTMP <800 مللي ثانية، ودعم الإرسال المشفر TLS، ويمكن تعديل عتبة الحماية ديناميكيًا، ولكن القواعد المخصصة تتطلب تطبيق أمر عمل - مناسب للشركات العملاقة.
CDN07: تغطية واسعة للعقدة، وأداء مذهل في زمن الاستجابة في جنوب شرق آسيا، ولكن عند مواجهة هجوم فيضان SYN، سيضطر إلى تبديل البروتوكولات، مما قد يتسبب في انقطاع تدفق الدفع - وهو مناسب للأعمال التجارية الخارجية.
08Host: رخيص رخيص حقًا، حزمة حماية حركة المرور 1T رخيصة حقًا، حزمة حماية حركة المرور 1T ليست سوى بضع مئات من الدولارات، ولكن استجابة الدعم الفني بطيئة، تم ضرب منتصف الليل يمكن فقط كتابة البرامج النصية الخاصة بهم لتحمل - مناسبة لقدرات البحث الذاتي للفريق الصغير.
إنها الحفرة الخفية التي تقتل.
في العام الماضي لمساعدة منصة تجارة إلكترونية للقيام بهجوم البث المباشر والحفر الدفاعي وجدت ظاهرة غريبة: من الواضح أن مفتاح مصادقة RTMP الذي تم تكوينه بشكل واضح، لا يزال بإمكان المهاجم تزوير عنوان دفق الدفع. وأخيرا في Wireshark القرفصاء لمدة نصف ليلة فقط لتجد أن بائعي CDN من أجل أن تكون متوافقة مع الإصدار القديم من المشفر، الافتراضي لكل دفق لإنشاء عنوان URL بديل غير موقع - هذا الباب الخلفي هو ببساطة هدية عيد الميلاد المخصصة للمهاجم.
هناك الآن ثلاثة أشياء يجب على فريقي القيام بها قبل نشر خدمات RTMP:
1 - الكشف عن دقة اعتراض شبكة CDN من خلال محاكاة تدفقات الدفع الخبيثة باستخدام أداة ffprobe
2 - تحقق من وحدة التحكم بحثًا عن مفاتيح توافق البروتوكول المخفية
3 - مطالبة البائعين بتقديم تقارير الحماية من الهجمات ضد بروتوكولات RTMP للأشهر الثلاثة الماضية.
بالمناسبة، دعنا نشارك حالة حقيقية: قبل حدث كبير، لاحظنا فجأة تأخراً دورياً في جانب تدفق الدفع. بعد التقاط الحزم، وجدنا أن جدار الحماية الخاص بعقدة CDN كان يسقط بشكل عشوائي حزم RTMP التي تحتوي على طوابع زمنية محددة - والسبب هو أن البائع أضاف عن طريق الخطأ نطاقًا معينًا من الطوابع الزمنية العادية إلى القائمة السوداء. لا يمكن اكتشاف هذا النوع من المشاكل بدون اختبار الضغط.
ساحة المعركة المستقبلية في طبقة البروتوكول
الآن ابتكرت السوق السوداء خدعة جديدة: هجمات التلاعب بجودة الخدمة من خلال تحليل معلمة حجم النافذة أثناء مصافحة RTMP. ببساطة، هو الإعلان عمدًا عن نافذة استقبال صغيرة جدًا، بحيث يقلل الخادم من معدل الإرسال لإحداث تأخير. ويتطلب الدفاع ضد هذا الهجوم نشر محركات تحليل سلوك البروتوكول في العقد الطرفية لشبكة CDN، ولم تعد معدات تنظيف حركة المرور وحدها كافية.
الحل الذي كنت أختبره مؤخرًا هو حقن علامات مائية رقمية في مرحلة مصادقة تدفق الدفع:
يمكّن هذا النظام كل دفق فيديو من حمل توقيع فريد من نوعه يمكن تتبعه بسرعة إلى طرف البث المحدد في حالة سرقة البث أو الهجوم - أي ما يعادل ختمًا فولاذيًا غير مرئي لكل حزمة.
اختيار النصيحة لتكون صادقاً
إذا كنت بصدد اختيار نموذج، تذكر هذه الدروس الثلاثة الدامية:
1 - لا تنخدع بدعاية “الدعم الكامل لـ RTMP”، اختبر دائمًا توافق البروتوكول وربط الحماية.
2. اسأل البائع عما إذا كان يدعم الإرسال المشفر RTMPS، فإن تدفقات الدفع المرسلة بنص واضح هي نفسها التي تعمل عارية.
3 - تحقق مما إذا كان بإمكان وحدة التحكم تخصيص قواعد الحماية لـ RTMP، مثل تعيين عتبات محددة لمعدل الحزمة.
ملاحظة أخيرة من الفكاهة السوداء: لقد اكتشفت ذات مرة أن وحدة تحكم البائع يمكنها بالفعل تصدير سجلات الحماية إلى جدول بيانات Excel - ولكن من يحلل بيانات جدول البيانات بالعين المجردة بعد مرور ساعتين على الهجوم؟ الأمر أشبه بتسليم دليل المستخدم إلى غريق.
يجب أن يكون نظام الحماية الجيد حقاً مؤتمتاً. على سبيل المثال، يمكن لنظام الجدولة الذكي لشبكة CDN5 إعادة توجيه تدفقات RTMP تلقائيًا إلى مجموعات التنظيف المخفية بعد تحديد نمط الهجوم، وتكون العملية برمتها غير محسوسة في نهاية تدفق الدفع. فكرة التصميم هذه هي الاتجاه المستقبلي.
بعد ثماني سنوات من العمل في مجال البث المباشر، أشعر بشكل متزايد أن التكنولوجيا ليست سوى الإطار الأساسي فقط، فالخندق الحقيقي هو “البيانات القذرة” المتراكمة في عملية المواجهة. معرفة أي نوع من الحزم المشوّهة سيؤدي إلى تعطل أي نوع من برامج التشفير، ومعرفة أي نوع من قطاعات بروتوكول الإنترنت في المنطقة المعرضة لشن هجمات محددة - هذه الخبرات هي الأصول الأساسية التي لا يمكن شراؤها بالمال.
إذًا نعود إلى السؤال الافتتاحي: هل تدعم شبكة CDN الدفاعية العالية المباشرة RTMP؟ الدعم، ولكن يمكن أن تسمح لك بالنوم بشكل سليم، اعتمادًا على البائع المخفي وراء قائمة ميزات القدرة القتالية الفعلية. في المرة القادمة التي تزور فيها أحد مزودي الخدمة، قد ترغب في أن تسألهم مباشرةً: “إذا قام شخص ما بضرب دفق الدفع الخاص بي بهجوم بطيء متغير RTMP الآن، فأي طبقة من آلية الدفاع لديك ستكون أول من يستجيب؟ -- قد تجعلك الإجابة تتصبب عرقاً من البرد.
