Nmap في لاب Active Directory: وش تثبت المنافذ المفتوحة، ووش ما تقدر تحكم عليه؟

عندك Domain Controller في لابك، وأداة LDAP ترفض الاتصال. تشغل Nmap وتطلع لك منافذ مفتوحة، فتحتار: إذا الجهاز متاح، ليش الأداة ما تشتغل؟ المشكلة هنا غالبًا في السؤال اللي طلبته من الفحص. فحص المنفذ يساعدك تعرف جزءًا من الطريق، لكنه ما يفحص كل شيء يحصل بعد الوصول.
خلنا نشتغل على حالة محددة: جهاز فحص واحد وخادم واحد تملكه، والمطلوب فهم إمكانية الوصول إلى خدمات معروفة. بنقرأ النتائج كأدلة صغيرة نربطها ببعض، بدل ما نعامل قائمة المنافذ كأنها تقرير اختراق أو شهادة سلامة للدومين. هذا الفرق يفيدك في لاب CRTP وCRTE، وفي أي مراجعة مهنية تحتاج فيها تفسر سبب فشل أداة قبل ما تغير إعداداتها.

ابدأ بوصف المشكلة قبل اختيار الأمر

اكتب المشكلة بصيغة تقدر تختبرها: من جهاز LAB-CLIENT لا يكتمل اتصال التطبيق إلى dc01.lab.test عبر LDAP. هذه الجملة فيها جهاز مصدر، واسم وجهة، وخدمة مقصودة. أما عبارة الدومين خربان، فهي واسعة لدرجة أن أي نتيجة بتبدو مرتبطة بها. قد يكون الخادم يعمل بشكل طبيعي، بينما جهازك يستخدم محلل أسماء مختلفًا أو يتجه إلى عنوان قديم.
سجل عنوان الجهاز المصدر، والعنوان الذي يحل إليه اسم الخادم، ووقت المحاولة. ما تحتاج تجمع معلومات عن كامل الشبكة عشان تفهم اتصالًا واحدًا. إذا كان عندك أكثر من واجهة، مثل واجهة اللاب وواجهة الإنترنت وVPN، انتبه إلى أن الفحص قد يخرج من مسار غير الذي تتوقعه. تشابه أسماء الشبكات الافتراضية ما يكفي لتحديد الطريق الفعلي.
حدد أيضًا ما المقصود بالنجاح. هل تريد إثبات وصول TCP؟ أم نجاح المصادقة؟ أم قراءة كائن من الدليل؟ كل مرحلة تحتاج دليلًا مختلفًا. لو المطلوب الأخير، فتح المنفذ بداية مفيدة، لكنه ما يحل محل طلب قراءة مصرح باستخدام حساب اللاب.
في ملاحظاتك، افصل المتوقع عن المشاهد. المتوقع أن هذا الخادم يقدم LDAP وفق تصميم اللاب. المشاهد حاليًا أن التطبيق يعطي مهلة انتظار. هذا الفصل يمنعك تكتب تفسيرًا قبل إجراء الاختبار، ويسهل مراجعة قرارك لو ظهرت نتيجة تناقض الفرضية الأولى.

فحص صغير لهدف واحد تملكه

في المثال التالي الاسم والعناوين تخص لابًا معزولًا تملكه، والفحص محدد على خادم واحد. تأكد أن الاسم يحل إلى جهاز اللاب الصحيح قبل التشغيل، ولا تنقل الأمر إلى نطاق خارجي أو جهاز عميل بدون نطاق اختبار واضح:
nmap -sT -p 88,389,445,636 -oN lab-ad-ports.txt dc01.lab.test
اختيار -sT هنا يحدد فحص اتصال TCP. الخيار -p يحصر قائمة المنافذ، و-oN يحفظ خرجًا نصيًا للمراجعة. القائمة ليست كل منافذ Active Directory، ولا تصلح بوصفها فحصًا شاملًا للدومين. اخترنا عددًا محدودًا يناسب النقاش، وليس وصفة ثابتة لكل مشكلة.
الفكرة العملية من هذا التحديد أنك تعرف بالضبط ما سألته وما تركته خارج الفحص. إذا كانت المشكلة في خدمة أخرى، عدل السؤال أولًا ثم اختر منفذها المصرح. لا تضف قائمة كبيرة لمجرد أنها موجودة في ملاحظات دورة تدريبية. كثرة النتائج قد تخفي السؤال الأصلي، وتزيد العمل المطلوب لتفسير أمور ما لها علاقة بالمشكلة.
حتى الفحص المحدود يرسل اتصالات فعلية ويمكن أن يظهر في سجلات الشبكة أو الخادم. لا تصفه بأنه قراءة محلية أو عملية بلا أثر. في اللاب تقدر تنسق المحاولة مع وقت ملاحظاتك، ثم تقارن ما ظهر في الخادم. هذا تدريب مفيد على توثيق النشاط الطبيعي للأداة، وليس محاولة إخفاء استخدامها.

