استكشاف الشبكة والمنافذ والخدمات مع Nmap

تسلم مازن إدارة أنظمة شركة سعودية صغيرة تبيع برمجيات للعيادات، اثني عشر موظفاً وثلاثة سيرفرات على مزود سحابي، ورثها عن زميل غادر دون أن يترك جرداً Inventory لما يعمل عليها. وفي أول أسبوع وصله استبيان أمني Security Questionnaire من مستشفى يريد التعاقد، فيه سؤال بسيط في ظاهره: «ما المنافذ Ports والخدمات المكشوفة على أنظمتكم للإنترنت؟». فتح مازن لوحة المزود فوجد قائمة بالسيرفرات فقط، لا قائمة بما يستمع على كل منها. وهنا أدرك أنه لا يعرف ما يعرفه أي مهاجم يمسح عنوانه في دقيقة: أي أبواب مفتوحة، وأي خدمة خلف كل باب، وبأي إصدار. والأداة التي تجيب عن هذا السؤال بالضبط اسمها Nmap، وهي أول ما يفتحه خبير الاختراق، وأول ما يجب أن يعرفه مدير النظام عن أنظمته قبل غيره.

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

• من أين جاء Nmap، ولماذا هو أداة الاستكشاف الأولى للمدافع قبل المهاجم.
• كيف يعمل فحص المنفذ Port Scan من الداخل: مصافحة TCP وفحص SYN نصف المفتوح.
• بناء مختبر من Containers نملكها بأربع خدمات مختلفة وجدار ناري Firewall.
• المرحلة الأولى: اكتشاف المضيفات Host Discovery، ومن يعمل على الشبكة.
• المرحلة الثانية: فحص المنافذ، والفرق الجوهري بين مفتوح ومغلق ومرشح.
• المرحلة الثالثة: كشف الخدمة والإصدار Version Detection، ولماذا هو نقطة البداية للثغرات.
• المرحلة الرابعة: محرك السكربتات NSE وفئاته بحسب الخطر على الهدف.
• التوقيت Timing والتخفي، وقراءة المخرجات وحفظها، والسياق السعودي، وقائمة تحقق وأخطاء شائعة.

والصورة التالية تلخص مسار مازن: أربع مراحل متتالية، كل مرحلة تجيب عن سؤال أعمق من سابقتها، على مختبر من أهداف يملكها:

من أين جاء Nmap، ولماذا يبدأ به المدافع؟

نشر Gordon Lyon، المعروف باسم Fyodor، أداة Nmap سنة 1997 في مجلة Phrack، وكانت فكرتها بسيطة: أداة واحدة سريعة تكتشف المضيفات الحية على شبكة وتعرف أي منافذ مفتوحة عليها. وقبلها كان على مدير الشبكة أن يجرب كل منفذ يدوياً أو يكتب سكربتات متفرقة. ومنذ ذلك الحين تطورت الأداة حتى صارت تكشف إصدار الخدمة خلف المنفذ، ونظام التشغيل، وتشغل سكربتات متخصصة، وهي اليوم المرجع الذي تبنى عليه أدوات أخرى كثيرة، ومفتوحة المصدر برخصة مشتقة من GPL، وتوثيقها الرسمي في كتاب Nmap من أفضل ما كتب في المجال.

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

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

ما المنفذ Port والخدمة Service أصلاً؟

قبل أن نفحص المنافذ، لنتفق على ما هي. عنوان IP يوصلك إلى الجهاز، لكن الجهاز الواحد يشغل خدمات كثيرة في وقت واحد: خادم ويب، وقاعدة بيانات، وخادم SSH للإدارة. فكيف تعرف حزمة قادمة أي خدمة تريد؟ الجواب هو المنفذ Port، وهو رقم من 0 إلى 65535 يميز كل خدمة داخل الجهاز. فإذا كان العنوان مثل عنوان مبنى، فالمنفذ مثل رقم الشقة داخله. وبعض الأرقام متفق عليها عالمياً: 80 للويب غير المشفر HTTP، و443 للويب المشفر HTTPS، و22 لـ SSH، و5432 لـ PostgreSQL، و6379 لـ Redis، وتنشر هيئة IANA قائمة هذه المنافذ المعروفة.

والخدمة Service هي البرنامج الذي «يستمع Listen» على منفذ ما وينتظر الاتصالات. فعندما نقول إن المنفذ 80 «مفتوح»، نعني أن برنامجاً، هو خادم الويب هنا، يستمع عليه ومستعد للرد. وعندما يكون «مغلقاً»، لا برنامج يستمع عليه. وهذا هو جوهر ما يكشفه Nmap: أي منافذ عليها برامج تستمع، وأي برنامج بالضبط. ومن هنا تأتي خطورة «المنفذ المفتوح غير المقصود»: خدمة تركها أحدهم تستمع على كل الواجهات بدل الواجهة الداخلية فقط، فصارت بوابة لم يخطط لها أحد، وهذا بالضبط ما خشي مازن أن يكون في سيرفراته.

كيف يعمل فحص المنفذ من الداخل؟

