فحص المنافذ المفتوحة في Linux: ss وnetstat وlsof وnmap

فحص المنافذ المفتوحة باستخدام ss، المعيار الحديث

كل منفذ مفتوح على نظام Linux موجود لأن عملية ما طلبت من النواة الاستماع عليه. والأداة التي تعرض لك هذه المقابس اليوم هي ss (socket statistics)، وهي جزء من حزمة iproute2 المثبّتة في كل توزيعة حديثة. أمر واحد يغطي معظم الحالات:

sudo ss -tulpn

كل خيار يؤدي مهمة واحدة:

• -t: تضمين مقابس TCP
• -u: تضمين مقابس UDP
• -l: إظهار المقابس المستمعة فقط (أزله لرؤية الاتصالات القائمة أيضًا)
• -p: إظهار العملية المالكة لكل مقبس؛ ولهذا تحتاج إلى sudo، لأنك بدونه لا ترى سوى عملياتك الخاصة
• -n: خرج رقمي: يطبع :22 بدل :ssh ويتخطى استعلامات DNS العكسية، ما يجعل الأمر أسرع أيضًا

يبدو سطر الخرج النموذجي كالتالي:

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=712,fd=3))

عمود Local Address هو المهم من ناحية الأمان. فـ 0.0.0.0:22 يعني أن المقبس يقبل الاتصالات على كل واجهات IPv4، و[::]:22 هو المقابل في IPv6، أما 127.0.0.1:5432 فيعني أن الخدمة تستجيب على الحلقة المحلية فقط ولا يمكن الوصول إليها من الشبكة إطلاقًا.

بعض الصيغ التي يجدر حفظها:

ss -tlnp                      # TCP listeners only
ss -ulnp                      # UDP listeners only
sudo ss -tlnp 'sport = :22'   # who is listening on port 22
ss -tn state established      # active TCP connections right now

netstat لا تزال تعمل، لكنها قديمة

لا تزال ملايين الدروس تذكر netstat -tulpn، والخيارات تتطابق واحدًا لواحد مع أمر ss أعلاه، لذا تنتقل العادة في الاتجاهين. الفرق في العمق: تنتمي netstat إلى حزمة net-tools التي لم تعد تُطوَّر وتقرأ ملفات /proc، بينما تستعلم ss من النواة مباشرة عبر netlink، وهي أسرع بشكل ملحوظ على الأجهزة التي تدير آلاف المقابس.

معظم التوزيعات الحالية لم تعد تضمّن net-tools افتراضيًا. وإن احتجتها مع ذلك:

sudo netstat -tulpn

# if the command is missing:
sudo apt install net-tools    # Debian / Ubuntu
sudo dnf install net-tools    # RHEL / Fedora

لا سبب لتثبيتها على خادم جديد. اعتبر netstat حلًا احتياطيًا للتوافق مع الأنظمة القديمة التي ترثها، واستخدم ss في كل ما عدا ذلك.

lsof: المنافذ من منظور العمليات

في Linux كل شيء ملف، بما في ذلك مقابس الشبكة، لذا تعمل lsof (list open files) كأداة لفحص المنافذ أيضًا. وهي تتفوق عندما تفكر بالعمليات أكثر من المنافذ:

sudo lsof -i -P -n                  # every process with a network socket
sudo lsof -iTCP -sTCP:LISTEN -P -n  # TCP listeners only
sudo lsof -i :443                   # everything touching port 443

يعطّل -P و-n ترجمة أسماء المنافذ والمضيفات، وهي الفكرة نفسها الموجودة في -n ضمن ss -tulpn. الصيغة الثالثة هي الأكثر استخدامًا يوميًا: وجّهها إلى منفذ فتحصل على اسم الأمر والـ PID والمستخدم ومعرّف الملف في جدول واحد واضح. وخلافًا لـ ss، تسرد lsof أيضًا الاتصالات القائمة لكل عملية إلى جانب مقابسها المستمعة، ما يساعد عندما تريد معرفة مَن يتحدث حاليًا إلى خدمة ما، لا مجرد وجود الخدمة.

nmap: الاستماع لا يعني إمكانية الوصول

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

نفّذ الفحص من جهاز آخر موجّهًا إلى عنوان IP العام للخادم:

nmap 203.0.113.10                            # top 1000 TCP ports
nmap -p- 203.0.113.10                        # all 65535 TCP ports
sudo nmap -sU --top-ports 100 203.0.113.10   # common UDP ports (slow)

