ابتُكر UFW ليتسنى ضبط جدار الحماية بثلاثة أوامر، وهو ينجح في ذلك. لكن المشكلة في مكان آخر: يعرض ufw status النوايا لا النتائج. فقد تكون القاعدة في القائمة ولا تغلق شيئًا على الإطلاق — لثلاثة أسباب مختلفة، وكلها تظهر بانتظام على خوادم حقيقية.

بداية لا تقفل عليك الباب من الخارج

ترتيب الأوامر مهم. اسمح بـ SSH أولًا ثم فعّل:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

تشغيل ufw enable قبل السماح بـ SSH يقطع جلستك أنت، ولا يبقى بعدها سوى وحدة تحكم المزوّد. وإن كان الخادم مضبوطًا سلفًا ولست واثقًا، فأبقِ اتصالًا ثانيًا مفتوحًا — فهو ينجو من تعديل فاشل.

انظر إلى الحالة المفصّلة؛ فالمختصرة تخفي السياسة الافتراضية:

sudo ufw status verbose

الخطأ الأول: القاعدة موجودة والمنفذ مفتوح للعالم

أشيع سطر في إعدادات الآخرين:

sudo ufw allow 3306

هكذا يُفتح MySQL «كي أتصل من البيت» — ويُفتح للإنترنت كله. وهناك صيغتان صحيحتان وكلتاهما أفضل:

sudo ufw allow from 203.0.113.25 to any port 3306

أو، وهو أكثر موثوقية، لا تُخرج الخدمة إلى الخارج أصلًا: bind-address = 127.0.0.1 في إعداد MySQL، والوصول الخارجي عبر نفق SSH. فجدار الحماية هو الخط الثاني؛ أما الأول فهو ألا تستمع الخدمة على عنوان عام. وقاعدة في UFW قد تُحذف خطأً، بينما لا يتغيّر bind-address من تلقاء نفسه.

الخطأ الثاني: IPv6

قاعدة مثل ufw allow from 203.0.113.25 تنطبق على IPv4 وحده. وإن كان للخادم عنوان IPv6 — ومعظم خوادم VPS لديها واحد مفعّل — تبقى الخدمة قابلة للوصول عبره. المزوّد منح عنوانًا، وأنت لا تتذكره، والماسح يتذكره.

تحقّق أن ترشيح v6 مفعّل أصلًا (IPV6=yes في /etc/default/ufw) وأن الخدمة لا تستمع على :: بلا حاجة:

ss -tulpn | grep ':::'

والقواعد التي تسمّي عنوانًا صراحة يجب كتابتها منفصلة لكل إصدار من البروتوكول.

الخطأ الثالث: Docker

وهو الأكثر إثارة للغيظ. ينشر Docker المنافذ بإضافة قواعده الخاصة إلى سلاسل iptables قبل تلك التي يكتبها UFW. والنتيجة أن حاوية أُطلقت بـ -p 5432:5432 تكون قابلة للوصول من الإنترنت رغم أن UFW يبلّغ عن Status: active وسياسة deny incoming. وجدار الحماية ليس معطلًا — بل لا يأتي دوره ببساطة.

والعلاج ليس في UFW بل في طريقة نشر المنفذ:

ports:
  - "127.0.0.1:5432:5432"

الربط بالعنوان المحلي هو الحل الأبسط والأكثر موثوقية. ولا ينبغي أن يطلّ إلى الخارج سوى ما يخدم الزوّار فعلًا: عادةً المنفذان 80 و443 لوكيل عكسي.

ترتيب القواعد

يطبّق UFW أول قاعدة مطابقة ويتوقف عندها. ولذلك لن يعمل منع أُضيف بعد سماح: فلا يصل الدور إليه أبدًا. انظر إلى الترقيم وأدرِج حيث يلزم:

sudo ufw status numbered
sudo ufw insert 1 deny from 198.51.100.0/24
sudo ufw delete 7

وتُحذف القواعد بالرقم، لكن الأرقام تنزاح بعد كل حذف — احذف واحدة تلو الأخرى وأعد قراءة القائمة.

الفحص من الخارج

تعرض الأوامر المحلية ما هو مضبوط. أما ما نتج فعلًا فلا يظهر إلا من آلة أخرى:

nmap -Pn -p- 203.0.113.25
nc -zv 203.0.113.25 3306

يفي بالغرض أي خادم آخر أو حاسوبك المنزلي. وهذا هو الفحص الوحيد الذي لا يكذب، ويستحق تشغيله بعد كل إعادة ضبط ملحوظة — وخصوصًا بعد تثبيت شيء «يضبط الشبكة بنفسه»: Docker، أو لوحات التحكم، أو شبكات VPN.

السجلات

افتراضيًا لا يكتب UFW شيئًا تقريبًا. ويُفعَّل ذلك بـ:

sudo ufw logging low

وتذهب القيود إلى /var/log/ufw.log — لكن فقط إذا كان rsyslog موجودًا في النظام. وعلى Debian 12 و Ubuntu 24.04 قد لا يكون موجودًا، وعندها يذهب كل شيء إلى سجل systemd:

sudo journalctl -k | grep -i '\[UFW'

وملف /var/log/ufw.log الفارغ لا يعني بذاته شيئًا — انظر في السجل أولًا.

ماذا تتوقع من جدار حماية

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