بعد أن عرف مازن ما المنفذ، أراد أن يفهم ما الذي يحدث فعلاً عندما «يفحص Nmap منفذاً»، لأن فهم الآلية يفسر لماذا بعض الفحوص أسرع وبعضها يحتاج صلاحية root، ولماذا تظهر حالة «مرشح» أحياناً. وكل شيء يبدأ من بروتوكول TCP.

عندما يريد برنامجان أن يتصلا عبر TCP، يتبادلان مصافحة ثلاثية Three-way Handshake: يرسل الأول حزمة SYN أي «أريد أن أبدأ»، فيرد الثاني بـ SYN/ACK أي «موافق، وأنا أيضاً»، ثم يرسل الأول ACK أي «تم»، وعندها يكتمل الاتصال وتبدأ الخدمة في العمل. وNmap يستغل هذه المصافحة ليعرف حالة المنفذ دون أن يحتاج بالضرورة إلى إكمالها، والصورة التالية تبين الفرق بين طريقتين:

• فحص SYN نصف المفتوح (-sS): يرسل Nmap حزمة SYN فقط، فإذا جاءه SYN/ACK علم أن المنفذ مفتوح، لكنه لا يكمل المصافحة، بل يرسل RST ليقطع الاتصال قبل أن يبدأ. ولذلك يسمى «نصف مفتوح Half-open»، وهو أسرع لأنه يرسل حزمتين بدل ثلاث، وأهدأ لأن الاتصال لم يكتمل فقد لا تسجله الخدمة في سجلاتها. وهذا هو الفحص الافتراضي في Nmap، لكنه يحتاج صلاحية root لأنه يبني حزماً خاماً Raw Packets بنفسه.
• فحص الاتصال الكامل (-sT): يترك Nmap نظام التشغيل يكمل المصافحة الثلاثية كاملة عبر استدعاء النظام العادي، فلا يحتاج root، لكنه أبطأ وأظهر لأن الاتصال اكتمل وغالباً سجل. يستخدمه Nmap تلقائياً عندما لا تملك صلاحيات خام.

وهذا يفسر ملاحظة مهمة: الفحص ليس «اختراقاً»، فهو لا يرسل إلا ما يرسله أي عميل يريد الاتصال، لكنه يفعل ذلك على آلاف المنافذ بسرعة. ومع ذلك يبقى الفحص دون إذن مخالفة في كثير من الأنظمة، لأنه محاولة وصول لم يأذن بها صاحب النظام، كما شرحنا في مقال المنهجية.

حالات المنفذ: مفتوح ومغلق ومرشح

من رد المنفذ على حزمة SYN، يستنتج Nmap حالته، والصورة التالية تبين الحالات الثلاث الأساسية:

• مفتوح open: رد المنفذ بـ SYN/ACK، أي أن خدمة تستمع عليه وترحب بالاتصال. وهذا ما تبحث عنه: باب مفتوح.
• مغلق closed: رد المنفذ بـ RST، أي أن الجهاز يعمل لكن لا خدمة على هذا المنفذ، فالباب غير موجود لكن الجدار موجود.
• مرشح filtered: لم يأت رد إطلاقاً، أو جاء رد ICMP يقول «المنفذ غير قابل للوصول»، ومعناه أن جداراً نارياً Firewall بينك وبين المنفذ أسقط الحزمة أو رفضها، فلا تعرف إن كانت هناك خدمة خلفه أم لا.

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

بناء المختبر: أربع خدمات وجدار ناري

لكي يتعلم مازن على بيئة آمنة تشبه بيئته، بنى مختبراً من Containers Docker على شبكة معزولة: Container للفحص، وثلاث خدمات حقيقية مختلفة (خادم ويب وقاعدة بيانات ومخزن مفتاح وقيمة)، وContainer رابع يمثل مضيفاً خلف جدار ناري. والصورة التالية تبين الخريطة بالعناوين الحقيقية التي ظهرت في التجربة:

ننشئ الشبكة والأهداف:

docker network create lab-net
docker run -d --name lab-web   --network lab-net nginx:1.31.6-alpine
docker run -d --name lab-redis --network lab-net redis:8-alpine
docker run -d --name lab-pg    --network lab-net -e POSTGRES_PASSWORD=labpass postgres:18-alpine
docker run -d --name lab-fw    --network lab-net --cap-add NET_ADMIN nginx:1.31.6-alpine
docker run -d --name scanner   --network lab-net debian:trixie-20261005-slim sleep infinity

ثم نثبت Nmap على Container الفحص، وعلى المضيف الرابع نضيف قاعدتي جدار ناري لنرى حالة «مرشح» بأعيننا لاحقاً:

docker exec -it scanner bash -c "apt-get update && apt-get install -y nmap"
docker exec lab-fw sh -c "apk add iptables && \
  iptables -A INPUT -p tcp --dport 8080 -j DROP && \
  iptables -A INPUT -p tcp --dport 9000 -j REJECT"

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

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

المرحلة الأولى: اكتشاف المضيفات Host Discovery