open لا تعني أنك دخلت الدومين

إذا ظهرت 389/tcp بحالة open، فهذا يدعم أن اتصالًا إلى ذلك المنفذ كان متاحًا من موضع الفحص وقت المحاولة. لكنه ما يثبت أن حسابك صحيح، أو أن التطبيق يطلب المصادقة المناسبة، أو أن استعلامه داخل قاعدة بحث صحيحة. الوصول والهوية والصلاحية أجزاء مختلفة من العملية.
وش المقصود هنا؟ تخيل باب استقبال مبنى مفتوحًا. هذا يفيدك أن الوصول إلى الاستقبال ممكن، لكنه ما يحدد الغرف المسموح لك دخولها. المثال يساعد في تصور الفصل بين الطبقات، لكن في التطبيق نحتاج أدلة فعلية: نتيجة اتصال، ثم استجابة بروتوكول، ثم نتيجة مصادقة، ثم نتيجة الطلب المحدد.
إذا ظهر 445 مفتوحًا، لا تكتب مباشرة أن مشاركة ملفات حساسة مكشوفة. ما اختبرت مشاركة محددة ولا حسابًا محددًا. وحتى نجاح اتصال إلى SMB ما يثبت أن سياسة خدمة أخرى في الجهاز متساهلة. اكتب ما حصل فعلًا، وبعدها ضع السؤال التالي المناسب ضمن حدود اللاب.
الخطأ المتكرر هو الانتقال من منفذ مفتوح إلى تصنيف خطورة. المنفذ قد يكون مطلوبًا لوظيفة الخادم. تقييمه يحتاج معرفة من يستطيع الوصول، وما الخدمة الفعلية، وما العمليات المتاحة، وهل هذا يتفق مع التصميم. قائمة المنافذ تساعدك ترتب الاختبارات، لكنها ما تحمل هذه الإجابات كلها داخل كلمة open.

closed وfiltered نتيجتان مختلفتان

بحسب وصف Nmap، closed تدل على منفذ أمكن الوصول إليه لكنه لا يقدم مستمعًا في نتيجة الفحص. filtered تعني أن الفحص لم يستطع تحديد كونه مفتوحًا بسبب ترشيح الاتصال. اقرأ الكلمتين كما هما، ولا تختصرهما في عبارة الجهاز طافي. حالة المنفذ تعبر عن رؤية الأداة من موقعها، وليست صفة أبدية للخادم.
لو كانت 636 مغلقة و389 مفتوحة، لا تقفز إلى أن شهادة الخادم معطوبة. قد لا يكون مستمع الخدمة المشفرة متاحًا أصلًا، وقد يكون تصميم اللاب لا يتضمنه. تحتاج مراجعة تصميم الخادم وملاحظة المسؤول في بيئة الاختبار قبل بناء استنتاج يخص الشهادات. فشل الوصول يقع قبل خطوات كثيرة تتعلق بالمصادقة.
أما إذا ظهرت 389 filtered من جهاز، ومفتوحة من جهاز آخر مصرح، فالمقارنة توجهك إلى اختلاف المسار أو السياسات بين الموضعين. لا تجعلها دليلًا أن أحد الفحصين كاذب. النتائج قد تكون متوافقة تمامًا مع وجود حدود شبكية مقصودة بين مجموعتين من الأجهزة.
في التقرير اذكر المصدر مع النتيجة. عبارة المنفذ محجوب من LAB-CLIENT أدق من المنفذ محجوب عند الجميع. إذا ما اختبرت إلا مصدرًا واحدًا، لا توسع الاستنتاج ليشمل بقية الشبكة. حدود الدليل ليست ضعفًا في التقرير؛ هي اللي تخلي القارئ يعرف أين يحتاج اختبارًا إضافيًا.

