إدارة جدار الحماية بسهولة باستخدام UFW على خوادم لينكس

UFW على خوادم لينكس هو أداة جدار حماية تُبسط القواعد المعقدة لـ iptables، مما يجعل إدارة جدار الحماية لـ SSH وHTTP وHTTPS والمنافذ الخاصة سريعة وآمنة. خاصةً على خوادم Ubuntu وDebian، يمكنك باستخدام UFW إغلاق حركة المرور الافتراضية، وفتح الخدمات اللازمة، والسماح لعناوين IP معينة، وتقليل محاولات الدخول الفاشلة. الاقتراب الموصى به لبداية أمنة هو: تأمين وصول SSH، رفض حركة المرور الافتراضية، السماح بحركة المرور الصادرة، فتح فقط منافذ الخدمات المستخدمة، والتحقق من حالة UFW بانتظام.

عندما يتم فتح خادم ويب على الإنترنت، فإنه يواجه عمليات فحص تلقائية، ومحاولات كلمات مرور، وأدوات فحص الثغرات، واستفسارات عن المنافذ غير الضرورية. لذلك، يُعتبر جدار الحماية أحد الطبقات الأولى لأمان خادم لينكس. UFW هو أداة عملية مفضلة للفرق الفنية في العمليات اليومية؛ لأنه يحتوي على أوامر قابلة للقراءة، ويتيح إضافة وحذف القواعد بسرعة، ويقدم تسجيلات، ويقلل من مخاطر التكوين الخاطئ مقارنةً بأوامر iptables. في هذا الدليل، سيتم تناول تثبيت UFW، والأوامر الأساسية، ومنع قفل SSH، ومنافذ خادم الويب، وإذونات بناءً على IP، والتحقق من السجلات، وIPv6، وحالات خاصة مثل Docker، والممارسات الأمنية المتوافقة مع معايير 2026 خطوة بخطوة.

ما هو UFW وماذا يفعل؟

UFW هو اختصار لـ Uncomplicated Firewall. يمكن ترجمته إلى العربية على أنه "جدار حماية بسيط". يستخدم في الخلفية بنية تصفية الحزم لنواة لينكس، ولكنه يقدم أوامر أكثر وضوحًا لمسؤول النظام. على سبيل المثال، بدلاً من كتابة قواعد iptables أو nftables مباشرة، يمكنك السماح بحركة مرور HTTPS باستخدام الأمر: sudo ufw allow 443/tcp.

UFW مفيد بشكل خاص في السيناريوهات التالية:

• توفير الأمان الأساسي بسرعة على خادم VPS أو خادم مخصص تم إنشاؤه حديثًا.
• فتح فقط المنافذ 80 و443 على خادم الويب.
• تقييد وصول SSH لعناوين IP محددة فقط.
• إدارة اتصالات SSH بحدود لتقليل محاولات القوة الغاشمة.
• عدم ترك لوحات الاختبار والتطوير والإدارة مفتوحة بالكامل على الإنترنت.
• متابعة الاتصالات المشبوهة من خلال السجلات.

UFW بمفرده لا يحل جميع مشكلات الأمان؛ ولكنه يقلل من مساحة الهجوم. عند استخدامه مع كلمات مرور قوية، والوصول باستخدام مفتاح SSH، والتحديثات المنتظمة، وتكوين SSL/TLS، وأمان التطبيقات، فإنه يشكل طبقة أساسية فعالة. إذا كنت تستضيف موقعًا إلكترونيًا على خادمك، فلا ينبغي عليك إهمال استخدام شهادة SSL مع جدار الحماية شهادات SSL.

مقارنة UFW وiptables وfirewalld

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

إذا كنت تدير خادم ويب يعتمد على Ubuntu، فإن UFW يكفي لمعظم الاحتياجات. في الشبكات المؤسسية الكبيرة أو في هياكل الأمان متعددة الطبقات، يجب أن يتم التفكير في UFW جنبًا إلى جنب مع مجموعات أمان السحابة، وWAF، وIDS/IPS، وحلول تسجيل السجلات المركزية.

تثبيت UFW وأول الفحوصات

عادةً ما يأتي UFW مثبتًا مسبقًا على Ubuntu. ومع ذلك، من الجيد التحقق مما إذا كان مثبتًا. الأمر: sudo ufw status. إذا حصلت على مخرجات مثل command not found، ستحتاج إلى التثبيت.

التثبيت على Ubuntu وDebian

