في الآونة الأخيرة، ساعدت صديقًا في التعامل مع مشروع تعرض لهجوم من قبل DDoS ولم أستطع أن أتولى الأمر بنفسي، فتذكرت أن أسأله: “هل تستخدم شبكة CDN لا تتمتع بدفاعات عالية؟ ونتيجة لذلك، سألني هذا الصديق بوجه مرتبك: ”هل يمكنك اختيار بروتوكول لشبكة CDN عالية الدفاع؟ وليس إعطاء اسم نطاق لتعليقه في نهاية الأمر؟“ كدت أن أحطم لوحة المفاتيح على الفور - في هذه الأيام لا يزال هناك أشخاص يعتقدون أن شبكات CDN هي فقط للتسريع، وأن الدفاع ودعم البروتوكول للعرض فقط؟
بصراحة، أمر دعم البروتوكول ليس ميتافيزيقيًا حقًا. لقد رأيت الكثير من الأشخاص يشترون خدمة عالية الدفاع، والنتيجة هي أن البروتوكول غير مقترن، تم اختراقه بعد أن وبخ البائعون أيضًا القمامة. في الواقع، تكمن المشكلة في أنك لا تفهم سيناريوهات العمل: أنت تدفع البث المباشر مع RTMP، وتقوم بالاتصال في الوقت الحقيقي مع WebSocket، ومواقع الويب العادية مع HTTPS، والبروتوكولات المختلفة للذهاب إلى المنفذ والتشفير مختلفة تمامًا. إذا كان بائعو CDN يساعدونك فقط على منع منافذ 80/443 ، فإن البروتوكولات الأخرى ببساطة لا تمر عبر عقدة التنظيف ، وما الفرق بين تشغيل عارية؟
خذ HTTPS أولاً، وهو الأكثر أساسية. لكن دعم HTTPS لشبكة CDN عالية الدفاع HTTPS وشبكة CDN العادية هما ببساطة شيئان مختلفان. قد تساعدك CDN العادية فقط على القيام بنقطة نهاية SSL، بينما يجب أن تشارك CDN عالية الدفاع في العملية الكاملة لحماية مصافحة TLS. لقد اختبرت خدمات CDN5، ويمكنهم حتى تحديد الحزم غير الطبيعية في حركة المرور المشفرة - على سبيل المثال، يرسل عنوان IP فجأة طلبات مصافحة TLS بتردد عالٍ، مما يؤدي مباشرة إلى تشغيل القواعد التي يتم إلقاؤها في الثقب الأسود. لا تصدق دعاية “الدعم الكامل للبروتوكول”، فالعديد من بائعي حماية HTTPS ببساطة لا يقومون بالكشف عن SNI، ويواجهون ESNI (SNI المشفرة) كتم الصوت مباشرة.
عند تكوين HTTPS عالي الأمان، عليك الانتباه إلى طريقة نشر الشهادة. يوصى باستخدام التحقق من الشهادة ثنائي الاتجاه، على الرغم من أن المشكلة تكمن في أنه يمكن أن يمنع معظم هجمات الشهادات المزورة. انشر مثالاً على تكوين Nginx:
بالإضافة إلى بروتوكول RTMP، وهو صديق قديم لصناعة البث المباشر. يعد دعم شبكة CDN عالية الدفاع لـ RTMP مفتاحًا لعزل عقد الدفع والسحب. بعض البائعين من أجل توفير التكاليف، ودفع التدفق وسحب التدفق مع نفس مجموعة الخوادم، ونتائج هجوم المهاجمين على RTMP الفيضان، وانهيار السلسلة المباشرة بأكملها. الممارسة الموثوقة مثل CDN07، دفع عقد التدفق وحدها مع مجموعة دفاعية عالية، وسحب عقد التدفق ثم القيام بالتسريع الموزع. وبمجرد قياس حماية RTMP الخاصة بهم، دفع عقد التدفق لحمل هجوم فيضان 200 جيجابت في الثانية في نفس الوقت، لم يتجاوز تأخير تدفق السحب 200 مللي ثانية.
WebSocket هو السيناريو الذي يختبر بالفعل تقنية البائع. يتميز هذا البروتوكول بالاتصالات الطويلة، واستراتيجية الحماية التقليدية القائمة على تردد الطلبات غير فعالة بشكل أساسي. حيث يقوم المهاجمون ببناء مئات الآلاف من اتصالات WebSocket المعلقة التي لا تزال تستنفد موارد الخادم. شبكة CDN جيدة عالية الدفاع مثل 08Host للقيام بتحليل سلوك الاتصال - على سبيل المثال، بروتوكول الإنترنت لبناء اتصال بعد الفشل المستمر في إرسال الحزم، أو إرسال حزمة نبضات قلب في الثانية أكثر من العتبة، قرصة الاتصال مباشرة. يجب أيضًا دعم المجموع الاختباري لترقية البروتوكول، لمنع المهاجمين المتخفين في شكل مصافحة WebSocket يتم إرسالها في الواقع HTTP Flood.
هناك مأزق آخر واجهته مؤخرًا: حماية WebSocket عبر TLS (WSS). يعتقد العديد من البائعين أن نفس تكوين حماية HTTPS سيعمل، ولكن النتيجة هي اختراق مرحلة مصافحة TLS. يوصى بتكوين WSS لفرض إصدار TLS بحد أدنى 1.2 وتعطيل مجموعات التشفير الضعيفة. لقد اختبرت التكوين الافتراضي لأحد البائعين، ولكنه يدعم أيضًا TLS 1.0، والذي تم إدراجه مباشرةً في القائمة السوداء.
بالإضافة إلى هذه البروتوكولات السائدة، هناك بعض السيناريوهات الخاصة التي تستحق الحديث عنها. على سبيل المثال، بروتوكول UDP المستخدم بشكل شائع في صناعة الألعاب، يجب أن تدعم شبكة CDN عالية الأمان حماية UDP Flood؛ قد تحتاج الصناعة المالية إلى بروتوكول TCP الخاص، اعتمادًا على ما إذا كانت شبكة CDN تدعم حماية المنافذ المخصصة. لقد رأيت نظامًا لتداول الأوراق المالية بسبب استخدام منافذ غير قياسية، وشراء شبكة CDN عالية الأمان لا تكتشف حركة مرور المنفذ، وقد شُلّت بسبب فيضان SYN قبل التفكير في القواعد المخصصة.
لا تنظر فقط إلى السعر عند اختيار شبكة CDN عالية الدفاع. سأدرج بيانات مقارنة واقعية:
أخيراً، أود أن أعطي نظرية عنيفة: لقد تجاوزت هجمات الشبكة هذه الأيام منذ فترة طويلة هجمات ICMP Flood البسيطة والفجة. فقد بدأ المهاجمون في استهداف ثغرات البروتوكول للقيام بهجمات طبقة التطبيق، مثل هجمات بطء الاتصال WebSocket، وهجمات تشويش بروتوكول RTMP. إذا اخترت بائع CDN حتى تكييف البروتوكول ليس مثاليًا، أي ما يعادل فتح القراصنة الباب الخلفي وتمرير المفتاح بشكل فعال.
عند تهيئة شبكة CDN عالية الدفاع تذكر أن تجلس القرفصاء في الخلفية وتلقي نظرة على تقارير حركة المرور في الوقت الفعلي. سيُظهر نظام الحماية الجيد بوضوح أنواع الهجمات وعمليات التخفيف من حدة الهجمات للبروتوكولات المختلفة. لا تنتظر حتى ينهار عملك حتى تتحقق من السجلات - سيكون عملاؤك قد نفد بحلول ذلك الوقت. الأمن هو شيء من الأفضل دائماً الوقاية منه بدلاً من معالجته بعد وقوعه.
نسيت أن أقول نقطة أساسية: يعتمد دعم البروتوكول أيضًا على طريقة العودة إلى المصدر. تعلن بعض شبكات CDN عن دعم WebSocket، ولكن العودة إلى المصدر تكون أقل من ذلك إلى استطلاع HTTP، والانفجار المباشر لوقت الاستجابة. تأكد من الاختبار مع سيناريوهات العمل الفعلية قبل الشراء، وإلا فإنك تنفق المال لشراء وحيد.
باختصار (لم أستطع مقاومة القول باختصار مرة أخرى)، دعم البروتوكول لشبكات CDN عالية الدفاع ليس بالتأكيد لعبة خانة اختيار. من HTTPS إلى WebSocket، كل بروتوكول له سطح هجوم فريد ونقاط حماية فريدة من نوعها. عند اختيار البائع، عليك أن تأخذ قوة التحقق من العلاقة، وتوافق البروتوكول، ودقة الحماية، ولا يمكن تجنب فقدان الأداء. بعد كل شيء، في هذه الأيام، حتى شبكة CDN يجب أن “تمنع زملاء الفريق” - اختيار البائع الخطأ، زملاء الفريق في العدو هو الأكثر فظاعة.
