كيفية استخدام وضع "تحت الهجوم" من Cloudflare لموقع تعرض لهجوم DDoS؟

وضع "تحت الهجوم" من Cloudflare لموقع يتعرض لهجوم DDoS هو إعداد دفاعي طارئ يقوم بتصفية حركة المرور الروبوتية عن طريق عرض تحقق أمني قصير للزوار. من خلال اختيار موقعك في لوحة تحكم Cloudflare وتفعيل خاصية وضع "تحت الهجوم" من قسم الأمن، يمكنك تقليل الطلبات الكثيفة على مستوى HTTP/HTTPS خلال دقائق، وحماية وصول المستخدمين الحقيقيين إلى الموقع، وتقليل الحمل على الخادم الخاص بك. ومع ذلك، فإن هذا الوضع ليس حلاً دائماً بمفرده؛ بل يجب استخدامه مع إعدادات DNS الصحيحة، وقواعد WAF، وتحديد معدل الطلبات، وتكوين التخزين المؤقت، وأمان الخادم الأصلي.

في هذا الدليل، سنتناول خطوة بخطوة كيفية تفعيل وضع "تحت الهجوم" من Cloudflare، ومتى يجب استخدامه، وما هي الإعدادات الداعمة له، وكيفية العودة إلى الوضع الآمن بعد انتهاء الهجوم. الهدف هو تقديم قائمة مرجعية قابلة للتطبيق في لحظات الذعر واستعادة إمكانية الوصول إلى موقعك في أقرب وقت ممكن.

ما هو وضع "تحت الهجوم" من Cloudflare؟

وضع "تحت الهجوم" من Cloudflare هو مستوى أمان طارئ تقدمه Cloudflare. عند تفعيله، يقوم Cloudflare بتمرير زوار الموقع عبر تحقق قصير من متصفحهم. عادة ما يستغرق هذا التحقق بضع ثوانٍ، مما يجعل من الصعب على الروبوتات، أو أدوات الفيضانات البسيطة، أو العملاء الخبيثين تحميل الموقع مباشرة.

الغرض الأساسي من هذا الوضع هو تخفيف الهجمات على مستوى تطبيقات الويب، أي على مستوى Layer 7. على سبيل المثال، إذا كانت الصفحة الرئيسية تتلقى آلاف طلبات GET في الثانية، أو كانت هناك محاولات تسجيل دخول كثيفة على صفحة تسجيل الدخول في WordPress، أو كانت الاستعلامات المكلفة ترسل إلى صفحة البحث، أو كانت حركة المرور الوهمية تتدفق إلى صفحة السلة، فإن وضع "تحت الهجوم" يوفر تدخلاً أولياً سريعًا.

هنا، النقطة الجوهرية هي أن وضع "تحت الهجوم" يقوم بتصفية طلبات الويب؛ ولكن إذا كان عنوان IP الخاص بالخادم الخاص بك مستهدفًا مباشرة، أو إذا كانت خدماتك خارج Cloudflare عرضة للخطر، أو إذا كانت الهجمة تتم على مستوى Layer 3/4، فإن تدابير إضافية ستكون ضرورية. لذلك، من الضروري أن تكون سجلات DNS موجهة عبر Cloudflare، وأن يتم إخفاء عنوان IP الأصلي، وأن يتم تطبيق تدابير الأمان الصحيحة على جانب الاستضافة. يمكن ربط محتويات خدمات استضافة الويب الآمنة وتثبيت شهادة SSL في هذا السياق.

أعراض هجوم DDoS: ماذا يجب فحصه قبل الانتقال إلى وضع "تحت الهجوم"؟

ليس كل بطء في الأداء يعني وجود هجوم DDoS. أحيانًا يمكن أن يتسبب مكون إضافي معطل، أو تجميد قاعدة البيانات، أو مهمة cron تستهلك CPU بشكل مرتفع، أو إعداد تخزين مؤقت غير صحيح في نتائج مشابهة. لذلك، من المفيد إجراء تشخيص سريع قبل تفعيل وضع "تحت الهجوم". ومع ذلك، إذا كان الخادم يواجه صعوبة في الاستجابة، وكان المستخدمون يتلقون أخطاء 502، 503، 504، وكانت هناك انفجارات غير عادية في الطلبات في السجلات، فلا ينبغي تأخير التفعيل.

مؤشرات DDoS النموذجية

