How to Monitor Apache Logs with Wazuh

Apache is the backbone of millions of websites globally, making it a primary target for cybercriminals.

Every visit, failed login, and exploit attempt leaves a digital footprint in your web server logs.

If you are not actively monitoring these files, you are essentially operating blind.

Monitoring Apache logs is a critical component of maintaining a strong security posture. Without central visibility, detecting a web attack in real-time is nearly impossible.

Web applications face a barrage of automated and targeted attacks daily.

By analyzing Apache logs, you can spot critical security threats including:

Brute-force attacks: Repetitive HTTP 401 or 403 error codes indicating automated login attempts.
SQL Injection (SQLi): Malicious SQL commands hidden inside URL parameters or form inputs.
Cross-Site Scripting (XSS): Script tags embedded within HTTP requests aimed at executing code in user browsers.
Path Traversal: Directory traversal attempts (e.g., ../../etc/passwd) seeking access to restricted system files.
DDoS activity: Unusually high volumes of rapid requests originating from single or distributed IP addresses.

Wazuh transforms static, flat log files into actionable security intelligence.

Instead of manually parsing text files across multiple servers, Wazuh provides:

Automated log parsing: Real-time decoding of complex Apache log strings.
Instant threat detection: Built-in rulesets that trigger immediate alerts on known attack signatures.
Centralized visibility: A unified dashboard to correlate web server events with your broader infrastructure.
Regulatory compliance: Easy auditing mapping to frameworks like PCI-DSS and SOC 2.

In this guide, you will learn exactly how Apache structures its logs, how the Wazuh architecture processes web data, and how to configure your agents to stream logs directly to your manager for real-time analysis.

Understanding Apache Log Files

Before configuring any SIEM tool, you must understand the structure of the data you are collecting. Apache handles traffic logs and error logs differently.

Apache Access Logs

Purpose of access logs:

Access logs track all inbound client requests processed by the server.

Information recorded in access logs:

They track who visited, when they visited, what resource they requested, and whether the server responded successfully.

Typical access log format:

Most Apache servers use the Common Log Format (CLF) or the Combined Log Format.

A typical entry looks like this:

192.168.1.50 – – [16/Jun/2026:14:32:10 +0000] “GET /index.html HTTP/1.1” 200 4523

Apache Error Logs

Purpose of error logs:

Error logs capture any diagnostic information or failures encountered while processing requests.

Common errors recorded:

These include broken links (HTTP 404), server misconfigurations (HTTP 500), timeout issues, and dropped database connections.

Security and troubleshooting value: A sudden spike in 404 errors might indicate an attacker directory-busting your site.

A spike in 500 errors could indicate a successful denial-of-service attack crashing your backend application.

Custom Apache Log Formats

Combined Log Format:

This is the recommended standard for security monitoring.

It extends the Common Log Format by adding the Referer and User-Agent fields, which are vital for identifying malicious automated bots.

Virtual host logging:

If you host multiple domains on one server, adding the %v variable ensures your logs specify exactly which site received the traffic.

Application-specific logging:

Custom formats can log response times or unique session tokens to assist in deep forensic investigations.

Why Apache Log Monitoring Is Important

Detecting malicious traffic:

Security teams rely on logs to isolate malicious scraping, exploit payloads, and unauthorized access attempts.

Identifying application issues:

Sysadmins use them to debug slow loading pages, broken assets, and server crashes.

Meeting compliance requirements:

Frameworks like PCI-DSS explicitly demand the tracking and review of all access to network resources and web servers.

According to the SANS Institute’s CIS Critical Security Controls comprehensive log monitoring is a foundational requirement for modern enterprise defense.

Improving operational visibility:

Correlating web traffic with system performance metrics allows you to optimize resources and scale your infrastructure accurately.

How Wazuh Processes Apache Logs

Wazuh uses a lightweight, highly efficient engine to ingest, parse, and alert on web server events.

[ Apache Web Server ] —> [ Wazuh Agent ] —> [ Wazuh Manager ] —> [ Wazuh Indexer & Dashboard ]

Log Collection Architecture

Wazuh agent log monitoring:

The lightweight Wazuh agent monitors the Apache log files directly on the endpoint.

If your web server runs on Linux, you can easily pair this collection with tools like Suricata to monitor network traffic simultaneously; see our guide on How to Integrate Wazuh with Suricata for Better Threat Detection for deeper network insights.

If you need to set up your primary servers first, check our guide on How to Add Linux Endpoints to Wazuh.

Event forwarding to the manager:

As new log lines are written by Apache, the agent reads them in near real-time, encrypts the payload, and streams it to the central Wazuh manager.

Storage and indexing process:

The manager processes the incoming stream, archives the raw logs, and sends matching alerts to the Wazuh indexer for search availability.

Decoders and Rules

How decoders parse Apache logs:

Wazuh utilizes pre-built regex decoders specifically designed for Apache.

