أفضل جدران الحماية المجانية لخادم Linux VPS

أفضل جدار حماية مجاني لخادم Linux VPS ليس أداة واحدة. إنه جدار حماية للمضيف (الطبقة التي يحتاجها كل خادم)، وإذا كنت تشغّل تطبيق ويب، فجدار حماية لتطبيقات الويب فوقه. يغطي هذا الدليل كليهما، ويسمّي أقوى خيارات جدران الحماية المجانية أو مفتوحة المصدر لكل طبقة، ويوضّح ما يكلّفك كل منها من RAM وجهد إعداد. نطاقه مشغّلو Linux VPS. وهو ليس مراجعة لأنظمة Windows.

النسخة المختصرة

• "أفضل جدار حماية مجاني" يعني أربعة منتجات مختلفة: جدران حماية مضيف Linux، وتوزيعات جدران حماية الشبكات، وجدران حماية تطبيقات الويب (WAFs)، وأدوات Windows الاستهلاكية. الأول والثالث فقط هما المناسبان لخادم VPS.
• على طبقة المضيف، استخدم أبسط أداة تناسب توزيعتك: UFW على Ubuntu، وfirewalld على عائلة RHEL، وإما UFW أو nftables مباشرة على Debian بحسب مقدار التحكم الذي تحتاجه. تعتمد أدوات الواجهة الحديثة عمومًا على nftables، لكن nftables نفسه هو الإطار الافتراضي والموصى به على Debian.
• الـ WAF طبقة منفصلة ومكمّلة لتطبيقات الويب. إنه ليس بديلًا عن جدار حماية المضيف.
• SafeLine هو أخفّ WAF مجاني (1 GB RAM). BunkerWeb هو الأكثر شمولًا في الميزات لكنه يتطلب 8 GB. وHaltdos Community خيار مجاني ثالث مع واجهة ويب.

ما يتجاوزه هذا الدليل

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

• جدران حماية Windows والأجهزة الطرفية الاستهلاكية (ZoneAlarm وComodo وTinyWall). نظام تشغيل خاطئ وجهاز خاطئ.
• جدران الحماية التجارية والمؤسسية المدفوعة (Cisco ASA وPalo Alto وFortinet). خارج نطاق "المجاني".
• خدمات WAF السحابية بنموذج SaaS (Cloudflare وSucuri). صالحة، لكنها قائمة على DNS/الوكيل وخارج نطاق خادم VPS المُستضاف ذاتيًا. يوفّر Cloudflare بالفعل مجموعة قواعد WAF أساسية مجانية، بينما تعتمد تغطية القواعد المُدارة الأشمل ومجموعة قواعد OWASP على الباقة.
• تشغيل pfSense أو OPNsense كبوابة على خادم VPS مشترك. غير مناسب معماريًا دون تمرير NIC. مشروح في قسم توزيعات الشبكة.

ما يعنيه "أفضل جدار حماية مجاني" فعليًا (أربع فئات)

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

1. جدران حماية مضيف/VPS في Linux: برمجيات تعمل على الجهاز نفسه الذي تعمل عليه خدماتك وتتحكم في المنافذ التي يمكن الوصول إليها. UFW وfirewalld وnftables. هذه هي الطبقة التي يحتاجها كل خادم VPS.
2. توزيعات جدران حماية الشبكات: أنظمة تشغيل كاملة مبنية حول محرّك جدار حماية، تُنشَر على جهاز مخصّص أو جهاز افتراضي لحماية شبكة كاملة. OPNsense وpfSense وIPFire. هذه مخصّصة لمختبر منزلي أو شبكة LAN مكتبية، وليست لخادم VPS الذي تحاول حمايته.
3. جدران حماية تطبيقات الويب (WAFs): وكلاء عكسيون يفحصون حركة مرور HTTP بحثًا عن هجمات طبقة الويب مثل حقن SQL وXSS وبقية قائمة OWASP Top 10. SafeLine وBunkerWeb وHaltdos وModSecurity. هذه مخصّصة لتطبيق ويب أو API يعمل على خادم VPS الخاص بك.
4. جدران حماية الأجهزة الطرفية الاستهلاكية/Windows: برمجيات سطح مكتب تتحكم في وصول كل تطبيق إلى الإنترنت على Windows. مذكورة هنا فقط لاستبعادها.

