How to Monitor Linux Event Logs Using Wazuh

Linux systems generate thousands of log entries every day, recording everything from user logins and authentication attempts to service failures, kernel events, scheduled jobs, and application activity.

These logs provide one of the most valuable sources of security telemetry because they document exactly what is happening across your infrastructure in real time.

Monitoring Linux event logs is essential for detecting unauthorized access attempts, identifying malware activity, troubleshooting operational issues, and maintaining compliance with industry regulations.

Organizations that rely on manual log reviews often struggle to keep pace with the sheer volume of events generated by modern Linux servers, containers, and cloud workloads.

Wazuh provides a centralized platform that automatically collects, normalizes, analyzes, and correlates Linux event logs from multiple endpoints.

Instead of logging into each server individually to inspect files such as /var/log/auth.log or /var/log/syslog, administrators can monitor every Linux system from a single dashboard while receiving real-time alerts whenever suspicious activity occurs.

In this guide, you’ll learn how Linux event log monitoring works, how Wazuh collects and analyzes Linux logs, which log sources should be monitored, how to configure event collection, and best practices for building an efficient monitoring strategy that improves both security visibility and operational awareness.

What Is Linux Event Log Monitoring?

Linux event log monitoring is the continuous collection, analysis, and alerting of system-generated log events to detect security incidents, operational problems, and abnormal system behavior.

Every Linux component, from the kernel and authentication services to background daemons and applications, records events that describe what is happening on the system.

These event logs serve as a historical timeline of system activity.

Security teams use them to investigate incidents, identify malicious behavior, and reconstruct attack timelines after a compromise.

Unlike application logs, Linux event logs primarily record operating system and infrastructure-level events.

Application logs focus on software-specific activities such as web requests, database queries, or API errors, while system event logs capture authentication events, privilege escalations, kernel messages, service starts and stops, hardware failures, network activity, and scheduled task execution.

For example:

Linux Event Logs	Application Logs
SSH login attempts	Apache access requests
User account creation	Web application errors
sudo privilege usage	Database query logs
Kernel warnings	API request logs
System service failures	Business application events

Monitoring Linux event logs is important for several reasons:

Detecting brute-force login attacks
Identifying privilege escalation attempts
Discovering unauthorized account creation
Tracking configuration changes
Investigating system crashes
Troubleshooting service failures
Meeting compliance requirements such as PCI DSS, HIPAA, ISO 27001, and NIST

The importance of centralized log management has been emphasized by the National Institute of Standards and Technology (NIST) in Special Publication 800-92, which recommends automated log collection and continuous analysis as foundational security practices.

Some of the most common Linux log sources include:

/var/log/auth.log (Debian/Ubuntu authentication events)
/var/log/secure (RHEL/CentOS authentication logs)
/var/log/syslog
/var/log/messages
/var/log/kern.log
systemd-journald
Cron logs
Auditd logs
SSH logs
Package manager logs
Kernel audit events
Application-specific log files

Collectively, these logs provide comprehensive visibility into system behavior and are often the first place incident responders look when investigating suspicious activity.

How Wazuh Monitors Linux Event Logs

Wazuh continuously collects Linux logs using lightweight agents installed on monitored endpoints.

The platform analyzes every incoming event through a multi-stage processing pipeline that transforms raw log entries into structured security alerts.

At a high level, the Wazuh architecture consists of four primary components:

Wazuh Agent
Wazuh Manager
Wazuh Indexer
Wazuh Dashboard

The monitoring process begins on each Linux endpoint, where the Wazuh agent watches configured log files in real time.

Whenever a new event is written, the agent immediately captures it and securely forwards it to the Wazuh manager for analysis.

Role of the Wazuh Agent

The Wazuh agent acts as the local collector running on each monitored Linux machine.

Its responsibilities include:

Monitoring configured log files
Detecting new log entries
Compressing and encrypting events
Sending logs securely to the manager
Performing local integrity checks
Collecting inventory and system information

Unlike traditional polling solutions, the agent streams events almost immediately after they are written, enabling near real-time detection of security incidents.

For example, if an attacker performs multiple failed SSH login attempts, the authentication logs are forwarded to the manager within seconds.

Related Guide: How to Add Linux Endpoints to Wazuh

Log Collection Workflow

The log collection process follows a straightforward pipeline:

A Linux service generates a log event.
The event is written to a monitored log file or the systemd journal.
The Wazuh agent detects the new entry.
The event is securely transmitted to the Wazuh manager.
The manager decodes and analyzes the event.
Matching security rules are evaluated.
Alerts are generated if detection conditions are met.
Alerts are indexed for searching and visualization.

Because collection happens continuously, administrators receive alerts quickly rather than waiting for scheduled scans.

Event Processing Pipeline

After reaching the Wazuh manager, every event passes through several analysis stages designed to extract useful security information.

The processing pipeline typically includes:

Log normalization
Decoder selection
Field extraction
Rule evaluation
Threat classification
Severity assignment
Alert generation
Storage and indexing

This layered approach allows Wazuh to understand events from many different Linux distributions and log formats without requiring manual parsing for common services.

According to the MITRE ATT&CK framework, many attacker techniques, including credential access, persistence, privilege escalation, and defense evasion, leave detectable artifacts in operating system logs, making continuous log monitoring a key component of threat detection.

Decoding, Rule Matching, and Alert Generation

One of Wazuh’s most powerful capabilities is its decoder and rules engine.

A decoder identifies the log format and extracts structured fields such as:

Username
Source IP
Destination IP
Process name
Service
Command executed
Event ID
Timestamp