• زيادة حركة المرور بشكل غير طبيعي بمقدار 5، 10، أو 50 مرة في فترة زمنية قصيرة.
• تلقي مئات الطلبات في الثانية لصفحة واحدة أو نقطة نهاية واحدة.
• تدفق حركة المرور من دول مختلفة ولكن بقيم user-agent مشابهة.
• استهداف عناوين URL المكلفة مثل admin، login، search، cart في WordPress، WooCommerce، OpenCart أو تطبيقات مخصصة.
• امتلاء حدود CPU، RAM، PHP-FPM worker أو اتصالات MySQL على الخادم.
• ارتفاع مفاجئ في أخطاء 4xx و5xx على شاشة تحليلات Cloudflare.
• قدرة المستخدمين الحقيقيين على الوصول إلى الموقع بشكل متقطع، ولكن حركة المرور الروبوتية ترسل طلبات باستمرار.

على سبيل المثال، إذا كان موقع التجارة الإلكترونية يتلقى عادةً 2000 طلب في الدقيقة، وارتفعت الطلبات إلى 80000 طلب في الدقيقة خلال 10 دقائق، وكان 70% من الطلبات تتجه إلى صفحة السلة أو البحث، فإن هذا يعد علامة واضحة على هجوم Layer 7. في هذه الحالة، يجب تفعيل وضع "تحت الهجوم" في أول 5 دقائق، ثم إضافة قواعد WAF وتحديد معدل الطلبات مخصصة للنقاط المستهدفة.

متى يجب استخدام وضع "تحت الهجوم" من Cloudflare؟

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

الحالات المناسبة للاستخدام

• إذا كانت هناك طلبات HTTP/HTTPS كثيفة وغير طبيعية تتجه إلى الموقع.
• إذا كانت موارد الخادم تنفد بسرعة وزادت أخطاء 502/503.
• إذا لم يتم تكوين WAF من Cloudflare بعد بقواعد خاصة، وكنت بحاجة إلى درع سريع.
• إذا كانت حركة المرور الروبوتية تتجاوز بشكل واضح حركة مرور المستخدمين الحقيقيين.
• إذا كانت صفحات الويب، النماذج، واجهات تسجيل الدخول، أو نقاط النهاية للبحث هي أهداف الهجوم.

الحالات التي يجب استخدامها بحذر

• إذا كنت تستخدم تطبيقات موبايل، أو موفرات الدفع، أو webhook، أو حركة مرور API بكثافة.
• إذا كنت في فترة حاسمة حيث تقوم محركات البحث بالزحف بشكل مكثف.
• إذا كان العملاء المؤسسيون يصلون من متصفحات قديمة أو بيئات شبكية محدودة.
• إذا كان لديك نطاقات فرعية لا تمر عبر Cloudflare.

في المواقع التي تحتوي على حركة مرور API، قد يؤدي تطبيق وضع "تحت الهجوم" على نطاق كامل إلى فشل بعض التكاملات. لذلك، إذا أمكن، يجب التخطيط لقواعد WAF خاصة لنطاقات API، أو قائمة السماح، أو مستويات أمان مختلفة. يمكن الإشارة إلى دليل أمان API وتحديد المعدل كمرجع شامل.

كيفية تفعيل وضع "تحت الهجوم" من Cloudflare؟ تطبيق خطوة بخطوة

الخطوات التالية هي قائمة مرجعية عملية تم إعدادها للتحرك بسرعة أثناء الهجوم. قد تتغير واجهة Cloudflare قليلاً بمرور الوقت، لكن المنطق يظل كما هو: اختر اسم النطاق الخاص بك، وزد مستوى الأمان، ومرر حركة المرور الواردة من خلال Cloudflare للتحقق.

1. تسجيل الدخول إلى حساب Cloudflare الخاص بك

أولاً، قم بتسجيل الدخول إلى حساب Cloudflare الخاص بك واختر اسم النطاق المعرض للهجوم. إذا كنت تدير عدة أسماء نطاقات، فتأكد من أنك تعمل على المنطقة الصحيحة. فتح وضع "تحت الهجوم" عن طريق الخطأ على اسم نطاق خاطئ قد يضيع الوقت ويستمر الهجوم الفعلي.

2. تحقق من أن سجلات DNS موجهة

