مشین میں کون لاگ ان ہوا: لاگ ان لاگز
کامیاب اور ناکام لاگ ان کہاں دیکھیں، last، lastb، اور journalctl کیسے پڑھیں، sudo کے ذریعے اعمال کیسے ٹریک کریں، اور لاگ ریٹینشن کیسے سیٹ اپ کریں۔
اپ ڈیٹ 23 اگست، 2026
ہر مشین میں لاگ اِن اپنا نشان چھوڑتا ہے۔ اِن نشانات کو پانچ منٹ میں پڑھ لینا ہی پرسکون واقعہ جائزے کو اندازے سے الگ کرتا ہے۔
فوری جائزہ
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
اہم سطریں:
| سطر | مطلب |
|---|---|
Accepted publickey for artem | کلید کے ذریعے کامیاب لاگ اِن |
Accepted password for root | پاس ورڈ کے ذریعے کامیاب لاگ اِن — تشویش کی بات |
Failed password for invalid user admin | غیر موجود ناموں پر بروٹ فورس، پس منظر کا شور |
Disconnected from authenticating user | کوشش منسوخ |
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
سائز کی حد لازمی ہے: ڈسک کھا جانے والا جرنل سروسز روک دیتا ہے۔
عام غلطیاں
| غلطی | نتیجہ | حل |
|---|---|---|
| جرنل ری بوٹ کے درمیان محفوظ نہیں ہوتا | نشانات ضائع | Storage=persistent |
صرف .bash_history پر انحصار | ڈیٹا جعل سازی کے لیے آسان | sudo اور auditd لاگز دیکھیں |
| جرنل کا سائز محدود نہیں کیا | ڈسک بھر گئی | SystemMaxUse |
| بروٹ فورس شور کو ہیک سمجھنا | جھوٹا الارم | Accepted دیکھیں، Failed نہیں |
اگر آپ کو کسی اور کے ایڈریس سے کامیاب لاگ اِن ملے تو مشین کے اپنے لاگز کو مزید قابلِ اعتماد نہیں سمجھا جا سکتا: جس نے لاگ اِن کیا وہ اُنہیں تبدیل کر سکتا تھا۔ مضمون مداخلت کی علامات پر عمل کریں اور فرض کریں کہ مشین دوبارہ انسٹال کرنی پڑے گی۔