The decoder extracts variables like target IP address, HTTP status code, requested URL, and the user-agent string into isolated data fields.

How rules generate alerts:

Once decoded, the log fields are evaluated against the internal Wazuh ruleset.

If an event matches an attack pattern (like a high frequency of web errors), an alert triggers.

If you ever find your rules aren’t acting as expected during deployment, read our troubleshooting steps on How to Test Wazuh Rules.

Severity levels and classifications:

Alerts are assigned levels from 0 to 15. Low levels represent routine traffic (like standard HTTP 200 responses), while high levels (level 10+) represent active web exploits or critical errors.

Integration with the Wazuh Dashboard

Searching Apache events:

The OpenSearch-powered backend allows analysts to filter traffic by specific fields, such as focusing strictly on malicious POST requests or specific source IPs.

Visualizing web server activity:

The dashboard transforms raw log data into visual elements, creating geolocation maps of your visitors, pie charts of HTTP response codes, and timelines of traffic spikes.

Investigating alerts:

Security analysts can click into any triggered alert to view the complete raw log payload alongside threat intelligence details, allowing them to rapidly determine if an event is a true positive or a benign anomaly.

Prerequisites

Before configuring Wazuh to monitor Apache logs, ensure all required components are installed and functioning correctly.

Verifying these prerequisites helps avoid data collection issues later in the setup process.

Required Components

To monitor Apache logs successfully, you will need:

A functioning Wazuh server deployment
A Wazuh agent installed on the Apache web server
Apache HTTP Server configured and generating logs
Network connectivity between the Wazuh agent and manager
Sufficient permissions for the Wazuh agent to access Apache log files

Wazuh Server Installation

The Wazuh server is responsible for receiving, analyzing, indexing, and storing log events collected from monitored endpoints.

Before proceeding, verify that:

The Wazuh manager is running
The Wazuh indexer is operational
The Wazuh dashboard is accessible
Agents can successfully register with the manager

If you have not deployed Wazuh yet, refer to the official Wazuh installation documentation:

Wazuh Agent Installation

The Apache server must have a Wazuh agent installed to collect and forward log events.

Verify agent installation:

sudo systemctl status wazuh-agent

A healthy agent should show an active (running) status.

For Linux-based web servers, see:

How to Add Linux Endpoints to Wazuh

Apache HTTP Server Deployment

Apache must be installed and actively serving content before log monitoring can be configured.

Verify Apache status:

Ubuntu/Debian:

sudo systemctl status apache2

RHEL/CentOS:

sudo systemctl status httpd

Confirm that the service is running and capable of generating log entries.

Verify Apache Logging Is Enabled

Apache typically enables logging by default, but it is important to verify that access and error logs are configured correctly.

Checking Access Log Configuration

Open the Apache configuration file and locate the access logging directive:

CustomLog ${APACHE_LOG_DIR}/access.log combined

On RHEL-based systems, you may see:

CustomLog "logs/access_log" combined

This directive instructs Apache to record incoming HTTP requests.

Checking Error Log Configuration

Locate the error log directive:

ErrorLog ${APACHE_LOG_DIR}/error.log

Or:

ErrorLog "logs/error_log"

Apache writes startup issues, configuration problems, application failures, and other operational events to this log.

Locating Apache Log Files

Verify that the log files exist and contain recent events.

Ubuntu/Debian:

ls -lah /var/log/apache2/

RHEL/CentOS:

ls -lah /var/log/httpd/

You should see files similar to:

access.log
error.log

access_log
error_log

Confirm Agent Connectivity

Before configuring log monitoring, verify that the agent is communicating with the Wazuh manager.

Verifying Agent Status

Check agent status:

sudo systemctl status wazuh-agent

You can also verify agent registration from the Wazuh dashboard by navigating to:

Agents → Summary

The Apache server should appear as an active agent.

Testing Communication with the Manager

On the Wazuh manager, list connected agents:

sudo /var/ossec/bin/agent_control -l

Example output:

ID: 001, Name: webserver01, IP: any
Status: Active

If the agent appears disconnected, troubleshoot connectivity before continuing.

For common connectivity issues, see:

Wazuh Agent Not Connecting to Manager? 12 Proven Fixes

Configure Wazuh to Monitor Apache Logs

Once the prerequisites are complete, configure the Wazuh agent to collect Apache access and error logs.

Locate Apache Log Files

Before modifying the Wazuh configuration, identify the exact log file locations on your system.

Common Linux Log Locations

Ubuntu/Debian:

/var/log/apache2/access.log
/var/log/apache2/error.log

RHEL/CentOS:

/var/log/httpd/access_log
/var/log/httpd/error_log

Distribution-Specific Paths

Some Linux distributions use alternative locations based on package configuration or security policies.

Verify the configured log paths:

apachectl -V

httpd -V

Custom Log Directories