بالنسبة لخادم VPS، الفئتان 1 و3 هما اللتان تشغّلهما. الفئة 2 تعمل على جهاز مختلف. الفئة 4 تعمل على نظام تشغيل مختلف. خيار جدار الحماية المجاني أو مفتوح المصدر المناسب لوضعك هو أي أداة في الفئة 1، وربما الفئة 3، تناسب توزيعتك وحركة مرورك.

الحكم السريع: بالنسبة لمعظم مشغّلي VPS، استخدم UFW للمضيف، وأضف SafeLine إذا كنت تشغّل تطبيق ويب وتريد WAF دون إعداد خادم بسعة 8 GB.

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

جدران حماية المضيف: UFW مقابل nftables مقابل firewalld

جدار حماية المضيف هو الطبقة الوحيدة التي تحتاجها دائمًا. يتحكم في المنافذ التي تقبل الاتصالات على خادمك، وعلى خادم VPS جديد يمثّل الفرق بين جهاز محكم الإغلاق وآخر مفتوح. على Ubuntu، عادة ما يكون هذا الجدار هو UFW. على توزيعات عائلة RHEL، يكون firewalld. على Debian، UFW واجهة بسيطة لجدار حماية المضيف، لكن الإطار الافتراضي والموصى به لجدار الحماية في Debian هو nftables.

تنقسم الخيارات الثلاثة بوضوح بحسب التوزيعة ومقدار التحكم الذي تحتاجه:

UFW هو أداة إعداد جدار الحماية الافتراضية في Ubuntu وخيار بسيط شائع على Debian، لكن إطار جدار الحماية الافتراضي في Debian هو nftables. بالنسبة لخادم VPS واحد، لا يزال UFW أسهل نقطة بداية عندما تحتاج فقط إلى مجموعة صغيرة من قواعد السماح/الرفض. الـ CLI هو الأبسط بين الثلاثة، وتُحفَظ القواعد تلقائيًا عبر عمليات إعادة التشغيل، وتغطّي بضعة أوامر كل ما يحتاجه معظم مشغّلي VPS. حدّه هو القواعد المتقدمة: المنطق المعقّد القائم على المجموعات أو المطابقة الدقيقة أمر صعب في UFW.

firewalld هو الافتراضي على RHEL وCentOS وAlmaLinux وRocky. إنه قائم على المناطق، ويتكامل مع systemd، وأقدر من UFW على تقسيم حركة المرور بحسب الواجهة أو مستوى الثقة. تلك القدرة تكلّف وقت إعداد. إذا كنت على خادم VPS من عائلة RHEL، فإن firewalld موجود بالفعل وهو مسار المقاومة الأقل.

nftables هو المحرّك على مستوى النواة الذي يعمل تحت كليهما. تستخدمه مباشرة عندما تحتاج فعلًا إلى حجم قواعده أو سرعته: آلاف القواعد، أو التصفية عالية الأداء، أو تحكم لا تكشفه أي واجهة. وفقًا لـ مقارنة Better Stack بين UFW وnftables، يعمل nftables أسرع من iptables بمقدار 10 إلى 100 مرة بمجرد وجود آلاف القواعد. هذا الرقم هو nftables مقابل iptables، وليس UFW مقابل iptables. بالنسبة لخادم VPS نموذجي به حفنة من قواعد السماح، لن تشعر بذلك الفرق، ولا يستحق منحنى التعلم الأكثر انحدارًا وغياب واجهة UI سهلة أن تدفع مقابلهما. هناك أيضًا زاوية أمنية يجب أخذها في الاعتبار: nftables كانت به ثغرات نواة حقيقية، منها CVE-2025-40206، لذا أبقِ نواتك محدّثة بالترقيعات. هذا سبب للبقاء على أحدث إصدار، وليس سببًا لتجنب الواجهة الخلفية التي تشغّلها بالفعل.

إذا أردت شرح كيفية إعداد قواعد UFW، فإن دليل أوامر UFW من Cloudzy يغطّي الأوامر خطوة بخطوة. هذا القسم يتعلق باختيار الأداة، وليس بكتابة القواعد.

نصيحة احترافية: "iptables مهجور" لا يعني أن عليك عملًا لتقوم به. حلّ nftables محلّ iptables كواجهة خلفية للنواة، وUFW وfirewalld يعتمدان بالفعل على nftables في التوزيعات الحديثة. قواعد UFW الحالية لديك لا تحتاج إلى إعادة كتابة؛ أمر الواجهة نفسه، تغيّر المحرّك أسفله فقط. إذا كنت قادمًا من iptables الخام وتريد فهم الانتقال، فإن مرجع قواعد iptables من Cloudzy لا يزال ساريًا، لأن القواعد التي كتبتها تنطبق على الواجهة الخلفية الجديدة.

