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/ — เช่นไฟล์ sshd.conf ที่มีบรรทัด Detail = High

เกณฑ์ตรวจสอบ: รายงานควรพอดีหนึ่งถึงหนึ่งหน้าจอครึ่ง อะไรที่ยาวกว่านั้นจะเลิกถูกอ่าน — ไม่ใช่เพราะขี้เกียจ แต่เพราะในสามร้อยบรรทัดของเรื่องประจำวัน ความเบี่ยงเบนมองไม่เห็นเลย

เพื่อดูผลลัพธ์โดยไม่ต้องรอถึงเช้า:

sudo logwatch --detail Low --range today --output stdout

ส่วน SSH ที่ว่างเปล่าบน Debian 12

กับดักแยกต่างหากบนระบบใหม่ 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 relay ภายนอก หรือไม่ใช้เมลเลยแล้วเขียนรายงานลงไฟล์:

Output = file
Filename = /var/log/logwatch/report.txt

ทางที่สองซื่อสัตย์กว่า: อีเมลที่ไม่มีใครส่งได้สร้างภาพลวงตาของการเฝ้าดู ในขณะที่ไฟล์บนดิสก์อย่างน้อยก็เปิดได้

ควรอ่านอะไรในรายงาน

เรียงตามประโยชน์จากมากไปน้อย:

  • sshd การเข้าสู่ระบบที่สำเร็จ — ใครและจากที่ใด สำเร็จโดยเฉพาะ ไม่ใช่ความล้มเหลวนับพัน: ความล้มเหลวคือพื้นหลัง ในขณะที่การเข้าสู่ระบบจากที่อยู่แปลกหน้าต้องการคำอธิบาย;
  • sudo และ pam_unix ใครยกระดับสิทธิ์และใครสร้างผู้ใช้;
  • Disk Space บรรทัดเดียวที่เตือนเรื่องดิสก์ที่กำลังเต็มไว้ล่วงหน้า;
  • cron งานที่ปรากฏขึ้นและงานที่ล้มเหลว;
  • http การพุ่งขึ้นของการตอบ 404 มักหมายถึงการงมหาเส้นทาง ส่วนการพุ่งขึ้นของ 500 หมายถึงมีอะไรของคุณพัง;
  • postfix ถ้าเซิร์ฟเวอร์ส่งเมล: คิวขาออกที่โตขึ้นคือสัญญาณตามแบบฉบับว่าเซิร์ฟเวอร์ถูกเอาไปใช้เป็นรีเลย์สแปม

ข้อจำกัดของมัน

Logwatch คือสรุปของวันที่ผ่านมา ไม่ใช่การแจ้งเตือน มันจะไม่ปลุกคุณกลางดึกและตามนิยามแล้วมันตามหลัง: มันรันจากงานรายวันตอนเช้ามืดและครอบคลุมเมื่อวาน สำหรับ «ตอนนี้กำลังเกิดอะไรขึ้น» มันไม่เหมาะและไม่ได้ถูกสร้างมาเพื่อการนั้น

จุดแข็งของมันอยู่ที่อื่น — มันแสดงรูปร่างของวันธรรมดาให้คุณเห็น หลังอ่านไปหนึ่งเดือน คุณจะรู้ว่าปกติมีการเข้าสู่ระบบล้มเหลวกี่ครั้ง เว็บไซต์รับคำขอเท่าไร และเมลออกไปเท่าไร และเมื่อตัวเลขใดตัวเลขหนึ่งเพิ่มเป็นสองเท่า มันก็เห็นได้ทันทีโดยไม่ต้องมีเกณฑ์และไม่ต้องมีกฎใด ๆ ด้วยเหตุนี้รายงานจึงควรอยู่ในที่ที่สะดุดตา ไม่ใช่ในโฟลเดอร์เมล ภาพบนหน้าเดียวเป็นอย่างไรดูได้ที่เดโมด้านล่าง