إعداد ufw في لينكس: جدار ناري للخادم ومبادئ nftables

يقرر الجدار الناري في لينكس أي حزم الشبكة تُسمح بالدخول إلى الخادم وأيها تُرفض. تنفذ هذا في النواة نظام netfilter، وتتحكم فيه أدوات مثل iptables وnftables منخفضة المستوى، والواجهة المبسطة ufw (Uncomplicated Firewall). في معظم خوادم Ubuntu وDebian يستغرق إعداد ufw خمس دقائق: تمنع كل ما هو وارد، ثم تفتح SSH والمنافذ الخاصة بالخدمات، ثم تفعّله. فيما يلي سيناريو خطوة بخطوة، والأخطاء الشائعة، والحد الأدنى من nftables لفهم ما يجري في الخلفية.

كيف يعمل الجدار الناري في لينكس

تتم تصفية الحزم داخل النواة، وهذا هو netfilter. وهو يوفّر نقاط اعتراض (hooks): الحركة الواردة إلى الجهاز نفسه، والصادرة منه، والعابرة (forward). أما الأدوات التي يستخدمها المستخدم فتكتب القواعد في النواة لهذه النقاط فقط.

المهم: استخدم أداة إدارة واحدة. إذا عدّلت القواعد عبر ufw وiptables يدوياً في الوقت نفسه، فستمحو كل أداة قواعد الأخرى ويصبح الوضع غير متوقع.

تثبيت ufw والتحقق منه

في Ubuntu يكون ufw مثبتاً عادةً لكنه معطّل. أما في Debian فيُثبَّت يدوياً:

$ sudo apt update
$ sudo apt install ufw
$ sudo ufw status
Status: inactive

الحالة inactive تعني أن قواعد ufw غير مطبّقة. لا ترفع الجدار الناري بعد: سمح أولاً بـ SSH، وإلا فستقطع وصولك إلى الخادم البعيد.

خطوات إعداد ufw على الخادم

الخطوة 1. السياسات الافتراضية

السياسة الافتراضية هي ما يُفعل بالحزمة إذا لم تطابق أي قاعدة. والمخطط الآمن للخادم: منع الوارد، والسماح بالصادر.

$ sudo ufw default deny incoming
Default incoming policy changed to 'deny'
$ sudo ufw default allow outgoing
Default outgoing policy changed to 'allow'

الردود على اتصالاتك الصادرة تمر تلقائياً: يتتبّع ufw حالة الاتصالات (connection tracking)، لذلك لا حاجة إلى فتح منافذ للردود.

الخطوة 2. السماح بـ SSH

$ sudo ufw allow OpenSSH
Rules updated
Rules updated (v6)

OpenSSH ملف تعريف لتطبيق. إذا كان SSH يستمع على منفذ غير قياسي، فاسمح به صراحةً: sudo ufw allow 2222/tcp. ولمعرفة المنفذ الذي يستمع إليه sshd فعلاً استخدم sudo ss -tlnp | grep sshd.

الخطوة 3. فتح منافذ الخدمات

$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp

حدّد البروتوكول: بدون /tcp سيفتح ufw المنفذ لـ TCP وUDP معاً، والباب المفتوح الزائد لا فائدة منه.

الخطوة 4. تفعيل الجدار الناري

$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

يبدأ ufw فوراً ويعمل مع كل إقلاع. لا تُغلق جلسة SSH الحالية: افتح جلسة ثانية وتأكد أن الاتصال يعمل.

الخطوة 5. التحقق من القواعد

$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)

يُنشئ ufw قواعد IPv6 تلقائياً إذا كانت القيمة IPV6=yes موجودة في /etc/default/ufw (وهي القيمة الافتراضية).

كيف تفتح منفذاً في ufw: كل صيغ الأمر

يفهم الأمر ufw allow الصيغة المختصرة والكاملة. الصيغة المختصرة مناسبة للحالات المعتادة، والكاملة عندما تحتاج إلى تحديد المصدر أو الواجهة أو عنوان الوجهة.

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

قاعدة البيانات متاحة من خادم واحد فقط

مهمة شائعة: لا يجب أن يكون PostgreSQL أو MySQL مرئياً من الإنترنت، لكن التطبيق على خادم مجاور يحتاج إلى الاتصال به.