خلاصة القسم الرئيسية: استخدم المسار المعتاد لتوزيعتك: UFW على Ubuntu، وfirewalld على عائلة RHEL، وUFW أو nftables مباشرة على Debian بحسب مقدار التحكم الذي تحتاجه. لا تلجأ إلى nftables مباشرة إلا عندما تحتاج فعلًا إلى حجم قواعده أو سرعته.

توزيعات جدران حماية الشبكات: أين يناسب OPNsense وpfSense (ولماذا لا يناسبان خادمك VPS)

OPNsense وpfSense وIPFire أنظمة تشغيل كاملة لجهاز مخصّص أو جهاز افتراضي يحمي شبكة بأكملها. إنها ليست شيئًا تشغّله على خادم VPS الذي تحاول حمايته. تستحق المعرفة لأن نتائج البحث ستضعها أمامك، لذا إليك أين تناسب وأين لا تناسب.

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

لماذا هي الأداة الخاطئة على خادم VPS مشترك: تتوقّع هذه التوزيعات التحكم في حركة المرور بين عدة واجهات شبكة. على خادم VPS مشترك، يعني ذلك تمرير NIC، وهو ما لا يكشفه معظم المزودين. دونه، تكون تشغّل نظام تشغيل بوابة شبكة على جهاز ليس له شبكة يحرسها. إذا كان لديك خادم VPS واحد، فهذه الفئة بأكملها هي الطبقة الخاطئة، وUFW إضافة إلى WAF هما الصحيحان.

الخيارات المجانية الثلاثة اعتبارًا من 2026، باختصار:

• OPNsense (مرخّص بموجب BSD، سلسلة CE المستقرة الحالية: 26.1، مع 26.1.11 صدر في 1 يوليو 2026). مفتوح المصدر بالكامل، ويُحدَّث بشكل متكرر، وغير مقسّم وفق نموذج CE/Plus نفسه الذي يتّبعه pfSense. هذا يجعله الخيار الأنظف كجهاز شبكة مجاني للعديد من المستخدمين الذين يريدون توزيعة جدار حماية مفتوحة المصدر بالكامل دون التباس مستويات الميزات.
• pfSense Community Edition (إصدار CE الحالي: 2.8.1، صدر في سبتمبر 2025). لا يزال مجانيًا ومفتوح المصدر، مع توثيق ومكتبة مجتمع أكبر من OPNsense. المأخذ هو انقسام CE/Plus: يبقى pfSense CE المنتج المجتمعي المجاني، بينما pfSense Plus هو المسار التجاري المنفصل لأجهزة Netgate والنشر السحابي والعتاد من أطراف ثالثة. لمعرفة شروط Plus الحالية، راجع صفحة pfSense Plus من Netgate بدلًا من الوثوق برقم من منشور مقارنة.
• IPFire (الأحدث 2.29 Core Update 202، وفقًا لـ مدونة إصدارات IPFire). بصمة أخفّ من الاثنين الآخرين، مع مجتمع أصغر. خيار معقول عندما تريد جهازًا أخفّ ولا تحتاج إلى اتساع إضافات OPNsense.

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

خلاصة القسم الرئيسية: إذا كان لديك شبكة لحمايتها وجهاز احتياطي، فإن OPNsense هو الخيار المجاني في 2026. إذا كان لديك خادم VPS واحد، فهذه الفئة بأكملها هي الطبقة الخاطئة.

جدران حماية تطبيقات الويب: SafeLine مقابل BunkerWeb مقابل Haltdos

جدار حماية المضيف يتحكم في المنافذ المفتوحة. أما الـ WAF فيفعل شيئًا مختلفًا: يفحص حركة مرور HTTP بحثًا عن هجمات طبقة الويب مثل حقن SQL وXSS وبقية قائمة OWASP Top 10، وهو ما لا يستطيع جدار حماية قائم على المنافذ رؤيته. إذا كنت تشغّل تطبيق ويب أو API على خادمك VPS، فإن الـ WAF طبقة ثانية مكمّلة. إنه ليس بديلًا عن جدار حماية المضيف؛ فالاثنان يقعان عند نقاط مختلفة في المكدّس.

بالنسبة لعمليات نشر VPS، ابدأ ببصمة الموارد. الـ WAF الذي يناسب ميزانية RAM لديك هو عادة الذي يمكنك فعلًا إبقاؤه قيد التشغيل.

