Defaults.Exposed › الإصلاحات › CDN / WAF والاستضافة

كيف تُصلح CDN / WAF والاستضافة

قراءتان للسباكة خلف موقعك: ما إذا كنت تجلس خلف درع واقٍ (CDN مع جدار حماية تطبيقات الويب، مثل Cloudflare) يُرشِّح الهجمات ويمتصّ ذُرى الحركة، وخريطة لمن يدير فعلاً DNS وموقعك وبريدك. كلاهما للعلم في تقييمنا — لا يحرّكان درجتك — لكنهما يصفان مدى تعرّض خادمك الأصلي للهجوم والانقطاع، ومدى تشابك مزوّديك. درع في المقدمة ومجموعة مزوّدين مقسّمة بحكمة هو ما تبدو عليه الأنشطة التجارية المتينة.

الخلاصة لعملك: موقع بلا درع في مقدمته يتلقّى كل هجوم وكل ذروة حركة مباشرة على الخادم الأصلي — فطوفان بوتات، أو اندفاعة يوم الإطلاق، أو هجوم آلي واحد قد يُخرِجك من الخدمة لساعات، والتعافي عليك أنت. ووضع CDN/WAF في المقدمة (تتوفّر طبقة مجانية) يُرشِّح الغالبية العظمى من الهجمات الآلية، ويمتصّ الاندفاعات، ويُسرِّع الموقع عالمياً — عادة عمل ظهيرة للشخص التقني لديك، بلا تكلفة ترخيص. وبشكل منفصل، إذا عاش DNS وموقعك وبريدك جميعاً لدى مزوّد واحد، فإن انقطاعاً أو اختراقاً واحداً هناك يُسقِط وجودك على الإنترنت كله دفعة واحدة؛ ومعرفة خريطة مزوّدك أول ما تحتاجه في حادث. لا فحص منهما يغيّر درجتك — لكن كليهما يصف تعرّضاً حقيقياً للانقطاع والمبيعات الضائعة والتعافي البطيء المؤلم.

ماذا قد يكلّفك هذا

• اندفاعة من حركة بوتات أو DDoS صغير يضرب خادمك غير المدرَّع صباح ترويج كبير — فيزحف الموقع أو ينهار، ويحصل العملاء على أخطاء عند الدفع، وتخسر مبيعات اليوم بينما يهرع مضيفك. ودرع CDN/WAF في المقدمة كان سيمتصّه.
• يعمل DNS وموقعك وبريدك جميعاً عبر مزوّد واحد؛ يمرّ ذلك المزوّد بانقطاع فيُعتِم موقعك ونظام حجوزاتك وبريدك في اللحظة نفسها — ولا تستطيع حتى إرسال 'نحن على علم بالمشكلة' لأن صندوق البريد معطّل أيضاً.
• يفحص هجوم آلي موقعك طوال الليل — سكربتات حقن SQL وتخمين تسجيل الدخول تطرق خادمك الأصلي مباشرة لأنه لا توجد طبقة جدار حماية لترشيحها — ولا تكتشف إلا حين يتعطّل شيء. وWAF يحجب جزءاً كبيراً من تلك الضوضاء قبل أن تصل إلى شيفرتك أصلاً.
• يضرب حادث ولا يستطيع أحد الإجابة عن السؤال الأساسي 'بمن نتصل أصلاً؟' — هل الموقع على المضيف نفسه كالبريد؟ من يدير DNS؟ تنزف الساعات في مجرّد رسم خريطة السباكة بينما يبقى الموقع معطّلاً.
• يمسحك فريق تقني لمشترٍ محتمل قبل التوقيع فيرى خادماً أصلياً عارياً بلا CDN/WAF وترويسة إصدار خادم مُسرِّبة تُعلِن بالضبط أي برنامج (وأي إصدار) تشغّله — إشارة صغيرة 'هؤلاء لم يحصّنوا الأساسيات' في أسوأ لحظة ممكنة.