السؤال الأول الذي واجه مازن: ما الذي يعمل أصلاً على الشبكة؟ قبل أن تفحص منافذ جهاز، تحتاج أن تعرف الأجهزة الحية Live Hosts. والخيار -sn يفعل ذلك: يرسل نبضات خفيفة دون فحص أي منفذ، فيعطيك قائمة بالمضيفات التي ردت فقط:

nmap -sn 192.168.112.0/24

والمخرج كان كما يلي:

Nmap scan report for 192.168.112.1
Nmap scan report for lab-web.lab-net (192.168.112.3)
Nmap scan report for lab-redis.lab-net (192.168.112.4)
Nmap scan report for lab-pg.lab-net (192.168.112.5)
Nmap scan report for 7505cfff0c92 (192.168.112.2)
Nmap done: 256 IP addresses (5 hosts up) scanned in 3.01 seconds

في ثلاث ثوان فحص Nmap مئتين وستة وخمسين عنواناً، ووجد خمسة مضيفات تعمل. لنقرأ المخرج سطراً سطراً: العنوان 192.168.112.1 هو بوابة الشبكة Gateway التي ينشئها Docker، و192.168.112.2 هو Container الفحص نفسها بمعرفها، والثلاثة الباقية هي أهدافنا بأسمائها لأن Docker يوفر خدمة أسماء داخلية. والعبارة الأخيرة تلخص: خمسة مضيفات من أصل 256 عنواناً. وهذه الخطوة ثمينة في شبكة لا تعرف محتواها، فترسم خريطتها أولاً قبل أن تتعمق في أي جهاز.

ويعمل اكتشاف المضيفات بعدة أساليب بحسب موقعك، وفهمها يفسر لماذا ينجح الاكتشاف أحياناً ويفشل أحياناً. على نفس الشبكة المحلية يستخدم Nmap طلبات ARP، وهي الطبقة التي تربط عنوان IP بعنوان البطاقة الفعلي، فأي جهاز حي على الشبكة المحلية مضطر للرد عليها، ولذلك هي الأدق والأسرع ولا يمكن لجدار ناري عادي أن يمنعها. أما عبر الإنترنت فلا تصل ARP، فيرسل Nmap مزيجاً: نبضة ICMP echo وهي «ping» المعتادة، ونبضات TCP إلى منفذ 80 و443، ونبضة ICMP timestamp. والسبب في هذا المزيج أن كثيراً من مزودي السحابة والجدران النارية تمنع ICMP افتراضياً، فلو اعتمد Nmap على ping وحده لظن أن نصف الإنترنت معطل. وهنا تفهم لماذا احتجنا الخيار -Pn في التجربة السابقة: على خدمات الإنتاج الحديثة التي تتجاهل كل نبضات الاكتشاف، هو الطريق الوحيد لإجبار Nmap على الفحص.

تجربة: ماذا لو منع الهدف النبضات؟ الخيار -Pn

سأل مازن: ماذا لو كان السيرفر يعمل لكنه لا يرد على نبضات الاكتشاف لأن جداره الناري يمنعها؟ جرب أن يفحص عنواناً لا يرد:

nmap -p 80 192.168.112.200

Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 1.77 seconds

هنا رسالة مهمة يراها كل من يستخدم Nmap: Host seems down، أي أن Nmap لم ير رداً على نبضة الاكتشاف فافترض أن المضيف معطل ولم يكمل، واقترح عليك بنفسه الحل. فكثير من السيرفرات، خاصة خلف جدار ناري مضبوط، تتجاهل نبضات الاكتشاف عمداً، فلو توقفت عند هذه الرسالة لظننت أن سيرفرك معطل وهو يعمل. والحل الخيار -Pn الذي يقول لـ Nmap: «تخط مرحلة الاكتشاف، وعامل الهدف كأنه حي، وافحص منافذه مباشرة»:

nmap -Pn -p 80 192.168.112.200

مع -Pn يفحص Nmap المنافذ دون أن يسأل أولاً «هل أنت حي؟»، وهذا هو الخيار الذي ستحتاجه غالباً عند فحص سيرفرات الإنتاج الحديثة التي لا ترد على ICMP. وثمنه أن الفحص أبطأ قليلاً لأنه يفحص منافذ مضيف قد يكون معطلاً فعلاً دون أن يوفر الوقت بتخطيه مبكراً.

المرحلة الثانية: فحص المنافذ Port Scan

بعد أن عرف مازن من يعمل، انتقل إلى السؤال الثاني: أي منافذ مفتوحة على كل هدف؟ بدأ بالفحص الافتراضي على خادم الويب، وهو يفحص أكثر ألف منفذ شيوعاً:

nmap lab-web

Not shown: 999 closed tcp ports (reset)
PORT   STATE SERVICE
80/tcp open  http
Nmap done: 1 IP address (1 host up) scanned in 1.10 seconds