لكي يكون وضع "تحت الهجوم" فعالاً، يجب أن تمر حركة المرور عبر Cloudflare. تأكد من أن سجلات A وAAAA وCNAME في قسم DNS هي في حالة السحابة البرتقالية، أي موجهة. سجلات DNS فقط في حالة السحابة الرمادية لا تمر عبر طبقة الأمان من Cloudflare. يجب التحقق بشكل خاص من www، واسم النطاق الجذري، والنطاقات الفرعية المستخدمة.

إذا كان عنوان IP الأصلي الخاص بك مرئيًا على الإنترنت، يمكن للمهاجمين تجاوز Cloudflare والاعتداء على الخادم مباشرة. لذلك، فإن السماح فقط بحركة HTTP/HTTPS القادمة من نطاقات IP الخاصة بـ Cloudflare في جدار الحماية الخاص بالخادم هو إجراء إضافي قوي. يمكنك تلقي الدعم من مزود الاستضافة الخاص بك في هذا الشأن أو توجيهك إلى كيفية إعداد DNS في Cloudflare كمرجع.

3. تفعيل وضع "تحت الهجوم" من قسم الأمن

بعد فتح اسم النطاق المعني في لوحة تحكم Cloudflare، ابحث عن خيار وضع "تحت الهجوم" في شاشة الأمن أو النظرة العامة. عند تفعيل هذا الخيار، سيبدأ Cloudflare في عرض صفحة تحقق قصيرة للزوار القادمين إلى الموقع. في بعض اللوحات، قد يظهر هذا الإعداد تحت مستوى الأمان "أنا تحت الهجوم".

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

4. اختبار تجربة المستخدم الحقيقية

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

5. تحديد عناوين URL المستهدفة للهجوم

يوفر وضع "تحت الهجوم" درعًا عامًا؛ ولكن الفعالية الحقيقية تتحقق من خلال القواعد الخاصة بالأهداف. ابحث عن المسارات الأكثر طلبًا من أحداث أمان Cloudflare، وتحليلات الويب، وسجلات وصول الاستضافة، وسجلات التطبيق. على سبيل المثال، قد تكون عناوين URL مثل /wp-login.php، /xmlrpc.php، /search، /cart، /api/login، أو /checkout تحت الهجوم.

بمجرد تحديد عنوان URL المستهدف، يمكن اتخاذ إجراءات باستخدام قواعد WAF المخصصة استنادًا إلى البلد، وuser-agent، وطريقة الطلب، ومسار URI، أو درجة الروبوت. على سبيل المثال، يمكن تطبيق تحدي مُدار على عناوين IP التي ترسل عددًا كبيرًا من الطلبات إلى نقطة تسجيل دخول معينة في الدقيقة. يمكن أن يكون الربط بمحتوى إجراءات أمان WordPress فرصة جيدة للربط الداخلي.

الفروقات بين وضع "تحت الهجوم" وخيارات أمان Cloudflare الأخرى

تخدم أدوات أمان Cloudflare أغراضًا مختلفة. يوفر وضع "تحت الهجوم" فلترًا طارئًا سريعًا وعامًا؛ بينما توفر قواعد WAF وتحديد معدل الطلبات حلولًا أكثر استهدافًا واستدامة وتوازنًا من حيث تجربة المستخدم.

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

إعدادات Cloudflare الإضافية الموصى بها أثناء الهجوم

على الرغم من أن وضع "تحت الهجوم" يمكن تفعيله بضغطة زر، فإن نجاح الدفاع ضد DDoS يعتمد على الإعدادات الداعمة. فيما يلي الاقتراحات الأكثر فعالية التي تُستخدم في العمليات الحقيقية.

إنشاء حماية مستهدفة باستخدام قواعد WAF

تتيح لك WAF من Cloudflare اتخاذ إجراءات بناءً على شروط معينة. على سبيل المثال، يمكنك تطبيق تحديات على طلبات POST التي تأتي فقط إلى صفحة /wp-login.php من دول معينة. ومن ثم، يمكنك عزل الهدف من الهجوم دون إبطاء الموقع بالكامل.

• افتح صفحات admin وlogin فقط لدول معينة أو نطاقات IP معينة.
• قم بحظر نقاط النهاية غير المستخدمة مثل XML-RPC.
• طبق تحديات مُدارة على قيم user-agent المشبوهة.
• حد من الطلبات المتكررة على مسار URI معين باستخدام تحديد معدل الطلبات.