لماذا يهمّ. كلا الفحصين هنا للعلم في منهجيتنا — مسجَّلان بصفر نقاط ولا يغيّران درجتك أبداً — لأنهما يصفان بنيتك بدلاً من اختبار ضابط أمن ناجح/فاشل. نعرضهما لأنهما يرسمان تعرّضاً تجارياً حقيقياً. فموقع بلا CDN/WAF يتلقّى كل هجوم وذروة حركة على الأصل مباشرة، بلا ترشيح وبلا امتصاص اندفاعات؛ وإضافة واحد (الطبقة المجانية من Cloudflare هي الطريق الشائع) من أعلى ترقيات المتانة رافعة وأقلها تكلفة يمكن لنشاط تجاري صغير القيام بها. وخريطة مزوّد واضحة — معرفة ما إذا كان DNS والويب والبريد مقسَّمين أم مكدَّسين على مزوّد واحد — أول ما تحتاجه حين يحدث خطأ والفرق بين حادث محتوى وانقطاع تامّ.

ما هذا، بكلمات بسيطة

كل موقع يعمل على خادم في مكان ما. والسؤال الذي تجيب عنه هذه الصفحة: ما الذي يقف بين الإنترنت المفتوح وذلك الخادم — ومن يدير فعلاً قطع وجودك على الإنترنت؟

هناك جزآن:

1. CDN / WAF — الدرع في المقدمة. CDN (شبكة توصيل المحتوى) شبكة عالمية تجلس في مقدمة موقعك، وتقدّم محتواك بسرعة للزوّار في أي مكان، وتمتصّ ذُرى الحركة. وWAF (جدار حماية تطبيقات الويب) مرشّح يفحص الطلبات الواردة ويحجب الخبيثة قبل أن تصل إلى خادمك. والخدمات الشائعة (Cloudflare، AWS CloudFront، Fastly، Akamai، Sucuri، وغيرها) تجمعها معاً. ننظر في استجابات موقعك ونُبلّغ بما إذا كنا نرى درعاً في المقدمة — ونلاحظ أي خادم ويب تشغّل أيضاً.

2. خريطة الاستضافة/المزوّد — من يدير سباكتك. نقرأ السجلات العامة التي تقول من يتولّى DNS الخاص بك (الدليل الذي يحوّل نطاقك إلى عنوان)، ومن يتولّى بريدك. ومن ذلك يمكننا معرفة ما إذا كان DNS وموقعك وبريدك مقسَّمين عبر مزوّدين (متين) أم مكدَّسين على واحد (مريح، لكنه نقطة فشل وحيدة).

الأهمّ الذي يجب معرفته سلفاً: في تقييمنا، كلاهما للعلم. لا يؤثران في درجتك. نعرضهما لأنهما يصفان مدى تعرّض نشاطك التجاري للانقطاع والهجوم — وهو سؤال مختلف، وعملي جداً، عن الدرجة.

ما قد يكلّفك هذا

هذه ليست مخاطر مجرّدة — إنها الطرق اليومية التي يحوّل بها إعداد غير مدرَّع متشابك مشكلة صغيرة إلى يوم سيئ.

• مُخرَج من الخدمة في اليوم الأهمّ. يجلس موقعك على الخادم الأصلي بلا شيء في مقدمته. وصباح إطلاق أو ترويج، ترتفع الحركة — أو يضرب طوفان بوتات متواضع — فلا يستطيع الخادم التحمّل. تنتهي مهلة الصفحات، ويُخطئ الدفع، وتخسر إيرادات اليوم بينما يكافح مضيفك الحريق. وCDN يمتصّ الاندفاعات وWAF يُرشِّح الحركة غير المرغوبة؛ ومعاً هما الفرق بين “يوم مزدحم” و”معطّل طوال الصباح”.