يبلّغ nmap عن ثلاث حالات يجدر فهمها: open تعني أن خدمة استجابت، وclosed تعني أن الحزمة وصلت لكن لا شيء يستمع هناك، وfiltered تعني أن الحزمة أُسقطت بصمت، وغالبًا بواسطة جدار حماية. والمنفذ الذي تُظهره ss بحالة LISTEN بينما يبلّغ nmap عن بُعد بأنه filtered هو تمامًا شكل جدار الحماية الذي يعمل. وهناك قاعدة لا استثناء لها: افحص فقط المضيفات التي تملكها أو المصرّح لك صراحةً باختبارها.

تحديد العملية التي تحتجز منفذًا بدقة

لنفترض أن شيئًا يحتل المنفذ 8080 ولا يستطيع تطبيقك الارتباط به. ثلاث طرق تؤدي إلى الـ PID:

sudo ss -tlnp 'sport = :8080'
sudo lsof -i :8080
sudo fuser -v 8080/tcp

fuser هي الأكثر إيجازًا: تطبع الـ PID، ويضيف -v المستخدم واسم الأمر. بل يمكنها قتل العملية المخالفة مباشرة بـ fuser -k 8080/tcp، لكن ذلك يرسل إشارة دون أي تنظيف على مستوى الخدمة، فاعتبره الحل الأخير. وبعد حصولك على الـ PID، يعرض ps -fp PID سطر الأمر الكامل، ويخبرك systemctl status PID بوحدة systemd التي أنشأته.

وعندما لا تتوفر أي أدوات على الإطلاق (كصورة حاوية مجرّدة مثلًا)، يبقى جدول النواة نفسه متاحًا: cat /proc/net/tcp. تظهر المنافذ بالنظام الست عشري (0016 يساوي 22) والحالة 0A تعني LISTEN. وهذا الجدول الخام هو البيانات ذاتها التي تحللها الأدوات الأخرى وتنسّقها لك.

كل ما يرتبط بمقبس يظهر في هذه القوائم بالطريقة نفسها، سواء كان قاعدة بيانات أو منظومة وكيل؛ فمدخل V2Ray، مثلًا، ليس إلا مستمعًا آخر على المنفذ الذي ضبطته، كما نوضح في دليل بروتوكول V2Ray.

إغلاق منفذ مفتوح: kill مقابل جدار الحماية

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

الحل النظيف هو إيقاف الخدمة المالكة للمقبس وتعطيلها. قتل الـ PID يبدو أسرع لكنه نادرًا ما يصمد: يعيد systemd تشغيل الخدمات الخاضعة لإشرافه تلقائيًا، ويعود المنفذ قبل أن تعيد تنفيذ ss. احتفظ بـ kill للعمليات التي شغّلتها يدويًا. ولمعرفة ما يعمل وإيقاف ما لا تحتاجه، يغطي دليلنا حول سرد الخدمات باستخدام systemctl هذا الإجراء من أوله إلى آخره.

sudo systemctl stop cups
sudo systemctl disable cups

ويتولى جدار الحماية الرافعة الثانية. على Ubuntu، اسمح بـ SSH قبل تمكين ufw، وإلا حجبت نفسك عن الخادم:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

على أنظمة عائلة RHEL، تُسقط المنطقة الافتراضية في firewalld حركة المرور غير المطلوبة أصلًا؛ أزل أي منفذ فتحته سابقًا بـ firewall-cmd --permanent --remove-port=8080/tcp ثم firewall-cmd --reload. وهناك أمر ليس حلًا: نقل خدمة إلى منفذ غير قياسي. فهو يخفيك عن أكثر الفحوص تراخيًا ويقلل ضجيج السجلات، لكن nmap -p- يجد المنفذ الجديد في دقائق. الغموض ليس أمانًا. أغلق المنفذ أو احجبه بجدار الحماية.

تدقيق منافذ في خمس دقائق لخادم جديد

في أول تسجيل دخول إلى خادم جديد، ابدأ الجرد بـ sudo ss -tulpn. ينبغي أن يُظهر التثبيت الأدنى النظيف القليل جدًا: sshd على 22، وعلى التوزيعات التي تستخدم systemd-resolved، محوّل DNS مبدئي على 127.0.0.53:53. وأي شيء آخر يستحق تفسيرًا. ثم اتبع قائمة التحقق هذه:

1. حدّد كل مستمع باسم العملية والـ PID؛ وعطّل أي خدمة لم تطلبها.
2. راجع كل ارتباط بـ 0.0.0.0 أو [::]؛ فقواعد البيانات ولوحات الإدارة مكانها 127.0.0.1 إلا إذا كانت تخدم الشبكة فعلًا.
3. تعرّف على المنافذ الشائعة من النظرة الأولى: 22 لـ SSH، و80/443 للويب، و3306 لـ MySQL، و5432 لـ PostgreSQL، و6379 لـ Redis. والمنفذ 3389 هو سطح المكتب البعيد، وعلى Linux يعني أن xrdp يعمل، وقواعد تعريض هذا المنفذ وتحصينه هي موضوع دليل منفذ RDP 3389.
4. افحص عنوان IP العام من جهازك بـ nmap -p- وقارن النتيجة بقائمة ss؛ فكل اختلاف هو إما جدار حماية يؤدي عمله أو ارتباط بالحلقة المحلية.
5. أنهِ بجدار حماية يرفض افتراضيًا ولا يسمح إلا بالمنافذ التي اخترت عرضها بوعي.