ضبط مستوى التخزين المؤقت بشكل صحيح

إذا كان يجب على الخادم الأصلي الاستجابة لكل طلب أثناء هجوم DDoS، فإن الموارد ستنفد بسرعة. يجب تقديم الملفات الثابتة، والصور، وCSS، وJavaScript، وصفحات التخزين المؤقت من خلال Cloudflare edge. في تطبيقات ديناميكية مثل WordPress، يمكن استخدام مكون إضافي للتخزين المؤقت، وقواعد التخزين المؤقت من Cloudflare، وHTTP headers المناسبة.

على سبيل المثال، يمكن تخزين الصفحات المعروضة للزوار المجهولين في موقع يركز على الأخبار أو المدونات لمدة تتراوح بين 5 إلى 30 دقيقة. هذا الإعداد البسيط يقلل من قيم TTFB حتى في فترات عدم الهجوم، ويخفف من موارد الاستضافة. يمكن تقييم جانب الأداء من خلال الربط بمحتوى دليل تسريع الموقع.

حدد عتبات تحديد معدل الطلبات بشكل واقعي

تحديد معدل الطلبات يكون فعالاً بشكل خاص في نقاط النهاية المكلفة. ومع ذلك، إذا تم تحديد العتبات بشكل عشوائي، يمكن أن يتم حظر المستخدمين الحقيقيين. على سبيل المثال، قد يقوم مستخدم عادي بإجراء 5-15 بحثًا في الدقيقة على صفحة بحث منتج؛ في حين أن 100 بحث في الدقيقة يعتبر غير طبيعي. في صفحة تسجيل الدخول، يُعتبر 10 محاولات فاشلة خلال 5 دقائق مشبوهة في معظم السيناريوهات.

نهج نموذجي: يمكن تطبيق تحدٍ مُدار على عناوين IP التي ترسل أكثر من 10 طلبات في الدقيقة إلى /wp-login.php، بينما يمكن تطبيق حظر مؤقت على عناوين IP التي ترسل أكثر من 50 طلبًا في 5 دقائق. في نقاط النهاية الخاصة بـ API، يجب تفضيل حدود أكثر دقة بناءً على جلسة المستخدم، وعنوان IP، والتوكن، والطريقة.

إخفاء عنوان IP الأصلي وتقييد الوصول من خلال جدار الحماية

إحدى الأخطاء الأكثر خطورة التي تحدث عند استخدام Cloudflare هي ترك عنوان IP الأصلي مكشوفاً. يمكن أن تؤدي سجلات DNS القديمة، أو نطاقات فرعية تعمل مباشرةً عبر IP، أو خدمات الويب التي تتداخل مع سجلات البريد، أو التكوينات التي تم تسريبها إلى تمكين المهاجمين من الوصول إلى الخادم من خارج Cloudflare.

يوفر فتح المنافذ 80 و443 فقط لنطاقات IP الخاصة بـ Cloudflare حماية قوية. بالإضافة إلى ذلك، يجب عدم ترك منافذ SSH، أو لوحة التحكم، أو قاعدة البيانات، أو إدارة الخادم متاحة على الإنترنت؛ بل يجب استخدام قيود IP، وكلمات مرور قوية، والتحقق بخطوتين، وإذا أمكن، استخدام VPN. يمكن ربط محتويات إعدادات أمان cPanel وتكوين جدار حماية VPS لأمان الاستضافة.

نقاط يجب الانتباه إليها في مواقع WordPress وWooCommerce والمواقع المؤسسية

ليس لكل موقع هيكل حركة مرور متشابه. يمكن أن يؤدي استخدام وضع "تحت الهجوم" في موقع مدونة، أو متجر WooCommerce، أو لوحة SaaS إلى نتائج مختلفة. لذا، يجب تحديد المسارات الحرجة وفقًا لنوع الموقع.

مواقع WordPress

الملفات الأكثر استهدافًا في WordPress هي الطرق /wp-login.php و/xmlrpc.php. إذا لم تكن تستخدم XML-RPC، فإن حظره يعد عادةً خيارًا آمنًا. يمكن تطبيق قيود على لوحة الإدارة وفقًا للبلد أو نطاق IP. بالإضافة إلى ذلك، يجب التأكد من عدم وجود تضارب بين مكونات الأمان وقواعد Cloudflare؛ حيث يمكن أن يؤدي وجود الكثير من آليات التحدي في نفس الوقت إلى إدخال المستخدم في دورة تحقق.