أولاً، قم بتحديث قائمة الحزم: sudo apt update. ثم قم بتثبيت UFW: sudo apt install ufw -y. بعد التثبيت، تحقق من حالة الخدمة: sudo systemctl status ufw. قد يكون من الطبيعي ألا تظهر في المخرجات بأنها نشطة؛ لأن قواعد UFW تبقى في حالة سكون حتى يتم تفعيلها.

القاعدة الأولى في إدارة الخادم هي عدم التسرع. إذا كنت تعمل على VPS بعيد، تأكد من السماح بمنفذ SSH قبل تفعيل UFW. خلاف ذلك، قد تفقد الوصول إلى خادمك. إذا كنت تستخدم VPS من Hostragons، فمن الحكمة تدوين وصول اللوحة وخيارات وحدة التحكم قبل إجراء التكوين الأمني الأول الخادم VPS.

عرض الحالة الحالية

يمكنك استخدام الأمر sudo ufw status verbose لرؤية حالة UFW. للحصول على قائمة القواعد بشكل أكثر تفصيلًا ورقمًا، فإن الأمر sudo ufw status numbered مهم. تسهل القائمة المرقمة إزالة القواعد. على سبيل المثال، إذا كنت ترغب في حذف منفذ قمت بفتحه عن طريق الخطأ، يمكنك رؤية رقمه أولاً ثم تستخدم الأمر sudo ufw delete 3 لإزالته.

بداية آمنة: القواعد الافتراضية

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

الأوامر الأساسية التي يجب تنفيذها:

• sudo ufw default deny incoming
• sudo ufw default allow outgoing
• sudo ufw allow OpenSSH أو sudo ufw allow 22/tcp
• sudo ufw enable
• sudo ufw status verbose

النقطة الحرجة هنا هي وصول SSH. إذا كان SSH يعمل على منفذ مختلف، على سبيل المثال 2222، فلا تفعل UFW دون تنفيذ الأمر: sudo ufw allow 2222/tcp. تغيير منفذ 22 القياسي في أمان الخادم لا يوفر الأمان بمفرده؛ ولكنه قد يقلل من محاولات البوت التلقائية. الأكثر أهمية هو إغلاق إدخال كلمة المرور لـ SSH واستخدام الوصول القائم على المفتاح.

جعل وصول SSH أكثر أمانًا

SSH هو بوابة إدارة خادمك. لذلك، هو الخدمة التي يجب التعامل معها بحذر أكبر في تكوين UFW. إذا كان الوصول إلى SSH مفتوحًا لكل عنوان IP، فإن برامج الفحص التلقائية على الإنترنت قد تبدأ في محاولة الوصول إلى خادمك بسرعة.

السماح بمنفذ SSH

إذا كنت تستخدم المنفذ القياسي، فإن الأمر بسيط: sudo ufw allow 22/tcp. إذا كان هناك ملف تعريف تطبيق متاح في Ubuntu، يمكن استخدام sudo ufw allow OpenSSH أيضًا. إذا كنت تستخدم منفذًا مختلفًا، على سبيل المثال 2222، فإن الأمر المطلوب هو sudo ufw allow 2222/tcp.

تقييد وصول SSH إلى IP معين

واحدة من أكثر الطرق أمانًا هي فتح وصول SSH فقط لعناوين IP الثابتة للإدارة. على سبيل المثال، إذا كان عنوان IP لمكتبك هو 203.0.113.10، يمكنك استخدام الأمر: sudo ufw allow from 203.0.113.10 to any port 22 proto tcp. بهذه الطريقة، يبقى منفذ SSH مغلقًا بشكل عام على الإنترنت.

إذا كان لديك أكثر من مسؤول، أضف قاعدة منفصلة لكل IP. إذا كنت تستخدم IP ديناميكي، يجب تقييم هذه الطريقة بعناية؛ لأنه قد يتم قطع وصولك عند تغيير IP. في مثل هذه الحالات، يكون الإدارة عبر VPN أو استخدام خادم الباستيون أو الوصول إلى وحدة التحكم الطارئة من لوحة التحكم الخاصة بالمزود هو حل أكثر احترافية.

استخدام الحد للحد من محاولات القوة الغاشمة

يوفر UFW أمر الحد لتقليل محاولات الاتصال المتكررة. الأمر هو: sudo ufw limit 22/tcp. هذه القاعدة تساعد في الحد من محاولات الاتصال الزائدة في فترات معينة. ومع ذلك، لا يمكن أن تحل محل أدوات مثل fail2ban تمامًا. في بيئة الإنتاج، يجب استخدام UFW limit، وfail2ban، والوصول القائم على المفتاح، وسياسات المستخدم القوية معًا لتعزيز أمان SSH.

