كيف تقرأ سجلات Linux وتكتشف النشاط غير المعتاد

كيف تقرأ سجلات Linux وتكتشف النشاط غير المعتاد؟ دليل عملي لطالب الأمن السيبراني

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

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

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

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

ما سجلات Linux؟

السجل ملف أو قاعدة بيانات صغيرة تحفظ رسائل أنشأها النظام أو إحدى خدماته. قد تحتوي الرسالة على:

• وقت وقوع الحدث.
• اسم الجهاز.
• اسم الخدمة أو البرنامج.
• رقم العملية PID.
• المستخدم المرتبط بالحدث.
• وصف مختصر لما حدث.
• نتيجة العملية، مثل النجاح أو الفشل.

لا تسجل جميع توزيعات Linux الأحداث بالطريقة نفسها. تستخدم معظم التوزيعات الحديثة systemd-journald، بينما تحتفظ بعض الخدمات أيضًا بملفات نصية داخل المجلد /var/log.

لذلك لا تفترض أن ملفًا ظهر في Ubuntu سيظهر بالاسم نفسه في Kali Linux أو Fedora.

قبل قراءة السجل: اطرح خمسة أسئلة

عند مشاهدة أي رسالة، لا تبدأ بالبحث عن كلمة «اختراق». ابدأ بهذه الأسئلة:

1. متى وقع الحدث؟
2. على أي جهاز أو خدمة وقع؟
3. من المستخدم أو العملية المرتبطة به؟
4. ماذا حدث بالضبط؟
5. هل يتوافق الحدث مع النشاط الطبيعي للجهاز؟

هذه الأسئلة تحول السجل من سطر طويل ومربك إلى بطاقة حدث يمكن تحليلها.

التعرف إلى journalctl

الأداة journalctl هي الواجهة الأساسية لقراءة السجلات التي يجمعها systemd-journald.

لعرض السجل:

journalctl

قد تظهر آلاف الرسائل. استخدم مفتاح المسافة للانتقال إلى الصفحة التالية، والحرف q للخروج.

في بعض الأنظمة تحتاج إلى صلاحيات إضافية لرؤية جميع الرسائل:

sudo journalctl

استخدام sudo هنا لا يعني تعديل السجلات؛ بل يسمح بقراءة رسائل قد تكون محجوبة عن المستخدم العادي.

ابدأ بسجل عملية الإقلاع الحالية

لعرض الأحداث المسجلة منذ آخر تشغيل للجهاز:

journalctl -b

يساعد هذا الخيار على عزل الأحداث الحالية عن رسائل عمليات الإقلاع السابقة.

لعرض سجل عملية الإقلاع السابقة:

journalctl -b -1

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

يمكنك عرض قائمة عمليات الإقلاع المسجلة باستخدام:

journalctl –list-boots

تحديد الفترة الزمنية

نادراً ما يحتاج المحلل إلى قراءة السجل كاملًا. الأفضل تحديد الفترة التي وقع فيها الحدث.

لعرض رسائل اليوم:

journalctl –since today

لعرض آخر ساعة:

journalctl –since “1 hour ago”

لعرض فترة محددة:

journalctl –since “2026-09-21 10:00:00” –until “2026-09-21 11:00:00”

استبدل التاريخ والوقت بالفترة التي تريد تحليلها.

تأكد من معرفة المنطقة الزمنية المستخدمة على الجهاز:

timedatectl

اختلاف التوقيت بين جهازين قد يجعلك تربط أحداثًا غير متزامنة أو تضعها بترتيب خاطئ.

قراءة آخر الرسائل ومراقبتها مباشرة

لعرض آخر خمسين رسالة:

journalctl -n 50

ولمتابعة الرسائل الجديدة فور وصولها:

journalctl -f

الخيار -f مفيد داخل المختبر. افتح نافذة طرفية وشغله، ثم نفّذ حدثًا بسيطًا في نافذة أخرى، مثل تشغيل خدمة أو محاولة sudo فاشلة، وراقب الرسائل الجديدة.

اضغط Ctrl + C لإيقاف المتابعة.

تصفية السجل حسب الخدمة

بدل قراءة كل شيء، يمكنك عرض رسائل خدمة واحدة:

journalctl -u اسم-الخدمة

مثلًا، لمعرفة الاسم الفعلي لخدمة SSH في جهازك:

systemctl status ssh

أو:

systemctl status sshd

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

sudo journalctl -u ssh

أو:

sudo journalctl -u sshd

يمكن دمج الخدمة مع الوقت:

sudo journalctl -u ssh –since “30 minutes ago”

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

تصفية الرسائل حسب مستوى الخطورة

تصنف رسائل journal إلى مستويات، منها التحذير والخطأ والحالة الحرجة.

لعرض التحذيرات وما هو أشد منها في عملية الإقلاع الحالية:

journalctl -b -p warning

لعرض الأخطاء:

journalctl -b -p err

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

تحسين تنسيق الوقت

لعرض الوقت بصورة واضحة ومتسقة:

journalctl -o short-iso

ويمكن دمجه مع مرشح آخر:

sudo journalctl -u ssh -o short-iso –since today

وجود الوقت بتنسيق ثابت يسهل نقل الأحداث إلى جدول زمني ومقارنتها بسجلات الشبكة.

أين توجد ملفات السجلات التقليدية؟

يمكن استعراض محتويات مجلد السجلات باستخدام:

ls -lh /var/log

قد تجد ملفات مثل:

• /var/log/auth.log لأحداث المصادقة في Ubuntu وDebian وبعض التوزيعات المبنية عليهما.
• /var/log/syslog لرسائل عامة في بعض التوزيعات.
• /var/log/kern.log لرسائل النواة عندما يكون الملف مفعّلًا.
• /var/log/apt/history.log لسجل تثبيت الحزم وتحديثها في الأنظمة التي تستخدم APT.
• /var/log/wtmp لبيانات جلسات تسجيل الدخول.
• /var/log/btmp لمحاولات تسجيل الدخول الفاشلة.

قد لا تظهر هذه الملفات جميعها، وقد تعتمد توزيعتك على journal بدلًا منها.

لقراءة آخر الأسطر من ملف نصي:

sudo tail -n 50 /var/log/auth.log

ولمتابعة الملف مباشرة:

sudo tail -f /var/log/auth.log

لا تعدّل ملف السجل الأصلي أثناء التحقيق؛ لأن ذلك قد يغيّر دليلًا مهمًا أو يضيف وقت تعديل جديدًا للملف.

مراجعة عمليات تسجيل الدخول

لعرض جلسات تسجيل الدخول المسجلة:

last

يقرأ الأمر عادة بيانات ملف wtmp ويعرض الجلسات من الأحدث إلى الأقدم.

لعرض عمليات إعادة التشغيل:

last reboot

ولعرض محاولات تسجيل الدخول الفاشلة، إذا كان ملف btmp متاحًا:

sudo lastb

أما لمعرفة المستخدمين المتصلين حاليًا:

who

ولرؤية المستخدمين الحاليين والعمليات التي ينفذونها:

w

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

كيف تقرأ رسالة SSH؟

قد ترى رسالة تفيد بفشل كلمة مرور مستخدم معين أو نجاح تسجيل دخوله. لا تتوقف عند كلمة Failed أو Accepted، بل استخرج منها:

• الوقت الدقيق.
• اسم المستخدم.
• عنوان المصدر إن ظهر.
• طريقة المصادقة.
• عدد المحاولات القريبة منها.
• هل تبعتها جلسة ناجحة؟
• هل كان الدخول متوقعًا في ذلك الوقت؟

المؤشر المهم ليس الحدث المنفرد فقط، بل النمط. خمسون محاولة على أسماء مستخدمين مختلفة، ثم دخول ناجح، أقوى دلالة من محاولة واحدة فاشلة.

ولا تنشر عناوين IP العامة أو أسماء المستخدمين أو أسماء الأجهزة الحقيقية في تقرير عام أو مستودع GitHub. استبدلها بقيم تدريبية مثل 192.0.2.10 أو student-user.

البحث داخل السجلات

يمكن استخدام grep للبحث داخل ملف نصي:

sudo grep “Failed password” /var/log/auth.log

وللبحث دون مراعاة حالة الأحرف:

sudo grep -i “error” /var/log/syslog

ولعرض رقم السطر:

sudo grep -n “Failed password” /var/log/auth.log

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

sudo grep -B 3 -A 3 “Failed password” /var/log/auth.log

يعرض الخيار -B 3 ثلاثة أسطر قبل النتيجة، بينما يعرض -A 3 ثلاثة أسطر بعدها.

الفرق بين الدليل والاستنتاج

إذا وجدت سطرًا يقول إن تسجيل الدخول فشل، فالدليل هو:

«حدثت محاولة مصادقة فاشلة في وقت محدد.»

أما القول:

«تعرض الجهاز لهجوم تخمين كلمات المرور.»

فهذا استنتاج يحتاج إلى قرائن إضافية، مثل:

• تكرار المحاولات بسرعة.
• استخدام أسماء حسابات متعددة.
• مصدر غير معتاد.
• نجاح تسجيل دخول بعد المحاولات.
• بدء عمليات أو اتصالات جديدة بعد الدخول.
• تغييرات في المستخدمين أو الصلاحيات.

المحلل الجيد يكتب ما يعرفه، ثم يوضح ما يرجحه، ولا يخلط بين الاثنين.

قاعدة خط الأساس

لا يمكنك اكتشاف السلوك غير المعتاد قبل معرفة السلوك المعتاد.

أنشئ خط أساس بسيطًا لجهاز المختبر:

• من المستخدمون الطبيعيون؟
• متى يُشغّل الجهاز عادة؟
• ما الخدمات التي تعمل باستمرار؟
• ما المنافذ المتوقعة؟
• ما التحديثات التي ثُبتت مؤخرًا؟
• هل خدمة SSH مفعلة أصلًا؟
• ما عناوين الشبكة الطبيعية للمختبر؟

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

مثلث التحقق من الحدث

لتجنب الحكم من سجل واحد، اربط بين ثلاثة أنواع من الأدلة:

دليل المستخدم

من سجل الدخول؟ وهل استخدم sudo؟ وهل أُنشئ حساب جديد؟

دليل العملية

ما البرنامج أو الخدمة التي بدأت؟ وما رقم العملية؟ وهل استمر تشغيلها؟

دليل الشبكة

هل أنشأ الجهاز اتصالًا جديدًا؟ وهل ظهر الحدث نفسه في التقاط Wireshark أو في سجل الجدار الناري؟

عندما تتفق هذه الأدلة، يصبح استنتاجك أقوى. وإذا تعارضت، فلا تخفِ التعارض؛ بل سجله وابحث عن تفسير.

دوران السجلات ولماذا تختفي الأحداث القديمة

لا تستطيع الأنظمة الاحتفاظ بالسجلات إلى الأبد. تستخدم Linux عادة آلية تدوير السجلات Log Rotation لتغيير اسم الملف القديم وضغطه وإنشاء ملف جديد.

قد ترى ملفات مثل:

• auth.log
• auth.log.1
• auth.log.2.gz

لذلك لا تستنتج أن الحدث غير موجود قبل فحص الملفات المدورة وسياسة الاحتفاظ.

لعرض إعدادات المساحة المستخدمة في journal:

journalctl –disk-usage

غياب السجل قد ينتج عن:

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

مختبر عملي: بناء خط زمني لحادثة آمنة

نفّذ هذا التدريب على جهاز Linux افتراضي تملكه. إذا لم تُجهّز بيئة التدريب بعد، فاتبع خطوات إنشاء مختبر أمن سيبراني منزلي آمن قبل تنفيذ التجربة، حتى تبقى جميع الأنشطة معزولة عن جهازك وشبكتك الأساسية.خذ Snapshot قبل البدء إن أمكن.

الخطوة الأولى: سجل وقت البداية

date –iso-8601=seconds

اكتب الوقت في ملاحظاتك.

الخطوة الثانية: أنشئ حدث مصادقة بسيطًا

نفّذ أمرًا يحتاج إلى sudo، ثم أدخل كلمة مرور خاطئة مرة واحدة فقط قبل إدخال الكلمة الصحيحة:

sudo whoami