متاجر WooCommerce

تتطلب صفحات السلة، والدفع، والحساب في WooCommerce اهتمامًا خاصًا. نظرًا لأن هذه الصفحات ديناميكية، يجب تجنب تطبيق تخزين مؤقت عدواني. أثناء تفعيل وضع "تحت الهجوم"، يجب التأكد من أن عناوين URL الخاصة بمزود الدفع تعمل بشكل صحيح. إذا لزم الأمر، يجب إدراج نطاقات IP الخاصة بمزود الدفع في قائمة السماح أو كتابة قاعدة خاصة لذلك.

المواقع المؤسسية والمواقع التي تستخدم API

قد لا تتمكن البوابات المؤسسية، وتكاملات CRM، وواجهات برمجة التطبيقات لتطبيقات الهواتف المحمولة من معالجة شاشة التحقق من JavaScript. في مثل هذه الهياكل، قد يكون من الأفضل إدارة نطاق API بشكل منفصل بدلاً من تطبيق وضع "تحت الهجوم" على النطاق الكامل. على سبيل المثال، يمكن تفعيل وضع "تحت الهجوم" لـ www.example.com، بينما يتم تطبيق أمان قائم على التوكن، وتحديد معدل الطلبات، وقائمة السماح لـ api.example.com.

المؤشرات التي يجب مراقبتها بعد تفعيل وضع "تحت الهجوم"

لفهم ما إذا كانت تدابير الأمان فعالة أم لا، يلزم المراقبة الرقمية. ليس كافياً أن يكون الموقع متاحًا فقط؛ يجب تقييم نسبة الأخطاء، وحمل الخادم، وسلوك المستخدم الحقيقي معًا.

• أحداث أمان Cloudflare: تظهر عدد الطلبات التي تم تحديها أو حظرها بواسطة أي قواعد.
• رموز حالة HTTP: يجب مراقبة التغييرات في الأخطاء 403، 429، 502، 503، و504.
• استخدام CPU وRAM على الخادم: يُتوقع أن ينخفض بعد تفعيل وضع "تحت الهجوم".
• اتصالات PHP-FPM وMySQL: تظهر الاسترخاء في مستوى تطبيق الويب.
• عرض النطاق الترددي وعدد الطلبات: يجب مقارنة حجم المرور مع نسبة الطلبات المصفاة.
• تحويلات المستخدمين الحقيقيين: يجب اختبار إرسال النماذج، والطلبات، وتسجيل الدخول، وخطوات الدفع.

على سبيل المثال، إذا كانت إجمالي الطلبات هي نفسها بعد تفعيل وضع "تحت الهجوم"، ولكن الطلبات التي تصل إلى الخادم الأصلي انخفضت بنسبة 60%، فهذا يعني أن طبقة Cloudflare تمتص جزءًا كبيرًا من الحمل. ومع ذلك، إذا ظل استخدام CPU لـ MySQL مرتفعًا، فقد يعني ذلك أن الهجوم يثير استعلامًا ديناميكيًا معينًا؛ في هذه الحالة، يجب فحص سجلات التطبيق.

كيفية إيقاف تشغيل وضع "تحت الهجوم" بعد انتهاء الهجوم؟

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

خطوات العودة الآمنة إلى الوضع الطبيعي

• انتظر لمدة 30-60 دقيقة على الأقل حتى تعود مستويات الحركة إلى طبيعتها.
• تحقق من شاشة أحداث أمان Cloudflare للتأكد من انخفاض أعداد التحديات والحظر.
• تأكد من أن قواعد WAF المستهدفة وتحديد معدل الطلبات فعالة قبل إيقاف وضع "تحت الهجوم".
• اسحب مستوى الأمان إلى مستوى أكثر توازنًا مثل High أو Medium.
• اختبر الموقع من أجهزة مختلفة وراقب معدل الأخطاء 5xx.
• راقب السجلات لمدة 24 ساعة للتحقق مما إذا كانت الهجمات قد بدأت مرة أخرى.

كأفضل ممارسة، يجب إعداد تقرير حدث بعد الهجوم. يجب أن يتضمن هذا التقرير وقت بدء الهجوم، وعناوين URL المستهدفة، وأعلى عدد من الطلبات، والإجراءات المتخذة، والقواعد التي أثبتت فعاليتها، والتحسينات الدائمة. ستساعد هذه الوثيقة في تقليل وقت الاستجابة في الحدث التالي بشكل كبير.