After decoding, the extracted data is evaluated against Wazuh’s extensive library of detection rules.

For example, Wazuh can detect:

Multiple failed SSH login attempts
Successful root logins
Unauthorized sudo usage
User account creation
Privilege escalation
Service crashes
Kernel errors
Malware indicators
Suspicious cron modifications

Each matching rule assigns a severity level, descriptive message, MITRE ATT&CK mapping (when applicable), and recommended response information.

The creator of Linux, Linus Torvalds, has frequently emphasized that observability and detailed system diagnostics are essential for understanding and maintaining complex Linux systems.

While this principle extends beyond security, comprehensive logging forms the foundation of effective monitoring and incident response.

If built-in rules do not meet your organization’s requirements, Wazuh also allows administrators to create custom decoders and detection rules tailored to proprietary applications or unique environments.

Related Guide: How to Test Wazuh Rules

Prerequisites

Before configuring Wazuh to monitor Linux event logs, verify that your environment meets the necessary requirements.

Proper setup ensures reliable log collection, minimizes troubleshooting, and guarantees that alerts reach the Wazuh manager without interruption.

Wazuh Manager Installed

The Wazuh manager is responsible for receiving log events from agents, decoding them, matching them against detection rules, and generating alerts.

Ensure that:

The Wazuh manager is installed and running.
The manager can accept agent connections.
Required services are healthy.
The Wazuh dashboard and indexer are operational (if installed).

You can verify the manager status using:

sudo systemctl status wazuh-manager

If the manager is not functioning correctly, agents may appear connected while logs never reach the analysis engine.

Wazuh Agent Installed on Linux Systems

Every Linux endpoint that you want to monitor must have the Wazuh agent installed.

The agent performs several tasks, including:

Reading monitored log files
Monitoring system activity
Collecting security events
Forwarding logs securely to the manager

Verify the agent is running:

sudo systemctl status wazuh-agent

If the service is stopped, start it with:

sudo systemctl start wazuh-agent

If the service refuses to start, investigate configuration or service-related issues before continuing.

Related Guides:

How to Install a Wazuh Agent on Windows Server (for Windows endpoints in mixed environments)

How to Add Linux Endpoints to Wazuh

Supported Linux Distributions

Wazuh supports virtually all major Linux distributions, including:

Ubuntu
Debian
CentOS
Red Hat Enterprise Linux (RHEL)
Rocky Linux
AlmaLinux
Fedora
Oracle Linux
Amazon Linux
SUSE Linux Enterprise Server (SLES)

Most distributions store logs in similar locations, although filenames may differ.

For example:

Distribution	Authentication Log
Ubuntu/Debian	`/var/log/auth.log`
RHEL/CentOS	`/var/log/secure`

Modern distributions that rely heavily on systemd may also store events within the systemd journal rather than traditional log files.

Required Permissions

The Wazuh agent must have sufficient privileges to read the log files you intend to monitor.

Depending on the log source, this may require access to:

/var/log
/etc
/var/log/audit
systemd journal
Application log directories

Some security-sensitive logs, such as audit logs, are readable only by the root user or authorized system groups.

Running the Wazuh agent with the default installation permissions is typically sufficient for collecting standard system logs.

Network Connectivity Between Agent and Manager

The agent must be able to communicate with the Wazuh manager over the network.

Before configuring log monitoring, verify:

The manager is reachable.
Firewalls permit communication.
Required ports are open.
DNS resolution works correctly (if using hostnames).
TLS certificates are valid.

A network interruption prevents collected logs from reaching the manager, resulting in delayed or missing alerts.

If you’re troubleshooting connectivity issues, start by confirming that the agent remains registered and connected.

Linux Log Sources You Can Monitor with Wazuh

One of Wazuh’s biggest strengths is its ability to monitor virtually any Linux log source.

Whether the logs originate from the operating system, security framework, web server, database, or custom application, Wazuh can collect and analyze them in real time.

Below are the most common Linux log sources that organizations monitor.

System Logs

System logs provide a broad view of operating system activity, including service events, daemon messages, startup processes, and hardware notifications.

Common system logs include:

/var/log/syslog (Ubuntu/Debian)
/var/log/messages (RHEL/CentOS)

These logs are useful for detecting:

Service failures
Unexpected reboots
Daemon crashes
Network configuration changes
Hardware problems
General operating system events

Authentication Logs

Authentication logs are among the most valuable security log sources because they record user authentication activity.

Common files include:

/var/log/auth.log
/var/log/secure

Typical events include:

Successful logins
Failed login attempts
sudo usage
User creation
Password changes
SSH authentication
PAM authentication failures

These logs are essential for detecting brute-force attacks, credential abuse, and unauthorized access attempts.

Kernel Logs

Kernel logs record low-level operating system events generated by the Linux kernel.

Common sources include:

/var/log/kern.log
dmesg

These logs can reveal:

Driver failures
Hardware faults
Kernel panics
Filesystem errors
Security module events
Boot diagnostics

Kernel logs are particularly useful when investigating stability issues or suspicious kernel-level behavior.

Audit Logs

The Linux Audit Framework (auditd) records detailed security events that standard system logs often miss.

Examples include:

File access
File deletion
Process execution
Permission modifications
System call monitoring
SELinux activity
Privilege escalation

Audit logs provide deep visibility into user activity and are commonly used in forensic investigations and compliance reporting.

Many compliance standards, including PCI DSS and HIPAA, recommend centralized monitoring of audit logs.

Cron Logs

Cron logs record scheduled task execution.

These events help administrators monitor:

Scheduled scripts
Backup jobs
Maintenance tasks
Unexpected cron modifications
Suspicious scheduled commands

