Skip to content
VDS · سیکیورٹی

مشین میں کون لاگ ان ہوا: لاگ ان لاگز

کامیاب اور ناکام لاگ ان کہاں دیکھیں، 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 نہیں

اگر آپ کو کسی اور کے ایڈریس سے کامیاب لاگ اِن ملے تو مشین کے اپنے لاگز کو مزید قابلِ اعتماد نہیں سمجھا جا سکتا: جس نے لاگ اِن کیا وہ اُنہیں تبدیل کر سکتا تھا۔ مضمون مداخلت کی علامات پر عمل کریں اور فرض کریں کہ مشین دوبارہ انسٹال کرنی پڑے گی۔