لا تكرر المحاولات بكثرة حتى لا يتعامل النظام معها كسلوك مزعج أو يفرض تأخيرًا مؤقتًا.

الخطوة الثالثة: افحص خدمة

اختر خدمة موجودة على الجهاز، مثل cron:

systemctl status cron

في بعض التوزيعات قد يكون اسمها crond:

systemctl status crond

اعرض سجل الخدمة المتاحة لديك:

sudo journalctl -u cron –since “10 minutes ago”

الخطوة الرابعة: راجع سجل المصادقة

في Ubuntu أو Debian جرّب:

sudo tail -n 30 /var/log/auth.log

إذا لم يكن الملف موجودًا، استخدم journal:

sudo journalctl –since “10 minutes ago” | grep -i sudo

الخطوة الخامسة: راجع جلسات الدخول

last -n 10

ثم:

who

الخطوة السادسة: أنشئ جدولًا زمنيًا

سجل كل حدث في خمسة أعمدة:

• الوقت.
• المصدر أو الخدمة.
• المستخدم.
• الحدث.
• التفسير الأولي.

مثال:

• الوقت: 10:05:12
• المصدر: sudo
• المستخدم: student
• الحدث: محاولة مصادقة فاشلة
• التفسير: خطأ تدريبي متعمد، وليس دليل اختراق بمفرده

ثم أضف الحدث الناجح الذي تلاه. بهذه الطريقة ستلاحظ أن السياق يغير تفسير السطر الأول.

تمرين إضافي: اربط السجل بحركة الشبكة

يساعدك درس قراءة حركة الشبكة باستخدام Wireshark على فهم عملية الالتقاط واختيار الواجهة واستخدام الفلاتر، ثم يمكنك مقارنة وقت الاتصال في Wireshark بوقت الحدث المسجل داخل Linux.

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

• وقت الاتصال في Wireshark.
• وقت العملية في journal.
• اسم البرنامج أو الخدمة.
• عنوان الوجهة والبروتوكول.

هذا الربط يحولك من قارئ رسائل إلى محلل يربط بين النظام والشبكة.

أخطاء شائعة عند تحليل سجلات Linux

البحث عن كلمة error فقط

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

اعتبار كل فشل تسجيل دخول هجومًا

الفشل المنفرد شائع. ابحث عن التكرار والتسلسل والمصدر.

تجاهل المنطقة الزمنية

قد يبدو حدث الشبكة سابقًا لحدث النظام بسبب اختلاف التوقيت، وليس لأن ترتيب الأحداث الحقيقي مختلف.

تحليل السجل الأصلي بطريقة تغيره

انسخ السجل إلى موقع عمل منفصل إذا احتجت إلى معالجته، واحتفظ بالأصل دون تعديل.

الاعتماد على مصدر واحد

اربط سجل المصادقة بسجل الخدمة والعمليات وحركة الشبكة.

نشر بيانات حساسة

نظف التقارير من أسماء المستخدمين وعناوين IP العامة وأسماء الأجهزة والرموز السرية قبل مشاركتها.

قالب مختصر لتوثيق حدث

استخدم هذا القالب في مشروعاتك:

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

درجة الثقة مهمة؛ لأنها تمنع عرض الاحتمال كحقيقة مؤكدة.

مشروع تطبيقي للطالب

أنشئ تقريرًا بعنوان «تحليل ساعة واحدة من سجلات Linux»، ونفّذ داخله ما يلي:

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

المشروع الجيد لا يقاس بعدد الأوامر، بل بوضوح المنهج وقدرتك على الفصل بين الدليل والاستنتاج.

الخلاصة

قراءة سجلات Linux ليست حفظ أسماء الملفات أو البحث عن كلمة «فشل». المهارة الحقيقية هي تحديد الفترة الزمنية، وعزل الخدمة المناسبة، وفهم السياق، ثم ربط المستخدم بالعملية وحركة الشبكة.

ابدأ دائمًا بسؤال واضح، ثم استخدم journalctl وملفات /var/log وأوامر تسجيل الدخول لجمع الأدلة. لا تعتبر غياب السجل دليلًا على عدم وقوع الحدث، ولا تعتبر رسالة واحدة إثباتًا للاختراق.

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

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