SafeLine هو أخفّ نقطة دخول. يعرّفه مستودعه على GitHub بأنه WAF/وكيل عكسي مُستضاف ذاتيًا بموجب رخصة GPL-3.0. تغطية تثبيت من طرف ثالث تحدّد حده الأدنى بنواة CPU واحدة و1 GB RAM و5 GB من القرص، مع Docker 20.10.14 أو أحدث وDocker Compose 2.0.0 أو أحدث. يستخدم SafeLine التحليل الدلالي بدلًا من الاعتماد فقط على قائمة قواعد تقليدية، لكن أرقام معدل الكشف المنشورة الخاصة به ينبغي التعامل معها كمزاعم مقدّمة من المشروع/المورّد لا كنتائج قياس مستقلة. من حيث الموارد وحدها، لا يزال SafeLine الخيار للخوادم VPS الصغيرة.

BunkerWeb هو الأكثر شمولًا في الميزات والأثقل. إنه WAF بوكيل عكسي قائم على NGINX بموجب AGPLv3، مبني على ModSecurity مع OWASP Core Rule Set. التكلفة هي RAM. توثيق BunkerWeb الرسمي يحدّد 2 vCPU و8 GB من RAM كحد أدنى للمواصفات الموصى بها، و4 vCPU مع 16 GB للإنتاج مع خدمات كثيرة.

Haltdos Community هو الخيار المجاني الثالث. إن صفحة الإصدار المجتمعي الخاصة به تسرد تغطية OWASP Top 10، وحماية من DDoS والبوتات، وتحديد المعدل، وقواعد مدمجة، وواجهة GUI للإدارة قائمة على الويب. يحدّد توثيقه 2 GB RAM و60 GB قرص و2 vCPU على الأقل كمتطلبات دنيا، مع دعم النشر على جهاز افتراضي أو Docker أو عتاد.

SafeLine, BunkerWeb، و Haltdos كلها متاحة كعمليات نشر بنقرة واحدة في سوق Cloudzy، كما تعمل يدويًا على أي خادم VPS. سواء كنت تحمي API موجّهًا للعملاء أو خدمة شخصية تعرضها للإنترنت، فالطبقة نفسها؛ والاختيار يتعلق في الأغلب بمقدار RAM الذي أنت مستعد لمنحه إياه.

خلاصة القسم الرئيسية: الـ WAF طبقة منفصلة عن جدار حماية المضيف. SafeLine هو أخفّ خيار مجاني؛ وBunkerWeb هو الأكثر شمولًا في الميزات لكنه يحتاج إلى خادم أكبر بكثير.

إذا قرّرت أن الـ WAF ينتمي إلى خادمك، فإن خطوة النشر هي حيث يمكن للسوق أن يوفّر الوقت. يعمل كل من SafeLine وBunkerWeb في Docker، وهو ما يعني عادة ملف Compose وإعداد وكيل عكسي وتصحيح أخطاء التشغيل الأول. يمكن لخيارات سوق Cloudzy الخاصة بـ SafeLine وBunkerWeb وHaltdos تجاوز خطوة التثبيت الأولية، لكن لا يزال عليك إعداد توجيه المنبع وDNS وTLS ومعالجة النتائج الإيجابية الخاطئة وقواعد جدار حماية المضيف. طبقة جدار حماية المضيف نفسها خفيفة ومتوفّرة عادة من حزم التوزيعة؛ تأكّد من تثبيتها وإعدادها وتفعيلها قبل تعريض الخدمات. حدّد حجم الباقة بحسب الـ WAF: 1 GB جيد لـ SafeLine، لكن الحد الأدنى لـ BunkerWeb البالغ 8 GB يعني نسخة أكبر. يمكنك نشر WAF على خادم Cloudzy Linux الافتراضي وتشغيل جدار حماية المضيف على الجهاز نفسه.

تحذير واحد بخصوص Docker: إذا كان تطبيقك أو الـ WAF يعمل في Docker، فلا تفترض أن UFW وحده يتحكم في كل منفذ حاوية منشور. ينشئ Docker قواعد جدار الحماية الخاصة به افتراضيًا، لذا اربط حاويات الواجهة الخلفية بـ localhost أو بشبكات Docker خاصة حيثما أمكن، ولا تعرّض إلا المنافذ الموجّهة إلى الـ WAF التي تنوي فعلًا نشرها.

هل تحتاج إلى جدار حماية مضيف وWAF معًا؟