• كل شيء يُعتِم دفعة واحدة. يعمل DNS وموقعك وبريدك جميعاً عبر مزوّد واحد. يمرّ ذلك المزوّد بانقطاع (يحدث لجميعهم في النهاية) فيختفي موقعك ونظام حجوزاتك وبريدك في آن. لا تستطيع معالجة الطلبات، ولا تستطيع حتى مراسلة العملاء لتقول إنك على علم — لأن صندوق البريد معطّل أيضاً. وتقسيم المزوّدين يعني أن فشلاً واحداً محتوى، لا تامّ.

• شيفرتك تتلقّى كل هجوم مباشرة. بلا WAF، يضرب كل سبر آلي — محاولات حقن، تخمين تسجيل دخول، ماسحات استغلال معروفة — شيفرة تطبيقك بلا ترشيح. أنت تراهن على أن برنامجك خالٍ من العيوب ومُرقَّع بالكامل، إلى الأبد. وWAF يحجب الغالبية الساحقة من تلك الضوضاء الآلية قبل أن تصل إليك، مُحوِّلاً “هجوم خلفية مستمر” إلى “مُرشَّح في معظمه”.

• حادث بطيء مذعور لأن لا أحد لديه الخريطة. يتعطّل شيء وتُهدَر الساعة الأولى في “مهلاً، من يدير DNS لدينا؟ هل البريد على المضيف نفسه؟ بمن نتصل؟” حين تكون خريطة مزوّدك غير واضحة، يبدأ كل حادث من الصفر. ومعرفة الخريطة سلفاً تحوّل الهرع إلى مكالمة هاتفية.

• انطباع أول سيئ لمشترٍ حذر. يمسحك فريق تقني لمشترٍ محتمل قبل التوقيع فيرى أصلاً عارياً بلا CDN/WAF — وترويسة خادم تُعلِن صراحةً برنامجك وإصدارك بالضبط. إنها إشارة صغيرة، لكنها تضعك في خانة “لم يحصّنوا الأساسيات” في أسوأ لحظة بالذات.

ما هو فعلاً

CDN / WAF — الطبقة الواقية

حين يطلب زائر (أو مهاجم) موقعك، يمكن للطلب إمّا أن يذهب مباشرة إلى خادمك الأصلي، أو أن يمرّ عبر CDN/WAF أولاً. فإذا كان هناك درع في المقدمة، فيمكن لذلك الدرع:

• ترشيح الطلبات الخبيثة (جزء WAF): حجب محاولات الحقن، وهجمات البوتات، وأنماط الاستغلال المعروفة قبل أن تصل إلى شيفرتك أصلاً.
• امتصاص الحركة (جزء CDN): تقديم محتوى مخزّن من خوادم قرب كل زائر وامتصاص الاندفاعات، فلا تسحق ذروة — مشروعة أو معادية — أصلك.
• تسريع الموقع: المحتوى المُقدَّم من خادم حافة قريب يُحمَّل أسرع للزوّار حول العالم.

نكتشف درعاً بالنظر في البصمات التي تتركها هذه الخدمات في ترويسات استجابة موقعك — مثلاً ترويسة cf-ray (Cloudflare)، أو x-amz-cf-id (Amazon CloudFront)، أو x-served-by (Fastly)، أو x-akamai-transformed (Akamai)، أو x-sucuri-id (Sucuri). ونقرأ أيضاً ترويسة Server لتحديد خادم الويب الأساسي لديك (nginx، Apache، IIS، LiteSpeed، Caddy، وما إلى ذلك)، ونُعلِّم أي ترويسة X-Powered-By تُفرِط في المشاركة.

كيف يبدو “الجيد”: CDN/WAF مكتشَف في مقدمة أصلك، وترويسة Server لا تُعلِن رقم إصدار محدّد.

خريطة الاستضافة/المزوّد — اعتمادات بنيتك

يشير نطاقك بهدوء إلى عدة خدمات مختلفة:

• DNS — الدليل الذي يحوّل yourbusiness.com إلى عنوان الخادم الفعلي. نقرأ سجلات خوادم أسمائك (NS) ونتعرّف على المزوّدين الشائعين (Cloudflare، AWS Route 53، Azure DNS، GoDaddy، Namecheap، DigitalOcean، Hetzner، Linode، والمُسجِّلين الإقليميين بينهم).
• البريد — حيث يُتولّى بريدك. نقرأ سجلات MX لديك ونتعرّف على المزوّدين الشائعين (Google Workspace، Microsoft 365، Proofpoint، Mimecast، Barracuda، Zoho، وغيرها).

ومن هذا يمكننا رؤية ما إذا كانت هذه المسؤوليات مقسَّمة عبر مزوّدين (فشل في واحد لا يُسقِط الآخرين) أم مكدَّسة على مزوّد واحد (مريح، لكن انقطاعاً أو اختراقاً واحداً يأخذ كل شيء).

كيف يبدو “الجيد”: كحدّ أدنى، DNS محفوظ لدى مزوّد مخصّص موثوق بدلاً من تجميعه في الحساب نفسه مع كل شيء آخر — فلا يشارك دليل نطاقك مصير موقعك وصندوق وارد بريدك.

كيفية الإصلاح (مجاناً، ~ظهيرة واحدة)

سلّم هذا للشخص التقني لديك أو مطوّر الويب — الإصلاح مجاني. وضع CDN/WAF في مقدمة موقعك لا يكلّف شيئاً على الطبقات المجانية الشائعة، وكتم إصدار خادمك إعداد من سطر واحد. لا ترخيص لشرائه. (الخيارات المدفوعة هنا هي المراقبة وتتبّع المحفظة والتدقيقات فقط — أبداً الإصلاح نفسه.) وقرار المالك الوحيد هو: نعم، ضع درعاً في مقدمة الموقع.

ولأن كلا الفحصين للعلم، لا شيء من هذا مُقيَّم — لكن CDN/WAF من أعلى ترقيات المتانة قيمة يمكن لنشاط تجاري صغير القيام بها، فيستحق الفعل.

1. ضع CDN/WAF في مقدمة موقعك

الطريق الأكثر شيوعاً المجاني هو Cloudflare:

1. أنشئ حساب Cloudflare مجاني وأضِف نطاقك.
2. تقرأ Cloudflare سجلات DNS الموجودة لديك؛ تحقّق من استيرادها بشكل صحيح.
3. غيّر خوادم أسماء نطاقك (لدى مُسجِّلك) إلى الاثنين اللذين تمنحك إياهما Cloudflare. هذا هو التبديل الذي يوجّه الحركة عبر Cloudflare.
4. اضبط وضع SSL/TLS على Full (strict) فيبقى التشفير من طرف إلى طرف بين الزائر ← Cloudflare ← أصلك. (تجنّب “Flexible”، التي تترك المرحلة الأخيرة غير مشفّرة.)
5. أصبح CDN وWAF أساسي فعّالين الآن. يمكنك ضبط قواعد WAF لاحقاً، لكن الافتراضات تُرشِّح أصلاً الكثير.

طرق أخرى، حسب حزمتك:

• AWS CloudFront — أنشئ توزيعاً يشير إلى أصلك؛ واقرنه بـ AWS WAF للترشيح. الأفضل إن كنت على AWS أصلاً.
• Sucuri WAF — قائم على DNS، لا يتطلب تغييرات على خادمك؛ جيد إن لم تستطع لمس الأصل.
• Fastly / Akamai — شبكات CDN/WAF بمستوى مؤسسي، عادة للمواقع الأكبر أو الأعلى حركة.

بعد التبديل، اختبر الموقع، وتأكد من عمل HTTPS في كل مكان، وراقِبه يوماً. لا تخزّن بعدوانية صفحات يجب أن تبقى شخصية أو حيّة (المناطق المسجَّل دخولها، العربات، صفحات الدفع).

2. توقّف عن الإعلان عن إصدار خادمك

