Every time a user connects via SSH, a script requests a web page, or a background service encounters an error, your Linux server securely records the event on disk. These system logs are your first line of visibility into potential security breaches. However, actively maintaining security means actually reading these logs—and manually parsing through thousands of lines in /var/log every day is completely impractical.

If you do not actively monitor your logs, you might not realize an attacker has been probing your network or attempting privilege escalation until the breach is already complete. Automating your log analysis ensures you maintain a watchful eye on your infrastructure without dedicating hours to manual auditing.

Centralizing Visibility with Logwatch

Logwatch is a highly customizable, open-source log analysis system. It actively parses your server's raw log files, filters out the normal background noise, and generates a structured, easy-to-read daily summary of all significant activity.

Instead of hunting for anomalies via the command line, Logwatch proactively delivers a formatted report straight to your email inbox. It automatically categorizes events by service, clearly highlighting failed authentication attempts, out-of-memory errors, and unauthorized software executions.

Installing and Configuring the Service

Getting Logwatch running on a standard Ubuntu or Debian environment is a rapid process, as the tool is heavily vetted and available in the default package repositories.

  • Connect to your server via SSH and ensure your package manager lists are current by running sudo apt update.

  • Install the package, along with a lightweight mail transfer agent (like Postfix or mailutils) to handle the email dispatch: sudo apt install logwatch mailutils.

  • Never edit the default configuration file directly. Copy it to your local directory so your custom settings are preserved during future system updates: sudo cp /usr/share/logwatch/default.conf/logwatch.conf /etc/logwatch/conf/logwatch.conf

  • Open your newly created local configuration file with your preferred text editor: sudo nano /etc/logwatch/conf/logwatch.conf.

Tailoring Your Daily Security Report

Out of the box, Logwatch might send either too much raw data or not enough specific detail. Adjusting the configuration file ensures you only receive actionable, relevant intelligence.

  • Output Destination: Locate the Output directive and ensure its value is strictly set to mail.

  • Email Address: Find the MailTo directive and change its value from the default root account to your actual, regularly monitored email address (e.g., MailTo = security@yourdomain.com).

  • Detail Level: Adjust the Detail setting. By default, it is set to Low. Changing this to Med or High provides deeper insights into specific blocked connections and web server error codes, though High can generate very long emails on high-traffic servers.

  • Service Filtering: The Service = All directive instructs Logwatch to analyze every active daemon on the server. You can explicitly exclude noisy, low-risk services from your daily report by adding a minus sign, such as Service = "-systemd".

Analyzing the Output

Once configured, the system's daily cron job automatically triggers Logwatch to compile and send the report. When reviewing your daily email, you should quickly scan for a few critical indicators of compromise:

  • SSHd (Secure Shell): Look for successful logins from unrecognized IP addresses or unexpected root escalations. While tools like Fail2Ban handle the active blocking, this section reveals how heavily your SSH port is being targeted and if any attackers slipped through.

  • Sudo Operations: Every single command executed with elevated root privileges is logged here. If you see administrative commands executed by a user account that shouldn't have sudo access, your system is likely compromised.

  • Disk Space and Kernel Errors: Security isn't strictly about hackers; a full hard drive will crash your database and cause a denial of service. Logwatch warns you when storage partitions reach critical capacity or when hardware begins to fail.

Var dette svaret til hjelp? 0 brukere syntes dette svaret var til hjelp (0 Stemmer)