السطر الأول مهم: Not shown: 999 closed tcp ports (reset)، أي أن Nmap فحص ألف منفذ، وجد تسعمئة وتسعة وتسعين منها مغلقة ردت بـ RST، فلم يعرضها كلها حتى لا يغرقك، وعرض المفتوح فقط: المنفذ 80 يشغل http. وهذه الألف ليست أول ألف رقم، بل أكثر ألف منفذ شيوعاً في الواقع، اختارها Fyodor من فحص ملايين الأجهزة على الإنترنت، فتغطي أغلب الخدمات الحقيقية بأقل عدد من الحزم. وتتحكم في عدد المنافذ بثلاثة خيارات: -F للفحص السريع لأشهر مئة منفذ، و--top-ports N لأشهر N منفذ، و-p- لكل المنافذ الخمسة والستين ألفاً. والقاعدة: ابدأ بالفحص السريع لترى الصورة بسرعة، ثم اعمل فحصاً كاملاً -p- في الجرد الجاد، لأن الخدمة التي يخفيها أحدهم عمداً يضعها على منفذ غريب لن يظهر في أشهر ألف.

ثم فحص المنافذ المحددة التي تهمه على الأهداف الثلاثة معاً:

nmap -p 80,5432,6379 lab-web lab-redis lab-pg

Nmap scan report for lab-web (192.168.112.3)
PORT     STATE  SERVICE
80/tcp   open   http
5432/tcp closed postgresql
6379/tcp closed redis

Nmap scan report for lab-redis (192.168.112.4)
PORT     STATE  SERVICE
6379/tcp open   redis

Nmap scan report for lab-pg (192.168.112.5)
PORT     STATE  SERVICE
5432/tcp open   postgresql

كل هدف يفتح منفذاً واحداً فقط كما بنيناه. لكن انتبه إلى تفصيل مهم: عمود SERVICE هنا ليس حقيقة، بل تخمين من Nmap بناءً على رقم المنفذ فقط، من ملف جاهز يربط الأرقام بالخدمات المعتادة. فالمنفذ 6379 يسمى «redis» لأنه المنفذ المعتاد لـ Redis، لا لأن Nmap تحقق من ذلك. وهذا الفرق سبب وجود المرحلة الثالثة.

تجربة: كيف تبدو حالة «مرشح» فعلاً؟

الآن نفحص المضيف الذي وضعنا عليه جدار ناري، ونضيف الخيار --reason ليخبرنا لماذا قرر Nmap كل حالة:

nmap -p 80,8080,9000 --reason lab-fw

PORT     STATE    SERVICE    REASON
80/tcp   open     http       syn-ack ttl 64
8080/tcp filtered http-proxy no-response
9000/tcp filtered cslistener port-unreach ttl 64

هذا المخرج درس كامل في فهم الجدار الناري. المنفذ 80 مفتوح لأنه رد بـ syn-ack. والمنفذان الآخران كلاهما «مرشح»، لكن للسبب تفصيل: المنفذ 8080 سببه no-response لأن قاعدة DROP أسقطت الحزمة بصمت فلم يأت رد إطلاقاً، والمنفذ 9000 سببه port-unreach لأن قاعدة REJECT ردت بحزمة ICMP تقول «غير قابل للوصول». فالخيار --reason يحول المخرج من «ثق بي» إلى «إليك الدليل»، وهو أول ما تلجأ إليه عندما تشك في نتيجة.

المرحلة الثالثة: كشف الخدمة والإصدار Version Detection

وصل مازن إلى السؤال الأهم: ليس أي منفذ مفتوح فحسب، بل أي خدمة بالضبط وأي إصدار، لأن الثغرات ترتبط بالإصدار لا بالمنفذ. والخيار -sV يتجاوز التخمين: يتصل بكل منفذ مفتوح، ويرسل سلسلة من الاستجسات Probes، ويحلل الرد ويطابقه بقاعدة بصمات Nmap ليعرف الخدمة وإصدارها:

nmap -sV -p 80,5432,6379 lab-web lab-redis lab-pg

Nmap scan report for lab-web (192.168.112.3)
PORT   STATE SERVICE VERSION
80/tcp open  http    nginx 1.31.6

Nmap scan report for lab-redis (192.168.112.4)
PORT     STATE SERVICE VERSION
6379/tcp open  redis   Redis key-value store 8.10.2

Nmap scan report for lab-pg (192.168.112.5)
PORT     STATE SERVICE    VERSION
5432/tcp open  postgresql PostgreSQL DB 9.6.0 or later

الآن صار لدى مازن معلومة حقيقية لا تخميناً: nginx 1.31.6، وRedis 8.10.2، وPostgreSQL. ولاحظ رد قاعدة البيانات الذكي: PostgreSQL DB 9.6.0 or later، أي أن Nmap عرف نوعها لكنه لم يحدد الإصدار الدقيق، والسبب أن PostgreSQL لا تكشف إصدارها الكامل قبل المصادقة، وهذا سلوك أمني جيد منها. أما Redis فكشفت إصدارها الدقيق لأنها مفتوحة دون كلمة مرور، وتلك إشارة إلى مشكلة سنعود إليها.

