الأسباب الخمسة الشائعة لفشل دفاع CDN عالي الدفاع وتفاصيل الحل

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

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

أولاً، تسرب بروتوكول الإنترنت لمحطة المصدر: تعتقد أنه مخفي، في الواقع، في

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

في العام الماضي، ساعدت أحد مواقع التجارة الإلكترونية في العام الماضي على إجراء اختبار اختراق، باستخدام أداة بصمة مفتوحة المصدر لفحص عنوان IP المصدر مباشرةً - فقط لأنهم نسوا حذف المصدر الذي يشير إلى مجال فرعي في سجل A. والأكثر شيوعًا هو من خلال خادم البريد، والنطاقات الفرعية القديمة، وحتى معلومات شهادة SSL للتحقق العكسي من عنوان IP. لا تصدق هراء “تعيين CDN آمن تمامًا”.

الحل:

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

2 - استخدام الأداة بانتظام للتحقق الذاتي من مخاطر التعرض لبروتوكول الإنترنت:

3- حل منفصل من طرف ثالث (على سبيل المثال، SendGrid) لخدمات البريد، وليس على نفس عنوان IP الخاص بالشركة;

4. يرفض جدار حماية الخادم كل حركة المرور بشكل افتراضي ويفتح فقط المنافذ اللازمة لقطاعات بروتوكول الإنترنت التي يوفرها بائع شبكة توصيل المحتوى.

ثانياً: سوء تكوين قواعد الحماية: الغطاء المفتوح لا يعني جاهزاً للاستخدام

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

قام البعض الآخر بتعيين عتبات الحماية الخاصة بهم لتكون شديدة للغاية: يُسمح لعنوان IP واحد بـ 1000 طلب في الثانية، مما يجعل حماية CC غير موجودة تقريبًا. من المهم أن تعرف أن ذروة سلوك المستخدم الحقيقي لا تتجاوز عادةً 20 طلبًا في الثانية، ناهيك عن أن “الوضع الذكي” لبعض البائعين هو في الواقع مجرد مفتاح عتبة.

الحل:

1 - قاعدة قاعدة WAF مفتوحة على الأقل إلى مستوى “صارم”، لا تخف من الحظر عن طريق الخطأ، فهو أفضل من أن تُضرب بالشنق;

2. قواعد التكرار المخصصة: اعتدت على تعيين عتبات حسب نوع العمل. يتم تحديد بوابة واجهة برمجة التطبيقات بـ 50 مرة في الثانية لعنوان IP واحد، ويتم تخفيف الموارد الثابتة إلى 200 مرة، ويجب الضغط على واجهة تسجيل الدخول إلى أقل من 10 مرات;

3. قم بتمكين وضع تحدي المصادقة البشرية لإظهار اختبار CAPTCHA مباشرةً لحركة المرور المشبوهة. 08Host قام بعمل جيد في هذا المجال ويدعم أوضاعًا متعددة للمصادقة غير المحسوسة وتحدي JS;

4 - النظر بانتظام في تقارير الهجمات: التركيز على أنماط الهجمات التي تهدف إلى تجاوز القواعد، مثل حقول رأس المستخدم أو حقول رأس XFF العشوائية.

ثالثًا، مشكلات توافق الشهادات والبروتوكولات: يمكن أن تصبح TLS أيضًا نقطة ضعف

واجهت موقفًا مثيرًا للشفقة بشكل خاص: اشترى العميل مصنعًا صغيرًا لشبكة CDN عالية الدفاع، ونتائج الطرف الآخر لا تدعم بروتوكول TLS1.3. أُجبر الموقع على الرجوع إلى TLS1.2، وصادف أن تعرض الموقع لهجوم CC باستخدام ثغرات البروتوكول، وارتفعت وحدة المعالجة المركزية مباشرةً إلى أقصى طاقتها. والأكثر شيوعًا هو أن سوء تكوين شهادة SSL يؤدي إلى عدم إمكانية مصافحة CDN بشكل طبيعي، وتعود حركة المرور إلى مصدر غير مشفر عاريًا.

الحل:

1 - اختبر الرابط المشفر بالكامل باستخدام مختبرات Qualys SSL Labs:

2. تأكد من اكتمال سلسلة الشهادات ويجب نشر الشهادات الوسيطة. يوصى باستخدام خدمات الإدارة التلقائية للشهادات، يوفر كل من CDN5 و CDN07 نشر SSL وقفة واحدة;

3. قم بتعطيل البروتوكولات القديمة (SSLv3 وTLS1.0) وفرض تمكين امتداد SNI;

4- يجب أيضًا تشفير الرابط المؤدي إلى المصدر، ولا تستخدم HTTP المؤدي إلى المصدر - فقد رأيت الكثير من الأشخاص يقعون في هذا الخطأ.

رابعًا، سوء تكوين دقة DNS: النقطة العمياء القاتلة في توجيه حركة المرور

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

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

الحل:

1. CNAME دائمًا CNAME اسم النطاق إلى اسم النطاق المحمي الذي توفره شبكة CDN عالية الدفاع أولاً، ثم شبكة CDN إلى المصدر;

2 - اضبط وقت TTL أقصر، 300 ثانية للاستخدام العادي و60 ثانية للتبديل في حالات الطوارئ;

3. استخدم وظيفة التحليل متعدد الخطوط في DNSPod أو Cloudflare لإرسالها إلى العقد عالية الدفاع بشكل فردي لمنطقة الهجوم;

4- إجراء اختبار اختراق DNS بشكل منتظم:

خامساً: التعارض بين خصائص العمل واستراتيجيات الحماية

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

بالإضافة إلى ذلك، يجب التعامل مع حماية واجهة واجهة برمجة التطبيقات بشكل منفصل. تختلف خصائص طلب POST بتنسيق JSON عن خصائص طلب النموذج العادي وتتطلب تعديل قواعد الكشف عن واجهة برمجة التطبيقات. قاعدة القواعد الافتراضية لبعض البائعين لديها معدل اكتشاف أقل من 30% لهجمات واجهة برمجة التطبيقات.

الحل:

1 - قبل بدء تشغيل الخدمة، يجب عليك إجراء اختبار القائمة البيضاء: تسجيل حركة مرور الخدمة الحقيقية للتشغيل، ومراقبة قواعد الحماية لقتل الموقف;

2 - خدمات WebSocket وخدمات الاتصال الطويل لأخذ قناة إعادة توجيه مخصصة، تم تحسين سياسة حماية WebSocket الخاصة بـ 08Host بشكل منفصل;

3 - تمكّن خدمات واجهة برمجة التطبيقات (API) من تمكين أوضاع حماية خاصة للتركيز على نواقل الهجوم الجديدة مثل التحليل العميق لـ JSON وحقن GraphQL;

4. يجب إجراء تحليل السجل في الوقت الحقيقي، أو تحليل سجلات الوقت الحقيقي، أو تحليل سجلات مكدس ELK أو مباشرة مع خدمات تسجيل مورد CDN لالتقاط الأنماط الشاذة بشكل أكثر موثوقية من مجرد الاعتماد على WAF.

في الختام

إن شبكة CDN عالية الدفاع ليست آمنة للتوصيل والتشغيل، ولكنها نظام متطور يتطلب ضبطًا مستمرًا. الدفاع الفعال حقًا = 70% التكوين الصحيح + 20% المراقبة والتحذير + 10% الاستجابة للطوارئ. لا تعتمد كليًا على “الحماية التلقائية” التي يوفرها البائع، وألقِ نظرة على تخطيط حركة المرور في الوقت الفعلي، وقم بإجراء تدريبات الهجوم والدفاع بانتظام.

إذا كنت تريد حقًا أن توصي - CDN07 فعال من حيث التكلفة للشركات الصغيرة، ويفضل CDN5 لسيناريوهات حركة المرور العالية مع شبكة Anycast Network، ويمكنك النظر إلى حل الحماية الهجين 08Host للسعي وراء التخصيص الشديد. ولكن تذكر أنه لا يوجد حل واحد للجميع، بل استراتيجية حماية متكررة ومستمرة.

(لا توجد مشكلة بعد التحقق من عناصر التكوين هذه؟ أرسل لي رسالة خاصة لإرسال تقرير تشخيصي للمساعدة في معرفة ما إذا كنت تعاني من هجوم شرير)