الأخطاء الشائعة وما يجب تجنبه

يجب اتخاذ قرارات سريعة أثناء هجوم DDoS؛ ومع ذلك، يمكن أن تؤدي الإعدادات الخاطئة إلى حظر المستخدمين الحقيقيين أيضًا. تظهر الأخطاء التالية بشكل خاص تحت ضغط شديد.

• الاعتقاد بأن وضع "تحت الهجوم" سيوفر الحماية دون توجيه سجلات DNS.
• ترك عنوان IP الأصلي مكشوفًا وعدم إغلاق الوصول من خلال جدار الحماية لغير نطاقات IP الخاصة بـ Cloudflare.
• تطبيق تحديات على جميع النطاقات دون اختبار عناوين API، أو webhook، أو عناوين رد الاتصال للدفع.
• كتابة قواعد حظر WAF واسعة جدًا مما يؤدي إلى حظر العملاء الحقيقيين.
• تخزين صفحات السلة، والدفع، أو لوحة المستخدم بشكل عدواني، بينما لا ينبغي تخزينها.
• ترك وضع "تحت الهجوم" مفعلًا لأسابيع بعد انتهاء الهجوم.
• اتخاذ قرارات بناءً على شاشة Cloudflare فقط دون فحص سجلات الخادم.

يمكن أن يؤدي حظر ردود الاتصال للدفع في مواقع التجارة الإلكترونية إلى فقدان كبير في الإيرادات. لذلك، عند كتابة قواعد الأمان، يُفضل اختبار الإجراءات مثل تسجيل الدخول أو التحدي المُدار قبل تطبيق الحظر. بعد رؤية تأثير القاعدة، يمكن الانتقال إلى إجراءات أكثر صرامة.

كيف يمكن تخطيط دفاع أكثر مقاومة في بنية Hostragons؟

يوفر Cloudflare طبقة أمامية قوية؛ لكن الدفاع الناجح ضد DDoS لا ينتهي عند CDN فقط. يجب التفكير في بنية الاستضافة، وتحسين البرمجيات، وتكوين SSL، وإدارة DNS، واستراتيجية النسخ الاحتياطي بشكل متكامل. يجب أن تكون المقاربة الأساسية لموقع مستضاف على Hostragons كالتالي: يقوم Cloudflare بتصفية الحركة، وتتعامل طبقة الاستضافة فقط مع الحركة النظيفة، ويتم تحسين التطبيق بحيث لا ينتج حملاً غير ضروري على قاعدة البيانات.

قبل إطلاق مشروع جديد، من المهم إدارة اسم النطاق بسجلات DNS الصحيحة، وتثبيت شهادة SSL بدون مشاكل، واختيار موارد خادم الويب المناسبة لملف حركة المرور الخاص بك. في هذه النقطة، يمكن أن تساعد الروابط مثل استعلام عن النطاق وتسجيل اسم المجال، وحزم استضافة الويب، وحلول الاستضافة المؤسسية، وشهادة SSL مجانية المستخدمين.

في المشاريع ذات الحركات العالية أو ذات خطر الهجوم العالي، يمكن التفكير في خيارات VPS أو خوادم مُدارة بدلاً من الاستضافة المشتركة القياسية. هذا يسمح بتكوين جدار الحماية، وخادم الويب، وPHP-FPM، وRedis، وتخزين الكائنات، وإعدادات قاعدة البيانات بشكل أكثر مرونة. ومع ذلك، أيًا كانت البنية التي يتم اختيارها، يجب أن يتم وضع وضع "تحت الهجوم" من Cloudflare كأداة طارئة فقط؛ ويجب دعم العمارة الأمنية الدائمة بقواعد WAF، وتحليل السجلات، والتحديثات المنتظمة.

قائمة مراجعة سريعة: أول 15 دقيقة أثناء هجوم DDoS

الوقت حاسم أثناء الهجوم. تلخص القائمة التالية ما يمكن أن يفعله الفريق الفني أو مالك الموقع في أول 15 دقيقة.