$ sudo ufw allow from 10.0.0.5 to any port 5432 proto tcp
Rule added

يبقى المنفذ 5432 مغلقاً أمام الجميع غيره بفضل سياسة deny incoming. ومن الأفضل أيضاً أن تُضبط قاعدة البيانات نفسها للاستماع إلى العنوان الداخلي فقط، فالجدار الناري وإعدادات الخدمة يحميان أحدهما الآخر.

ملفات تعريف التطبيقات

يمكن للحزم أن تضع وصفاً لمنافذها في /etc/ufw/applications.d/. قائمة الملفات ومحتوياتها:

$ sudo ufw app list
Available applications:
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH
$ sudo ufw app info "Nginx Full"
Profile: Nginx Full
Title: Web Server (Nginx, HTTP + HTTPS)
Description: Small, but very powerful and efficient web server

Ports:
  80,443/tcp

للسماح بملف تعريف: sudo ufw allow "Nginx Full". ضع الأسماء التي فيها مسافات بين علامتي تنصيص. ويمكنك وصف ملف تعريف خاص بك بصيغة INI في المجلد نفسه، ثم تطبيقه بالأمر sudo ufw app update الاسم.

حذف قاعدة في ufw

أكثر الطرق موثوقية هي الحذف بالرقم:

$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] OpenSSH                    ALLOW IN    Anywhere
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere
[ 4] OpenSSH (v6)               ALLOW IN    Anywhere (v6)
[ 5] 80/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 6] 443/tcp (v6)               ALLOW IN    Anywhere (v6)

$ sudo ufw delete 2
Deleting:
 allow 80/tcp
Proceed with operation (y|n)? y
Rule deleted

بعد الحذف تتغير الأرقام، لذلك قبل الحذف التالي نفّذ status numbered من جديد. الطريقة الثانية هي تكرار القاعدة مع كلمة delete: sudo ufw delete allow 80/tcp، وهذه تحذف نسخة IPv4 ونسخة IPv6 معاً.

ترتيب القواعد والإدراج في البداية

يفحص ufw القواعد من الأعلى إلى الأسفل، وتُطبَّق أول قاعدة مطابقة. لذلك يجب أن يكون المنع لعنوان محدد فوق السماح العام:

$ sudo ufw insert 1 deny from 198.51.100.23
Rule inserted

لو أضفت deny بالأمر العادي فستقع في نهاية القائمة بعد allow 443/tcp ولن تعمل على ذلك المنفذ.

حماية SSH من التخمين: ufw limit

تسمح قاعدة limit بالاتصال، لكنها تمنع العنوان الذي فتح 6 اتصالات أو أكثر خلال 30 ثانية:

$ sudo ufw limit OpenSSH
Rule updated

هذه حماية بسيطة من تخمين كلمات المرور بالجملة. للحماية الجادة أضف الدخول بالمفاتيح فقط، ويمكنك إضافة fail2ban إذا أردت، فهو يستطيع حظر العناوين عبر ufw.

سجلات ufw

يُفعَّل التسجيل بالأمر sudo ufw logging on، والمستويات هي low وmedium وhigh وfull. تُكتب السجلات في /var/log/ufw.log (عبر rsyslog) وفي سجل النواة:

$ sudo journalctl -k | grep 'UFW BLOCK' | tail -2
Oct 14 10:12:03 web kernel: [UFW BLOCK] IN=eth0 OUT= SRC=45.155.205.1 DST=192.0.2.10 PROTO=TCP SPT=51544 DPT=3389
Oct 14 10:12:09 web kernel: [UFW BLOCK] IN=eth0 OUT= SRC=89.248.165.7 DST=192.0.2.10 PROTO=TCP SPT=40312 DPT=23

تُظهر الحقول SRC وDPT من طرق الباب ومن أي منفذ. إذا كانت خدمة لا تستجيب وفي السجل توجد رسالة UFW BLOCK على منفذها، فهذا يعني أن القاعدة لم تُضَف.

ufw وDocker: لماذا تُفتح المنافذ رغم القواعد

