في الآونة الأخيرة، ساعدت صديقًا في التحقق من محطة تعرضت لهجوم، ووجدت أنه على الرغم من أنهم وضعوا شبكة CDN عالية الدفاع، إلا أنهم لم يتحققوا مما إذا كان الدفاع فعالاً أم لا. وبمجرد وقوع الهجوم، انكشف عنوان IP الخاص بالمحطة المصدر مباشرة، وأصبحت شبكة CDN مكيدة. في هذه الأيام، حتى شبكة CDN يجب أن “تمنع زملاء الفريق” - بعض البائعين لم يكتبوا مستندات التكوين الخاصة بهم لفهمها.
هل صحيح أن شبكة CDN عالية الدفاع يمكن أن تتحمل الضرب؟ لا تستمع إلى تفاخر المبيعات، عليك أن تقيسها بنفسك. لقد رأيت الكثير من الأشخاص الذين يعتقدون أنهم اشتروا الخدمة ليطمئنوا، نتيجة الموجة الأولى من حركة المرور على العارية المباشرة. دردشة اليوم من طريقتين للاختبار، لقد صعدت على الحفرة على مر السنين خرجت من التجربة، ويمكن حتى في المقابل إجبار البائع على إعطائك التكوين.
دعنا نبدأ بحمام بارد: ما تعتقد أنه “ساري المفعول” قد يكون وهمًا.يقوم العديد من البائعين بتشغيل الحماية لبعض العقد فقط بشكل افتراضي، أو يتم تعيين سياسة التخزين المؤقت بشكل سيء للغاية بحيث لا تصل حركة المرور إلى مركز التنظيف. جوهر الاختبار هو جملة واحدة فقط:تأكد من أن كل حركة مرور الهجوم يجب أن تمر عبر عقدة التطهير الخاصة بشبكة CDN بينما يكون الموقع الأصلي غير مرئي تمامًا.
تُستخدم الطريقتان أدناه، الأولى للتحقق السريع والثانية لمحاكاة الجهد العالي، معًا لراحة البال الحقيقية.
الطريقة 1: اختبار دقة DNS - أساسي ولكنه مميت
إذا لم تقم بهذه الخطوة بشكل صحيح، فسيذهب كل شيء هباءً. لقد وجدت أن أكثر من 30٪ من مشاكل التكوين في حل DNS. كثير من الناس يغيرون CNAME ظنًا منهم أن الأمر قد انتهى، لكنهم لا يعرفون ذاكرة التخزين المؤقت المحلية لنظام أسماء النطاقات DNS، يمكن أن يتيح لك فرق وقت TTL تشغيل عارية لساعات.
تذكّر دائماًأولاً، استخدم dig أو nslookup للتحقق من نتائج دقة اسم النطاق الخاص بك.من الناحية المثالية، يجب أن يكون عنوان IP الذي تم حله هو عنوان IP الخاص بعقدة بائع CDN. من الناحية المثالية. يجب أن يكون عنوان IP الذي تم حله هو عنوان IP الخاص بعقدة مورد CDN وليس عنوان IP الخاص بموقعك المصدر:
إذا كانت النافذة المنبثقة هي عنوان IP المصدر الخاص بك، فأسرع بالتحقق من تكوين DNS. لا تضحك، لقد قابلت أيضًا عميلًا الشهر الماضي، قيمة سجل CNAME مملوءة بالحرف الخطأ، والقرار يعود مباشرة إلى المصدر، “حماية زائفة” صعبة لمدة ثلاثة أشهر.
ستكون الخطوة الأصعب هيتعديل ملف "المضيفين المحليين" لفرض الحل إلى عقدة CDN. على سبيل المثال، يمكنك توجيه اسم النطاق إلى عنوان IP الاختباري الذي يوفره بائع CDN، ثم قم بزيارة الموقع الإلكتروني لمعرفة ما إذا كان طبيعياً. إذا كان الأمر طبيعياً، فهذا يعني أن رابط الإرجاع من العقدة إلى الموقع المصدر قد تم؛ أما إذا أبلغ عن خطأ، فقد تكون هناك مشكلة في تكوين الإرجاع (مثل رأس المضيف أو الشهادة).
بعض البائعين مثل CDN07 سيوفرون نطاق اختبار مخصص، لذلك لن تضطر إلى انتظار تفعيل DNS للتحقق من حالة العقدة. هذه الميزة عملية للغاية في الواقع، لكن 80% من المبيعات لن تبادر بإخبارك - ففي النهاية، الأكثر أفضل من الأقل.
الطريقة 2: اختبار الهجوم بالمحاكاة - اللعب الحقيقي موثوق به
لا يكفي التحليل بشكل صحيح، بل عليك أن تثبت أن العقدة يمكن أن تحمل الضربة بالفعل. فيما يلي اتجاهان موصى بهما: محاكاة حركة مرور DDoS واختبار هجوم CC.
اختبار DDoSمن الأفضل العثور على بائع للعمل معه. يسمح البائعون الشرعيون ذوو الدفاعات العالية مثل CDN5 و 08Host للعملاء بإطلاق هجمات محاكاة خلال فترة الاختبار (بالطبع، عليك تحديد موعد مسبقاً). سيراقب مهندسوهم لوحة حركة المرور لمساعدتك في تحليل تأثير التنظيف. لا تقاتل بمفردك بشكل أعمى، خاصة أولئك الأشخاص المتهورين الذين يشترون VPS ويفتحون hping3 - احذر من أن يتم حظره من قبل قطاع شبكة المشغل.
التركيز عند الاختبارتباين زمن الاستجابة وفقدان الحزمة. حالة التنظيف العادية، يجب أن تكون زيارات الموقع بلا معنى تقريبًا، أثناء مراقبة الخلفية لرؤية ارتفاع حركة مرور التنظيف. على سبيل المثال، في المرة الأخيرة التي قمت فيها بقياس عقدة 08Host، ضرب فيضان UDP 200G في الثانية في الماضي، ارتفع زمن انتقال العمل 20 مللي ثانية فقط، وهذا فعال حقًا.
اختبار هجوم CC الهجوميإنها مناسبة أكثر للعبث بنفسك. استخدم أداة لمحاكاة الكثير من الطلبات العادية، مثل التنظيف المحموم لبعض الصفحات الديناميكية:
انتبه إلى منحنى QPS وإرجاع رمز الحالة من وحدة تحكم CDN. إذا كان عدد كبير من الطلبات يعود مباشرةً إلى المصدر أو إذا كان عدد كبير من الطلبات يعود مباشرةً إلى المصدر أو إذا ارتفعت وحدة المعالجة المركزية للمصدر، فهذا يعني أن قواعد CC غير سارية المفعول. يجب أن تكون الحماية الجيدة قادرة على اعتراض الطلبات الخبيثة مباشرةً في العقد الطرفية، وحتى إرجاع تحديات CAPTCHA.
إليك ما يلي: بعض قواعد CC لدى بعض الشركات المصنعة لديها حساسيات افتراضية منخفضة بشكل سخيف لدرجة أنك يجب أن تضربها بشدة قبل أن تكون على استعداد لتعديلها. لذلك قد ترغب في الضغط عليها بقوة أكبر قليلاً عند اختبارها، وضربها حتى عتبة الزناد مباشرةً لتجعلها تعمل.
إجراء تافه إضافي: إعادة نشر مسارات الهجوم باستخدام سجلات SSH
إذا كان خادم المصدر الخاص بك يحتوي على SSH قيد التشغيل، انتقل مباشرةً إلى سجلات /var/log/secure logs (أنظمة لينكس). في الهجوم الحقيقي، إذا لم تكن شبكة CDN غير مفعلة، سترى الكثير من محاولات تسجيل الدخول الفاشلة القادمة من عنوان IP الحقيقي؛ إذا كانت الشبكة مفعلة، يجب أن تأتي جميع الطلبات من شريحة عنوان IP المصدر المرتجع لشبكة CDN فقط.
تعد هذه الطريقة أكثر دقة من النظر في سجلات الأعمال لأن المخترقين دائمًا ما يمسحون المنفذ 22 يدويًا، وهذا النوع من حركة المرور لا يتم تخزينه مؤقتًا وسيعود بالتأكيد إلى المصدر.
الاختبار ليس لمرة واحدة
فقط لأنه يعمل اليوم لا يعني أنه سيعمل غدًا. خاصةً عندما يكون موقعك على الويب قد غيّر ميزات أو بنية جديدة، فمن المحتمل أن تتجاوز بعض الواجهات شبكة CDN مرة أخرى. يوصى باستخدام الطريقة المذكورة أعلاه للتحقق بشكل كامل كل ثلاثة أشهر، خاصةً دقة DNS ومخاطر تعرض الموقع المصدر.
رد أخيرغالبًا ما لا تكمن أعماق شبكات CDN عالية الدفاع في التكنولوجيا ولكن في الأعمال التجارية. بعض البائعين يبيعونك 10 جيجا من الحماية، وقد يتقاسمون فعليًا مجموعة النطاق الترددي؛ مدعين أنه يمكن منع أي هجوم، ونتيجة لقواعد CC يجب أن تضيف أموالاً لفتحها. الاختبارات ليس فقط للتحقق من التأثير، ولكن أيضًا وسيلة لإجبارهم على الوفاء بوعودهم.
ففي النهاية، أنت تدفع مقابل الأمان وليس الراحة النفسية.
