لماذا يغيّر الترشيح على الـ edge قواعد اللعبة
عندما يُجري خادم تطبيقك فحوص الأمان بنفسه، يظل كل طلب خبيث يصل إليه، ويستهلك وحدة المعالجة، ويفتح اتصالاً بقاعدة البيانات، وينافس المستخدمين الحقيقيين على الموارد. ينقل cdn.com.tr هذا الفحص إلى الـ edge، فتُرفض محاولات الحقن وتحقيقات الماسحات وحركة المرور غير المرغوبة بعيداً عن الـ origin ولا تمس شيفرتك أو قاعدة بياناتك أبداً. هذا هو الفرق بين خادم ينهار تحت هجوم وآخر لا يكاد يلاحظه، لأن الحمل المُسيء تمتصّه شبكة موزَّعة مبنية لتحمّله.
مجموعة قواعد WAF المُدارة
يفحص جدار حماية تطبيقات الويب طريقة الطلب ومساره وترويساته وجسمه مقابل قواعد تتعرّف على فئات الهجوم المعروفة: حقن SQL، والبرمجة عبر المواقع، وتضمين الملفات عن بُعد، واجتياز المسارات، وحقن الأوامر من بينها. تُصان هذه القواعد مركزياً فتستفيد من التحديثات دون تعديل إعداداتك الخاصة، وهو أمر بالغ الأهمية لمنصّات مثل WordPress وتطبيقات PHP القديمة حيث قد يكون التطبيق نفسه بطيئاً في تلقّي الترقيعات. يمكنك تفعيل الحماية لكل نطاق وإضافة قواعد السماح والرفض الخاصة بك فوقها للمسارات الخاصة بالتطبيق.
امتصاص طوفانات DDoS
يحاول هجوم حجب الخدمة الموزَّع استنزاف طاقتك بإرسال حركة مرور أكبر بكثير مما يمكن لـ origin واحد الإجابة عليه. ولأن cdn.com.tr يضع أمام نطاقك edge موزَّعاً، تُوزَّع الطوفانات الحجمية عبر الشبكة وتُرشَّح قبل أن تتركّز على خادمك، وتستمر الاستجابات المخزَّنة في التقديم من الـ edge حتى أثناء الهجوم. النتيجة العملية أن الـ origin يبقى قابلاً للوصول للزوار الشرعيين في اللحظات ذاتها التي يظلم فيها موقع غير محمي.
تحديد المعدّل والتخفيف من الروبوتات
ليس كل تهديد توقيعاً؛ بعضها ببساطة طلبات كثيرة جداً من عميل واحد. يتيح لك تحديد المعدّل وضع حدّ لعدد مرات وصول عنوان IP إلى النقاط الحسّاسة مثل نماذج تسجيل الدخول أو إعادة تعيين كلمات المرور أو مسارات الـ API المكلفة، ما يوقف حشو بيانات الاعتماد بالقوة الغاشمة والكشط العدواني دون حجب المستخدمين العاديين. مقروناً بقواعد الوصول حسب الدولة وعنوان IP، يمنحك هذا طريقة لإيقاف الأتمتة المُسيئة التي قد يفوّتها جدار قائم على التوقيعات وحده، وكل ذلك يُضبط لكل نطاق من اللوحة.
إخفاء الـ origin يزيل مسار الالتفاف
لا يعمل جدار الحماية على الـ edge إلا إذا تعذّر على المهاجمين الالتفاف حوله، والخطأ الكلاسيكي هو ترك خادم الـ origin قابلاً للوصول على عنوان IP الحقيقي. يشجّعك cdn.com.tr على إحكام إغلاق الـ origin بحيث يقبل الاتصالات من الـ edge فقط وإبقاء عنوانه خارج الـ DNS العام، ما يعني أن المسار الوحيد إلى تطبيقك يمرّ عبر طبقة الأمان. تحوّل حماية الـ origin هذه جدار الـ WAF من مطبّ سرعة اختياري إلى نقطة تفتيش إلزامية، كما تُقلّص سطح الهجوم المكشوف للماسحات المنتشرة عبر الإنترنت.
سياسة أمان واحدة عبر كل تطبيق تُشغّله
سواء نشرت موقع WordPress أو بوابة PHP قديمة أو API قائماً على الحاويات، ينطبق نفس نموذج أمان الـ edge بمجرد توجيه النطاق عبر cdn.com.tr. هذا يعني أنك لا تصون حزمة جدار حماية منفصلة لكل تطبيق؛ بل تربط النطاق، وتفعّل الـ WAF، وتضبط حدود المعدّل، فتحميه السياسة بشكل موحّد. بالنسبة للفرق التي تُشغّل عدة مواقع أو خدمات، هذا الاتساق هو ما يجعل الأمان قابلاً للإدارة بدلاً من تخبّط لكل مشروع.
كيفية الإعداد، خطوة بخطوة
وجّه النطاق عبر الـ edge
أضف اسم المضيف إلى حساب الـ CDN ووجّه الـ DNS الخاص به إلى edge لدى cdn.com.tr. من تلك اللحظة يدخل كل طلب للنطاق عُقدة edge أولاً، وهذا هو الشرط المسبق لتطبيق أي سياسة أمان، لأن جدار الحماية لا يفيد إلا إذا مرّت كل حركة المرور عبره فعلاً.
فعّل الـ WAF للنطاق
فعّل جدار حماية تطبيقات الويب في اللوحة لهذا النطاق. تبدأ مجموعة القواعد المُدارة فوراً بفحص الطلبات بحثاً عن توقيعات الهجوم الشائعة مثل حقن SQL، والبرمجة عبر المواقع، واجتياز المسارات، دون أي تغييرات على تطبيقك.
أخفِ الـ origin وأحكِم إغلاقه
بمجرد تدفّق حركة المرور عبر الـ edge، قيّد الـ origin بحيث يقبل الاتصالات من cdn.com.tr فقط وتوقّف عن نشر عنوان IP الحقيقي له في الـ DNS العام. هذا يُغلق الثغرة التي يهاجم فيها المهاجم الـ origin مباشرةً ويتخطّى الـ WAF كلياً.
أضف حدود المعدّل وقواعد الوصول
اضبط تحديد المعدّل على النقاط الحسّاسة مثل /wp-login.php و /xmlrpc.php أو مسار المصادقة في الـ API الخاص بك، وأضف قواعد سماح/رفض حسب الدولة أو عنوان IP عند الحاجة. هذا يوقف إساءة الاختراق بالقوة الغاشمة والكشط قبل أن تستهلك موارد التطبيق.
أكّد TLS وافرض HTTPS
مع تفعيل Auto SSL، فعّل إعادة التوجيه إلى HTTPS بحيث يُرقّى كل طلب إلى TLS على الـ edge. هذا يضمن أن حركة المرور التي تُفحَص وتُمرَّر إلى الـ origin مشفّرة من طرف إلى طرف بالنسبة للزوار.
راقِب ثم اضبط
راجع ما يحجبه الـ WAF، وتأكّد من عدم اصطياد حركة المرور المشروعة، واضبط القواعد أو الاستثناءات للإيجابيات الكاذبة النادرة. الأمان سياسة تُنقّحها مع الوقت، وليس مفتاحاً تضغطه مرة واحدة، واللوحة تمنحك الرؤية للقيام بذلك بأمان.
سيناريوهات مثالية
يفعّل موقع WordPress جدار الـ WAF ويحدّد معدّل /wp-login.php و /xmlrpc.php، فيقطع روبوتات القوة الغاشمة على الـ edge بحيث لا تمس حركة الهجوم عملية PHP أو قاعدة البيانات أبداً.
يُنشَر API بصيغة JSON قائم على الحاويات مع تفعيل الـ WAF وحدود معدّل لكل مسار، فتُرشَّح محاولات الكشط والحقن قبل أن تصل إلى الخدمة، بينما يُقيَّد الـ origin ليقبل اتصالات الـ edge فقط.
قبيل إطلاق عالي الظهور، يعتمد الموقع على امتصاص DDoS على الـ edge والتقديم المخزَّن مؤقتاً بحيث تُوزَّع أي طفرة مفاجئة، سواء كانت زواراً حقيقيين أو هجوماً، عبر الشبكة بدلاً من أن تُسقط الـ origin.
الأسئلة الشائعة
هل يجب أن أغيّر شيفرة تطبيقي لاستخدام الـ WAF؟
لا. يعمل جدار الحماية على الـ edge في مسار الطلب، فيفحص حركة المرور ويحجبها قبل أن تصل إلى تطبيقك. تفعّله لكل نطاق في اللوحة؛ وتبقى شيفرتك وإطار عملك وإعدادات خادمك كما هي تماماً.
ما أنواع الهجمات التي يوقفها الـ WAF فعلاً؟
تستهدف مجموعة القواعد المُدارة فئات هجوم الويب الشائعة بما فيها حقن SQL، والبرمجة عبر المواقع، واجتياز المسارات، وتضمين الملفات عن بُعد، وحقن الأوامر، إضافةً إلى الحجم المُسيء عبر تحديد المعدّل. وهي مصمّمة لالتقاط محاولات التحقيق والاستغلال الآلية التي تشكّل معظم حركة المرور المعادية على الويب.
هل يستطيع المهاجمون تجاوز الـ WAF بمهاجمة الـ origin مباشرةً؟
فقط إذا تركت الـ origin مكشوفاً. يُحكِم الإعداد المُوصى به إغلاق الـ origin ليقبل الاتصالات من edge لدى cdn.com.tr ويُبقي عنوان IP الحقيقي خارج الـ DNS العام، بحيث يمرّ المسار الوحيد إلى تطبيقك عبر طبقة الأمان وتُقطَع الهجمات المباشرة على الـ origin.
هل سيحجب الـ WAF الزوار الشرعيين خطأً؟
الإيجابيات الكاذبة ممكنة مع أي جدار حماية، ولهذا تتيح لك اللوحة رؤية ما يُحجب وإضافة استثناءات لمسارات أو عملاء محدّدين. النهج العملي هو تفعيل الحماية ومراقبة النتائج وضبط القواعد بحيث تتدفّق حركة المرور الحقيقية بينما تبقى الهجمات محجوبة.
كيف تختلف حماية DDoS عن الـ WAF؟
يحلّان مشكلتين مختلفتين. يفحص الـ WAF محتوى الطلبات الفردية بحثاً عن أنماط خبيثة، بينما تتعامل حماية DDoS مع الحجم الهائل بتوزيع الطوفانات وامتصاصها عبر الـ edge الموزَّع. غالباً ما يشمل الهجوم الجادّ كليهما، لذا تعمل الطبقتان معاً أمام الـ origin.
هل يُبطئ تفعيل الأمان موقعي؟
يجلس الـ edge أصلاً في مسار الطلب من أجل التخزين المؤقت، لذا فإن إضافة فحص الـ WAF هناك لا تُدخل قفزة منفصلة، وتظل الاستجابات المخزَّنة تُقدَّم بسرعة. عملياً، الطبقة نفسها التي تحميك تُسرّعك أيضاً، لأن حركة المرور المحجوبة والمخزَّنة لا تُثقل الـ origin أبداً.