وكيف يعرف Nmap الخدمة أصلاً؟ لا يكتفي بأن المنفذ 80 «يفترض أنه http»، بل يفتح اتصالاً ويرسل سلسلة استجسات Probes من ملف ضخم اسمه nmap-service-probes، فيه آلاف البصمات: أرسل هذا النص، وإذا جاء رد يطابق هذا النمط فالخدمة كذا وإصدارها كذا. فحين يرد خادم الويب بترويسة Server: nginx/1.31.6 يطابقها Nmap ببصمة معروفة فيستخرج الاسم والإصدار. وهذا يفسر لماذا يكشف الإصدار خدمة تعمل على منفذ غير معتاد أيضاً: لو شغلت خادم ويب على المنفذ 8899، لعرفه -sV من رده لا من رقم المنفذ، وهذا ما يفوت التخمين البسيط القائم على الرقم وحده.

وهذه الأسطر، الخدمة والإصدار، هي نقطة البداية لكل ما يلي: تأخذ «nginx 1.31.6» وتبحث عن ثغراتها في قواعد الثغرات التي شرحناها، فتعرف إن كان إصدارك متأثراً بثغرة منشورة. ولذلك فإن -sV هو الجسر بين الاستكشاف وإدارة الثغرات.

ويتحكم الخيار --version-intensity من 0 إلى 9 في عدد الاستجسات التي يرسلها Nmap ليعرف الإصدار: الأعلى أدق لكنه أبطأ وأظهر. وفي المختبر جربنا الطرفين على Redis:

nmap -sV --version-intensity 0 -p6379 lab-redis   # Redis key-value store 8.10.2
nmap -sV --version-intensity 9 -p6379 lab-redis   # Redis key-value store 8.10.2

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

كشف نظام التشغيل والفحص الشامل

أراد مازن صورة أشمل، فجرب الفحص العدواني -A الذي يجمع كشف الإصدار وكشف نظام التشغيل والسكربتات الافتراضية ومسار الحزم Traceroute في أمر واحد:

nmap -A -p 80 lab-web

80/tcp open  http    nginx 1.31.6
|_http-server-header: nginx/1.31.6
|_http-title: Welcome to nginx!
Warning: OSScan results may be unreliable because we could not find
  at least 1 open and 1 closed port
Running: Linux 4.X|5.X, MikroTik RouterOS 7.X
OS details: Linux 4.15 - 5.19, OpenWrt 21.02 (Linux 5.4), ...
Network Distance: 1 hop

هنا ظهر درس في حدود الأداة. كشف نظام التشغيل -O يعمل بتحليل تفاصيل دقيقة في حزم TCP، ويحتاج أن يجد منفذاً مفتوحاً وآخر مغلقاً ليقارن. وداخل Container Docker تشارك نواة Kernel المضيف وتمر عبر شبكة افتراضية، فجاء التخمين غير دقيق، ونبه Nmap نفسه بذلك في سطر Warning: OSScan results may be unreliable. وهذه أمانة من الأداة يجب أن تنقلها إلى تقريرك: كشف نظام التشغيل تقديري دائماً، وأقل دقة داخل الـ Containers والشبكات الافتراضية، فلا تبن عليه قراراً دون تأكيد.

المرحلة الرابعة: محرك السكربتات NSE

أقوى ما في Nmap لم يره مازن بعد: محرك السكربتات Nmap Scripting Engine، واختصاراً NSE. فبعد أن يعرف المنفذ مفتوحاً وخدمته معروفة، يستطيع سكربت متخصص أن يسأل الخدمة أسئلة أعمق: ما عنوان صفحة الويب، وما الطرق المسموحة، وما تفاصيل شهادة TLS، وما معلومات Redis. ويأتي مع Nmap أكثر من ستمئة سكربت جاهز، مكتوبة بلغة Lua، مصنفة في فئات بحسب خطرها على الهدف، والصورة التالية تبينها:

بدأ مازن بالفئة الآمنة عبر الخيار -sC الذي يشغل مجموعة السكربتات الافتراضية، وكلها للقراءة فقط:

nmap -sV -sC -p 80 lab-web

80/tcp open  http    nginx 1.31.6
|_http-title: Welcome to nginx!
|_http-server-header: nginx/1.31.6

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

nmap -p80 --script http-headers lab-web

| http-headers:
|   Server: nginx/1.31.6
|   Date: Sun, 25 Oct 2026 22:40:58 GMT
|   Content-Type: text/html
|   Content-Length: 896

ثم وجه سكربت معلومات Redis إلى المخزن المفتوح، وهنا ظهرت المشكلة التي لمح إليها كشف الإصدار:

nmap -p 6379 --script redis-info lab-redis

6379/tcp open  redis
| redis-info:
|   Version: 8.10.2
|   Operating System: Linux 5.15.167.4-microsoft-standard-WSL2 x86_64
|   Used memory: 1.36M

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

وكيف تعرف ما السكربتات المتاحة لخدمة ما؟ تأتي السكربتات ملفات في مجلد Nmap، وتبحث فيها بالاسم أو الفئة، وتقرأ ما يفعله كل سكربت قبل تشغيله:

nmap --script-help "redis-*"        # ماذا يفعل كل سكربت redis
nmap --script "http-* and safe" -p80 lab-web   # كل سكربتات http الآمنة
sudo nmap --script-updatedb         # تحديث فهرس السكربتات بعد إضافة واحد