فتح منافذ خادم الويب: HTTP وHTTPS

لنشر موقع ويب، عادةً ما تحتاج إلى المنافذ 80/tcp و443/tcp. المنفذ 80 هو لحركة مرور HTTP، والمنفذ 443 هو لحركة مرور HTTPS. في الوقت الحاضر، أصبح HTTPS معيارًا من حيث SEO الحديث، وأمان المتصفح، وثقة المستخدم. المواقع التي لا تحتوي على شهادة SSL تواجه تحذيرات أمان وتعاني من انخفاض معدلات التحويل شهادات SSL.

القواعد الأساسية لـ Nginx أو Apache

لـ HTTP، الأمر هو: sudo ufw allow 80/tcp. ولـ HTTPS، الأمر هو: sudo ufw allow 443/tcp. لفتح كلا المنفذين معًا، يُفضل كتابة الأوامر بشكل منفصل بدلاً من sudo ufw allow 80,443/tcp، حيث يكون ذلك أكثر وضوحًا لمعظم المسؤولين.

يمكن أيضًا استخدام ملفات تعريف تطبيق UFW. يمكنك رؤية الملفات الشخصية باستخدام الأمر sudo ufw app list لـ Nginx. على سبيل المثال، ملف تعريف Nginx Full يسمح بالوصول إلى كل من HTTP وHTTPS. الأمر هو: sudo ufw allow Nginx Full. وبالمثل، يمكن استخدام ملف تعريف Apache Full على جانب Apache.

هل يكفي استخدام HTTPS فقط؟

تقنيًا، يمكن لموقعك أن يعمل فقط عبر HTTPS؛ لكن عمليات تجديد الشهادات مثل Let’s Encrypt وإعادة توجيه HTTP إلى HTTPS تتطلب عادةً أن يكون المنفذ 80 مفتوحًا في معظم السيناريوهات. لذلك، من الأكثر عملية إدارة المنافذ 80 و443 معًا على خوادم الويب. من الأفضل توجيه جميع طلبات HTTP إلى HTTPS باستخدام 301 على مستوى التطبيق.

المنافذ الخاصة، قواعد البيانات، ولوحات الإدارة

فتح كل منفذ سهل؛ لكن الخبرة تكمن في معرفة أي المنافذ يجب عدم فتحها. يمكن أن تشكل المنافذ مثل 3306 لـ MySQL، و5432 لـ PostgreSQL، و6379 لـ Redis، و9200 لـ Elasticsearch مخاطر أمان خطيرة إذا تم تركها مفتوحة على الإنترنت. يجب أن تستمع هذه الخدمات، إذا أمكن، فقط على localhost أو أن تكون قابلة للوصول عبر شبكة خاصة.

فتح منفذ خاص لعنوان IP معين

على سبيل المثال، إذا كنت ترغب في السماح فقط لخادم تطبيقك بالوصول إلى خادم قاعدة البيانات، يجب عليك استخدام قاعدة قائمة على IP. الأمر هو: sudo ufw allow from 198.51.100.25 to any port 5432 proto tcp. هذه القاعدة تفتح الوصول إلى PostgreSQL فقط للعنوان IP المحدد.

مثال خاطئ هو استخدام الأمر sudo ufw allow 5432/tcp بشكل مفتوح في قاعدة البيانات الإنتاجية. هذا ينشئ سطح هجوم غير ضروري. يجب دائمًا التفكير في قيود IP على خوادم قواعد البيانات، ولوحات الإدارة، والخدمات الداخلية.

التحكم في cPanel وPlesk ولوحات الإدارة

يمكن أن تستخدم لوحات التحكم في الاستضافة منافذ متعددة. إذا كنت تستخدم Plesk أو cPanel أو لوحة إدارة خاصة، فلا تفعل UFW دون التحقق من قائمة المنافذ الرسمية. خلاف ذلك، قد يتعطل الوصول إلى البريد الإلكتروني أو DNS أو FTP أو لوحة التحكم. بالنسبة للمستخدمين الذين يفضلون الاستضافة المدارة، يتم التعامل مع هذه التعقيدات عادةً بواسطة المزود استضافة الويب.

حذف القواعد، وتعديلها، ومنطق الترتيب

