Logwatch وہ مسئلہ حل کرتا ہے جو ورنہ حل ہی نہیں ہوتا: یہ آپ کے بجائے سرور کے تمام لاگ پڑھتا ہے اور گزشتہ دن کا خلاصہ بھیجتا ہے۔ روزانہ auth.log اور ویب سرور کے لاگ کوئی نہیں دیکھتا، جبکہ صبح ایک خط پڑھ لینا ممکن ہے۔
اور معلوم مسئلہ: پہلا خط کئی سو سطروں کے ساتھ آتا ہے، دوسرے پر سرسری نظر پڑتی ہے، ایک ہفتے بعد میل کا کوئی قاعدہ انہیں الگ فولڈر میں بھیج دیتا ہے، اور نگرانی وہیں ختم ہو جاتی ہے۔ سبب تقریباً ہمیشہ طے شدہ ترتیبات ہوتی ہیں، اور اصلاح میں دس منٹ لگتے ہیں۔
تنصیب اور ترتیبات کہاں بدلیں
sudo apt install logwatchآپ اپنی قدریں کہاں رکھتے ہیں، یہ اہم ہے۔ فائل /usr/share/logwatch/default.conf/logwatch.conf کو ہاتھ نہیں لگانا — پیکج کی تازہ کاری پر یہ اوپر سے لکھ دی جاتی ہے۔ آپ کی فائل /etc/logwatch/conf/logwatch.conf ہے۔ وہ خالی بھی ہو سکتی ہے؛ صرف وہی جوڑنا کافی ہے جو آپ بدل رہے ہیں۔
Output = mail
Format = html
MailTo = admin@example.com
Detail = Low
Range = yesterdayتفصیل کی سطح سب کچھ طے کرتی ہے
Detail 0 سے 10 تک قدریں یا Low، Med، High الفاظ لیتا ہے۔ اور فرق بہت بڑا ہے: High پر رپورٹ میں ہر کنکشن اور ہر درخواست شامل ہوتی ہے؛ Low پر صرف مجموعے اور بے قاعدگیاں۔
عملی طریقہ یہ ہے: مجموعی طور پر Low، اور اُن سروسز کے لیے چن کر تفصیل بڑھا دیں جو واقعی آپ کے لیے اہم ہیں۔ فی سروس ترتیبات /etc/logwatch/conf/services/ میں جاتی ہیں — مثلاً Detail = High سطر والی فائل sshd.conf۔
جانچنے کا پیمانہ: رپورٹ ایک یا ڈیڑھ اسکرین میں سما جانی چاہیے۔ اس سے لمبی چیز پڑھنا چھوڑ دی جائے گی — سستی سے نہیں بلکہ اس لیے کہ تین سو سطروں کے معمول میں کوئی انحراف دکھائی ہی نہیں دیتا۔
صبح کا انتظار کیے بغیر نتیجہ دیکھنے کے لیے:
sudo logwatch --detail Low --range today --output stdoutDebian 12 پر خالی SSH حصہ
نئے نظاموں پر ایک الگ پھندا۔ Logwatch /var/log میں متنی فائلیں پڑھتا ہے، اور Debian 12 اور Ubuntu 24.04 اب rsyslog بطور طے شدہ نصب نہیں کرتے — فائل /var/log/auth.log سرے سے موجود نہیں اور سب کچھ systemd کے جرنل میں چلا جاتا ہے۔ رپورٹ پھر بھی باقاعدگی سے آتی ہے، مگر سب سے اہم حصہ — SSH کے لاگ اِن — خالی نکلتا ہے یا غائب ہوتا ہے۔
جانچ ایک سیکنڈ لیتی ہے:
ls -l /var/log/auth.logاگر فائل نہ ہو تو یا rsyslog نصب کریں یا مان لیں کہ اس مشین پر Logwatch نامکمل تصویر دکھا رہا ہے۔ اور خالی حصے کو «کچھ نہیں ہوا» پڑھ لینا آسان ہے، اور یہی سب سے خطرناک نتیجہ ہے۔
میل کہاں جاتی ہے
«رپورٹیں نہیں آتیں» کی دوسری عام وجہ: سرور پر میل کی ترسیل مرتب ہی نہیں۔ Logwatch خط نظام کے ایجنٹ کو دیتا ہے، وہ اسے کہیں نہیں بھیجتا، اور خط root کے مقامی میل باکس میں بیٹھ جاتا ہے جہاں کبھی کوئی نہیں جھانکتا:
sudo cat /var/mail/root | tail -50دو راستے ہیں۔ یا بیرونی SMTP ریلے کے ذریعے ترسیل مرتب کریں، یا میل استعمال ہی نہ کریں اور رپورٹ کسی فائل میں لکھیں:
Output = file
Filename = /var/log/logwatch/report.txtدوسرا زیادہ دیانت دار ہے: ایسا خط جسے کوئی پہنچا ہی نہ سکے، نگرانی کا دھوکا پیدا کرتا ہے، جبکہ ڈسک پر پڑی فائل کم از کم کھولی تو جا سکتی ہے۔
رپورٹ میں کیا پڑھیں
افادیت کے گھٹتے ہوئے ترتیب سے:
- sshd۔ کامیاب لاگ اِن — کون اور کہاں سے۔ عین کامیاب، ہزاروں ناکامیاں نہیں: ناکامیاں پس منظر ہیں، جبکہ نامانوس پتے سے لاگ اِن وضاحت مانگتا ہے؛
- sudo اور pam_unix۔ کس نے اختیارات بڑھائے اور کس نے صارف بنائے؛
- Disk Space۔ ایک سطر جو بھرتی ہوئی ڈسک کے بارے میں پہلے سے خبردار کرتی ہے؛
- cron۔ جو کام نمودار ہوئے اور جو ناکام ہوئے؛
- http۔ 404 جوابوں میں اچھال عموماً راستوں کے ٹٹولنے کا مطلب رکھتا ہے؛ اور 500 میں اچھال یہ کہ آپ کا کچھ ٹوٹ گیا؛
- postfix، اگر سرور میل بھیجتا ہو: بڑھتی ہوئی باہر جانے والی قطار اس بات کی نمایاں علامت ہے کہ سرور کو اسپام کے ریلے کے طور پر استعمال کیا جا رہا ہے۔
اس کی حدود
Logwatch گزشتہ دن کا خلاصہ ہے، اطلاع نہیں۔ یہ آپ کو رات کو نہیں جگائے گا اور بالتعریف پیچھے رہتا ہے: یہ صبح سویرے روزانہ کے کام سے چلتا ہے اور کل کا احاطہ کرتا ہے۔ اور «ابھی کچھ ہو رہا ہے» کے لیے یہ نہ موزوں ہے نہ اس کے لیے بنا ہے۔
اس کی طاقت کہیں اور ہے — یہ آپ کو ایک عام دن کی شکل دکھاتا ہے۔ ایک مہینے پڑھنے کے بعد آپ جانتے ہیں کہ عام حالت میں کتنے ناکام لاگ اِن ہوتے ہیں، سائٹ کتنی درخواستیں لیتی ہے اور کتنی میل باہر جاتی ہے؛ اور جب ان میں سے کوئی عدد دگنا ہو جائے تو یہ فوراً نظر آ جاتا ہے، بغیر کسی حد اور بغیر کسی قاعدے کے۔ اسی لیے رپورٹ کو وہاں رکھنا چاہیے جہاں وہ نظر میں آئے، نہ کہ میل کے کسی فولڈر میں۔ یہ ایک صفحے پر کیسا لگتا ہے، نیچے ڈیمو دکھاتا ہے۔