BloodHound CE ما يفتح؟ شخّص Docker والمنفذ والسجلات قبل ما تعيد التثبيت

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

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

حدد المنتج وطريقة التثبيت قبل البحث عن الحل

BloodHound CE تختلف عن شروحات Legacy التي قد تجدها في نتائج البحث. ابدأ بتسجيل إصدار المنتج وطريقة تثبيته ومصدر ملفاته ونظام التشغيل ومعمارية الجهاز. توثيق SpecterOps الحالي يوصي بـBloodHound CLI لتبسيط إعداد CE باستخدام Docker Compose، ويعرض أيضًا مسار تثبيت مخصص. لا تجمع ملف إعداد من شرح قديم مع أمر تشغيل من توثيق جديد ثم تعتبر أي خطأ مشكلة في البرنامج نفسه.

لو أنت تستخدم BH-CLI، احتفظ بالمجلد والملفات التي أنشأها وبسجل الخطوة التي نفذتها. ولو تستخدم Compose مخصصًا، حدد ملف المشروع والمتغيرات المطلوبة له. الأوامر التي تقرأ حالة مشروع لا تفيد إذا شغلتها من مجلد مشروع آخر. هذه نقطة تبدو بسيطة، لكن وجود أكثر من نسخة لاب أو نسخة احتياطية من compose.yaml يجعلها سببًا واقعيًا لنتائج تقول إن ما عندك حاويات بينما الحاويات المقصودة تعمل تحت مشروع مختلف.

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

Docker موجود، لكن هل تتواصل مع البيئة المقصودة؟

قبل فحص BloodHound، تأكد أن أدوات Docker تتحدث مع بيئة التشغيل التي تستخدمها لهذا اللاب. إذا أعاد أمر حالة الحاويات خطأ يتعلق بمحرك Docker أو الصلاحيات أو الاتصال به، فهذه مشكلة تسبق التطبيق. لا تبدأ بتغيير كلمات مرور BloodHound أو إعادة جمع SharpHound؛ البيانات لم تصل أصلًا إلى موضع التشخيص. راجع رسالة الخطأ نفسها، واعرف هل المشكلة في بيئة تشغيل الحاويات أم في مشروع معين داخلها.

في الأجهزة التي تستخدم Docker Desktop، الصورة المرفقة تساعدك تلاحظ الفرق بين قائمة الحاويات وبين حالة المحرك العامة. قد تكون هناك حاويات متوقفة ضمن القائمة، وقد تكون قائمة مشروعك مخفية بسبب فلتر يعرض العامل فقط. لا تفترض أن كل ما لا تراه محذوف. كذلك واجهة جهاز محلي لا تخبرك تلقائيًا عن Docker يعمل على جهاز لاب آخر. حدد المكان الذي يجري فيه التنفيذ، ومكان المتصفح الذي تحاول منه الوصول.

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

docker compose ps --all: اقرأ الحالة، مو الاسم بس

داخل مجلد المشروع الصحيح، أمر docker compose ps --all يعرض الحاويات المرتبطة به، بما فيها المتوقفة. توثيق Docker يوضح أن العرض الافتراضي لـps يركز على الحاويات العاملة، لذلك خيار --all مهم عندما تبحث عن خدمة بدأت ثم انتهت. راجع اسم الخدمة وحالتها والمنفذ المعروض. لا تفترض أن أسماء الخدمات في شرح آخر مطابقة لملفك؛ استخدم الأسماء التي تخص الإعداد الذي ثبتَّه.

الحالة running تصف عمل الحاوية، لكنها لا تحسم أن كل وظيفة داخل التطبيق جاهزة. والحالة exited تحتاج قراءة سبب الخروج وسجل الخدمة، لا إعادة تشغيل متكرر بلا ملاحظة. وإذا كانت restarting، دوّن النمط وراجع السجل حول آخر بدء. لا تجعل تغير الحالة السريع سببًا لحذف البيانات. ابدأ بآخر خطأ واضح، ثم اربطه بالخدمة التي أصدرته وبالخدمات التي تعتمد عليها وفق ملف المشروع.

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

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

المنافذ وlocalhost: أكثر التباس يكلفك وقت

localhost يعني الجهاز أو البيئة التي تنفذ منها الوصول، وليس اسمًا عالميًا لجهاز اللاب. إذا Docker يعمل على حاسب بعيد والمتصفح على حاسبك، كتابة localhost في المتصفح تشير إلى حاسبك. وفي إعدادات أخرى تكون هناك طبقة VM أو إعادة توجيه منفذ تحتاج فهمًا مستقلًا. اكتب سلسلة الوصول: المتصفح، والجهاز المستضيف، والمنفذ المعروض، والمنفذ داخل الحاوية. لا تحتاج عنوانًا معقدًا؛ تحتاج تعرف كل طرف في السلسلة.

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

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

logs يعطيك تسلسلًا، لا مجرد آخر سطر أحمر

استخدم docker compose logs --tail 100 --timestamps لقراءة جزء محدد من سجلات المشروع مع أوقاته، وفق الخيارات الموثقة في Docker. وإذا تعرف الخدمة التي تراجعها، أضف اسمها الحقيقي في مشروعك لتضييق الناتج. لا تحول السجل كله إلى منشور دعم قبل فحص ما فيه؛ قد يتضمن إعدادات أو معرفات أو بيانات لا تحتاجها المشكلة. احتفظ بنسخة محلية، وشارك مقطعًا منقحًا يوضح التسلسل ذي الصلة فقط.

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

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

config مفيد، لكن مخرجاته قد تحتوي أسرارًا

docker compose config يعرض نموذج الإعداد الناتج بعد معالجة ملفات Compose ومتغيراتها. يفيدك عندما تريد معرفة ما سيطبَّق فعلًا بدل الاكتفاء بقراءة ملف واحد قد تستكمله ملفات أو متغيرات أخرى. ومن خياراته config --services لعرض أسماء الخدمات. استخدم القراءة المحلية المناسبة لسؤالك. لا تنشر الإعداد الناتج كاملًا؛ قيم متغيرات الاتصال أو كلمات المرور قد تظهر بحسب إعداد المشروع، وتنقيحها مسؤولية أساسية عند طلب المساعدة.

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

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

الموارد والتخزين: لا تمسح الدليل عشان يخف اللاب

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

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

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

ثلاث حالات، وثلاث خطوات تالية مختلفة

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

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

للمراجعة: دليل CE الرسمي https://bloodhound.specterops.io/get-started/quickstart/community-edition-quickstart ، وps https://docs.docker.com/reference/cli/docker/compose/ps/ ، وlogs https://docs.docker.com/reference/cli/docker/compose/logs/ ، وconfig https://docs.docker.com/reference/cli/docker/compose/config/ . مصدر الصورة الخارجية هو Docker https://www.docker.com/products/docker-desktop/ ؛ تعرض مثالًا لواجهة الحاويات، وقد يختلف شكل نسختك. احتفظ ببطاقة التشخيص المختصرة، لأن ترتيب الأسئلة الذي تعلمته هنا يفيدك مع أغلب الأدوات التي تتكون من عدة خدمات.