اسم الخدمة في العمود مو إثبات هوية الخادم

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

منافذ Active Directory ترتبط بوظائف مختلفة

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

سيناريو: LDAP متاح لكن الطلب يفشل

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

سيناريو ثانٍ: نتيجتان من مسارين مختلفين

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

وثّق ما يسمح بإعادة الفحص

احفظ الأمر والخرج ووقت التشغيل ونسخة الأداة التي استخدمتها، ووصف موضع الجهاز المصدر. ملف نصي اسمه lab-ad-ports.txt مفيد، لكنه ما يكفي وحده لو نسيت من أي شبكة شغلته أو تغير عنوان الخادم لاحقًا. البيانات اللي تسجلها لازم تساعدك تفسر النتيجة بعد يومين، لا فقط تتذكر أنك شغلت Nmap.
اكتب بجانب النتيجة ما لم يشمله الفحص: لا يوجد اختبار حسابات في هذه المحاولة، ولا قراءة بيانات دليل، ولا مراجعة إعداد TLS. بهذه الطريقة ما يحتاج القارئ يستنتج حدود العمل من الخيارات بنفسه. الفصل بين ما فُحص وما لم يُفحص يساعد أيضًا عند تسليم المهمة لشخص آخر.
لما تعيد الفحص بعد إصلاح مصرح، حافظ على السؤال نفسه قدر الإمكان. تغيير المصدر والاسم وقائمة المنافذ وطريقة الفحص معًا يجعل المقارنة ضعيفة. إذا اضطررت تغير متغيرًا، سجله بوضوح. نجاح نتيجة جديدة ما يحدد سبب التحسن تلقائيًا إذا كانت المحاولة الجديدة مختلفة في عدة عناصر.
صغ الملاحظة بلغة بسيطة: من الجهاز الفلاني إلى الخادم الفلاني، كان اتصال المنفذ المحدد متاحًا وقت الاختبار، ثم فشلت قراءة التطبيق برسالة كذا. هذه الجملة أقل إثارة من عناوين كبيرة عن السيطرة على الدومين، لكنها أقرب للعمل المهني. القارئ يعرف منها الدليل والحدود والسؤال المتبقي، بدل أن يبحث عنها بين استنتاجات مبالغ فيها.

تدريب صغير يثبت أنك فهمت النتيجة

اختر خادم لاب واحدًا، وحدد مهمة مصرحًا بها تريد اختبار وصولها. نفذ الفحص المحدود مرة، ثم اكتب تفسيرًا لكل حالة ظهرت بدون استخدام كلمة ثغرة. بعد ذلك اكتب سؤالًا واحدًا يحتاج دليلًا إضافيًا. إذا ظهر منفذ مفتوح، اسأل عن استجابة الخدمة أو نجاح طلبك. إذا ظهر منع، اسأل هل هذا يتفق مع فصل الشبكات المتوقع.
راجع تفسيرك مع خرج التطبيق وجرد اللاب. لو كنت لا تملك صلاحية الاطلاع على إعداد الخادم، لا تخمنها. اكتف بوصف نتيجة المصدر الذي تملكه، وحدد المعلومات اللازمة للوصول إلى حكم أوسع. هذا سلوك طبيعي في اختبار مصرح؛ أحيانًا يكون أفضل ما عندك ملاحظة دقيقة تحتاج متابعة من مسؤول البيئة.
تجنب توسيع الفحص لمجرد الشعور أن الأمر القصير ما يبدو احترافيًا. الاحتراف في السؤال المناسب والدليل الكافي. عدد الخيارات ما يعطي نتيجة أقوى إذا كنت ما تعرف لماذا أضفت كل خيار، وأي نشاط إضافي ينشأ منه. ابدأ صغيرًا، ووسع فقط عندما يتضح ما تريد التحقق منه.
للتفاصيل ارجع إلى وثائق Nmap عن حالات المنافذ والتعرف على الخدمات، وإلى جدول Microsoft لاتصالات Active Directory:
https://nmap.org/book/man-port-scanning-basics.html
https://nmap.org/book/man-version-detection.html
https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/config-firewall-for-ad-domains-and-trusts
الفكرة اللي تحتاج تطلع بها واضحة: نتيجة المنفذ قطعة من التشخيص. اربطها بالمصدر والاسم والمهمة والاستجابة، وبعدها اختر خطوة تحقق تناسب السؤال الفعلي.