ولاحظ تعبير "http-* and safe": تستطيع أن تجمع بين النمط والفئة بمنطق بسيط، فتشغل كل سكربتات الويب التي صنفت آمنة فقط، وهذه طريقة عملية لتوسيع الفحص دون أن تخاطر بسكربت متطفل. واقرأ دائماً وصف السكربت بـ --script-help قبل أن توجهه إلى خدمة لا تملكها، فبعض ما يبدو من اسمه بريئاً مصنف intrusive.

التوقيت Timing والتخفي

سأل مازن: هل يمكن أن يسبب فحصي عبئاً على السيرفر؟ نعم، والتحكم في ذلك عبر قوالب التوقيت Timing Templates من -T0 الأبطأ والأخفى إلى -T5 الأسرع والأعنف، والافتراضي -T3. جرب مازن قالبين على هدفين:

nmap -T2 -p 80,6379 lab-web lab-redis   # scanned in 1.84 seconds
nmap -T4 -p 80,6379 lab-web lab-redis   # scanned in 0.87 seconds

الفرق واضح في الزمن، لكن الأسرع يعني حزماً أكثر في الثانية، وهو ما قد يرهق خدمة ضعيفة أو يطلق تنبيهاً في نظام المراقبة. وما الذي يغيره -T فعلاً؟ ليس رقماً واحداً، بل مجموعة إعدادات: كم استجساً يرسل في آن واحد Parallelism، وكم ينتظر رد كل منفذ قبل أن ييأس Timeout، وكم يفصل بين الحزم. فالقالب الأبطأ -T0 قد يرسل حزمة كل عدة دقائق ليتسلل تحت أنظار المراقبة، والأسرع -T5 يرسل بأقصى ما تحتمله الشبكة فيضحي بالدقة من أجل السرعة وقد يفوت منافذ على شبكة بطيئة. والقاعدة العملية: -T4 مناسب للشبكات المحلية السريعة والمختبرات، و-T3 أو أبطأ على خدمات إنتاج حساسة أو عبر الإنترنت. والتوقيت البطيء ليس للتخفي عن المدافع فقط، بل أيضاً احترام للخدمة التي تفحصها، فخدمة قديمة قد تسقط تحت فحص عنيف، وهذا سبب إضافي لألا توجه -T5 إلى نظام إنتاج لا تملك رفاهية إسقاطه.

لماذا لا يكفي فحص TCP؟ المنافذ على UDP

كل ما سبق كان على بروتوكول TCP، لكن خدمات مهمة تعمل على UDP: خادم الأسماء DNS على المنفذ 53، ومزامنة الوقت NTP على 123، وبروتوكول إدارة الشبكة SNMP على 161، وهو بروتوكول كثيراً ما يكشف معلومات حساسة إذا ترك بإعداده الافتراضي. وفحص UDP مختلف جوهرياً وأبطأ بكثير، والسبب في طبيعة البروتوكول: TCP يرد دائماً، بـ SYN/ACK أو RST، أما UDP فالخدمة المفتوحة قد لا ترد إطلاقاً، فلا يستطيع Nmap أن يميز بسهولة بين «مفتوح لكنه صامت» و«مرشح خلف جدار ناري»، فيضعهما معاً في حالة open|filtered. جرب مازن فحص UDP على خادم الويب:

nmap -sU --top-ports 5 lab-web

PORT    STATE  SERVICE
123/udp closed ntp
137/udp closed netbios-ns
138/udp closed netbios-dgm
161/udp closed snmp
631/udp closed ipp
Nmap done: 1 IP address (1 host up) scanned in 2.41 seconds

كل المنافذ مغلقة لأن nginx لا يشغل أي خدمة UDP، وظهرت الحالة closed لأن نواة النظام ردت بـ ICMP تقول «المنفذ غير قابل للوصول». ولاحظ أن فحص خمسة منافذ UDP استغرق أطول من فحص ألف منفذ TCP، لأن Nmap ينتظر مهلة لكل منفذ صامت قبل أن يقرر، ولذلك لا تفحص كل منافذ UDP الخمسة والستين ألفاً إلا لضرورة، بل اكتف بالمنافذ المهمة. والقاعدة: لا تنس UDP في جردك، فمنفذ SNMP أو DNS مكشوف قد يكون أخطر من منفذ TCP، لكن افحصه بذكاء لا بالكامل.

قراءة المخرجات وحفظها

في اختبار حقيقي أو جرد دوري، لا يكفي أن ترى المخرج على الشاشة، بل تحتاج أن تحفظه للتقرير وللمقارنة لاحقاً. يدعم Nmap عدة صيغ، وأفيدها -oA التي تحفظ ثلاث صيغ دفعة واحدة بالاسم نفسه: نصية عادية للقراءة، وصيغة قابلة للبحث بـ grep، وXML للأدوات. والصيغة القابلة للبحث مفيدة جداً للأتمتة:

nmap -p 80,6379 -oG - lab-web lab-redis

Host: 192.168.112.3 (lab-web.lab-net)   Ports: 80/open/tcp//http///, 6379/closed/tcp//redis///
Host: 192.168.112.4 (lab-redis.lab-net) Ports: 80/closed/tcp//http///, 6379/open/tcp//redis///