Many production environments store logs in custom locations.

Review Apache configuration files for:

CustomLog
ErrorLog

directives to determine the actual log paths.

Edit the Wazuh Agent Configuration

The Wazuh agent configuration file controls which logs are monitored.

Open:

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

Modifying the ossec.conf File

Locate the existing <localfile> sections or create new entries for Apache logs.

Adding Apache Access Logs

Add a monitoring entry for the access log:

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

Adding Apache Error Logs

Add a separate entry for the error log:

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

Example Apache Log Monitoring Configuration

The following example monitors both access and error logs.

Access Log Configuration Example

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

Error Log Configuration Example

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

Monitoring Multiple Log Files

For virtual hosts or custom applications, additional log sources can be added:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/apache2/example-site-access.log</location>
</localfile>

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

This approach provides visibility into activity across multiple hosted applications.

Restart the Wazuh Agent

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

sudo systemctl restart wazuh-agent

Applying Configuration Changes

Confirm the restart completed successfully:

sudo systemctl status wazuh-agent

Verifying Successful Startup

Review the Wazuh agent log for startup errors:

sudo tail -f /var/ossec/logs/ossec.log

Look for messages indicating successful monitoring of the configured Apache log files.

Generate Test Apache Log Events

After configuring log collection, generate sample events to verify that Apache logs are reaching Wazuh.

Create Normal Web Requests

Generate standard web traffic to create access log entries.

Accessing Web Pages

Use a browser or curl:

curl http://localhost/

curl http://localhost/index.html

Reviewing Generated Access Logs

Verify that Apache recorded the requests:

tail -f /var/log/apache2/access.log

You should see new log entries appear.

Generate Failed Requests

Failed requests help validate security monitoring and alert generation.

Triggering 404 Errors

Request a non-existent page:

curl http://localhost/nonexistent-page

Apache should generate a 404 entry.

Triggering Forbidden Requests

Request a restricted resource:

curl http://localhost/private/

If properly configured, Apache may generate a 403 Forbidden response.

Simulate Suspicious Activity

Security testing helps verify that Wazuh can detect potentially malicious behavior.

Multiple Failed Requests

Generate several invalid requests:

for i in {1..20}; do
curl http://localhost/fake$i;
done

This simulates reconnaissance activity.

Directory Enumeration Attempts

Request commonly targeted paths:

curl http://localhost/admin
curl http://localhost/phpmyadmin
curl http://localhost/.env

These requests frequently appear during vulnerability scans.

User-Agent Manipulation

Simulate suspicious scanners:

curl -A "sqlmap" http://localhost/

curl -A "Nikto" http://localhost/

These tools are commonly used during penetration testing and attacker reconnaissance.

Confirm Event Collection

After generating events, verify that Wazuh has successfully collected them.

Checking Agent Logs

Review agent activity:

sudo tail -f /var/ossec/logs/ossec.log

Look for log collection and forwarding messages.

Validating Events in Wazuh

Open the Wazuh Dashboard and search for Apache-related events.

You can filter by:

data.srcip

apache

error

access

If events appear in the dashboard, Apache log monitoring is functioning correctly and ready for rule creation, alerting, and threat detection.

Viewing Apache Logs in the Wazuh Dashboard

Once Apache logs are being collected by the Wazuh agent, the next step is to analyze them in the Wazuh Dashboard.

Wazuh provides powerful search, filtering, and visualization capabilities that help security teams identify suspicious activity, investigate incidents, and monitor web server health.

Search for Apache Events

The Wazuh Dashboard allows you to quickly locate Apache-related events using search filters and queries.

Navigate to:

Security Events → Events

Discover

to begin searching collected Apache logs.

Filtering by Log Source

One of the easiest ways to isolate Apache logs is by filtering based on the log file source.

Example filters:

location:/var/log/apache2/access.log

location:/var/log/apache2/error.log

These filters display only Apache access or error log events.

Searching by IP Address

Searching by source IP helps identify suspicious visitors and investigate attacks.

Example:

srcip:192.168.1.50

This query displays all requests originating from a specific IP address.

IP-based filtering is particularly useful when investigating:

Brute-force attacks
Vulnerability scans
Suspicious web traffic
Blocked connections

Searching by HTTP Status Code

HTTP status codes provide valuable insight into application behavior.

Example searches:

status:200

status:404

status:500

Monitoring status codes can help identify:

Successful requests
Missing resources
Application errors
Potential attack activity

Analyze Access Logs

Apache access logs contain detailed information about every HTTP request processed by the server.

Request Methods

Reviewing HTTP methods helps identify abnormal request patterns.

Common methods include:

GET
POST
PUT
DELETE
HEAD
OPTIONS

Unexpected PUT or DELETE requests may indicate unauthorized modification attempts.

Response Codes

Response codes reveal how the server handled requests.

Common examples include:

