في الآونة الأخيرة، ساعدت محطة للتجارة الإلكترونية في الاستجابة لحالات الطوارئ، وواجهت أمرًا شريرًا - لم يتعطل الخادم، ولم يكن عرض النطاق الترددي ممتلئًا، ولكن الموقع كان عالقًا لدرجة أنني لم أستطع حتى تسجيل الدخول إلى الخلفية. بعد تحقيق استغرق نصف يوم، وجدت أن القراصنة هذه الأيام بدأوا في لعب "العمل البطيء": كل اتصال معك لطحن نصف ساعة، يمكن لآلاف المستخدمين المزيفين أن يشغلوا مجموعة الاتصال المتزامن، ولا يمكن ببساطة الضغط على المستخدمين الجادين.
يلتقط هذا الهجوم البطيء (Slowloris) نقاط ضعف جدران الحماية التقليدية. تركز WAFs العادية على ذروة حركة المرور وتكرار الطلب، ولكن هذا الهجوم يتنكر كل طلب على أنه حركة مرور مشروعة، مثل الماء الذي يتساقط من خلال الحجر مثل استنزاف مواردك ببطء. لقد اختبرت جدار الحماية السائد، والتكوين الافتراضي هو في الواقع عميل واحد مع هجوم POST بطيء يسحب الخادم الخلفي.
تعتمد قدرة شبكة CDN عالية الدفاع على منع هذا الأمر من عدمه على نقطتين رئيسيتين: ما إذا كان بإمكانها تحديد الطلب "الطاحن" بدقة، وما إذا كانت تجرؤ على أخذ زمام المبادرة لقطع الاتصالات غير الطبيعية. وبالمناسبة، فإن الحصة التالية من تكامل البرنامج الفعلي لشبكة CDN5، CDN07 اثنين من البائعين للمنطق الأساسي، بالمناسبة، يبصق بعض البائعين الهوى ولكن لا يستخدمون الوظيفة.
لنبدأ بإعداد مهلة الطلب. هذا ليس مجرد تعيين مهلة عامة في نهاية الأمر، بل يجب التحكم فيه على مستويات مختلفة. عملاء الواجهة الأمامية إلى عقد حافة شبكة CDN، وعقد الحافة إلى المحطة المصدر، يجب ضبط سياسة المهلة للرابطين بشكل منفصل. لا تصدق هؤلاء البائعين الذين يتفاخرون بـ "المهلة الذكية"، لقد قمتُ بمراجعة التكوين الافتراضي لـ CDN07، المهلة الافتراضية للواجهة الأمامية تم تخفيفها إلى 300 ثانية، إنها ببساطة باب خلفي للهجمات البطيئة.
هذه هي الطريقة الموصى بها لتقسيم التكوين (باستخدام Nginx كمثال):
انتبه بشكل خاص إلى معلمة Client_body_timeout - هجوم POST البطيء هو تمرير نص الطلب ببطء لاستهلاك الموارد. وجد الاختبار أن أكثر من 30 ثانية لم تنتهِ من نقل جسم الطلب، 99.9% هو اتصال ضار. هناك مشكلة يجب تذكيرها: بعض إعدادات مهلة وحدة التحكم في وحدة التحكم في موفري CDN مخفية في "التكوين المتقدم"، القيمة الافتراضية عالية جدًا، تذكر أن تخفضها يدويًا.
ومع ذلك، فإن مجرد الاعتماد على المهلة للاعتراض سيؤدي إلى الإضرار بتحميل الملفات الكبيرة العادية عن طريق الخطأ. في العام الماضي، عندما أجرينا العام الماضي اختبار اختراق لـ 08Host، وجدنا أنهم قاموا بتعيين المهلة بشكل قوي للغاية، مما تسبب في فشل المصمم في تحميل ملفات PSD طوال الوقت. في وقت لاحق، أضفنا سياسة مهلة ديناميكية: يتم تخفيف مسار /content/upload إلى 120 ثانية، بينما تحافظ المسارات الأخرى على 30 ثانية. هذه الخطوة CDN5 ذكية جدًا، حيث تدعم هذه الخطوة CDN5 دعم تعيين عتبات المهلة حسب مسار عنوان URL.
هناك لعبة أكثر تقدماً تتمثل في تحديد السلوك الشاذ. تكشف الهجمات البطيئة، أثناء محاكاة المستخدمين العاديين، عن ميزات في طبقة البروتوكول. على سبيل المثال، لن يقوم المستخدم العادي بإرسال بايت كل 30 ثانية فقط أو الاحتفاظ بـ 500 اتصال خامل بشكل مستمر. لقد نشرنا مجموعة من قواعد الكشف على CDN07، والمنطق الأساسي هو حساب "كفاءة الاتصال" لكل عنوان IP:
هذه المجموعة من القواعد دقيقة بشكل خاص في التقاط الهجمات البطيئة، ولكن عليك أن تكون حريصًا على التمييز بين برامج الزحف والمستخدمين الحقيقيين. فبعض برامج زحف محركات البحث ستتعمد إبطاء سرعة محركات البحث لتجنب إزعاج الموقع، وقد عانينا من فقدان الحظر عن طريق الخطأ - وأضفنا لاحقًا قائمة بيضاء، وهي قائمة Googlebot التي تم التحقق منها لتخفيف السياسة.
ما ينقذني حقًا هو وحدات الجدولة الذكية لـ CDN5. فهي لا تنظر فقط إلى المهلة، بل تجمعها أيضًا مع تحليل حالة مكدس TCP. على سبيل المثال، إذا كان هناك فجأةً عدد كبير من اتصالات TCP عالقة في حالة LAST_ACK، أو إذا استمر امتلاء قائمة انتظار SYN_RECV، فسيقوم النظام تلقائيًا بتشغيل وضع تنظيف الهجوم البطيء. تُقاس هذه الميزة لتقليل التدخل اليدوي 70%، هو الثمن الجميل قليلاً.
وجدت الاستجابة للطوارئ أيضًا عملية رديئة: سيستخدم بعض المهاجمين مجموعة هجمات HTTP البطيئة + هجمات CC منخفضة السرعة. أول من يحسب لتجمع الاتصال لا يترك، في نفس الوقت مع هجمات CC منخفضة السرعة لاستهلاك وحدة المعالجة المركزية، هذه المرة إلى آلية الدفاع عن الربط CDN07 جاء في اللعب - عندما الكشف عن الاتصالات البطيئة والطلبات منخفضة التردد من نفس شريحة IP، مباشرة أسود الجزء C بأكمله، بدلاً من قتل خطأ لا يدخر.
أخيرًا، اقتراح حقيقي: لا تتوقع الاعتماد على شبكة CDN وحدها لمنع جميع الهجمات البطيئة. على جانب العميل، قمنا بعمل ثلاث طبقات من الدفاع: طبقة حافة CDN لحظر المهلة، وطبقة WAF للتحليل السلوكي، و iptables لتقييد الاتصال المتزامن على الخادم المصدر. على وجه الخصوص، يمكن لضبط معلمات نواة Linux kernel أن يزيد من قدرة الخادم على مقاومة الهجمات البطيئة بمقدار ثلاثة أضعاف:
لا يمكن للهجمات البطيئة أن تمنع جوهر حرب استهلاك الموارد. في العام الماضي، اختبرنا العام الماضي قدرة ثلاثة بائعين لشبكات CDN على مقاومة السرعات البطيئة، وفازت CDN5 من خلال تجمعات الموارد المرنة - توسيع حد الاتصال تلقائيًا عند اكتشاف هجوم، وإطلاق الموارد بعد توقف الهجوم.08Host هو الأكثر واقعية، على الرغم من أن الوظيفة ليست خيالية للغاية، ولكن التكوين الافتراضي أكثر أمانًا من غيره، وهو مناسب للمواقع الصغيرة والمتوسطة الحجم التي لا تريد إحداث ضجة كبيرة.
لقد أصبح المخترقون أكثر تطوراً الآن، وهم يستخدمون بالفعل هجمات بطيئة موزعة - كل مخترق يفتح بعض الاتصالات البطيئة فقط، ولا يبدو مختلفاً عن المستخدم العادي. أخشى أننا سنضطر في المستقبل إلى استخدام التعلم الآلي لتحليل أنماط سلوك المستخدم. ولكن في هذه المرحلة، ومع ذلك، فإن الحصول على إعدادات المهلة واكتشاف الشذوذ بشكل صحيح قد تمكن من القضاء على الهجوم البطيء 90%. تذكر أن سياسة الأمان ليست معقدة كما هي، المفتاح هو القدرة على تنفيذها.
لتقييم حزمة CDN عالية الدفاع، نوصيك ببناء بيئتك الخاصة للاختبار: استخدم أداة slowhttptest لمحاكاة الهجوم، لمعرفة ما إذا كان تقرير وحدة التحكم يمكنه التنبيه بدقة، وسياسة التنظيف فعالة حقًا. لا تصدق ما تتباهى به المبيعات من "حماية بنسبة 100 في المائة"، لقد اختبرت حزمة دفاعية عالية رئيسية، ولم توقف القواعد الافتراضية حتى الهجوم البطيء الأساسي - في النهاية، عليك تعديل القواعد يدويًا.
أمن الويب هو عملية متكررة من الهجوم والدفاع. الاستراتيجية التي تعمل اليوم قد يتم تجاوزها غداً. إن الحفاظ على شفافية التكوين والتدرب بانتظام على الاستجابات الطارئة أكثر واقعية من تكديس المنتجات الأمنية. في نهاية المطاف، في هذه الأيام، حتى شبكة CDN يجب أن "تمنع زملاء الفريق" - بعض البائعين من أجل تقليل معدل الإيجابيات الخاطئة، وتخفيف سياسات الأمن عمدًا، تسوء الأمور بدلاً من إلقاء الوعاء على العميل الذي يسيء التهيئة.