كل مضيف في سطر واحد، تستطيع أن تبحث فيه عن المنافذ المفتوحة بأدوات النصوص مباشرة. وفي الفحص الحقيقي استخدم -oA scan-name من البداية مع الخيار -p- الذي يفحص كل المنافذ الخمسة والستين ألفاً بدل الشائعة فقط، فقد تعمل خدمة منسية على منفذ غريب:

nmap -sV -sC -p- -oA company-web-scan lab-web

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

Nmap ليس كل شيء: حدوده وأدوات تكمله

أعجب مازن بالأداة، لكنه أراد أن يعرف حدودها حتى لا يبني عليها أكثر مما تحتمل. وأهم ما يجب أن تعرفه:

• الفحص ليس استغلالاً: Nmap يخبرك أن المنفذ مفتوح وأن إصداره كذا، لكنه لا يثبت أن الإصدار قابل للاستغلال فعلاً، فذلك عمل مرحلة الاستغلال في اختبار الاختراق. الفحص يرسم الخريطة، ولا يفتح الأبواب.
• الجدار الناري يحجب الرؤية: كما رأينا، المنفذ المرشح قد يخفي خدمة. وNmap يوفر أساليب تهرب Evasion مثل تجزئة الحزم -f والطعوم Decoys، لكن استخدامها على نظام لا تملكه مخالفة، وعلى نظامك هي اختبار لجدارك لا أكثر. والقاعدة أن النتيجة «مرشح» معلومة في ذاتها: جدارك يعمل.
• السرعة على نطاقات ضخمة: لفحص منفذ واحد على ملايين العناوين بسرعة فائقة، صممت أدوات متخصصة مثل masscan وnaabu وRustScan، لكنها تكتفي باكتشاف المنفذ المفتوح، ثم يأتي Nmap لكشف الإصدار والسكربتات على ما وجدته. فالأدوات تتكامل: السريعة للعرض، وNmap للعمق.
• كشف نظام التشغيل تقديري: كما رأينا في الفحص العدواني، -O تخمين إحصائي، وأقل دقة في الحاويات والشبكات الافتراضية.

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

السياق السعودي: الفحص والجرد في ضوابط NCA

استخدام مازن لـ Nmap على سيرفراته ليس مجرد عادة جيدة، بل جزء مما تتوقعه الجهات المنظمة. فمعرفة الأصول وما يعمل عليها أساس أي برنامج أمني، والضوابط الأساسية للأمن السيبراني NCA ECC تتطلب في مكونها الفرعي 2-11 اختبار الاختراق Penetration Testing بأن يشمل نطاقه، بحسب البند 2-11-3-1، كل الخدمات المقدمة عبر الإنترنت ومكوناتها التقنية، وأن يجرى دورياً بحسب البند 2-11-3-2، والنص الرسمي في وثيقة ECC-2:2024. وفحص المنافذ والخدمات خطوة أولى في أي اختبار من هذا النوع.

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

مازن يفحص سيرفره الحقيقي

بعد أن أتقن مازن الأداة على المختبر، طبق ما تعلمه على سيرفراته الثلاثة التي يملكها، لأنها ملكه فالإذن قائم، ولأن هذا بالضبط ما سأل عنه استبيان المستشفى. بدأ باكتشاف المضيفات على الشبكة الخاصة لمزوده ليرسم خريطة ما يعمل، ثم فحص كل منفذ -p- على كل سيرفر مع كشف الإصدار -sV من خارج الشبكة الخاصة، أي من حيث يرى المهاجم تماماً، وحفظ كل شيء بـ -oA.

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

أغلق مازن المنفذ في اليوم نفسه: ربط Redis بالعنوان المحلي والشبكة الخاصة فقط، وأضاف قاعدة جدار ناري، ووضع كلمة مرور، ثم أعاد الفحص وحفظ النتيجة الجديدة ليقارن. وهكذا تحول سؤال الاستبيان من مصدر قلق إلى إجابة موثقة: هذه منافذنا المكشوفة، وهذا ما أغلقناه، وهذا فحص قبل وبعد يثبته. هذه هي القيمة الحقيقية لـ Nmap للمدافع: لا أن «يخترق»، بل أن يرى قبل غيره فيغلق قبل أن يستغل.

قائمة تحقق Checklist وجدول القرار

بعد أن أنهى مازن تعلمه، لخص لنفسه كيف يستخدم Nmap على سيرفره الحقيقي الذي يملكه:

• ابدأ باكتشاف المضيفات -sn على نطاقك لترسم خريطة ما يعمل.
• افحص كل المنافذ -p- لا الشائعة فقط، فالخدمة المنسية تختبئ في منفذ غريب.
• أضف كشف الإصدار -sV دائماً، فالاسم بلا إصدار تخمين لا يفيد في البحث عن ثغرات.
• استخدم --reason عندما تشك في حالة منفذ، لترى لماذا قرر Nmap ما قرر.
• التزم بـ -sC والفئة الآمنة خارج بيئتك، ولا تشغل سكربتات متطفلة أو استغلالية إلا على ما تملكه وبإذن.
• اضبط التوقيت بحسب الهدف: -T4 للمختبر، و-T3 أو أبطأ لخدمات الإنتاج والإنترنت.
• احفظ النتيجة بـ -oA وسجل إصدار Nmap، وقارن مع فحص سابق لتكتشف أي منفذ جديد.
• عالج ما تجده: منفذ قاعدة بيانات أو خدمة داخلية مكشوفة للإنترنت تغلق اليوم.