إدارة القواعد باستخدام UFW بسيطة؛ ولكن من المهم الحفاظ على السجلات عند إجراء تغييرات في بيئة الإنتاج. أولاً، عرض القواعد الحالية برقم: sudo ufw status numbered. ابحث عن رقم القاعدة التي ترغب في حذفها، ثم استخدم الأمر sudo ufw delete 5 لإزالتها.

يمكن أيضًا الحذف باستخدام تعبير القاعدة مباشرة. على سبيل المثال، الأمر sudo ufw delete allow 8080/tcp يحذف قاعدة السماح للمنفذ 8080. ومع ذلك، يكون الحذف المرقم أكثر أمانًا في القواعد المعقدة القائمة على IP.

تكتسب ترتيب القواعد أهمية خاصة عند استخدام القواعد allow وdeny معًا. إذا كنت ترغب في إضافة قاعدة رفض خاصة قبل قاعدة السماح العامة، يمكنك استخدام الأمر insert. على سبيل المثال، يمكنك استخدام الأمر sudo ufw insert 1 deny from 203.0.113.55 لرفض عنوان IP معين في الأعلى. هذه الطريقة مفيدة لقطع الوصول بسرعة عن العناوين الضارة أو المسيئة.

مراقبة حركة المرور مع سجلات UFW

جدار الحماية ليس فقط لفتح وإغلاق المنافذ، بل هو أيضًا أداة لفهم سلوك الشبكة. لتمكين سجلات UFW، استخدم الأمر sudo ufw logging on. يمكن ضبط مستوى السجل حسب الحاجة على low أو medium أو high أو full. في معظم الخوادم، يكفي أن تكون البداية على مستوى low.

يمكنك فحص السجلات من خلال ملف /var/log/ufw.log. مثال على الأمر: sudo tail -f /var/log/ufw.log. هنا يمكنك رؤية الاتصالات المرفوضة، وعناوين IP المصدر، والمنافذ المستهدفة، ومعلومات البروتوكول. على سبيل المثال، إذا كانت هناك محاولات دخول عديدة من مئات العناوين IP المختلفة إلى المنفذ 22 في فترة قصيرة، يجب تعزيز تدابير أمان SSH.

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

إعدادات UFW وIPv6

اعتبارًا من عام 2026، أصبح دعم IPv6 معيارًا في العديد من مراكز البيانات. ومع ذلك، قد يترك بعض المسؤولين ثغرات أمنية بالتفكير فقط في قواعد IPv4. إذا كان خادمك يحصل على عنوان IPv6، يجب أن تتأكد من أن UFW يدير حركة مرور IPv6 أيضًا.

للتحقق، يجب أن تجد السطر IPV6=yes في ملف /etc/default/ufw. بعد إجراء التغييرات، يمكن إعادة تشغيل UFW: sudo ufw disable ثم sudo ufw enable. إذا كنت ترى قواعد تحتوي على v6 في مخرجات UFW status، فهذا يعني أن جانب IPv6 يتم إدارته أيضًا.

إذا كنت لا تستخدم IPv6، بدلاً من تعطيله تمامًا، تحقق أولاً من متطلبات المزود والتطبيق. قد تؤدي تكوينات IPv6 الخاطئة إلى بقاء خدمة مغلقة على جانب IPv4 قابلة للوصول عبر IPv6. هذه خطأ أمني شائع ولكن غالبًا ما يتم تجاهله.

لماذا قد يتصرف UFW بشكل مختلف عند استخدام Docker؟

يمكن أن تقوم Docker بتغيير قواعد iptables مباشرة عند نشر منافذ الحاويات. قد يكون هذا الأمر مفاجئًا للمسؤولين الذين يستخدمون UFW؛ لأن المنفذ الذي يبدو أنه مغلق في UFW يمكن أن يصبح قابلًا للوصول من الخارج بسبب إعداد Docker publish. على سبيل المثال، الأمر docker run -p 8080:80 ينشر المنفذ 80 داخل الحاوية على 8080 على المضيف.

يجب إجراء الفحوصات التالية على الخوادم التي تستخدم Docker:

• تحقق من أي المنافذ مفتوحة على الإنترنت من خلال مخرجات docker ps.
• قم بإزالة تعريفات -p أو ports غير الضرورية.
• قم بتقييم نشر الخدمات فقط على 127.0.0.1.
• تحقق من مجموعات أمان السحابة وقواعد UFW معًا.
• في بيئة الإنتاج، قم بالنشر بشكل محكوم عبر عكس الوكيل.