Status Code	Meaning
200	Successful request
301	Redirect
403	Forbidden
404	Resource not found
500	Internal server error

Large numbers of 403 or 404 responses often indicate reconnaissance activity.

User Agents

User-agent strings identify browsers, applications, bots, or automated tools.

Examples:

Mozilla/5.0

Googlebot

curl/8.0

sqlmap

Suspicious user agents can indicate:

Vulnerability scanners
Exploitation frameworks
Automated attacks
Penetration testing tools

Requested URLs

Monitoring requested URLs helps identify targeted resources.

Examples:

/wp-admin

/phpmyadmin

/.env

/admin

Attackers frequently probe these locations while searching for vulnerabilities.

Review Error Logs

Apache error logs contain operational and security-related information that may not appear in access logs.

PHP Errors

PHP applications often generate error log entries when exceptions occur.

Examples include:

Fatal errors
Undefined variables
Missing dependencies
Database connection failures

Repeated PHP errors may indicate application instability or attempted exploitation.

Application Failures

Application-specific failures commonly appear in Apache error logs.

Examples include:

Backend service failures
Database timeouts
API communication issues
Resource exhaustion

Monitoring these events improves troubleshooting and incident response.

Server Configuration Issues

Misconfigurations frequently generate Apache error log entries.

Examples include:

Invalid virtual host settings
Permission errors
SSL certificate issues
Missing modules

For certificate-related monitoring, see:

How to Fix Wazuh Certificate Errors

Build Custom Dashboards

Custom dashboards help security teams visualize trends and monitor Apache environments more efficiently.

Web Traffic Overview

A web traffic dashboard can display:

Requests per minute
Top source IPs
Most requested URLs
Geographic traffic distribution
HTTP method usage

These metrics provide visibility into overall server activity.

Error Monitoring Dashboard

An error-focused dashboard can track:

HTTP 404 rates
HTTP 500 rates
Application exceptions
Apache service issues
Error trends over time

This helps administrators identify operational problems before they impact users.

Security Monitoring Dashboard

Security-focused visualizations can include:

Top attackers by IP
Reconnaissance attempts
Login failures
Suspicious user agents
High-severity alerts

Combining these metrics creates a centralized web security monitoring view.

Detecting Web Attacks with Wazuh

Apache logs are one of the most valuable data sources for detecting web-based attacks.

Wazuh can identify suspicious behavior, generate alerts, and help security teams investigate potential compromises.

Brute Force and Credential Attacks

Authentication endpoints are common targets for attackers attempting unauthorized access.

Repeated Login Attempts

Attackers often submit large numbers of login requests against web applications.

Indicators include:

Multiple authentication requests
High request frequency
Requests from a single IP
Attempts against multiple accounts

Authentication Failures

Repeated authentication failures may indicate:

Password spraying
Credential stuffing
Brute-force attacks

Monitoring authentication failures helps identify attacks before an account is compromised.

Suspicious Login Behavior

Additional indicators include:

Logins from unusual locations
Rapid login attempts
Multiple usernames from one IP
Unusual user-agent strings

For SSH-based authentication monitoring, see:

How to Monitor Failed SSH Login Attempts Using Wazuh

Directory and File Enumeration

Attackers frequently enumerate directories and files while searching for vulnerable resources.

Detection of Scanning Activity

Common scanning indicators include requests for:

/admin

/wp-login.php

/phpmyadmin

/cgi-bin

Large numbers of requests targeting these paths often indicate automated scanning tools.

Excessive 404 Responses

A spike in 404 errors can indicate:

Vulnerability scanning
Directory enumeration
Automated reconnaissance

Security teams should investigate sudden increases in missing resource requests.

Reconnaissance Indicators

Additional indicators include:

Sequential URL requests
Requests for backup files
Requests for configuration files
High request diversity

These patterns frequently precede exploitation attempts.

SQL Injection Attempts

SQL injection remains one of the most common web application attack techniques.

According to the OWASP Top 10, injection attacks continue to be a significant application security risk.

Common SQL Injection Patterns

Examples include:

' OR 1=1--

UNION SELECT

DROP TABLE

information_schema

These patterns often appear in URL parameters and POST requests.

Monitoring Suspicious Query Strings

Review requests containing:

Single quotes
SQL keywords
Encoded payloads
Database function names

Wazuh rules can identify these indicators automatically.

Alert Generation

Custom rules can generate alerts when known SQL injection signatures are detected.

Alert severity should be adjusted based on:

Attack confidence
Asset importance
Historical activity

Cross-Site Scripting (XSS) Attempts

XSS attacks attempt to inject malicious JavaScript into web applications.

XSS Payload Indicators

Examples include:

<script>

javascript:

onerror=