أخطاء شائعة Common Mistakes

• الاكتفاء بالمنافذ الشائعة: الفحص الافتراضي ألف منفذ فقط، وقد تعمل خدمة على منفذ غريب، فاستخدم -p- للجرد الكامل.
• الثقة بعمود SERVICE دون -sV: الاسم بلا كشف إصدار تخمين من رقم المنفذ، وقد تعمل خدمة مختلفة تماماً عليه.
• الخلط بين closed وfiltered: المغلق لا خدمة، والمرشح جدار ناري يحجب الرؤية وقد يخفي خدمة.
• تشغيل سكربتات متطفلة على الإنتاج: فئة intrusive أو exploit قد توقف خدمة حقيقية.
• الثقة العمياء بكشف نظام التشغيل: -O تقديري، وأقل دقة داخل الـ Containers والشبكات الافتراضية، وNmap نفسه ينبهك.
• نسيان حفظ المخرجات: ابدأ بـ -oA بدل إعادة الفحص لاحقاً لكتابة التقرير.

حذف المختبر Cleanup

من قواعد العمل أن تحذف بيئة الاختبار بعد كل مهمة:

docker rm -f scanner lab-web lab-redis lab-pg lab-fw
docker network rm lab-net

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما تعلمه مازن:

• Nmap يجيب عن أربعة أسئلة بالترتيب: من يعمل، وأي منفذ مفتوح، وأي خدمة وإصدار، وماذا نعرف أكثر بالسكربتات.
• الفحص يرسل SYN ويقرأ الرد: SYN/ACK مفتوح، وRST مغلق، ولا رد مرشح، والفرق بين المغلق والمرشح جوهري.
• كشف الإصدار -sV هو الجسر إلى إدارة الثغرات، وفي المختبر كشف nginx 1.31.6 وRedis 8.10.2 وPostgreSQL.
• محرك NSE يضيف فحوصاً متخصصة بفئات متدرجة الخطر، وسكربت redis-info كشف خدمة مفتوحة دون استغلال.
• الأداة نفسها سلاح للمهاجم ومصباح للمدافع، والفرق أن تستخدمها ضد ما تملكه، بإذن، قبل أن يستخدمها غيرك.

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

دليلKali Linux في Docker وأدوات الفريق الأحمر الأساسيةنرافق مسؤول نظم وهو يبني محطة Kali في Docker ويوجه أدواتها إلى مختبر يملكه، فيكشف gobuster مجلدات مخفية وتجد hydra كلمة مرور ضعيفة.دليلاختبار الاختراق المصرح به: المنهجية والإذن والتقريريواجه مسؤول نظم طلب المستشفى باختبار اختراق سنوي، فنرافقه وهو يفهم الإذن والنطاق وقواعد الاشتباك وبنية التقرير قبل أن يبدأ.دليلتقوية السيرفر Hardening وقياسها مع Lynis ومعايير CISالتقوية حالة تقاس برقم لا شعور، فنقيس خادم Debian قبل وبعد بأداتي Lynis وCIS ونرى الفرق على السيرفر نفسه.دليلإدارة الثغرات Vulnerability Management: هل سيرفرك متأثر؟كيف تعرف خلال ساعات أن ثغرة جديدة تمس سيرفراتك، ولماذا يخدعك رقم الإصدار، وكيف ترتب الإصلاح وتتأكد أنه تم فعلاً.دليلمصطلحات الأمن السيبراني للمبتدئين: من CVE إلى Purple Teamماذا تعني الكلمات التي تتكرر في كل عرض أمني، من رقم الثغرة وخطورتها إلى أدوات المراقبة SOC والفرق الحمراء والزرقاء.

تدريب عملي Practice

• ابن المختبر، وشغل nmap -sV -sC -p- --reason على أحد الأهداف، واقرأ كل سطر، وحدد أي خدمة تكشف عن نفسها أكثر مما يجب.
• افحص سيرفرك الذي تملكه من خارج شبكته الخاصة بـ Nmap، وقارن المنافذ المفتوحة بما تظنه مفتوحاً، فكثيراً ما تجد مفاجأة تصلحها.
• احفظ فحص سيرفرك بـ -oA، ثم أعده بعد أسبوع وقارن الملفين، وتأمل أي فرق.

سجل التحديثات

• أكتوبر 2026: كتابة المقال وتنفيذ المختبر يوم 26 أكتوبر 2026 على Nmap 7.95 في Docker، ضد أربعة أهداف: nginx 1.31.6 وRedis 8.10.2 وPostgreSQL ومضيف بجدار ناري iptables، على شبكة Docker معزولة، مع مخرجات اكتشاف المضيفات وفحص المنافذ وكشف الإصدار وسكربتات NSE وحالة filtered الحقيقية.