الأمان في هياكل الحاويات ليس مقتصرًا على أوامر UFW فقط. يجب أن يتم التخطيط لشبكات Docker، وأمان الصور، وإدارة الأسرار، واستراتيجية التحديث معًا. يعد اختيار الخادم الصحيح للتطبيقات ذات الحركة العالية أمرًا حاسمًا بقدر ما هو الأمن والأداء خادم مخصص.

قائمة فحص الأمان القابلة للتطبيق لـ UFW

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

• قم بتحديث الخادم: sudo apt update && sudo apt upgrade -y.
• اختبر الوصول إلى SSH واترك جلسة طرفية ثانية مفتوحة إذا أمكن.
• رفض حركة المرور الواردة افتراضيًا: sudo ufw default deny incoming.
• السماح بحركة المرور الصادرة افتراضيًا: sudo ufw default allow outgoing.
• السماح بمنفذ SSH أو تطبيق قيود قائمة على IP.
• فتح فقط المنافذ 80 و443 لخادم الويب.
• لا تفتح منافذ قاعدة البيانات على الإنترنت بشكل عام.
• قم بتمكين UFW: sudo ufw enable.
• تحقق من القواعد: sudo ufw status verbose وsudo ufw status numbered.
• قم بفتح التسجيلات وتحقق من حركة المرور المشبوهة في الـ 24 ساعة الأولى.
• راجع قواعد IPv6.
• إذا كنت تستخدم Docker أو لوحة التحكم، اختبر التأثيرات الإضافية للمنافذ.

مثال واقعي: إعداد UFW لخادم WordPress

افترض أن لديك موقع WordPress واحد يعمل على Ubuntu مع Nginx وPHP-FPM وMySQL. يستمع MySQL فقط على localhost، والموقع يُنشر عبر HTTPS، وسيتم الوصول إلى SSH من عنوان IP الإداري. في هذا السيناريو، قد يكون تكوين UFW كما يلي:

• sudo ufw default deny incoming
• sudo ufw default allow outgoing
• sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
• sudo ufw allow 80/tcp
• sudo ufw allow 443/tcp
• sudo ufw logging on
• sudo ufw enable
• sudo ufw status verbose

في هذا التكوين، لا يكون SSH مفتوحًا للجميع، وهناك منفذين مفتوحين لحركة مرور الويب، وقاعدة البيانات مغلقة عن الوصول الخارجي. على الجانب الآخر من WordPress، يتم تحقيق أساس قوي مع ملحقات الأمان، وكلمة مرور إداري قوية، وثيمات وملحقات محدثة، والنسخ الاحتياطية المنتظمة، وSSL. كما أن إدارة اسم النطاق وتكوين سجلات DNS بشكل صحيح مهم من حيث الوصول استعلام عن النطاق.

الأخطاء الشائعة واقتراحات الحلول

تم قطع اتصال SSH عند تفعيل UFW

يحدث هذا عادةً عندما يتم تفعيل UFW دون السماح بمنفذ SSH. إذا كان لديك إمكانية الوصول إلى وحدة التحكم من لوحة المزود، يمكنك الاتصال وإضافة إذن باستخدام sudo ufw allow 22/tcp أو للمنفذ الخاص الذي تستخدمه. إذا لم يكن لديك وحدة التحكم، قد تحتاج إلى الاتصال بفريق الدعم. لذلك، يجب دائمًا إضافة قاعدة SSH قبل تفعيل UFW.

الموقع الإلكتروني لا يفتح

حتى لو كان Nginx أو Apache قيد التشغيل، إذا كانت المنافذ 80 و443 مغلقة، فلن يمكنك الوصول إلى الموقع. تحقق من المنافذ باستخدام sudo ufw status verbose. أيضًا، تحقق من المنفذ الذي يستمع له خادم الويب باستخدام الأمر ss -tulpn. تأكد من أن سجلات DNS موجهة بشكل صحيح أيضًا إدارة DNS.

الخدمات البريدية لا تعمل

تستخدم خوادم البريد الإلكتروني منافذ متعددة للبروتوكولات مثل SMTP وIMAP وPOP3 وإصداراتها الآمنة. قد تكون المنافذ مثل 25 و465 و587 و993 و995 مطلوبة حسب السيناريو. إذا كنت تستخدم خدمة استضافة البريد، فقد لا تحتاج إلى فتح هذه المنافذ على خادمك استضافة البريد الإلكتروني المؤسسي.