Attackers frequently establish persistence by creating malicious cron jobs, making these logs valuable for threat detection.

Package Management Logs

Package managers record software installation, updates, and removals.

Depending on the Linux distribution, these may include:

APT (Ubuntu/Debian)
YUM (CentOS/RHEL 7)
DNF (Fedora, RHEL 8+, Rocky Linux, AlmaLinux)

Monitoring package management logs allows administrators to detect:

Unauthorized software installation
Unexpected package upgrades
Security patch failures
Repository changes

SSH Logs

SSH logs provide detailed information about remote access activity.

Common events include:

Successful logins
Failed authentication attempts
Invalid usernames
Public key authentication
Session termination
Root login attempts
Privilege escalation events

These logs are one of the first places security analysts look during incident investigations.

Web Server Logs

Web server logs help identify attacks targeting internet-facing applications.

Supported web servers include:

Apache
Nginx

These logs commonly reveal:

SQL injection attempts
Directory traversal attacks
HTTP errors
Suspicious user agents
Excessive requests
Exploitation attempts

Related Guide: How to Monitor Apache Logs with Wazuh

Database Logs

Wazuh can also monitor database logs.

Common examples include:

MySQL
PostgreSQL

Useful events include:

Authentication failures
Unauthorized queries
Slow queries
Database crashes
Replication failures
Privilege changes

Monitoring database logs improves visibility into both security incidents and operational problems.

Application Logs

In addition to system logs, Wazuh can monitor virtually any custom application log.

Examples include:

Java applications
Python applications
Node.js services
Go applications
Custom enterprise software
Containerized workloads

Because Wazuh supports custom decoders and rules, organizations can build detections specifically for proprietary applications.

Configuring Wazuh to Monitor Linux Event Logs

Wazuh uses the agent configuration file (ossec.conf) to define which log sources should be monitored.

By adding log collection entries, you can monitor everything from standard system logs to custom application logs and the systemd journal.

Locate the Agent Configuration File

On Linux, the primary agent configuration file is:

/var/ossec/etc/ossec.conf

Open the file using your preferred text editor:

sudo nano /var/ossec/etc/ossec.conf

Most log monitoring settings are defined inside one or more <localfile> blocks.

If the agent fails to start after editing the configuration, validate the XML syntax before restarting the service.

Configure Local Log Collection

To monitor a log file, add a <localfile> entry.

Example:

<localfile>
  <location>/var/log/auth.log</location>
  <log_format>syslog</log_format>
</localfile>

This instructs the agent to continuously monitor the authentication log and forward new events to the manager.

Monitor Multiple Log Files

You can monitor multiple logs by defining additional <localfile> blocks.

Example:

<localfile>
  <location>/var/log/syslog</location>
  <log_format>syslog</log_format>
</localfile>

<localfile>
  <location>/var/log/auth.log</location>
  <log_format>syslog</log_format>
</localfile>

<localfile>
  <location>/var/log/kern.log</location>
  <log_format>syslog</log_format>
</localfile>

This approach enables centralized monitoring of several important log sources simultaneously.

Monitor Custom Log Files

Applications often store logs outside the /var/log directory.

For example:

<localfile>
  <location>/opt/myapp/logs/application.log</location>
  <log_format>syslog</log_format>
</localfile>

If the application uses a non-standard log format, you can create a custom decoder to properly parse its events.

Configure Wildcard Log Monitoring

Wildcard patterns simplify monitoring when applications create multiple rotating log files.

Example:

<localfile>
  <location>/var/log/myapp/*.log</location>
  <log_format>syslog</log_format>
</localfile>

This configuration automatically includes every .log file within the specified directory.

Configure Journald Log Collection

Many modern Linux distributions rely on systemd-journald instead of traditional log files.

Wazuh can collect events directly from the systemd journal, allowing you to monitor services that write exclusively to journald. This is particularly useful on newer distributions where important system and service events are not duplicated in /var/log.

Refer to the official Wazuh documentation for the exact journald configuration options supported by your installed version.

Exclude Unnecessary Logs

Not every log source provides useful security information.

Monitoring low-value or extremely verbose logs can increase storage consumption, processing overhead, and alert fatigue.

Consider excluding:

Temporary application logs
Debug logs
Frequently changing cache logs
Large archive files
Rotated logs that no longer receive updates

A focused collection strategy improves detection quality and overall system performance.

Restart the Wazuh Agent

After saving the configuration, restart the agent to apply the changes.

sudo systemctl restart wazuh-agent

Then verify that the service is running:

sudo systemctl status wazuh-agent

If the service fails to restart, review the agent logs and configuration for errors before proceeding.

Verify Configuration

Finally, confirm that log events are reaching the Wazuh manager.

You can verify this by:

Generating a test event (for example, an SSH login).
Opening the Wazuh Dashboard.
Searching for the event in the Security Events view.
Confirming that the expected rule matched.
Reviewing extracted fields such as username, source IP, and log file.

If events are not appearing, verify the agent configuration, network connectivity, file permissions, and manager status before continuing with further troubleshooting.

Example Wazuh Log Collection Configurations

The flexibility of Wazuh’s log collection engine allows you to monitor nearly any text-based log generated on a Linux system.

Whether you’re collecting authentication events, audit logs, web server logs, or custom application logs, the configuration follows the same basic pattern using <localfile> entries in the agent’s ossec.conf file.

Below are several common examples.

Monitoring Authentication Logs

Authentication logs are one of the highest-value sources for security monitoring because they capture login attempts, privilege escalation, password changes, and SSH activity.

On Ubuntu and Debian systems:

<localfile>
  <location>/var/log/auth.log</location>
  <log_format>syslog</log_format>
</localfile>

On RHEL-based distributions:

<localfile>
  <location>/var/log/secure</location>
  <log_format>syslog</log_format>
</localfile>

This configuration enables Wazuh to detect events such as:

Failed SSH logins
Successful remote logins
Invalid usernames
Root login attempts
sudo execution
Authentication failures

Monitoring Syslog

Many Linux services write operational messages to the system log.

Example:

<localfile>
  <location>/var/log/syslog</location>
  <log_format>syslog</log_format>
</localfile>

On distributions that use /var/log/messages:

<localfile>
  <location>/var/log/messages</location>
  <log_format>syslog</log_format>
</localfile>

Monitoring system logs helps identify:

Service failures
Unexpected daemon restarts
Network issues
Boot events
General operating system activity

Monitoring Auditd Logs

The Linux Audit Framework records detailed security events that are useful for compliance, forensics, and threat detection.

Example:

<localfile>
  <location>/var/log/audit/audit.log</location>
  <log_format>audit</log_format>
</localfile>

Auditd logs commonly include:

File access
Process execution
System calls
Permission changes
SELinux events
User account modifications

Because audit logs contain highly structured security data, they often produce richer alerts than traditional system logs.

Monitoring Apache Logs

Web server logs can reveal attacks against internet-facing applications.

Example:

<localfile>
  <location>/var/log/apache2/access.log</location>
  <log_format>apache</log_format>
</localfile>

<localfile>
  <location>/var/log/apache2/error.log</location>
  <log_format>syslog</log_format>
</localfile>

These logs can help detect:

Directory traversal attempts
SQL injection probes
HTTP 500 errors
Suspicious user agents
Excessive requests
Web application attacks

Monitoring Nginx Logs

Nginx logs can be monitored in a similar way.

Example:

<localfile>
  <location>/var/log/nginx/access.log</location>
  <log_format>syslog</log_format>
</localfile>

<localfile>
  <location>/var/log/nginx/error.log</location>
  <log_format>syslog</log_format>
</localfile>

These logs are useful for identifying:

Suspicious HTTP requests
Failed requests
Reverse proxy errors
Scanning activity
Denial-of-service attempts

Monitoring Custom Application Logs

Many organizations run internally developed applications that generate their own log files.

For example:

<localfile>
  <location>/opt/company/application/logs/app.log</location>
  <log_format>syslog</log_format>
</localfile>

If your application’s log format differs from standard formats, you can create a custom decoder and corresponding detection rules to extract meaningful fields and generate alerts.

Monitoring Multiple Log Sources

Most production environments monitor several log sources simultaneously.

Example:

<localfile>
  <location>/var/log/auth.log</location>
  <log_format>syslog</log_format>
</localfile>

<localfile>
  <location>/var/log/syslog</location>
  <log_format>syslog</log_format>
</localfile>

<localfile>
  <location>/var/log/audit/audit.log</location>
  <log_format>audit</log_format>
</localfile>

<localfile>
  <location>/var/log/nginx/access.log</location>
  <log_format>syslog</log_format>
</localfile>

<localfile>
  <location>/opt/app/logs/app.log</location>
  <log_format>syslog</log_format>
</localfile>

This configuration gives Wazuh visibility into operating system activity, authentication events, web traffic, security auditing, and application behavior from a single Linux endpoint.

Understanding How Wazuh Processes Linux Events

Collecting Linux logs is only the first step.

Wazuh transforms raw log entries into meaningful security alerts through a multi-stage event processing pipeline.

Each stage enriches the data, making it easier for analysts to identify suspicious activity and respond quickly.

Log Collection

The process begins on the monitored Linux endpoint.

The Wazuh agent continuously watches configured log files for new entries.

Unlike scheduled polling, the agent monitors logs in near real time, forwarding new events to the Wazuh manager almost immediately after they are written.

This approach minimizes detection delays and reduces the risk of missing short-lived events.

Decoding

Raw log entries are often unstructured and vary widely between services.

For example, an SSH authentication log looks very different from an Apache access log or an Auditd event.

Wazuh uses decoders to:

Identify the log source
Parse the message
Extract structured fields
Normalize event data

Common extracted fields include:

Username
Source IP address
Destination IP address
Process name
Command executed
Service name
Timestamp
Event type

Structured data enables the rules engine to evaluate events accurately, regardless of the original log format.

Rule Matching

After decoding, the event is evaluated against Wazuh’s extensive library of built-in detection rules.

These rules identify behaviors such as:

Brute-force attacks
SSH login failures
Privilege escalation
Malware indicators
Configuration changes
File integrity violations
Web application attacks
Policy violations

Organizations can also create custom rules for proprietary applications or unique security requirements.

Alert Generation

When a rule matches, Wazuh generates an alert containing detailed contextual information.

A typical alert includes:

Rule ID
Rule description
Severity level
Timestamp
Agent name
Source log file
Decoded fields
MITRE ATT&CK technique mapping (when applicable)

This enriched information helps analysts understand what happened without manually reviewing the original log.

Dashboard Visualization

Generated alerts are stored in the Wazuh Indexer and displayed through the Wazuh Dashboard.

Security analysts can:

Search alerts
Filter by severity
Investigate individual endpoints
Build dashboards
Visualize attack trends
Create reports
Analyze historical activity

The centralized dashboard provides a unified view of events across every monitored Linux system.

Active Response (Optional)

In addition to detecting threats, Wazuh can automatically respond to certain security events using Active Response.

Depending on your configuration, Wazuh can:

Block malicious IP addresses
Disable compromised user accounts
Terminate malicious processes
Remove malicious files
Execute custom response scripts

Automated response reduces the time between detection and containment, limiting the impact of an attack.

Because automatic actions can disrupt legitimate users if configured too broadly, they should be thoroughly tested before being deployed in production.

Related Guide: How to Configure Wazuh Active Response

Viewing Linux Events in the Wazuh Dashboard

Once Wazuh begins collecting Linux logs, you can use the Wazuh Dashboard to search, filter, and investigate events.

The dashboard provides powerful search capabilities that allow analysts to quickly locate authentication events, kernel messages, application logs, and other security-relevant information.

Navigate to Security Events

This view displays all events received from monitored endpoints, including Linux, Windows, network devices, and cloud services.

Each event typically includes:

Timestamp
Agent
Rule description
Severity level
Source IP
Event category
Original log message

Filter by Linux Agent

If your environment contains many monitored systems, filtering by agent helps narrow the results.

For example, you can filter events for:

A specific Linux server
A production environment
A development environment
A web server
A database server

This makes investigations significantly faster during incident response.

Search by Log File

You can also search events based on the originating log file.

Examples include:

/var/log/auth.log
/var/log/syslog
/var/log/messages
/var/log/audit/audit.log
/var/log/nginx/access.log

Searching by log source is particularly useful when investigating issues related to a specific service or subsystem.

Search by Event Type

The dashboard also supports searching by event type or rule description.

Examples include:

Failed SSH logins
Successful authentication
sudo execution
User creation
Kernel warnings
Audit events
File modifications
Service failures

Combining multiple filters, such as agent name, severity, and event type, can significantly reduce the number of results during an investigation.

Investigate Alert Details

Selecting an alert opens a detailed view containing the decoded event data.

Depending on the event, you may see:

Original log message
Parsed fields
Rule ID
Rule description
Severity
Source IP
Username
Process name
File path
MITRE ATT&CK mapping

Reviewing these details helps analysts determine whether the event represents normal activity or a potential security incident.

Create Saved Searches

If you routinely investigate the same types of events, consider creating saved searches within the dashboard.

Examples include searches for:

Failed SSH authentication attempts
Root logins
Auditd events
Apache errors
Nginx access logs
High-severity alerts
Events from production servers

Saved searches allow security teams to quickly return to commonly used views, reducing investigation time and ensuring consistency across recurring monitoring tasks.

Creating Custom Detection Rules for Linux Logs

Although Wazuh includes thousands of built-in detection rules, every environment is unique.

Organizations often run proprietary applications, use custom logging formats, or have security requirements that aren’t fully covered by the default ruleset.

Creating custom detection rules allows you to detect organization-specific events while improving the accuracy of your alerts.

When Custom Rules Are Needed

You should consider creating custom rules when:

Monitoring proprietary or in-house applications
Detecting business-specific security events
Parsing custom log formats
Assigning different severity levels to existing events
Correlating events that are unique to your environment
Meeting internal security or compliance requirements

For example, you might want to generate a high-severity alert whenever a critical application logs the message:

Administrative configuration changed

Even if this message isn’t suspicious in every environment, it may indicate a significant event in yours.

Create a Custom Rule File

Rather than modifying Wazuh’s built-in rule files, create a separate custom rule file.

This approach simplifies maintenance and prevents your changes from being overwritten during upgrades.

Custom rules are typically stored in:

/var/ossec/etc/rules/local_rules.xml

If the file does not already exist, create it and define your custom rules there.

Keeping custom rules separate also makes version control and collaboration easier for security teams.

Match Specific Log Patterns

Each rule should target a distinct log pattern or event of interest.

For example, suppose your application writes the following log entry:

CRITICAL: Configuration changed by user admin

You could create a rule that matches the keyword “Configuration changed” and generates an alert whenever it appears.

Effective rules focus on meaningful indicators such as:

Administrative actions
Security policy violations
Unauthorized configuration changes
Failed authentication events
Application errors
Suspicious command execution

Avoid writing rules that broadly match common log messages, as this can lead to excessive alerts.

Assign Alert Levels

Every Wazuh rule includes a severity level that reflects the importance of the event.

In general:

Alert Level	Typical Use
Low	Informational events
Medium	Suspicious activity requiring review
High	Confirmed security events
Critical	Immediate response required

Assign severity based on the potential impact rather than how frequently an event occurs.

For example:

Failed login attempt → Low or Medium
Multiple failed logins → High
Root login from an unknown IP → High
Unauthorized privilege escalation → Critical

Consistent severity levels help analysts prioritize investigations more effectively.

Test Custom Rules

Always validate new rules before deploying them into production.

Wazuh provides Logtest, which allows you to submit sample log entries and verify:

Decoder selection
Extracted fields
Matching rules
Alert severity

Testing helps identify syntax errors, unexpected matches, and rule conflicts before they generate production alerts.

Related Guide: How to Test Wazuh Rules

Deploy Rule Changes

After testing, restart or reload the Wazuh manager so the updated rules are loaded.

Once deployed:

Generate test events.
Confirm alerts appear in the dashboard.
Verify the correct rule ID and severity.
Ensure existing rules continue functioning as expected.

If your environment includes multiple managers, confirm that the updated rules have been distributed consistently across the cluster.

Reducing Noise and False Positives

One of the biggest challenges in security monitoring is alert fatigue.

Excessive low-value alerts can overwhelm analysts and make it easier to overlook genuine threats.

Wazuh provides several techniques for reducing unnecessary alerts while preserving visibility into meaningful security events.

Ignore Low-Value Events

Not every log entry requires an alert.

Examples of low-value events include:

Routine service startup messages
Scheduled maintenance tasks
Successful health checks
Expected application status messages
Periodic background jobs

Filtering these events allows analysts to focus on activity that may indicate security or operational issues.

Fine-Tune Detection Rules

Rather than relying solely on default rules, tailor them to your environment.

For example, you might:

Increase the threshold for failed login alerts
Ignore authentication attempts from trusted management systems
Create stricter rules for production servers
Assign higher severity to privileged account activity

Fine-tuning improves detection quality while reducing unnecessary investigations.

Related Guide: How to Reduce False Positives in Wazuh

Exclude Specific Log Entries

Some applications generate repetitive messages that have little operational value.

Examples include:

Debug logs
Verbose status messages
Routine synchronization events
Temporary warning messages during startup

Where appropriate, exclude these log entries from collection or rule evaluation to reduce storage consumption and processing overhead.

Use Rule Suppression

Rule suppression prevents repeated occurrences of the same event from generating excessive alerts.

For example, instead of creating hundreds of identical alerts for a recurring warning, you can suppress duplicate notifications for a defined period.

This is particularly useful for:

Repeated authentication failures from a known source
Frequent service restarts during maintenance
Temporary infrastructure issues
Expected application retries

Rule suppression reduces alert volume without completely hiding the underlying activity.

Group Similar Events

Correlating related events provides better context than treating each event independently.

Examples include grouping:

Multiple failed SSH logins from the same IP address
Repeated authentication failures for one user
Numerous web requests targeting the same endpoint
Multiple privilege escalation attempts within a short time window

Event grouping helps identify attack patterns while significantly reducing the number of alerts analysts must review.

Monitoring High-Value Security Events

Although Linux generates a large volume of logs, certain events deserve immediate attention because they frequently indicate security incidents or unauthorized activity.

Configuring Wazuh to prioritize these high-value events helps security teams detect threats more quickly and respond before they escalate.

Failed SSH Login Attempts

Repeated failed SSH logins often indicate:

Brute-force attacks
Password spraying
Credential stuffing
Attempts to access disabled accounts

Wazuh can detect repeated authentication failures, identify the originating IP address, and generate alerts when predefined thresholds are exceeded.

Successful Root Logins

Root logins should generally be rare.

Unexpected root authentication may indicate:

Credential compromise
Unauthorized administrative access
Misconfigured security policies
Insider threats

Security teams should investigate successful root logins, particularly those originating from unfamiliar systems or occurring outside normal business hours.

Sudo Privilege Escalation

Monitoring sudo activity provides visibility into administrative actions performed by privileged users.

Important events include:

Successful sudo execution
Failed sudo attempts
Execution of sensitive commands
Unexpected privilege escalation

Correlating sudo activity with authentication logs provides valuable context during investigations.

User Account Creation

New user accounts should typically be created through approved administrative processes.

Unexpected account creation may indicate:

Persistence mechanisms
Insider activity
Unauthorized administrative access
Malware establishing new accounts

Wazuh can alert whenever new Linux users are added to the system.

User Account Deletion

User account removal is another important administrative event.

Monitoring account deletion helps identify:

Unauthorized account removal
Attempts to hide malicious activity
Administrative mistakes
Insider threats

Maintaining an audit trail of account lifecycle events is particularly important in regulated environments.

Password Changes

Password modifications may represent:

Normal credential rotation
Administrative resets
Account recovery
Unauthorized credential changes

Unexpected password changes, especially for privileged accounts, should be investigated promptly.

Service Starts and Stops

Unexpected service state changes can indicate operational problems or malicious activity.

Examples include:

SSH service stopping unexpectedly
Web server restarts
Database service failures
Security agent shutdowns

Attackers sometimes disable monitoring or logging services to evade detection, making service events an important source of security telemetry.

Kernel Errors

Kernel logs can reveal serious system issues, including:

Hardware failures
Driver problems
Kernel panics
Filesystem corruption
Resource exhaustion

Although many kernel events are operational rather than security-related, unusual kernel behavior may also indicate exploitation attempts or unstable software.

Auditd Security Events

Auditd captures detailed information about security-sensitive operations.

High-value Auditd events include:

Permission modifications
File access
Process execution
System call monitoring
SELinux policy violations
Administrative commands

These logs provide detailed forensic evidence during incident investigations.

File Permission Changes

Unexpected permission modifications may allow attackers to:

Escalate privileges
Hide malicious files
Execute unauthorized programs
Access sensitive information

Monitoring changes to critical system files and directories helps identify unauthorized administrative activity before it leads to further compromise.

For comprehensive file change monitoring, combine log monitoring with Wazuh’s File Integrity Monitoring (FIM) capabilities.

Best Practices for Linux Event Log Monitoring

Implementing Linux event log monitoring is only the first step.

Following operational best practices helps ensure that your monitoring remains accurate, efficient, and scalable as your infrastructure grows.

Monitor Only Relevant Log Sources

Collecting every available log may seem beneficial, but excessive data increases storage requirements, processing overhead, and alert fatigue.

Prioritize logs that provide meaningful security and operational visibility, such as:

Authentication logs
Audit logs
System logs
Web server logs
Critical application logs

Review log collection periodically to remove sources that no longer provide value.

Enable Auditd for Detailed Auditing

The Linux Audit Framework provides deeper visibility than traditional system logs by recording security-sensitive system calls and administrative actions.

Auditd is particularly valuable for:

Compliance reporting
Incident investigations
Privilege monitoring
File access auditing
Administrative accountability

Combining Auditd with Wazuh significantly improves detection capabilities.

Rotate Logs Properly

Log rotation prevents files from growing indefinitely and consuming excessive disk space.

Use standard Linux log rotation tools to:

Archive older logs
Compress historical data
Remove outdated files
Preserve retention requirements

Proper rotation also helps maintain consistent agent performance.

Keep Time Synchronization Accurate

Accurate timestamps are essential for event correlation.

Synchronize Linux systems using NTP or another reliable time synchronization service to ensure:

Consistent timestamps
Accurate forensic timelines
Reliable cross-system investigations
Proper event sequencing

Clock drift can complicate incident response by making it difficult to reconstruct the order of events.

Regularly Review Detection Rules

Threats evolve continuously, and detection rules should evolve with them.

Review your rules periodically to:

Remove obsolete rules
Improve detection accuracy
Reduce false positives
Add coverage for emerging attack techniques
Reflect infrastructure changes

Routine rule maintenance helps keep your monitoring aligned with current risks.

Validate Log Collection After System Updates

Operating system upgrades and application updates can change:

Log file locations
Log formats
Service names
Journald behavior
Package paths

After any significant update, verify that Wazuh continues collecting and parsing logs correctly.

Testing after upgrades helps prevent silent monitoring gaps.

Secure Wazuh Agent Communications

Protect communication between Linux agents and the Wazuh manager by:

Using encrypted connections
Protecting authentication credentials
Restricting firewall access
Rotating certificates when appropriate
Monitoring for unauthorized agent registrations

Securing telemetry in transit helps preserve the integrity and confidentiality of security data.

Related Guide: How to Fix Wazuh Certificate Errors

Monitor Agent Health

Even the best detection rules are ineffective if an agent stops reporting.

Regularly verify:

Agent connectivity
Service status
Log collection activity
Queue health
Resource utilization
Software version consistency

Configure alerts for disconnected or inactive agents so monitoring gaps can be addressed quickly.

A healthy agent fleet ensures continuous visibility across your Linux infrastructure and reduces the likelihood of missing critical security events.

Troubleshooting Linux Event Log Collection

Even with a correct installation, you may occasionally encounter issues where Linux logs are not collected or alerts do not appear in the Wazuh Dashboard.

Most problems are caused by configuration mistakes, permission issues, connectivity problems, or changes introduced after system updates.

The following troubleshooting steps cover the most common causes.

Logs Are Not Appearing in Wazuh

If expected events never appear in the dashboard, start with the basics.

Verify that:

The Wazuh agent is running.
The monitored log file exists.
The correct log file is configured in ossec.conf.
The agent is connected to the Wazuh manager.
The manager is receiving events.
No firewall is blocking communication.

You can also generate a known event, such as an SSH login, and confirm whether it appears in the dashboard.

Working through the data flow from the log source to the dashboard helps isolate where events are being lost.

Incorrect Log File Path

One of the most common configuration mistakes is specifying the wrong log file.

For example:

Ubuntu uses /var/log/auth.log
RHEL and CentOS typically use /var/log/secure

Application log locations also vary depending on how software was installed.

Verify the configured path:

ls -l /path/to/logfile

If the file does not exist, update the <location> entry in ossec.conf to point to the correct path.

Permission Denied Errors

The Wazuh agent must be able to read every monitored log.

Permission issues commonly affect:

Auditd logs
Application logs
Security logs
Journald
Custom log directories

Check the permissions:

ls -l /var/log

If necessary, adjust file ownership or permissions so the agent can access the logs without unnecessarily exposing sensitive files to other users.

Wazuh Agent Not Running

If the agent is stopped, no events will be forwarded.

Verify its status:

sudo systemctl status wazuh-agent

If necessary, start or restart it:

sudo systemctl restart wazuh-agent

If the service repeatedly fails, inspect the agent logs and system journal for startup errors before making additional configuration changes.

Configuration Syntax Errors

Because ossec.conf is an XML file, even a small syntax mistake can prevent the agent from loading its configuration.

Common issues include:

Missing closing tags
Invalid nesting
Misspelled elements
Duplicate configuration blocks

Whenever you modify the configuration, validate your changes before restarting the agent.

Journald Logs Not Collected

Many modern Linux distributions rely primarily on systemd-journald instead of traditional log files.

If journald events are missing:

Verify that journald collection is configured.
Confirm your Wazuh version supports the configured options.
Check that the relevant services are writing to the systemd journal.
Ensure the Wazuh agent has permission to access journal entries.

On some systems, you may need to add the Wazuh user to the appropriate system group to access journal data.

Auditd Events Missing

If Auditd events do not appear:

Confirm the Auditd service is running.
Verify the audit log path.
Check that Auditd is actively generating events.
Ensure the Wazuh agent is configured to monitor the audit log.

You can verify that Auditd is recording events by running:

sudo auditctl -l

If no audit rules are configured, Wazuh will have little or no Auditd activity to collect.

Events Delayed or Missing

Delayed events may result from:

Network congestion
High CPU utilization
Large log backlogs
Manager overload
Indexing delays
Resource constraints

Review agent and manager logs to determine whether delays occur during collection, transmission, analysis, or indexing.

Monitoring system performance can also help identify bottlenecks affecting event delivery.

High Resource Usage During Log Collection

Monitoring a large number of high-volume log files can increase CPU, memory, and disk usage.

To improve performance:

Monitor only necessary logs.
Exclude verbose debug files.
Reduce unnecessary custom rules.
Optimize Auditd rules.
Review log rotation settings.
Eliminate duplicate log collection.

Balancing visibility with resource consumption helps maintain efficient monitoring without sacrificing important security telemetry.

Frequently Asked Questions (FAQ)

Question: Can Wazuh monitor both Syslog and Journald?

Yes. Wazuh can monitor traditional Syslog-based files such as /var/log/syslog and /var/log/messages, as well as logs stored in the systemd journal on modern Linux distributions.

The available configuration options depend on your Wazuh version and operating system, so consult the official documentation when configuring journald collection.

Question: Does Wazuh support custom Linux application logs?

Yes. Wazuh can monitor virtually any text-based log file generated by a Linux application.

You simply configure the log path in the agent’s ossec.conf file.

If the log format is not recognized by the built-in decoders, you can create custom decoders and detection rules to parse the events and generate meaningful alerts.

Question: Can Wazuh monitor logs from Docker containers?

Yes. Wazuh can monitor logs generated by containerized applications, provided those logs are accessible to the agent.

Depending on your deployment, this may involve monitoring container log files, bind-mounted log directories, or logs forwarded to the host operating system.

For broader container security, Wazuh also supports monitoring Kubernetes environments.

Related Guide: How to Monitor Kubernetes Using Wazuh

Question: How often are Linux logs sent to the Wazuh manager?

The Wazuh agent continuously watches configured log sources and forwards new events shortly after they are written.

In most environments, logs are transmitted in near real time rather than at fixed polling intervals, allowing security teams to detect suspicious activity quickly.

Question: Does Wazuh support real-time Linux log monitoring?

Yes. Real-time log monitoring is one of Wazuh’s core capabilities.

The agent monitors supported log sources continuously and forwards new events to the manager, where they are decoded, evaluated against detection rules, and displayed in the Wazuh Dashboard as alerts when appropriate.

Question: How do I reduce false positives in Linux event monitoring?

Reducing false positives typically involves refining your monitoring configuration rather than disabling detection altogether. Good practices include:

Monitoring only relevant log sources.
Adjusting rule severity levels.
Excluding known benign events.
Creating environment-specific custom rules.
Using rule suppression for repetitive events.
Regularly reviewing detection performance.

Question: Can I monitor multiple Linux servers from one Wazuh manager?

Yes. A single Wazuh manager is designed to centrally monitor many Linux endpoints, along with Windows systems, network devices, and cloud workloads.

Each server runs a Wazuh agent that securely forwards its events to the manager, where they are analyzed and presented through a unified dashboard.

As your environment grows, you can also deploy clustered Wazuh components to improve scalability and high availability.

Related Guide: How to Build a Wazuh Indexer Cluster

Conclusion

Monitoring Linux event logs is one of the most effective ways to improve system visibility, detect security threats, and simplify troubleshooting.

With Wazuh, the entire workflow, from collecting logs on individual Linux hosts to decoding events, applying detection rules, generating alerts, and visualizing results in a centralized dashboard, is automated, enabling security teams to identify suspicious activity much faster than with manual log reviews.

Centralized monitoring also makes it easier to investigate incidents across multiple servers, correlate related events, satisfy compliance requirements, and maintain a comprehensive audit trail.

Whether you’re monitoring authentication logs, Auditd events, kernel messages, web server activity, or custom application logs, Wazuh provides a flexible framework that can adapt to a wide range of Linux environments.

To keep your monitoring effective over time, regularly review your detection rules, remove unnecessary log sources, fine-tune alert thresholds, and verify log collection after operating system or application updates.

Continuous tuning helps reduce false positives while ensuring that important security events remain visible.

As your security program matures, consider expanding beyond basic log monitoring by enabling features such as File Integrity Monitoring (FIM), Active Response, vulnerability detection, and integrations with external threat intelligence platforms.

Combining these capabilities with comprehensive Linux event log monitoring gives you a stronger foundation for detecting, investigating, and responding to modern security threats.

How to Monitor Linux Event Logs Using Wazuh

What Is Linux Event Log Monitoring?

How Wazuh Monitors Linux Event Logs

Role of the Wazuh Agent

Log Collection Workflow

Event Processing Pipeline

Decoding, Rule Matching, and Alert Generation

Prerequisites

Wazuh Manager Installed

Wazuh Agent Installed on Linux Systems

Supported Linux Distributions

Required Permissions

Network Connectivity Between Agent and Manager

Linux Log Sources You Can Monitor with Wazuh

System Logs

Authentication Logs

Kernel Logs

Audit Logs

Cron Logs

Package Management Logs

SSH Logs

Web Server Logs

Database Logs

Application Logs

Configuring Wazuh to Monitor Linux Event Logs

Locate the Agent Configuration File

Configure Local Log Collection

Monitor Multiple Log Files

Monitor Custom Log Files

Configure Wildcard Log Monitoring

Configure Journald Log Collection

Exclude Unnecessary Logs

Restart the Wazuh Agent

Verify Configuration

Example Wazuh Log Collection Configurations

Monitoring Authentication Logs

Monitoring Syslog

Monitoring Auditd Logs

Monitoring Apache Logs

Monitoring Nginx Logs

Monitoring Custom Application Logs

Monitoring Multiple Log Sources

Understanding How Wazuh Processes Linux Events

Log Collection

Decoding

Rule Matching

Alert Generation

Dashboard Visualization

Active Response (Optional)

Viewing Linux Events in the Wazuh Dashboard

Navigate to Security Events

Filter by Linux Agent

Search by Log File

Search by Event Type

Investigate Alert Details

Create Saved Searches

Be First to Comment

Leave a Reply Cancel reply