وهذه صندوق الأدوات كاملًا، سطر واحد لكل أداة:

لا تتحول الأوامر إلى ردود فعل تلقائية إلا على جهاز تملك فيه صلاحيات root حقيقية ولا يمكن أن يتعطل فيه شيء مهم. وخادم VPS بنظام Linux من rdp.monster يمنحك هذه البيئة بالضبط: وصول إداري كامل، ومعالج وذاكرة مخصصان، وبنطاق ترددي غير محدود (بضوابط الاستخدام العادل)، وبدون KYC، ويصبح الخادم متصلًا بعد نحو 10 ثوانٍ من تأكيد الدفع، بسرعة تكفي لتنفيذ أول ss -tulpn عليه قبل أن تبرد قهوتك.

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

هل أحتاج إلى صلاحيات root لفحص المنافذ المفتوحة على Linux؟

لا لسرد المنافذ، نعم لمعرفة العملية المالكة لها.

يمكن لأي مستخدم تنفيذ ss -tuln أو قراءة /proc/net/tcp، لذا فقائمة المنافذ المستمعة ليست مخفية أبدًا. الحدّ يقع عند الخيار -p: بدون root، لا تكشف ss وlsof وfuser إلا العمليات التابعة لمستخدمك، وتظهر المقابس الأخرى بعمود عملية فارغ. أما في nmap، فيتطلب فحص SYN الافتراضي (-sS) صلاحيات root؛ والبديل غير المتميز هو فحص الاتصال (-sT)، وهو يعمل جيدًا لكنه أكثر ضجيجًا قليلًا.

كيف أتحقق من أن منفذًا محددًا مفتوح على خادم بعيد؟

استخدم netcat: الأمر nc -zv host port يعطي إجابة فورية.

يحاول nc -zv example.com 443 إنشاء اتصال TCP ويبلّغ بالنجاح أو الفشل دون إرسال بيانات. وإن لم تتوفر netcat، يكفي Bash وحده: timeout 3 bash -c '</dev/tcp/example.com/443' && echo open. وكلا الأسلوبين لا يثبت سوى أن شيئًا قبل الاتصال، ولا يقول شيئًا عن الخدمة التي استجابت أو عن سلامتها. أما في UDP فلا يوجد اختبار سريع موثوق، لأن المنفذ الصامت قد يكون مفتوحًا أو مُصفّى؛ استخدم nmap -sU هناك.

لماذا تُظهر ss منفذًا مستمعًا ولا أستطيع الاتصال من الخارج؟

المقبس مرتبط بالحلقة المحلية أو أن جدار حماية يُسقط حركة المرور.

افحص عمود Local Address أولًا: 127.0.0.1:PORT أو [::1]:PORT يعني أن الخدمة تقبل الاتصالات المحلية فقط، وهو أمر مقصود وشائع في قواعد البيانات. وإن كان الارتباط بـ 0.0.0.0، فالحزم تُصفّى في مكان ما على المسار: جدار حماية على المضيف مثل ufw أو firewalld أو nftables المباشرة، أو تصفية على حدود شبكة مزوّدك. وإذا أبلغ فحص nmap خارجي عن المنفذ بأنه filtered فذلك يؤكد وجود جدار حماية؛ أما closed فتعني أن حركة المرور تصل لكن لا شيء يستمع على تلك الواجهة.

ما المنافذ التي ينبغي أن تكون مفتوحة على خادم Linux جديد؟

واحد: SSH. وأي شيء آخر في تثبيت نظيف يستحق تفسيرًا.

ينبغي ألا يعرض تثبيت Debian أو Ubuntu أو Rocky الأدنى على الشبكة سوى sshd على المنفذ 22. ووجود محوّل DNS مبدئي على 127.0.0.53:53 (systemd-resolved) أمر طبيعي وغير قابل للوصول من الخارج. وتضيف صور السحابة أحيانًا وكيلًا أو خدمة مراقبة. حدّد كل مستمع بـ ss -tulpn وعطّل كل ما لم تطلبه. وكل خدمة تثبّتها بعد ذلك ينبغي أن ترتبط افتراضيًا بالحلقة المحلية إلا إذا كانت تحتاج فعلًا إلى خدمة الشبكة، مع جدار حماية لا يسمح إلا بما هو عام.