أضفت قاعدة ولكن لم تؤثر

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

أفضل ممارسات الأمان لـ UFW لعام 2026

تتطلب أمان الخادم الحالي نهجًا أكثر شمولية من مجرد إغلاق بعض المنافذ. يجب أن يدعم تكوين UFW الجيد في عام 2026 المبادئ التالية:

• أقل امتياز: افتح فقط المنافذ الضرورية حقًا.
• أمان المصادقة: استخدم الوصول القائم على المفتاح لـ SSH.
• تقييد IP: ضع منافذ الإدارة خلف IP ثابت أو VPN.
• قابلية المراقبة: راقب سجلات UFW وسجلات النظام بانتظام.
• خطة احتياطية: احتفظ بإمكانية الوصول إلى وحدة التحكم أو إجراءات الاسترداد في حالة قاعدة جدار حماية خاطئة.
• أمان متعدد الطبقات: استخدم UFW مع WAF وSSL والتحديثات والنسخ الاحتياطية وأمان التطبيقات.
• التوثيق: قم بتوثيق سبب إضافة كل قاعدة داخل الفريق.

يعتبر جدار حماية مُهيأ بشكل جيد جزءًا تكميليًا من بنية استضافة موثوقة وفعالة. مع زيادة حركة المرور لمشروعك، يجب أن يتم التخطيط ليس فقط لقواعد المنافذ، ولكن أيضًا لاستخدام الموارد، والنسخ الاحتياطية، وCDN، وSSL، وحلول المراقبة حزم الاستضافة.

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

هل تفعيل UFW يجعل خادمي آمنًا تمامًا؟

لا. يقلل UFW من مساحة الهجوم ويوفر طبقة أمان مهمة من خلال إغلاق المنافذ غير الضرورية؛ ولكنه غير كافٍ بمفرده. يجب استخدامه مع التحديثات ومفتاح SSH وكلمات المرور القوية وSSL والنسخ الاحتياطية وأمان التطبيقات.

هل يكفي فتح المنافذ 80 و443 باستخدام UFW؟

عادةً ما تكون المنافذ 80 و443 كافية لموقع ويب. ومع ذلك، تحتاج أيضًا إلى فتح منفذ 22 أو المنفذ الخاص بـ SSH بشكل آمن. يجب تقييد منافذ قاعدة البيانات ولوحات الإدارة، إن أمكن، بناءً على IP.

هل تغيير منفذ SSH يزيد الأمان؟

يمكن أن يقلل تغيير منفذ SSH من محاولات البوت التلقائية؛ ولكنه لا ينبغي اعتباره تدبيرًا أمنيًا حقيقيًا. النهج الأقوى هو استخدام مفتاح SSH، وإغلاق إدخال كلمة المرور، وتطبيق قيود IP، واستخدام UFW limit أو fail2ban.

هل تتحكم قواعد UFW أيضًا في حاويات Docker؟

قد لا تتحكم بها دائمًا كما تتوقع. يمكن أن تقوم Docker بتغيير قواعد iptables مباشرة عند نشر المنافذ. لذلك، يجب فحص مخرجات docker ps والمنافذ المنشورة وقواعد UFW معًا على الخوادم التي تستخدم Docker.

هل يجب أن أتحقق من إعدادات IPv6 عند استخدام UFW؟

نعم. إذا كان خادمك يحصل على عنوان IPv6، يجب التأكد من أن UFW يدير حركة مرور IPv6 أيضًا. يجب التحقق من إعداد IPV6=yes في ملف /etc/default/ufw، ويجب التحقق من وجود قواعد v6 في مخرجات UFW status.

باختصار، يمكن إدارة جدار الحماية باستخدام UFW على خوادم لينكس بسرعة وبشكل فعال. يمكنك تقليل مساحة الهجوم بشكل كبير من خلال القواعد الصحيحة للبداية، وأمان SSH، وفتح المنافذ الخاصة بالويب بشكل محكوم، ومراقبة السجلات. إذا كنت تطلق مشروعًا جديدًا، فإن التخطيط لبنية استضافة آمنة، وSSL، وخطوات الصيانة المنتظمة سيوفر نتائج أكثر صحة على المدى الطويل. يمكنك استكشاف حلول Hostragons لاختيار البنية التحتية المناسبة لاحتياجاتك، وتطوير إعداد الأمان الخاص بك تدريجيًا وفقًا لأهداف نموك.