إذا سبق لك أن سألت مزود الاستضافة أو فني الدعم الفني "أليس لدينا جدار حماية بالفعل؟" عندما اقترح أحدهم إضافة جدار حماية تطبيقات الويب، فأنت لست وحدك. هذه من أكثر نقاط اللبس شيوعاً في أمان المواقع. كلتا الأداتين تسمى "جدار حماية"، وكلتاهما تحجب الحركة الضارة، وكلتاهما تبدوان متشابهتين على الورق. لكنهما ليستا كذلك.
فهم الفرق بينهما مهم، لأن الاعتماد على الأداة الخاطئة يترك ثغرة حقيقية في دفاعاتك. لنوضح ما تفعله كل أداة فعلياً، بكلمات بسيطة.
ماذا يفعل جدار الحماية الشبكي فعلياً
يعمل جدار الحماية الشبكي على مستوى البنية التحتية. تخيله كحارس أمن يقف عند باب المبنى الرئيسي، يتحقق من الهويات قبل السماح لأي أحد بالدخول إلى المبنى أصلاً.
ينظر إلى أمور مثل:
- عناوين IP التي تحاول الاتصال
- المنافذ التي تحاول الوصول إليها (مثل المنفذ 22 لـ SSH أو المنفذ 3306 لـ MySQL)
- البروتوكول المستخدم (TCP أو UDP أو ICMP)
- ما إذا كان نمط الاتصال يشبه عملية فحص أو هجوم إغراق
جدار الحماية الشبكي لا يعرف ولا يهتم بما بداخل طلب HTTP. لا يقرأ الرابط، ولا بيانات النموذج، ولا ملفات تعريف الارتباط. كل ما يفعله هو أن يقرر: هل يُسمح لهذا الاتصال بالوصول إلى هذا المنفذ على هذا الخادم، نعم أم لا؟
هذا ما يجعله ممتازاً في منع أشياء مثل محاولات الوصول غير المصرح بها إلى منفذ قاعدة البيانات، أو عمليات فحص المنافذ العشوائية من الروبوتات التي تبحث عن خدمات مفتوحة، أو الحركة القادمة من نطاقات IP قمت بحظرها صراحة. إذا سبق أن حظرت عنوان IP أو أغلقت منفذاً على خادم، فهذا مجال جدار الحماية الشبكي.
أين يقصر جدار الحماية الشبكي
المشكلة هنا هي أن موقعك يحتاج إلى إبقاء المنفذ 443 (HTTPS) مفتوحاً للجمهور. الجميع يحتاج للوصول إليه، فهذا هو الغرض الأساسي من وجود موقع إلكتروني. لا يستطيع جدار الحماية الشبكي إغلاق هذا المنفذ دون تعطيل موقعك بالكامل، وهذا يعني أنه لا يستطيع إيقاف الهجمات التي تدخل من الباب الأمامي متنكرة على شكل حركة ويب عادية.
المهاجم الذي يرسل سلسلة حقن SQL ضارة عبر نموذج الاتصال الخاص بك يستخدم المنفذ 443، تماماً مثل أي زائر شرعي. بالنسبة لجدار الحماية الشبكي، تبدو هذه الحركة طبيعية تماماً. وصلت عبر المنفذ الصحيح وباستخدام البروتوكول الصحيح. ليس لدى جدار الحماية أي طريقة لمعرفة أن الطلب نفسه خطير، لأنه لا ينظر إليه بهذا التدقيق أصلاً.
ماذا يفعل جدار حماية تطبيقات الويب بشكل مختلف
هنا يأتي دور جدار حماية تطبيقات الويب. فبدلاً من التوقف عند سؤال "هل هذا الاتصال مسموح به"، يقوم جدار حماية تطبيقات الويب بقراءة محتوى الطلب فعلياً. يفحص معاملات الرابط، وحقول النموذج، والترويسات، وملفات تعريف الارتباط، ويقارنها بأنماط الهجمات المعروفة.
يستطيع جدار حماية تطبيقات الويب رصد أشياء مثل:
- محاولات حقن SQL المخفية داخل نموذج تسجيل الدخول
- شيفرات هجمات XSS المدسوسة داخل حقل تعليق
- محاولات رفع ملفات مشبوهة تهدف إلى زرع سكربتات ضارة
- طلبات لا تتطابق مع الأنماط المتوقعة لتطبيقك تحديداً
تناولنا كيفية بناء هذه القواعد وتطبيقها فعلياً في مقال شرح قواعد WAF: كيف يقرر جدار حماية تطبيقات الويب ما يجب حجبه. باختصار، يعمل جدار حماية تطبيقات الويب على المستوى السابع، وهو طبقة التطبيق، وهي بالضبط النقطة التي يتوقف عندها اهتمام جدار الحماية الشبكي.
لماذا تحتاج إلى الاثنين معاً، لا إلى أحدهما فقط
لا تحل أي من الأداتين محل الأخرى. فهما تحميان طبقتين مختلفتين من نفس البنية.
تخيل بنيتك التحتية كمبنى. جدار الحماية الشبكي هو حارس الأمن الذي يتحقق ممن يُسمح له بدخول المدخل الرئيسي. أما جدار حماية تطبيقات الويب فهو الشخص الذي يراقب ما يفعله الزوار فعلياً بمجرد دخولهم، للتأكد من أن أحداً لا يحاول كسر قفل غرفة الخوادم أو دس شيء في خزانة ملفات لا يجب أن يلمسها.
الموقع الذي يعتمد على جدار الحماية الشبكي فقط يبقى معرضاً لكامل فئة هجمات التطبيقات ضمن قائمة OWASP Top 10، مثل ثغرات الحقن وهجمات XSS، لأن هذه الحركة لا تُصنَّف أبداً كمشبوهة على المستوى الشبكي. نستعرض هذه التهديدات بتفصيل أكبر في تهديدات OWASP Top 10 وكيف يتعامل معها جدار حماية تطبيقات الويب.
في المقابل، الموقع الذي يعتمد فقط على جدار حماية تطبيقات الويب دون حماية على مستوى الشبكة يبقى معرضاً لفحص المنافذ، ومحاولات تخمين كلمات المرور بالقوة الغاشمة ضد الخدمات المكشوفة، وأنواع معينة من حركة هجمات الحرمان من الخدمة التي لا تصل أصلاً إلى طبقة التطبيق.
كيف يظهر هذا في بيئات الاستضافة الفعلية
في خادم VPS مُدار، عادة ما تتعايش الطبقتان جنباً إلى جنب دون الحاجة لضبط أي منهما يدوياً. يتولى جدار حماية الخادم تحديد المنافذ القابلة للوصول ومن أين يمكن الوصول إليها. وبشكل منفصل، يقوم فلترة الطلبات على مستوى التطبيق بفحص حركة HTTP الفعلية التي تصل إلى موقعك، والتحقق من أمور مثل أنماط الطلبات وبلد المنشأ وحدود معدل الطلبات، قبل أن يصل أي شيء إلى الكود الخاص بك. هذا هو الإعداد الذي نعتمده هنا، بحيث يجب أن يجتاز الطلب كلا الفحصين قبل أن يلمس تطبيقك.
إذا كنت تدير خادمك الخاص ولديك واحدة فقط من هاتين الطبقتين، فمن المفيد التحقق مما يغطيه إعدادك الحالي فعلياً. يفترض كثير من أصحاب المواقع أن "جدار الحماية" مربع اختيار واحد، بينما هو في الواقع مهمتان منفصلتان تماماً. يمكنك قراءة المزيد عن كيفية عمل فلترة الطلبات والقواعد المعتمدة على الدولة في صفحة نظرة عامة على WAF، وكيفية التعامل مع قواعد المنافذ وعناوين IP في صفحة جدار الحماية.
طريقة سريعة للتحقق مما لديك
اسأل نفسك هذين السؤالين:
- هل أستطيع حظر عنوان IP معين أو إغلاق منفذ معين على خادمي؟ هذا يعني أن جدار الحماية الشبكي يقوم بعمله.
- هل هناك ما يفحص محتوى النماذج المُرسَلة أو الروابط أو الترويسات بحثاً عن أنماط هجومية؟ هذا هو جدار حماية تطبيقات الويب، أو غيابه.
إذا كان بإمكانك الإجابة بنعم على السؤال الأول فقط، فأنت تملك نصف الحماية التي تحتاجها معظم المواقع الحديثة فعلياً.
خلاصة القول
جدار الحماية الشبكي وجدار حماية تطبيقات الويب ليسا أداتين متنافستين، بل شريكين يعملان على طبقتين مختلفتين من نفس المشكلة. أحدهما يقرر من يُسمح له بطرق الباب. والآخر يقرأ ما هو مكتوب في الرسالة التي يسلمونها لك بمجرد دخولهم. تجاهل أي منهما يعني ترك باب دون حراسة، حتى لو لم تدرك أنه كان مفتوحاً.