هذا أشهر فخ. عند نشر منفذ في Docker (-p 8080:80) يضيف Docker قواعد NAT وسلسلة DOCKER بنفسه، فتمر الحركة إلى الحاوية عبر forward متجاوزة قواعد الوارد في ufw. والنتيجة أن ufw status لا يعرض المنفذ 8080، ومع ذلك يكون متاحاً من الخارج.

طرق الحل:

• انشر المنافذ على localhost فقط: -p 127.0.0.1:8080:80، ووجّه الوصول الخارجي عبر وكيل عكسي (nginx).
• أضف قواعدك إلى سلسلة DOCKER-USER، فلا يكتبها Docker فوقها.
• لا تنشر منافذ الحاويات المساندة أصلاً، واربطها عبر شبكة Docker.

الإعادة إلى الضبط الأصلي والتعطيل

$ sudo ufw disable     # تعطيل مع بقاء القواعد محفوظة
$ sudo ufw reset       # حذف كل القواعد وتعطيل الجدار
$ sudo ufw reload      # إعادة قراءة الإعدادات

قبل reset يحفظ ufw نسخاً من ملفات القواعد في /etc/ufw/ مع لاحقة التاريخ. أما القواعد نفسها فتُحفظ في /etc/ufw/user.rules وuser6.rules، ولا تُعدَّل يدوياً، بل بالأوامر فقط.

أساسيات nftables

nftables هو البديل الحديث لـ iptables في نواة لينكس. في Debian 10 فما بعد وUbuntu 20.10 فما بعد يعمل الأمر iptables افتراضياً عبر طبقة التوافق iptables-nft، لذلك تنتهي قواعد ufw أيضاً في nftables. لعرض كل ما هو محمّل في النواة:

$ sudo nft list ruleset

بنية nftables: الجدول (من العائلة ip أو ip6، أو inet لكليهما) يحتوي على سلاسل مرتبطة بنقاط netfilter، والسلاسل تحتوي على قواعد. فيما يلي جدار ناري بسيط للخادم في الملف /etc/nftables.conf:

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        ct state invalid drop
        iif "lo" accept
        ip protocol icmp accept
        meta l4proto ipv6-icmp accept
        tcp dport { 22, 80, 443 } accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

للتطبيق والتفعيل عند الإقلاع:

$ sudo nft -c -f /etc/nftables.conf   # فحص الصياغة فقط
$ sudo systemctl enable --now nftables

يمكن إضافة القواعد أثناء التشغيل، لكنها تختفي بعد إعادة التشغيل ما لم تُكتب في ملف:

$ sudo nft add rule inet filter input tcp dport 5432 ip saddr 10.0.0.5 accept
$ sudo nft -a list chain inet filter input   # -a يعرض معرّف القاعدة handle
$ sudo nft delete rule inet filter input handle 9

الميزة الأهم لـ nftables هي المجموعات ({ 22, 80, 443 }) وجدول inet الواحد لـ IPv4 وIPv6. لا تشغّل خدمة nftables.service الخاصة بك مع ufw في الوقت نفسه: فالأمر flush ruleset سيمحو قواعد ufw.

الأخطاء الشائعة

• فعّلت ufw دون قاعدة لـ SSH — فقدت الوصول. ينقذك وحدة التحكم لدى المزوّد (VNC/serial): sudo ufw allow OpenSSH أو sudo ufw disable.
• فتحت المنفذ لكن الخدمة غير متاحة — الخدمة تستمع على 127.0.0.1 وليس على العنوان الخارجي. تحقق بـ ss -tlnp.
• يوجد جدار ناري سحابي آخر — لدى كثير من المزودين مجموعات أمان؛ يجب فتح المنفذ هناك أيضاً.
• قاعدة deny لا تعمل — القاعدة أسفل قاعدة السماح؛ استخدم insert 1.

الخلاصة

إعداد ufw الأساسي يتكون من default deny incoming، والسماح بـ SSH ومنافذ الخدمات، ثم ufw enable، والتحقق بـ status numbered. للوصول الدقيق استخدم القواعد مع from وport، ولـ SSH استخدم limit، ومع Docker تذكّر أنه يتجاوز ufw. وعندما تحتاج إلى NAT أو مجموعات قواعد معقدة فانتقل إلى nftables. وتُشرح حماية الخادم بالجدار الناري عملياً في دورة Linux.