alert(

These strings commonly appear in malicious requests.

Detecting Malicious Requests

Monitor URLs and request parameters for:

Script tags
Encoded payloads
Event handlers
JavaScript execution functions

Alerting Strategies

Organizations often assign medium-to-high severity alerts for confirmed XSS indicators.

Repeated attempts from the same source may justify escalation.

Web Shell and Exploitation Attempts

Web shells are commonly deployed after successful exploitation.

Suspicious URL Requests

Examples include requests targeting:

cmd.php

shell.php

upload.php

webshell.php

These requests should be investigated immediately.

Exploit Signatures

Attackers may also request:

/etc/passwd

/.git/

/vendor/

/wp-content/uploads/

These paths frequently appear in exploitation attempts.

High-Risk Indicators

Indicators requiring immediate attention include:

Successful exploit signatures
File upload attempts
Command execution requests
Web shell access patterns

For additional threat detection capabilities, see:

How to Detect Ransomware Activity Using Wazuh

Denial-of-Service Indicators

Apache logs can provide early warning signs of denial-of-service attacks.

High Request Volumes

Indicators include:

Sudden traffic spikes
Thousands of requests per minute
Repeated requests from a small set of IPs

Abnormal Traffic Spikes

Compare current traffic volumes with normal baselines.

Unexpected increases may indicate:

DoS attacks
Bot traffic
Vulnerability scanning campaigns

Detection Considerations

Not all traffic spikes are malicious.

Investigate:

Marketing campaigns
Search engine crawlers
Software updates
Legitimate user growth

Context is essential when evaluating high-volume traffic.

Creating Custom Wazuh Rules for Apache Logs

While Wazuh includes many built-in detection capabilities, custom rules allow organizations to monitor application-specific threats and unique attack patterns.

When Custom Rules Are Needed

Custom rules become valuable when default detections do not fully address organizational requirements.

Environment-Specific Requirements

Examples include:

Internal application monitoring
Custom authentication systems
Proprietary web services
Industry-specific compliance controls

Application-Specific Threats

Custom applications often generate unique log patterns that require specialized detection logic.

Organizations frequently create rules for:

Sensitive administrative pages
Internal APIs
Restricted resources
Business-critical workflows

Create a Custom Decoder

Decoders extract useful information from log entries before rules evaluate them.

Parsing Custom Log Formats

Some Apache deployments use customized log formats.

Example:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{User-Agent}i\"" custom

Custom decoders help Wazuh interpret these formats correctly.

Extracting Important Fields

Useful fields include:

Source IP
HTTP method
Requested URL
Status code
User agent
Response size

Accurate field extraction improves detection quality.

Create Custom Detection Rules

After creating decoders, define rules that identify suspicious activity.

Matching Suspicious Requests

Example use cases:

SQL injection attempts
XSS payloads
Directory enumeration
Sensitive file access

Rules can match specific strings, patterns, or extracted fields.

Assigning Alert Levels

Wazuh supports alert levels from low to critical severity.

Typical recommendations:

Activity	Suggested Level
Single 404	3
Directory enumeration	7
SQL injection attempt	10
Web shell activity	12

Severity should reflect organizational risk tolerance.

Adding Descriptions

Every custom rule should include meaningful descriptions.

Example:

Possible SQL injection attempt detected in Apache request

Clear descriptions simplify investigations and reporting.

Test Custom Rules

Custom rules should always be validated before production deployment.

Rule Validation

Use the Wazuh rule testing utility:

sudo /var/ossec/bin/wazuh-logtest

This tool allows you to test logs against decoders and rules.

Event Simulation

Paste sample Apache log entries into the testing utility.

Verify that:

The decoder matches correctly
Fields are extracted properly
The expected rule triggers

Alert Verification

After deploying rules:

Generate test events.
Verify alerts appear in the dashboard.
Confirm severity levels.
Review alert descriptions.

For a complete guide to custom rule development, see:

How to Create Custom Detection Rules in Wazuh (With Examples)

For rule validation techniques, see:

How to Test Wazuh Rules

Automating Responses to Apache Threats

Detecting malicious activity is only part of an effective security monitoring strategy.

Wazuh can also automate response actions to help contain threats before they escalate.

By combining Apache log monitoring with Active Response capabilities, organizations can reduce response times and limit attacker activity automatically.

Wazuh Active Response Overview

Active Response allows Wazuh to execute predefined actions when specific rules are triggered.

What Active Response Does

When Wazuh detects suspicious activity, it can automatically:

Block malicious IP addresses
Disable compromised accounts
Kill malicious processes
Execute custom scripts
Trigger notifications

These actions help security teams respond faster to active threats.

According to the SANS Institute, reducing the time between detection and containment is one of the most important factors in minimizing the impact of security incidents.

Use Cases for Web Server Protection

Common Apache monitoring use cases include:

Blocking web application scanners
Stopping brute-force attacks
Preventing repeated exploitation attempts
Limiting malicious bot activity
Responding to web shell access attempts

Organizations that host public-facing applications can significantly reduce risk by automating responses to known attack patterns.

Block Malicious IP Addresses

One of the most common Active Response actions is blocking malicious source IP addresses.

Temporary IP Blocking

When a predefined threshold is exceeded, Wazuh can automatically block the source IP.

Examples include:

Excessive 404 requests
Directory enumeration attempts
SQL injection activity
Repeated authentication failures

Temporary blocking helps stop automated attacks without requiring manual intervention.

Firewall Integration

Wazuh Active Response can integrate with:

iptables
nftables
firewalld
Windows Firewall

A typical workflow is:

Apache log generates an event.
Wazuh rule triggers an alert.
Active Response executes.
Firewall blocks the offending IP.

For environments already collecting firewall telemetry, see:

How to Collect Firewall Logs in Wazuh

Notify Security Teams

Not every event should trigger automated blocking. In many environments, notifications are the preferred response mechanism.

Email Notifications

Wazuh can generate email alerts for:

High-severity Apache events
Exploitation attempts
Web shell indicators
Large-scale scanning activity

Security teams can use email alerts as part of their incident response workflow.

SIEM Integration

Organizations often forward Wazuh alerts into external monitoring platforms for centralized visibility.

Examples include:

Security operations dashboards
Enterprise SIEM platforms
Ticketing systems
Threat intelligence workflows

For organizations evaluating SIEM solutions, see:

Wazuh vs Splunk

Incident Workflows

A typical incident workflow may include:

Wazuh generates an alert.
Notification is sent to analysts.
Incident ticket is created.
Investigation begins.
Remediation actions are performed.
Incident is documented and closed.

Automated workflows improve consistency and reduce response delays.

Response Best Practices

Automated responses can be extremely effective, but they should be implemented carefully.

Avoiding False Positives

Aggressive blocking policies can accidentally impact legitimate users.

Consider:

Setting reasonable thresholds
Allowing trusted IP addresses
Testing rules before deployment
Monitoring initial response behavior

For guidance on reducing alert noise, see:

How to Reduce False Positives in Wazuh

Monitoring Response Effectiveness

Regularly review:

Number of blocked IPs
Triggered Active Responses
False positive rates
Incident outcomes

Continuous tuning helps ensure automated responses remain effective without disrupting normal operations.

Troubleshooting Apache Log Monitoring

Even when Apache monitoring is configured correctly, issues can occasionally prevent logs from being collected, parsed, or displayed properly.

No Apache Logs Appearing in Wazuh

One of the most common issues is that Apache events never reach the Wazuh manager.

Incorrect File Paths

Verify that the monitored log paths match the actual Apache log locations.

Examples:

Ubuntu/Debian:

ls -lah /var/log/apache2/

RHEL/CentOS:

ls -lah /var/log/httpd/

A typo in the <location> field can prevent log collection entirely.

Permission Issues

The Wazuh agent must have permission to read Apache log files.

Check permissions:

ls -l /var/log/apache2/

ls -l /var/log/httpd/

Permission-related errors often appear in:

/var/ossec/logs/ossec.log

Agent Configuration Errors

Validate the agent configuration:

sudo /var/ossec/bin/wazuh-control info

Then review:

sudo tail -f /var/ossec/logs/ossec.log

Configuration syntax errors frequently prevent log monitoring from starting.

If the agent is disconnected, see:

Wazuh Agent Not Connecting to Manager? 12 Proven Fixes

Events Not Being Parsed Correctly

Sometimes events arrive in Wazuh but are not decoded correctly.

Decoder Mismatches

Built-in decoders may not recognize customized Apache log formats.

Symptoms include:

Missing fields
Unparsed messages
Generic log classifications

Custom decoders may be required for non-standard logging configurations.

Log Format Differences

Apache supports numerous log formats, including:

Common Log Format
Combined Log Format
Custom application logs
Virtual host logs

Changes to log formatting can impact decoder behavior.

Rule Validation

Use the Wazuh testing utility to verify parsing:

sudo /var/ossec/bin/wazuh-logtest

Paste sample Apache events and verify that:

The decoder matches correctly
Fields are extracted properly
Expected rules trigger

For additional testing guidance, see:

How to Test Wazuh Rules

Missing Alerts

Sometimes logs appear in the dashboard, but expected alerts are not generated.

Threshold Issues

Many rules rely on thresholds before generating alerts.

Examples:

Multiple failed requests
Excessive 404 responses
Brute-force attempts

A single event may not meet alert criteria.

Rule Conflicts

Custom rules can override or suppress built-in detections.

Review:

Rule IDs
Parent-child relationships
Rule inheritance
Rule ordering

Improper rule configuration can prevent alerts from firing.

Alert Suppression

Alert suppression settings may intentionally hide low-priority events.

Review:

Rule thresholds
Frequency settings
Ignore intervals
Alert level filters

These settings can significantly impact visibility.

Performance Concerns

High-volume Apache environments require additional planning.

High-Volume Log Environments

Busy web applications may generate:

Millions of requests per day
Gigabytes of log data
Large numbers of alerts

Without optimization, excessive logging can impact performance.

Log Rotation Considerations

Apache logs should be rotated regularly.

Benefits include:

Reduced disk usage
Improved performance
Easier log management
Better retention control

Verify that Wazuh continues monitoring rotated log files after rotation events.

Resource Optimization

Consider:

Filtering unnecessary events
Tuning custom rules
Increasing storage capacity
Adjusting retention policies

For long-term log management guidance, see:

How to Configure Wazuh Log Retention

Best Practices for Monitoring Apache Logs with Wazuh

Following established best practices improves detection quality, operational visibility, and incident response effectiveness.

Monitor Both Access and Error Logs

Many organizations focus exclusively on access logs and overlook valuable information contained in error logs.

Comprehensive Visibility

Access logs reveal:

Visitor activity
Request patterns
Response codes
Source IPs

Error logs reveal:

Application failures
Configuration problems
Backend service issues
Exploitation attempts

Monitoring both provides a more complete picture of web server activity.

Faster Troubleshooting

Correlating access and error events helps identify root causes more quickly during investigations.

Focus on High-Risk HTTP Status Codes

Certain HTTP response codes frequently indicate security or operational issues.

401 Unauthorized

Large numbers of 401 responses may indicate:

Credential attacks
Authentication probing
Unauthorized access attempts

403 Forbidden

Repeated 403 responses often suggest:

Restricted resource access attempts
Privilege escalation attempts
Directory traversal activity

404 Not Found

A high volume of 404 errors can indicate:

Vulnerability scanning
Directory enumeration
Automated reconnaissance

500 Server Errors

Server-side failures may reveal:

Application vulnerabilities
Resource exhaustion
Exploitation attempts
Configuration issues

The OWASP Foundation recommends monitoring abnormal error patterns because they frequently precede successful attacks.

Establish Baseline Traffic Patterns

Understanding normal activity makes it easier to identify abnormal behavior.

Normal User Behavior

Track:

Average request volume
Peak traffic periods
Typical user agents
Common URLs
Geographic distribution

Baselines help distinguish legitimate activity from attacks.

Anomaly Detection

Once a baseline exists, investigate deviations such as:

Traffic spikes
Unusual user agents
Increased error rates
New attack patterns

Anomaly detection often identifies threats that signature-based detection misses.

Tune Rules Regularly

Detection rules should evolve alongside the environment.

Reducing False Positives

Review recurring alerts and identify:

Benign automated processes
Internal scanners
Trusted applications
Legitimate business activity

Proper tuning improves alert quality.

Improving Detection Accuracy

Regular rule reviews help ensure:

New threats are detected
Outdated detections are removed
Alert priorities remain appropriate
Detection coverage remains effective

For optimization guidance, see:

How to Reduce False Positives in Wazuh

Retain Logs for Investigations

Historical log data is critical during incident response activities.

Compliance Requirements

Many regulations require log retention, including:

PCI DSS
HIPAA
ISO 27001
SOC 2

Retention periods vary depending on regulatory requirements.

Incident Response Needs

Historical Apache logs help investigators:

Reconstruct attacks
Determine attacker actions
Identify affected systems
Assess compromise timelines

Longer retention periods improve forensic capabilities.

Combine Apache Monitoring with Other Data Sources

Apache logs become far more valuable when correlated with additional telemetry sources.

Operating System Logs

Correlate Apache events with:

Linux system logs
Process creation events
File modifications
Service activity

For endpoint visibility, see:

How to Configure File Integrity Monitoring (FIM) in Wazuh

Authentication Logs

Authentication events provide additional context during investigations.

Examples include:

SSH logins
Failed login attempts
Privilege escalation activity
User account changes

See:

How to Monitor Failed SSH Login Attempts Using Wazuh

Network Security Events

Correlating Apache logs with network telemetry improves threat detection.

Examples include:

Firewall events
IDS alerts
Threat intelligence matches
Network anomalies

For enhanced network-based detection, see:

How to Integrate Wazuh with Suricata for Better Threat Detection

Organizations that correlate web server logs, endpoint telemetry, authentication data, and network events gain significantly better visibility into the full attack lifecycle and can detect threats more quickly than relying on Apache logs alone.

Frequently Asked Questions

Question: Can Wazuh monitor Apache access and error logs simultaneously?

Yes. Wazuh can monitor multiple Apache log files at the same time by adding separate <localfile> entries in the agent configuration.

This allows you to collect both access logs and error logs from a single Apache server.

Monitoring both log types provides more complete visibility because access logs show incoming requests while error logs reveal application failures, configuration issues, and server-side problems.

For the best results, configure Wazuh to monitor all relevant Apache log sources, including custom virtual host logs and application-specific log files.

Question: What Apache attacks can Wazuh detect?

Wazuh can help detect a wide range of web-based attacks and suspicious activities, including:

Brute-force login attempts
Credential stuffing attacks
Directory and file enumeration
Vulnerability scanning
SQL injection attempts
Cross-site scripting (XSS) attempts
Web shell activity
Exploitation attempts
Denial-of-service indicators
Suspicious user agents
Unauthorized access attempts

Detection capabilities can be further expanded through custom decoders, custom rules, threat intelligence integrations, and Active Response automation.

For advanced threat detection, consider integrating:

How to Integrate Wazuh with Suricata for Better Threat Detection

and

How to Integrate Wazuh with VirusTotal for Threat Intelligence

Question: Does Wazuh support custom Apache log formats?

Yes. Wazuh supports custom Apache log formats through the use of decoders and custom detection rules.

Many organizations modify Apache logging to include additional fields such as:

X-Forwarded-For headers
Session identifiers
Application-specific fields
Load balancer information
API request metadata

When built-in decoders cannot properly parse these logs, administrators can create custom decoders to extract the required fields and generate meaningful alerts.

For more information about building custom detections, see:

How to Create Custom Detection Rules in Wazuh (With Examples)

Question: Can Wazuh automatically block malicious IP addresses?

Yes. Wazuh supports Active Response, which can automatically execute actions when specific rules are triggered.

Common automated responses include:

Blocking malicious IP addresses
Updating firewall rules
Executing custom scripts
Sending notifications
Triggering incident response workflows

For example, if an IP address generates hundreds of 404 errors or triggers SQL injection detection rules, Wazuh can automatically block that source through firewall integration.

However, automated blocking should be carefully tested to minimize false positives and avoid disrupting legitimate users.

Question: How do I reduce false positives when monitoring Apache logs?

Reducing false positives requires ongoing tuning and validation.

Recommended strategies include:

Establishing normal traffic baselines
Adjusting alert thresholds
Whitelisting trusted sources
Excluding known scanners
Creating environment-specific rules
Regularly reviewing triggered alerts

Organizations should monitor alert quality and continuously refine their detection logic based on operational experience.

For a detailed tuning guide, see:

How to Reduce False Positives in Wazuh

Question: What is the difference between Apache log monitoring and web application firewall protection?

Apache log monitoring and web application firewall (WAF) protection serve different but complementary purposes.

Apache Log Monitoring	Web Application Firewall
Detects suspicious activity after events are logged	Blocks malicious requests before they reach the application
Provides visibility into attacks and application behavior	Prevents many attacks in real time
Supports investigations and threat hunting	Focuses on prevention
Helps identify trends and vulnerabilities	Enforces security policies
Enables alerting and automated response	Filters incoming traffic

Apache log monitoring helps organizations understand what happened, while a WAF helps prevent attacks from succeeding.

Security teams often deploy both technologies together to achieve stronger protection and better visibility.

The OWASP Logging Cheat Sheet emphasizes that logging and monitoring should complement preventative controls rather than replace them.

Conclusion

Monitoring Apache logs with Wazuh provides organizations with valuable visibility into web server activity, application behavior, and potential security threats.

By collecting and analyzing Apache access logs and error logs, security teams can detect suspicious requests, investigate incidents, identify operational issues, and improve overall web server security.

Key Security and Operational Advantages

Throughout this guide, we explored how Wazuh helps organizations:

Centralize Apache log collection
Detect web-based attacks and reconnaissance activity
Identify application errors and configuration issues
Create custom detection rules
Visualize web server activity through dashboards
Automate responses to malicious behavior
Improve incident response and threat hunting capabilities

These capabilities enable both security and operations teams to gain deeper visibility into their web infrastructure.

Next Steps for Improving Web Server Visibility with Wazuh

After implementing Apache log monitoring, consider expanding your monitoring strategy by:

Creating custom Apache detection rules
Implementing Active Response automation
Monitoring authentication events
Correlating firewall and IDS alerts
Integrating external threat intelligence feeds
Building security-focused dashboards

Organizations that correlate multiple data sources typically achieve faster detection and more effective investigations.

Additional Wazuh Monitoring Resources and Integrations

To continue enhancing your Wazuh deployment, consider these related guides:

How to Monitor Windows Event Logs Using Wazuh
How to Monitor Failed SSH Login Attempts Using Wazuh
How to Configure File Integrity Monitoring (FIM) in Wazuh
How to Collect Firewall Logs in Wazuh
How to Integrate Wazuh with Suricata for Better Threat Detection
How to Integrate Wazuh with VirusTotal for Threat Intelligence
How to Reduce False Positives in Wazuh
How to Test Wazuh Rules

By combining Apache log monitoring with endpoint monitoring, threat intelligence, file integrity monitoring, firewall visibility, and intrusion detection systems, organizations can build a more comprehensive security monitoring platform and maximize the value of their Wazuh deployment.