من سجّل الدخول إلى الجهاز: سجلات تسجيل الدخول

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

نظرة سريعة

last -a -n 20
lastb -a -n 20
lastlog
who
w

يعرض last عمليات تسجيل الدخول الناجحة مع العناوين، وlastb المحاولات الفاشلة، وlastlog موعد آخر تسجيل دخول لكل مستخدم. أما who وw فيعرضان من يوجد على الجهاز الآن.

إذا أظهر lastlog تاريخ تسجيل دخول لمستخدم نظام مثل www-data، فهذا سبب جدي للتحقيق.

سجل systemd

journalctl -u ssh -n 100
journalctl -u ssh --since "2026-08-20" --until "2026-08-21"
journalctl _COMM=sshd | grep "Accepted"
journalctl _COMM=sshd | grep "Failed password" | tail -50

الأسطر المهمة:

على Debian وUbuntu، تُكرَّر الأحداث نفسها في /var/log/auth.log؛ وعلى AlmaLinux في /var/log/secure.

grep "Accepted" /var/log/auth.log
grep -c "Failed password" /var/log/auth.log

مئات المحاولات الفاشلة يوميًا على عنوان عام أمر طبيعي. غير الطبيعي شيء آخر: تسجيل دخول ناجح من عنوان لا تعرفه. يساعد fail2ban في مواجهة الضجيج.

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

journalctl -t sudo -n 100
grep sudo /var/log/auth.log
cat /home/artem/.bash_history

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

تدقيق كامل على مستوى النواة:

apt install -y auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
ausearch -k passwd_changes

التخزين

افتراضيًا، قد يقيم سجل systemd في الذاكرة ويُفقد عند إعادة التشغيل. وهذا سيئ لمراجعة الحوادث. الملف /etc/systemd/journald.conf:

[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month

systemctl restart systemd-journald
journalctl --disk-usage

حد الحجم إلزامي: فالسجل الذي يلتهم القرص يوقف الخدمات.

أخطاء شائعة

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