نعم، إذا كنت تشغّل تطبيق ويب عام، فهما يحميان طبقتين مختلفتين. جدار حماية المضيف (UFW أو firewalld) يتحكم في المنافذ المفتوحة وهو الأساس لكل خادم VPS. أما الـ WAF فيفحص حركة مرور HTTP المتدفقة عبر تلك المنافذ المفتوحة بحثًا عن هجمات طبقة التطبيق. لا يحلّ الـ WAF محلّ جدار حماية المضيف؛ بل يقع خلفه.

جدار حماية المضيف غير قابل للتفاوض. يحتاجه كل خادم VPS، سواء كان به تطبيق ويب أم لا، لأنه ما يمنع بقية الإنترنت من الوصول إلى خدمات لم تقصد أبدًا تعريضها. أما الـ WAF فمشروط. أضفه عندما تقدّم حركة مرور HTTP أو HTTPS يمكن مهاجمتها في طبقة التطبيق: API عام، أو CMS، أو أي شيء يتلقى مدخلات المستخدم عبر الويب. قد لا يحتاج موقع ثابت أو خدمة داخلية فقط خلف VPN إلى WAF على الإطلاق؛ في تلك الحالة يكون جدار حماية المضيف وحده هو الإجابة الصحيحة، وإضافة WAF عبء لا تحتاجه. طابق الطبقات مع ما تشغّله فعلًا، لا مع قائمة تحقق.

خلاصة القسم الرئيسية: جدار حماية المضيف هو الأساس لكل خادم VPS. أضف WAF عندما تعرّض تطبيق ويب للإنترنت.

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

هل iptables مهجور على Linux؟

فعليًا، نعم. حلّ nftables محلّ iptables كواجهة خلفية لتصفية الحزم في النواة على Linux الحديث. لكن هذا تغيير في الواجهة الخلفية، وليس دعوة إلى فعل. UFW وfirewalld يعتمدان بالفعل على nftables في التوزيعات الحالية، وقواعد UFW الحالية لديك لا تحتاج إلى إعادة كتابة. أوامر الواجهة دون تغيير؛ تحرّك المحرّك أسفلها فقط.

هل لا يزال pfSense مجانيًا في 2026؟

نعم. pfSense Community Edition، حاليًا 2.8.1، مجاني ومفتوح المصدر. المأخذ هو انقسام CE/Plus: يبقى pfSense CE المنتج المجتمعي المجاني، بينما pfSense Plus هو المسار التجاري المنفصل لأجهزة Netgate والنشر السحابي والعتاد من أطراف ثالثة. لمعرفة شروط Plus الحالية وأي تكلفة اشتراك، راجع صفحة pfSense Plus من Netgate بدلًا من الاعتماد على رقم من مقارنة طرف ثالث.

هل يمكنني تشغيل pfSense أو OPNsense على خادم VPS؟

ممكن تقنيًا، لكن غير مناسب معماريًا على خادم VPS مشترك. هذه أنظمة تشغيل بوابة شبكة تتوقّع التحكم في حركة المرور بين عدة واجهات شبكة، وهو ما يتطلب تمرير NIC الذي لا يكشفه معظم مزودي VPS. على خادم VPS واحد، ما تريده فعلًا هو جدار حماية مضيف (UFW أو firewalld)، ولتطبيقات الويب، WAF.

هل أحتاج إلى WAF إذا كان لديّ بالفعل جدار حماية على خادم Linux الخاص بي؟

إنهما يحميان طبقتين مختلفتين، لذا يعتمد الأمر على ما تشغّله. جدار حماية المضيف يتحكم في المنافذ المفتوحة؛ والـ WAF يفحص حركة مرور HTTP المتدفقة عبرها بحثًا عن هجمات طبقة الويب مثل حقن SQL وXSS. إذا كنت تقدّم تطبيق ويب أو API عامًا، فأضف WAF فوق جدار حماية المضيف. إذا كنت تشغّل موقعًا ثابتًا أو خدمة داخلية فقط، فجدار حماية المضيف وحده يكفي.

ما هو أفضل WAF مجاني لخادم Linux VPS صغير؟

SafeLine هو أخفّ خيار مجاني، بحد أدنى 1 GB RAM يعمل في Docker، وهو ما يناسب خادم VPS صغير. BunkerWeb أكثر شمولًا في الميزات لكنه يحتاج إلى 8 GB من RAM، لذا فهو ليس عملية نشر على خادم صغير. وHaltdos Community خيار مجاني ثالث مع واجهة ويب؛ راجع توثيقه لمعرفة متطلبات الموارد الحالية قبل تحديد حجم خادمك.