واجهت مؤخرًا أمرًا شريرًا، فمن الواضح أن محطة التجارة الإلكترونية لأحد العملاء علقت محطة التجارة الإلكترونية الخاصة بالعميل شبكة CDN عالية الدفاع، أو تم تفريغ أكثر من 100,000 طلب مزيف. فحص السجل وجد أن المهاجم قام بتزوير عنوان IP الخاص بعقدة CDN بشكل مثالي، وتجاوز الطلب مباشرة نظام الحماية. في هذه الأيام، حتى شبكة CDN يجب أن “تمنع زملاء الفريق” - تعتقد أن الدرع على الأمن، ولكن لا تعرف أن التحقق من محطة المصدر ليس جيدًا، ستصبح شبكة CDN عالية الأمان نقطة انطلاق للمهاجمين.
هجمات انتحال بروتوكول الإنترنت ليست شيئًا جديدًا. لكن الكثير من الناس يعتقدون أن ذلك على شبكة CDN سترتاح بسهولة، في الواقع، خطأ كبير. سيخطو المهاجمون الآن أولاً بمسح مقطع IP الخاص بعقدة CDN، ثم يقومون بتزوير X-Forwarded-Forwarded لهذا النوع من الرؤوس، حركة مرور القمامة المعبأة على أنها “حركة مرور CDN شرعية” مباشرة إلى محطة المصدر. لقد اختبرت ثلاثة من مزودي خدمة CDN السائدة العام الماضي، اثنان من التكوين الافتراضي يسمحان في الواقع لأي بيان IP بأنهما عقدة CDN، هذه الثغرة الأمنية هي ببساطة أكثر من مجرد تسريب غربال.
السبب الجذري هو أن العديد من العمليات والصيانة تثق بشكل أعمى بقائمة عناوين IP التي يقدمها مزود خدمة CDN. ولكن يتم تحديث عناوين IP الخاصة بعقدة CDN آه يا أخي! قد تكون قائمة شرائح IP التي تم تحديثها الأسبوع الماضي غير صالحة هذا الأسبوع. ناهيك عن أن بائعي CDN الذين يستخدمون خدمات CDN السحابية مع عنوان IP المرن، يتغير عنوان IP للعقدة أسرع من الكتاب. هل تتوقع الاحتفاظ يدوياً بقائمة بيضاء لعناوين IP؟ قد يكون من الأفضل إرسال دعوة للمهاجمين.
بادئ ذي بدء، التحقق من مصدر بروتوكول الإنترنت. لا تستخدم “دفتر أجزاء بروتوكول الإنترنت CDN” الذي تم تنزيله من الإنترنت، حيث تنتهي صلاحيته أسرع من مدة صلاحية الزبادي. لقد تغيرت الآن جميع المشاريع لاستخدام آلية المصادقة الديناميكية: في لوحة تحكم CDN لإنشاء رمز مميز، ثم من خلال رأس مخصص يتم تمريره إلى محطة المصدر. تكوين موقع المصدر Nginx تكوين Nginx مباشرة كتابة ميتة:
هذه الخدعة لا ترحم في ماذا؟ حتى إذا قام المهاجم بتزوير عنوان IP لا يمكنه الحصول على الرمز المميز. تم اختبار CDN5 و CDN07 اثنين، مع التحقق من الرأس المخصص، ومعدل اعتراض الطلب غير القانوني مباشرة إلى 100%. ومع ذلك، تجدر الإشارة إلى أنه يجب تدوير الرمز المميز بانتظام، فمن المستحسن استخدام نظام إدارة المفاتيح للتحديث التلقائي.
الرمز المميز وحده لا يكفي. في العام الماضي، واجهنا حالة في العام الماضي، حيث قام المهاجم من خلال الهندسة الاجتماعية بالحصول على الرمز المميز (قام أحد الموظفين بإلقاء ملف التكوين على GitHub)، وهذه المرة نحتاج إلى خط دفاع ثانٍ - البصمة. مبدأ هذه التقنية بسيط للغاية في الواقع: لكل عقدة شرعية لشبكة CDN علامة مائية رقمية، تمامًا مثل شارات التعريف الصادرة عن الوكلاء.
لقد جربت هذا على عقدة 08Host: قم بإدخال مقتطف كود JS معين في تكوين CDN، ويؤكد الموقع المصدر الهوية من خلال اكتشاف هذه البصمة. على سبيل المثال، اطلب من عقدة CDN إضافتها تلقائيًا عند إرجاع استجابة:
عندما تتلقى المحطة المصدر الطلب، فإنها تستخدم نفس الخوارزمية للتحقق من التوقيع، وترفض الطلب إذا كان انحراف الطابع الزمني أكثر من 5 ثوانٍ. أكثر ما يثير السخرية في هذا المخطط هو أنه حتى لو حصل المهاجم على المفتاح، فإنه عديم الفائدة لأن الطابع الزمني ومعرف العقدة يتغيران ديناميكيًا. يمكن تضمين تطبيق محدد في OpenResty باستخدام نصوص Lua البرمجية:
والآن، دعنا نتحدث عن الأداء الزائد. يسمع الكثير من الناس “مصادقة التشفير” على الرأس، ويعتقدون أنها ستؤثر على الأداء. في الواقع، الاختبار الفعلي، زيادة تأخير التحقق من الطلب الواحد أقل من 2 مللي ثانية. وبالمقارنة مع تكلفة الشلل بسبب DDoS، فإن هذه النفقات العامة تكاد لا تذكر. ولكن انتبه إلى اختيار خوارزميات المفاتيح، لا تكن سخيفًا في استخدام RSA كسلاح ثقيل، فإن ECDSA أو HMAC-SHA256 كافية تمامًا.
مؤخرًا لمساعدة منصة مالية على إجراء اختبار الاختراق، وجدت هجومًا أكثر خبثًا: سيقوم المهاجم أولاً بالوصول الشرعي إلى عقدة CDN، والتقاط خصائص بصمة رأس الاستجابة، ثم محاولة إعادة تشغيل الهجوم. في هذا الوقت، لا يكفي الاعتماد فقط على التحقق من التوقيع الثابت، بل يجب إضافة آلية رقم عشوائي لمرة واحدة (Nonce). لقد رأيت في خلفية إدارة CDN07 أنه تم دعم أحدث إصدار من مولد Nonce الخاص بهم، حيث يتم تحديث القيمة الأولية تلقائيًا مرة كل 10 دقائق.
في الواقع، الحل الأكثر فعالية من حيث التكلفة هو استخدام SDK الخاص بالبائع مباشرةً. مثل وحدة المصادقة من CDN5 Edge Auth التي تغلف مجموعة كاملة من منطق المصادقة، تحتاج المحطة المصدرية فقط إلى ضبط واجهة برمجة التطبيقات للتحقق من المصادقة. ولكن لا تعتمد كلياً على حلول الصندوق الأسود - لقد رأيت ثغرة أمنية حيث تعرضت مجموعة SDK الخاصة بالمورّد لمفاتيح مشفرة بشكل ثابت. الآن أسلوبي هو استخدام المصادقة المختلطة: أستخدم SDK البائع للقيام بالتصفية الأولية، وأقوم أيضاً بتنفيذ مجموعة بديلة من منطق التحقق من التوقيع.
بالحديث عن تكوينات محددة، دعنا نعطي مثالاً على Nginx في العمل. يقوم التكوين التالي بتنفيذ الحماية الثلاثية لقائمة IP البيضاء والتحقق من الرمز المميز وتوقيع بصمة الإصبع في نفس الوقت:
أخيراً، بعض مزودي خدمة CDN الصغار من أجل توفير التكاليف، حتى عمليات التحقق الأمنية الأساسية كسولة جداً للقيام بها. في المرة الأخيرة التي اختبرت فيها شبكة CDN تدعى “الدفاع العالي الذكي”، وجدت أنهم في الواقع يضعون منطق التحقق على تنفيذ JS العميل - وهذا ليس واضحًا ليقولوا للمهاجم “بسرعة لتجاوزي؟ ” وهذه رسالة واضحة للمهاجمين. لذلك، عند اختيار نوع الفريق التقني يجب أن يكون برنامج حماية الاختبار الميداني، لا تنظر فقط إلى المسودة الترويجية التي تم تفجيرها في السماء.
يجب أن يكون نظام الحماية الموثوق به حقًا متعدد الطبقات وديناميكيًا. إن التحقق من مصدر بروتوكول الإنترنت هو مجرد الأساس، والبصمات هي الدعامة، ويجب أن يقترن بسلسلة من التدابير مثل تحليل سلوك حركة المرور (للكشف عن أنماط الطلبات غير الطبيعية) والحد من المعدل (لمنع هجمات CC). أنا الآن أنشر حلولاً لجميع العملاء، وسيتطلب الأمر مرة واحدة في الشهر على الأقل لإجراء اختبار تجاوز المحاكاة - هذا الشيء الأمني، لا يوجد برنامج لمرة واحدة فقط.
بصراحة، في السنوات الثلاث الماضية، تضاعف حجم هجمات تزوير بروتوكول الإنترنت أكثر من عشرة أضعاف. بدأت أدوات الهجوم في دمج بصمات شبكات CDN، ويمكن لأي أداة مفتوحة المصدر تحديد بائعي شبكات CDN تلقائيًا والتقاط خصائص العقدة. إذا كان الدفاع لا يزال عالقًا في “تكوين قائمة بيضاء على مستوى التفكير”، فإن الاختراق هو في الحقيقة مسألة وقت فقط.
أخيراً، أود أن أشارك درساً تعلمته من دموعي: لا تسرب أبداً تفاصيل التحقق من الصحة في سجل الأخطاء! لقد رأيت نظامًا يقوم بإرجاع “توقيع منتهي الصلاحية” و “رمز غير صالح” عند فشل التحقق، أليس هذا مثل تسليم سكين لمهاجم؟ النهج الصحيح هو إرجاع “404 غير موجود”، بحيث لا يستطيع المهاجم حتى لمس سبب الفشل.
إن الحماية من هجمات تزوير بروتوكول الإنترنت تشبه لعبة القط والفأر؛ فلا يوجد حل سحري. المفتاح هو إنشاء نظام دفاعي يتطور باستمرار، ففي نهاية المطاف، أساليب المهاجمين تتطور باستمرار أيضاً. على الأقل من خلال تجربتي القتالية، فإن الجمع بين الرمز الديناميكي ومخطط التوقيع المشفر لا يزال بإمكانه التصدي لهجوم التزوير 90% من المصدر.