سواء أضفت CDN أم لا، اكتم الإصدار الذي يُعلِنه خادمك — إنها معلومة مجانية تُسلِّمها للمهاجمين.

Nginx:

server_tokens off;

Apache (في الإعداد الرئيسي):

ServerTokens Prod
ServerSignature Off

أزِل ترويسة X-Powered-By مُفرِطة في المشاركة (مثلاً من PHP أو إطار عمل تطبيق) على مستوى الخادم أو CDN — على Cloudflare يمكنك نزعها بقاعدة تحويل ترويسة استجابة.

3. افحص خريطة مزوّدك للتأكد (اختياري، ~10 دقائق)

انظر إلى أين يعيش DNS وموقعك وبريدك فعلاً:

• إذا جلست الثلاثة جميعاً في حساب مزوّد واحد، ففكّر على الأقل في نقل DNS إلى مزوّد مخصّص (DNS من Cloudflare مجاني وسريع). ذلك التقسيم الواحد يعني أن دليل نطاقك ينجو من انقطاع استضافة.
• اكتب الخريطة — مزوّد DNS، ومضيف الويب، ومزوّد البريد، والمُسجِّل، وجهة تسجيل الدخول/الدعم لكلٍّ. هذه الصفحة الواحدة أنفع شيء يمكن أن يكون أمامك أثناء حادث.

ملاحظات المنصة

• Google Workspace / Microsoft 365: هذان مزوّدا بريدك، لا موقعك. ووضع CDN/WAF في مقدمة الموقع لا يمسّ البريد، والعكس — إنهما قراران منفصلان. (وجود البريد على Google/Microsoft والموقع خلف Cloudflare إعداد جيد تماماً، مقسَّم عمداً.)
• منشئو المواقع المُدارون (Wix، Squarespace، Shopify): يتضمّن هؤلاء CDN خاصاً بهم ومستوى من حماية WAF كجزء من المنصة، فقد تكون مدرَّعاً أصلاً حتى لو لم يُسمِّ فحص ترويستنا مزوّداً. وعادة لا تستطيع إضافة Cloudflare خاصاً بك في المقدمة؛ وذلك سليم — فالمنصة تتولّاه.
• WordPress على استضافتك الخاصة: مرشّح مثالي لطبقة Cloudflare مجانية في المقدمة. اقرنه بجدار حماية إضافة أمنية لقواعد على مستوى التطبيق.

الأخطاء الشائعة

• تشغيل أصل عارٍ “لأن الموقع صغير”. المواقع الصغيرة تُضرَب بالهجمات الآلية وطوفانات البوتات نفسها كالكبيرة — فالبوتات لا تفحص إيراداتك أولاً. والطبقة المجانية من CDN/WAF موجودة تحديداً للمواقع الصغيرة؛ وعدم استخدامها ترك فوز سهل على الطاولة.
• استخدام Cloudflare ‘Flexible’ SSL. يُظهِر قفلاً لكنه يترك الاتصال بين Cloudflare وأصلك غير مشفّر. استخدم دائماً Full (strict) فيكون مشفّراً من طرف إلى طرف.
• تخزين الأشياء الخطأ. التخزين العدواني لصفحات مسجَّل دخولها أو عربات أو صفحات دفع قد يُظهِر لعميل محتوى آخر أو أسعاراً قديمة. خزّن المحتوى الثابت؛ واترك الصفحات الشخصية والمعاملاتية دون تخزين.
• تكديس كل شيء على مزوّد واحد دون إدراك. الراحة سليمة إن كانت خياراً واعياً — لكن كثيراً من الأنشطة لا يكتشف أن DNS والويب والبريد يشتركون في حساب واحد إلا أثناء الانقطاع الذي يُسقِط الثلاثة. اجعله قراراً، لا اكتشافاً.
• ترك إصدار الخادم معروضاً. إنها خطوة تحصين مجانية من سطر واحد يسهل نسيانها. أطفئها.

ملاحظة حول الدرجة

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

الأسئلة الشائعة