• قم بتسجيل الدخول إلى لوحة Cloudflare واختر اسم النطاق الصحيح.
• تحقق من أن سجلات DNS هي في حالة السحابة البرتقالية، أي موجهة.
• قم بتفعيل وضع "تحت الهجوم".
• اختبر الصفحة الرئيسية، وتسجيل الدخول، والسلة، والدفع، ونقاط النهاية الخاصة بـ API.
• حدد عناوين URL المستهدفة من شاشة أحداث أمان Cloudflare.
• أضف قاعدة WAF أو تحديد معدل الطلبات مخصصة للمسارات الأكثر تعرضًا للهجوم.
• تحقق من حالة CPU وRAM وPHP-FPM وMySQL على الخادم.
• اختبر ما إذا كان هناك وصول مباشر إلى IP الأصلي.
• تحقق مما إذا كانت هناك حاجة لقائمة السماح لمزودي الدفع، وwebhooks، والتكاملات الحيوية.
• قم بتدوين جميع الإجراءات مع توقيتات.

إذا تم ممارسة هذه القائمة بانتظام، ستقلل من الذعر أثناء هجوم حقيقي، وستزيد من جودة التدخل. يُنصح بتوثيق هذه العملية كخطة استجابة للحدث في المواقع الكبيرة.

أسئلة متكررة

هل يوفر وضع "تحت الهجوم" حماية كاملة للموقع؟

لا. يوفر وضع "تحت الهجوم" من Cloudflare حماية فعالة ضد حركة المرور الروبوتية وهجمات الفيضانات على مستوى HTTP/HTTPS؛ لكنه لا يوفر حماية كاملة بمفرده. يجب استخدامه مع سجلات DNS الموجهة، وإخفاء IP الأصلي، وقواعد WAF، وتحديد معدل الطلبات، وإعدادات التخزين المؤقت، وجدار الحماية على الخادم.

هل يؤثر وضع "تحت الهجوم" سلبًا على SEO؟

الاستخدام القصير الأمد عادة لا يسبب ضررًا كبيرًا لـ SEO. ومع ذلك، إذا تم ترك الوضع مفعلًا لفترة طويلة، فقد يؤثر ذلك على فعالية الزحف من محركات البحث وتجربة المستخدم. لذلك، من الأفضل إيقاف الوضع بعد الهجوم والاستمرار بقواعد أمان مستهدفة.

إلى متى يجب ترك وضع "تحت الهجوم" مفعلًا؟

يمكن تركه مفعلًا حتى تتراجع شدة الهجوم؛ في الممارسة العملية، يُنصح بمراقبة الوضع لمدة 30-60 دقيقة على الأقل بعد عودة حركة المرور إلى طبيعتها، ثم إيقاف تشغيله تدريجيًا. يجب أن تكون قواعد WAF وتحديد معدل الطلبات جاهزة قبل إيقاف الوضع.

هل يؤثر وضع "تحت الهجوم" على API أو أنظمة الدفع؟

نعم، يمكن أن يؤثر. لأن بعض عملاء API، وخدمات webhook، وأنظمة رد الاتصال للدفع قد لا تتمكن من إكمال التحقق المستند إلى المتصفح. لذلك، يجب اختبار نقاط النهاية الحرجة، وإذا لزم الأمر، يجب تحديد قواعد Cloudflare خاصة أو قائمة السماح.

هل يجب اتخاذ تدابير إضافية على جانب الاستضافة أثناء استخدام Cloudflare؟

نعم. يوفر Cloudflare حماية قوية على الطبقة الأمامية؛ لكن يجب إخفاء عنوان IP الخاص بالخادم الأصلي، ويجب أن يسمح جدار الحماية فقط بحركة المرور الضرورية، ويجب تحديث البرمجيات، وتكوين التخزين المؤقت بشكل صحيح. إن بنية الاستضافة الآمنة هي جزء مهم من مقاومة DDoS.

الخاتمة

وضع "تحت الهجوم" من Cloudflare هو أداة طوارئ فعالة تمنح موقعًا يتعرض لهجوم DDoS فرصة للتنفس بسرعة. عند تفعيله بإعدادات DNS الصحيحة، يقلل من حركة المرور الروبوتية، ويقلل من الحمل على الخادم، ويزيد من فرصة وصول المستخدمين الحقيقيين إلى الموقع. لتحقيق أفضل النتائج، يجب دعم هذا الوضع بقواعد WAF، وتحديد معدل الطلبات، وتحسين التخزين المؤقت، وأمان جدار الحماية الأصلي.

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