يشير "جدار الحماية" في سياق خادم ويب عادة لأحد شيئين مختلفين جوهريًا: جدار حماية على مستوى الشبكة يصفّي الحركة حسب المنفذ والبروتوكول وعنوان المصدر قبل أن تصل أي تطبيق، أو جدار حماية تطبيقات الويب (WAF) يفحص محتوى طلبات HTTP نفسها بحثًا عن أنماط مرتبطة بهجمات محددة. يُسمَّى كلاهما "جدار حماية" ببساطة، ما يُخفي أنهما يحميان ضد فئتين مختلفتين تمامًا من الهجمات، ويعملان على طبقتين مختلفتين من البنية.
جدار الحماية على مستوى الشبكة: تصفية بالمنفذ والبروتوكول
يتخذ جدار حماية على مستوى الشبكة (أدوات كـiptables وnftables، أو إعدادات مجموعة أمان مزوّد سحابي، تطبيقات شائعة) قراراته بناءً على معلومات مستوى الاتصال: أي منفذ يحاول الاتصال الوصول إليه، وأي بروتوكول يستخدمه، وغالبًا عنوان IP المصدر. قد تسمح قاعدة باتصالات واردة على المنفذ 443 (HTTPS) والمنفذ 22 (SSH) من أي مكان، بينما تحظر كل منفذ آخر صراحة. ليس لهذه الطبقة أي رؤية لما بداخل اتصال مسموح به — لا تقرأ محتوى طلب HTTP إطلاقًا، بل تقرر فقط هل يُسمَح بمحاولة اتصال بناءً على وجهتها ومصدرها.
جدار حماية تطبيقات الويب: فحص الطلب نفسه
يقف جدار حماية تطبيقات الويب على طبقة HTTP، فاحصًا محتوى طلبات سُمِح بها بالفعل على المستوى الشبكي — معاملات الرابط، تقديمات النماذج، الترويسات، ملفات تعريف الارتباط — بحثًا عن أنماط مرتبطة بأنواع هجمات محددة: محاولات حقن SQL (صياغة SQL خبيثة مضمَّنة في حقل إدخال، تحاول التلاعب باستعلام قاعدة بيانات)، محاولات برمجة نصية عبر المواقع (كود نصي خبيث مضمَّن في إدخال يُعرَض لمستخدمين آخرين)، وهجمات مماثلة على مستوى التطبيق. يستطيع WAF حظر طلب يستخدم اتصال HTTPS صالحًا تقنيًا على منفذ مسموح به لكن محتواه الفعلي نمط هجوم معروف — بالضبط نوع التهديد الذي لا يملك جدار حماية الشبكة أي قدرة على رؤيته، لأن الاتصال نفسه يبدو شرعيًا تمامًا على تلك الطبقة.
مثال عملي: ماذا تلتقط كل طبقة وماذا لا تلتقط
اعتبر طلبين واردين مختلفين. الأول محاولة اتصال على المنفذ 3306 (منفذ MySQL الافتراضي) من عنوان IP غير مألوف، يحاول الاتصال مباشرة بخادم قاعدة البيانات. يحظر جدار حماية شبكة مضبوط للسماح فقط بالمنافذ 80 و443 وSSH هذا تمامًا — المنفذ نفسه غير مسموح به، بغض النظر عن نية الاتصال. لا يرى WAF هذه المحاولة أبدًا، لأنها لا تصل طبقة HTTP التي يفحصها WAF إطلاقًا. الثاني طلب لنموذج تسجيل الدخول الخاص بالموقع نفسه، مُرسَل عبر منفذ HTTPS العادي بقيمة حقل مُعدَّة لتحتوي صياغة حقن SQL، تحاول تجاوز المصادقة أو استخراج بيانات. يسمح جدار حماية الشبكة بهذا دون تردد — إنه اتصال HTTPS عادي على منفذ مسموح به، لا شيء يبدو غير معتاد في تلك الطبقة. يستطيع WAF، بفحص المحتوى المُقدَّم فعليًا، التعرّف على نمط الحقن وحظر الطلب قبل وصوله للتطبيق. تلتقط كل طبقة بالضبط ما لا تستطيع الأخرى رؤيته بنيويًا. يجعل مثال ثالث التباين أوضح: فحص آلي يتحسس مئات المنافذ المتتالية بحثًا عن أي شيء يستجيب يوقفه جدار حماية الشبكة تقريبًا بالكامل، لأن معظم تلك المنافذ مغلقة ببساطة؛ محاولة حشو بيانات اعتماد بطيئة ومنخفضة الحجم ضد نموذج تسجيل الدخول، باستخدام طلبات HTTPS تبدو صالحة على المنفذ الوحيد المفتوح، تمر مباشرة عبر الطبقة الشبكية وتعتمد إما على قواعد النمط ومعدل WAF أو حماية على مستوى التطبيق لتُلتقَط أصلاً.
سياسة منافذ بالرفض الافتراضي عمليًا
لخادم ويب نموذجي، تبدأ سياسة جدار حماية شبكي عملية من رفض كل شيء افتراضيًا والسماح صراحة فقط بما هو مطلوب فعلاً: المنفذ 443 لـHTTPS، والمنفذ 80 لـHTTP (مُعدَّ غالبًا لإعادة التوجيه لـHTTPS بدلاً من تقديم محتوى مباشرة)، ومنفذ SSH للوصول الإداري — ويُفضَّل تقييده لنطاق IP معروف محدَّد حيثما أمكن، لا فتحه للإنترنت بأكمله. ينبغي ألا تكون منافذ قواعد البيانات ومنافذ لوحات الإدارة وأي شيء آخر غير مُعَد للوصول العام المباشر مفتوحة إطلاقًا؛ حيث تحتاج قاعدة بيانات للوصول إليها، يُعالَج ذلك عادة عبر اتصال شبكة داخلية/خاصة أو نفق SSH بدلاً من كشف منفذ قاعدة البيانات مباشرة للإنترنت العام.
تحديد معدل الطلبات: نوع ثالث من الحماية
إلى جانب تصفية المنافذ وفحص محتوى الطلبات، يقيّد تحديد معدل الطلبات عدد الطلبات التي يستطيع مصدر واحد إرسالها خلال نافذة زمنية معيّنة — نوع مختلف من الحماية عن الطبقتين أعلاه، لأن فيضًا من محاولات تسجيل دخول أو استعلامات بحث تبدو شرعية تمامًا من مصدر واحد لا تحظره قواعد المنافذ (المنفذ مفتوح أصلاً) ولا تُعلِّمها عادة مطابقة أنماط WAF (لا شيء في الطلبات الفردية يبدو خبيثًا بالضرورة بمفرده). قد يسمح حد معدل معقول على نقطة نهاية تسجيل دخول، مثلاً، ببضع محاولات في الدقيقة من عنوان IP واحد قبل حظر محاولات لاحقة مؤقتًا — إبطاء محاولة قوة غاشمة أو حشو بيانات اعتماد لوتيرة غير عملية، دون التأثير في مستخدم شرعي أخطأ كتابة كلمة مروره مرة أو مرتين. تُضمِّن كثير من منتجات WAF تحديد المعدل إلى جانب فحص المحتوى، لكن يستحق الأمر إدراكه كحماية منفصلة مفاهيميًا، لأنه الطبقة التي تلتقط تحديدًا إساءة قائمة على الحجم لم تُبنَ تصفية المنافذ ولا مطابقة الأنماط لمعالجتها.
أخطاء شائعة
معاملة أي طبقة كافية بمفردها الخطأ الأكثر شيوعًا — جدار حماية شبكي محكَم الإغلاق يترك كل ثغرة على مستوى التطبيق مكشوفة لأي شخص يتصل عبر منفذ مسموح به، وWAF دون أي قيود على مستوى الشبكة يترك كل منفذ وخدمة أخرى في متناول أي شخص يجدها. خطأ شائع آخر فتح منفذ مؤقتًا لاختبار أو مهمة لمرة واحدة ونسيان إغلاقه لاحقًا — منفذ مفتوح وغير مستخدَم مسؤولية حتى لو لم يكن شيء يستمع عليه حاليًا، لأنه يوسّع ما هو متاح للوصول لحظة ينتهي شيء ما بالاستماع هناك. خطأ ذو صلة افتراض أن مجموعة قواعد WAF الافتراضية، المبنية غالبًا على أنماط ثغرات شائعة ومنشورة على نطاق واسع، لا تحتاج أي انتباه إضافي بمجرد تفعيلها — تلتقط القواعد الافتراضية مجموعة واسعة من أنماط الهجوم العامة، لكن تطبيقًا بمعالجة إدخال غير معتادة أو واجهة برمجية مخصَّصة قد يحتاج قواعد مُعدَّة خصيصًا له، وإعداد افتراضي لم يُلمَس إطلاقًا يُفوِّت أحيانًا خطرًا خاصًا بالتطبيق أو يُولِّد نتائج إيجابية كاذبة كافية على حركة شرعية ليُعطِّله أحد بهدوء لوقف الشكاوى، وهذا يُبطِل الغرض في الحالتين.
كيف تعمل الطبقتان معًا
الطبقتان متكاملتان لا متكررتان: يقلّل جدار حماية الشبكة ما هو قابل للوصول أصلاً، ويفحص WAF محتوى أي حركة مسموح بها على طبقة التطبيق الأهم — طلبات HTTP للموقع نفسه. تطبيق قواعد شبكية بأقل صلاحية (مذكورة كجزء من القائمة الأوسع في أساسيات أمان خوادم Linux لأصحاب المواقع) إلى جانب حماية على مستوى التطبيق يغلق سؤالي "ماذا يستطيع الوصول لهذا الخادم" و"ماذا يوجد فعليًا داخل الحركة المسموح لها بالوصول" معًا — لا يجيب أحدهما عن الآخر. لخادم يشغّل تطبيقًا واحدًا مفهومًا جيدًا، غالبًا لا يتطلب هذا عتادًا أو خدمات مخصَّصة منفصلة لكل طبقة — جدار حماية شبكي مضبوط مباشرة على الخادم إلى جانب وحدة WAF أو خادم وكيل عكسي أمام التطبيق يغطي الطبقتين دون الحاجة لأكثر من وقت ضبط كل واحدة عمدًا، بدلاً من افتراض أن إحداهما تُغني عن الأخرى.
