Wazuh MySQL Integration: Security & Log Detection

Databases store some of an organization’s most valuable information, making them one of the most attractive targets for attackers. Whether you’re running a small web application or a large enterprise environment, a compromised MySQL server can expose customer data, financial records, credentials, and business-critical applications.

Because of this, database security requires continuous visibility into authentication events, configuration changes, user activity, and potential indicators of compromise.

Wazuh provides an effective way to monitor MySQL by collecting database-related logs, correlating security events, detecting suspicious behavior, and generating actionable alerts from a centralized platform.

Rather than manually reviewing database logs after an incident occurs, security teams can continuously analyze MySQL activity alongside operating system events, network logs, and endpoint telemetry to identify attacks much earlier.

Integrating Wazuh with MySQL also allows organizations to improve threat detection while supporting compliance frameworks that require database auditing and log retention.

Since Wazuh combines log analysis, File Integrity Monitoring (FIM), Security Configuration Assessment (SCA), vulnerability detection, and active response capabilities, it provides much broader visibility than traditional database monitoring tools alone.

Why monitor MySQL with Wazuh?

Modern cyberattacks frequently target databases after an attacker gains initial access to a server.

Monitoring MySQL helps security teams detect abnormal login attempts, unauthorized privilege changes, suspicious SQL activity, database configuration modifications, and potential data exfiltration attempts before they become major security incidents.

Unlike standalone database auditing solutions, Wazuh correlates MySQL events with system logs, authentication logs, firewall activity, and endpoint telemetry, providing a much more complete picture of an attack.

Benefits of integrating Wazuh with MySQL

A properly configured Wazuh-MySQL integration offers several advantages:

Centralized monitoring for MySQL and operating system logs
Detection of brute-force attacks against database accounts
Visibility into administrative actions and privilege changes
File Integrity Monitoring for MySQL configuration files
Correlation of database events with endpoint and network activity
Faster incident detection through customizable alert rules
Improved compliance reporting for regulatory standards
Long-term searchable log storage and dashboards

These capabilities help reduce investigation time while giving analysts better context around suspicious database activity.

What readers will learn

By the end of this guide, you’ll understand:

How Wazuh integrates with MySQL
Which MySQL logs should be monitored
How Wazuh collects and analyzes database events
Which Wazuh components participate in database monitoring
Common security threats that can be detected
Best practices for securing MySQL with Wazuh
How to create effective detection rules for database events

Understanding Wazuh MySQL Integration

Wazuh integrates with MySQL primarily through log collection and file monitoring rather than by directly connecting to the database engine itself.

The Wazuh agent monitors MySQL log files and configuration files on the database server, forwards relevant events to the Wazuh Manager, and applies rules that detect suspicious or malicious behavior.

This approach keeps the monitoring lightweight while providing deep visibility into authentication events, configuration changes, database errors, administrative actions, and potential attacks.

What the integration does

The integration enables Wazuh to continuously monitor MySQL-related activity, including:

User authentication
Failed login attempts
Database errors
Administrative operations
Query activity (when enabled)
Configuration modifications
Service availability
Database file changes
Security policy violations

Collected events are normalized by Wazuh decoders, matched against detection rules, and presented in the Wazuh Dashboard where analysts can investigate alerts.

For organizations using SIEM workflows, this creates a centralized security monitoring solution that combines database activity with operating system logs, endpoint telemetry, cloud services, and network security events.

How Wazuh collects MySQL logs

Most deployments configure the Wazuh agent to monitor MySQL log files using Logcollector.

Typical monitored log files include:

Error log
General query log
Slow query log
Binary log metadata (where applicable)
Audit plugin logs
MySQL authentication events
System authentication logs related to MySQL

Whenever a new log entry appears, the Wazuh agent immediately forwards the event to the manager for decoding, rule matching, indexing, and visualization.

If MySQL configuration files are also monitored with File Integrity Monitoring (FIM), Wazuh detects unauthorized modifications and alerts administrators whenever critical settings change.

Supported MySQL log types

The exact logs available depend on the MySQL configuration, but Wazuh commonly monitors:

Error logs
General query logs
Slow query logs
Audit logs (Enterprise Audit or community audit plugins)
Authentication logs
Replication logs
Binary log status events
Configuration file changes
Operating system service logs

Enabling additional logging increases visibility but should be balanced against storage requirements and database performance.

Supported operating systems

Wazuh can monitor MySQL servers running on nearly every major operating system supported by both products, including:

Linux (Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux, CentOS, SUSE)
Windows Server
macOS (primarily development environments)
Cloud virtual machines
Containerized environments
Kubernetes deployments

Related Guide: How to Monitor Kubernetes Using Wazuh

Wazuh components involved

Several Wazuh components work together during MySQL monitoring.

Wazuh Agent

The Wazuh agent resides on the MySQL server and performs tasks such as:

Reading MySQL log files
Monitoring configuration changes
Collecting system information
Performing File Integrity Monitoring
Sending events securely to the manager

Since processing occurs close to the data source, organizations can monitor large environments efficiently.

Wazuh Manager

The manager receives events from agents and performs:

Event normalization
Rule evaluation
Alert generation
Correlation across multiple systems
Active response (if configured)

It acts as the central analysis engine for all collected MySQL events.

File Integrity Monitoring (FIM)

FIM watches important database-related files, including:

my.cnf
mysqld.cnf
SSL certificates
Database configuration directories
Plugin files

Unexpected modifications may indicate unauthorized administrative activity or malware attempting to weaken database security.

Log Analysis Engine

The log analysis engine processes incoming MySQL events by:

Parsing raw logs
Extracting important fields
Applying decoders
Matching detection rules
Assigning alert severity
Creating searchable security events

This automation eliminates the need to manually inspect large database log files.

Rules and Decoders

Rules and decoders transform raw MySQL log entries into meaningful alerts.

For example, they can detect:

Multiple failed logins
New administrator creation
Privilege modifications
Configuration changes
SQL errors
Suspicious database activity

Organizations can also create custom rules tailored to their environment.

Dashboard

The Wazuh Dashboard provides analysts with:

Searchable MySQL events
Alert timelines
Severity filtering
Visual dashboards
Correlated investigations
Compliance reporting
Historical log analysis

Security teams can quickly investigate suspicious database activity without manually searching log files.

Why Monitor MySQL with Wazuh?

MySQL is often one of the most targeted services in an organization’s infrastructure because it stores sensitive business information.

Continuous monitoring enables security teams to detect attacks early, investigate incidents faster, and maintain compliance with regulatory standards.

Detect Unauthorized Access

Unauthorized database access is one of the earliest indicators of compromise.

Wazuh can alert when:

Unknown users authenticate
Access occurs outside business hours
Remote connections originate from unexpected hosts
Dormant accounts become active
Service accounts authenticate abnormally

Correlating these events with operating system authentication logs provides valuable context during investigations.

Monitor Failed Login Attempts

Repeated authentication failures frequently indicate:

Password spraying
Credential stuffing
Brute-force attacks
Automated scanning
Misconfigured applications

Wazuh can identify repeated failures across multiple systems and generate alerts before attackers successfully gain database access.

The OWASP Authentication Cheat Sheet recommends monitoring authentication failures as part of a strong defense-in-depth strategy.

Audit Administrative Activity

Database administrators routinely perform legitimate maintenance, but attackers also seek elevated database privileges.

Monitoring administrative actions provides visibility into:

User creation
User deletion
Password changes
Database creation
Database deletion
Permission assignments
Administrative logins

Maintaining detailed audit records significantly improves forensic investigations after security incidents.

Detect Privilege Escalation

Privilege escalation inside MySQL can allow attackers to gain full administrative control over the database.

Important events include:

Granting global privileges
SUPER privilege assignments
New root-level accounts
Permission inheritance changes
Role modifications

These events should generate high-priority alerts for immediate investigation.

Identify Suspicious Queries

Although organizations may not log every SQL statement due to performance considerations, monitoring selected query logs can reveal:

Mass table exports
Unexpected DELETE operations
Bulk UPDATE commands
Schema modifications
Sensitive table access
Enumeration attempts

Database Activity Monitoring (DAM) guidance from security practitioners consistently emphasizes query monitoring for detecting insider threats and data exfiltration attempts.

Monitor Configuration Changes

Attackers often modify database configuration files to:

Disable logging
Weaken authentication
Enable insecure plugins
Reduce auditing
Change network exposure

Using Wazuh File Integrity Monitoring ensures administrators are alerted whenever critical MySQL configuration files change unexpectedly.

Meet Compliance Requirements

Many security regulations require organizations to monitor database access and retain audit logs.

PCI DSS

Organizations handling payment card data must monitor access to cardholder databases, generate audit logs, and review security events regularly.

Wazuh helps satisfy several logging and monitoring requirements by centralizing database audit events.

HIPAA

Healthcare organizations must maintain audit controls capable of recording system activity involving electronic protected health information (ePHI).

Continuous MySQL monitoring helps demonstrate accountability and detect unauthorized access to sensitive medical data.

GDPR

Organizations processing personal data should maintain appropriate security monitoring and detect unauthorized access to databases containing personal information.

Monitoring MySQL logs improves visibility into potential data breaches and supports incident investigations.

ISO 27001

ISO 27001 encourages organizations to implement logging, monitoring, event correlation, and security incident detection as part of an Information Security Management System (ISMS).

Centralized MySQL monitoring aligns well with these security controls.

SOC 2

SOC 2 emphasizes continuous monitoring, change management, audit logging, and security event detection.

Database activity monitoring provides evidence that organizations maintain visibility into systems handling sensitive customer data.

How Wazuh Monitors MySQL

Wazuh monitors MySQL by collecting database log files, decoding the log entries into structured events, matching them against detection rules, and generating alerts when suspicious or predefined conditions are met.

These alerts are then indexed and displayed in the Wazuh Dashboard, where analysts can investigate database activity alongside endpoint, network, and operating system events.

Unlike database monitoring tools that rely on direct database connections, Wazuh primarily uses its agent-based architecture to monitor log files and configuration changes.

This approach minimizes performance overhead while still providing comprehensive visibility into MySQL security events.

Log Collection

The monitoring process begins with the Wazuh Agent, which continuously watches designated MySQL log files for new entries.

Commonly monitored files include:

MySQL error log
General query log
Slow query log
Audit logs
MySQL service logs
Operating system authentication logs related to MySQL

The Wazuh Logcollector component reads newly appended log entries in near real time and securely forwards them to the Wazuh Manager for analysis.

Depending on your environment, log monitoring can be configured using the <localfile> section of the ossec.conf file.

Monitoring logs as they are written allows security teams to identify suspicious database activity almost immediately rather than waiting for scheduled scans or manual reviews.

Log Decoding

Raw MySQL log entries are often unstructured or semi-structured, making them difficult to analyze directly.

After receiving an event, the Wazuh Manager uses decoders to extract important information such as:

Username
Client IP address
Timestamp
Database name
SQL operation
Error code
Connection status
Authentication result

The decoded information is normalized into a consistent format so it can be processed by detection rules regardless of the operating system or log source.

Organizations with custom applications or plugins can also create their own decoders for proprietary log formats.

Rule Matching

Once a log entry has been decoded, Wazuh evaluates it against its rule engine.

Rules can identify events such as:

Failed authentication attempts
Multiple login failures
New administrative users
Privilege modifications
Suspicious SQL activity
Configuration changes
Replication failures
Service crashes

Rules can also correlate multiple events over time.

For example, several failed login attempts followed by a successful authentication from the same IP address may indicate a successful brute-force attack.

Custom rules allow organizations to tailor detections to their own database policies, application behavior, and security requirements.

Alert Generation

When a rule matches an event, Wazuh generates a security alert.

Each alert includes valuable investigation details such as:

Alert severity
Rule ID
Event timestamp
Source IP address
Database user
Hostname
Log message
Description of the detected activity

Security teams can adjust rule severity levels based on organizational risk tolerance, allowing high-priority database events to stand out during incident response.

Dashboard Visualization

Processed events are indexed and displayed in the Wazuh Dashboard, giving analysts a centralized view of MySQL activity.

Dashboard features include:

Searchable database events
Timeline visualizations
Alert severity filters
Event correlation
Historical investigations
Compliance reporting
Custom dashboards

Because MySQL events appear alongside endpoint, firewall, authentication, and cloud logs, analysts gain valuable context that would otherwise require switching between multiple security tools.

Active Response (Optional)

For organizations that want automated incident response, Wazuh can trigger Active Response actions when specific database threats are detected.

Examples include:

Blocking malicious source IP addresses
Disabling compromised accounts
Updating firewall rules
Executing custom response scripts
Isolating affected hosts (depending on the environment)

Automated responses should be carefully tested before deployment to avoid disrupting legitimate database users or applications.

Related Guide: How to Configure Wazuh Active Response

MySQL Logs That Wazuh Can Monitor

One of Wazuh’s strengths is its ability to analyze multiple types of MySQL logs simultaneously.

Each log provides unique visibility into database activity, allowing security teams to detect attacks, investigate incidents, troubleshoot operational issues, and meet compliance requirements.

The exact logs available depend on your MySQL configuration and whether optional auditing plugins are enabled.

Error Log

The MySQL error log records operational problems, startup messages, shutdown events, crashes, replication issues, and other critical system events.

Monitoring this log helps detect infrastructure problems before they affect database availability.

Startup and shutdown events

Unexpected database restarts may indicate:

System failures
Unauthorized maintenance
Service crashes
Server reboots
Malware attempting to disrupt operations

Tracking startup and shutdown events also helps correlate database availability with other security events occurring on the server.

Crashes

Database crashes can result from:

Software bugs
Disk failures
Corrupted tables
Memory exhaustion
Resource starvation
Malicious activity

Repeated crashes should always be investigated, particularly if they occur alongside authentication failures or suspicious system activity.

Permission issues

Permission-related errors often reveal:

Incorrect filesystem permissions
Failed database access
Misconfigured service accounts
Unauthorized file modifications

Unexpected permission failures may also indicate attempted privilege escalation.

Replication failures

Organizations using MySQL replication should monitor for:

Replication lag
Replica synchronization failures
Missing binary logs
Authentication failures between servers
Replication thread errors

These issues may impact database availability or data consistency across environments.

General Query Log

The General Query Log records nearly every client connection and SQL statement executed by the server.

While it provides excellent visibility, enabling it in production can significantly increase disk usage and I/O overhead, so it is often used selectively for troubleshooting or auditing.

User logins

Connection events allow administrators to monitor:

Successful logins
Failed logins
Remote client connections
Authentication patterns
New database users

Repeated authentication failures may indicate password spraying or brute-force attacks.

SQL queries

Monitoring SQL statements can reveal:

Schema modifications
Table deletions
Unexpected data exports
Bulk updates
Suspicious administrative commands

Because the General Query Log can become very large on busy servers, organizations should carefully evaluate storage and performance implications before enabling it continuously.

Session activity

Session information provides visibility into:

Connection duration
Concurrent sessions
Idle connections
Unexpected client activity
Application behavior

This information is useful during incident investigations and performance troubleshooting.

Slow Query Log

The Slow Query Log captures SQL statements that exceed a defined execution time threshold, making it valuable for identifying performance problems and potential abuse.

Long-running queries

Slow queries may result from:

Missing indexes
Inefficient SQL statements
Full table scans
Lock contention
Poor application design

Monitoring these events helps database administrators optimize performance while identifying unusual query behavior.

Performance bottlenecks

The Slow Query Log can highlight:

Resource-intensive workloads
CPU-intensive queries
Disk I/O bottlenecks
Memory pressure
Query optimization opportunities

Combining these insights with system metrics provides a more complete view of database performance.

Potential denial-of-service indicators

A sudden increase in slow queries may indicate:

Resource exhaustion attacks
Malicious query execution
Automated scanning tools
Misbehaving applications
Distributed denial-of-service (DDoS) activity affecting the database

Although slow queries are not always malicious, they can serve as valuable indicators when correlated with other security events.

Binary Logs

Binary logs record changes made to database data and are primarily used for replication and point-in-time recovery.

From a security perspective, they provide visibility into how data changes over time.

Data modifications

Binary logs capture operations such as:

INSERT
UPDATE
DELETE
Table modifications
Schema changes

Reviewing these events can help investigators determine when sensitive data was altered.

Replication events

Binary logs also contain replication-related activity, allowing administrators to detect:

Replication delays
Synchronization issues
Unexpected replication failures
Replica inconsistencies

Monitoring replication events improves both operational reliability and incident response.

Audit Logs (MySQL Enterprise or MariaDB Audit Plugin)

Audit logs provide the most comprehensive record of database activity and are particularly valuable for security monitoring and regulatory compliance.

Oracle’s MySQL Enterprise Audit plugin and the MariaDB Audit Plugin can generate detailed records of user activity and administrative operations.

Authentication

Audit logs record:

Login attempts
Authentication failures
Successful logins
Account lockouts
Connection sources

These events help identify unauthorized access attempts and compromised accounts.

Privilege changes

Monitoring privilege modifications allows organizations to detect:

New administrator accounts
GRANT statements
REVOKE operations
Role assignments
Permission changes

Privilege changes should generally be treated as high-priority security events.

Administrative commands

Administrative operations commonly include:

User creation
Password resets
Configuration changes
Backup operations
Server maintenance commands

Unexpected administrative activity may warrant immediate investigation.

Object access

Audit plugins can record access to database objects such as:

Tables
Views
Stored procedures
Functions
Schemas

Tracking object access is particularly useful for identifying unauthorized access to sensitive business data and supporting forensic investigations.

Prerequisites

Before integrating Wazuh with MySQL, verify that your environment meets the necessary software, permissions, and connectivity requirements.

Completing these prerequisites beforehand helps ensure a smooth deployment and reduces troubleshooting later.

Supported Wazuh version

Use a supported and up-to-date version of Wazuh to take advantage of the latest security improvements, bug fixes, and rule updates.

Keeping the Wazuh Manager and agents on compatible versions also helps prevent communication and parsing issues.

Related Guide: How to Upgrade a Wazuh Agent

MySQL Server

You should have a functioning MySQL Server installation with the appropriate logs enabled.

Depending on your monitoring objectives, you may need to enable:

Error logging
General Query Log
Slow Query Log
Binary logging
Audit logging (if available)

Avoid enabling verbose logging unnecessarily on production systems, as it may increase storage consumption and affect performance.

Wazuh Agent installed

The Wazuh Agent must be installed on the server hosting MySQL.

The agent is responsible for:

Monitoring MySQL log files
Collecting operating system events
Monitoring configuration files
Forwarding events to the Wazuh Manager

Related Guide: The Ultimate Wazuh Agent Deployment Guide

Root or sudo access

Administrative privileges are typically required to:

Install the Wazuh Agent
Configure MySQL logging
Modify Wazuh configuration files
Restart services
Verify log collection

On Linux systems, root or sudo access is generally sufficient.

Log file permissions

The Wazuh Agent must have permission to read the configured MySQL log files.

Verify that:

Log files exist
File paths are correct
Appropriate read permissions are assigned
Log rotation preserves access permissions

Improper permissions are a common cause of missing log events.

Network connectivity

The MySQL server must be able to communicate with the Wazuh Manager over the required ports.

Before beginning the integration, confirm:

Firewall rules permit agent-to-manager communication
DNS resolution is working correctly (if using hostnames)
No network devices are blocking traffic
The agent can successfully register with the manager

Time synchronization

Accurate timestamps are essential for event correlation and incident investigations.

Synchronize both the MySQL server and the Wazuh Manager using a reliable time source, such as NTP or Chrony.

Consistent system clocks ensure that authentication events, SQL activity, and alerts appear in the correct chronological order, making investigations significantly easier.

Step 1: Enable MySQL Logging

Before Wazuh can monitor MySQL activity, the database must generate the appropriate log files.

The more relevant logs you enable, the greater the visibility Wazuh has into authentication attempts, administrative actions, performance issues, and potential security incidents.

Keep in mind that some logs, particularly the General Query Log, can grow rapidly and may impact disk usage and performance on busy production systems.

Enable only the logs that align with your monitoring and compliance requirements.

Enable the Error Log

The MySQL Error Log is the most important log to monitor because it records server startup and shutdown events, crashes, replication issues, plugin errors, and other critical operational problems.

On most Linux systems, the error log is configured in the MySQL configuration file (my.cnf or mysqld.cnf).

Example:

[mysqld]
log_error = /var/log/mysql/error.log

After modifying the configuration, restart the MySQL service for the changes to take effect.

The Error Log is particularly useful for detecting:

Unexpected service restarts
Replication failures
Storage engine errors
Permission problems
Plugin failures
Database corruption

Enable the General Query Log

The General Query Log records client connections and nearly every SQL statement executed by the server.

Enable it by adding or updating the following settings:

[mysqld]
general_log = ON
general_log_file = /var/log/mysql/general.log

Because every SQL statement is recorded, this log can become very large.

Many administrators enable it only temporarily during troubleshooting or security investigations.

Typical use cases include:

Investigating unauthorized database access
Auditing user activity
Monitoring application behavior
Detecting suspicious SQL statements

For guidance on configuring query logging, refer to the MySQL Reference Manual.

Enable the Slow Query Log

The Slow Query Log captures SQL statements that exceed a configurable execution time threshold.

Example configuration:

[mysqld]
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

This configuration records queries that take longer than two seconds to execute.

Monitoring slow queries helps identify:

Inefficient SQL statements
Missing indexes
Resource-intensive workloads
Potential denial-of-service attempts
Application performance issues

These events can also provide useful indicators during incident investigations when combined with authentication and system logs.

Enable Audit Logging (Optional)

Organizations with strict compliance requirements may choose to enable database auditing using:

MySQL Enterprise Audit
MariaDB Audit Plugin
Percona Audit Log Plugin (depending on the distribution)

Audit logs provide much richer security information than standard database logs, including:

Authentication events
Privilege changes
Administrative commands
Object access
User management
Database modifications

Although audit logging increases visibility, it also generates significantly more log data.

Consider log retention policies and storage capacity before enabling it in production.

Step 2: Verify MySQL Log Locations

After enabling logging, confirm that MySQL is writing log files to the expected locations.

Wazuh can only monitor logs that actually exist and are accessible by the Wazuh Agent.

The exact paths vary depending on the operating system, Linux distribution, and MySQL installation method.

Linux

Common MySQL log locations include:

Log Type	Common Location
Error Log	`/var/log/mysql/error.log`
General Query Log	`/var/log/mysql/general.log`
Slow Query Log	`/var/log/mysql/slow.log`
MySQL Configuration	`/etc/mysql/my.cnf`
MySQL Configuration (RHEL)	`/etc/my.cnf`

To verify that logs are being written:

ls -lah /var/log/mysql

You can also monitor log activity in real time:

tail -f /var/log/mysql/error.log

If the files are empty after generating database activity, verify that logging is enabled and that MySQL has permission to write to the specified directory.

Windows

On Windows Server, log locations often depend on the MySQL installation directory.

Typical locations include:

C:\ProgramData\MySQL\MySQL Server 8.0\Data\

C:\Program Files\MySQL\MySQL Server 8.0\Data\

Verify that:

The log files exist.
New entries are being written.
The Wazuh Agent service account has permission to read them.

You can also confirm the configured log locations from MySQL itself:

SHOW VARIABLES LIKE '%log%';

This command displays the paths configured for various MySQL log files.

Step 3: Configure the Wazuh Agent

Once MySQL logs are being generated, configure the Wazuh Agent to monitor them.

This is done by editing the agent’s ossec.conf configuration file and defining each log source that should be collected.

Edit ossec.conf

Locate the Wazuh Agent configuration file.

Typical locations include:

Linux

/var/ossec/etc/ossec.conf

Windows

C:\Program Files (x86)\ossec-agent\ossec.conf

Open the file using your preferred text editor.

Add MySQL Log Sources

Add a <localfile> entry for each MySQL log you want to monitor.

Example:

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

If your MySQL logs use a different format, choose the appropriate log_format value for your environment.

Each monitored file should have its own <localfile> block.

Configure Multiple Log Files

Most deployments monitor several MySQL logs simultaneously.

Example:

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

<localfile>
  <location>/var/log/mysql/general.log</location>
  <log_format>syslog</log_format>
</localfile>

<localfile>
  <location>/var/log/mysql/slow.log</location>
  <log_format>syslog</log_format>
</localfile>

Depending on your deployment, you may also monitor:

Audit logs
MySQL service logs
Authentication logs
Replication logs

Collecting multiple log sources provides richer event correlation and more comprehensive threat detection.

Validate XML Configuration

Before restarting the Wazuh Agent, verify that the XML configuration is valid.

Common configuration errors include:

Missing closing tags
Invalid nesting
Typographical mistakes
Incorrect file paths
Unsupported XML elements

Even a single XML syntax error can prevent the agent from starting correctly.

Step 4: Restart the Wazuh Agent

After updating ossec.conf, restart the Wazuh Agent so it begins monitoring the newly configured MySQL log files.

On most Linux distributions:

sudo systemctl restart wazuh-agent

Verify that the service started successfully:

sudo systemctl status wazuh-agent

On Windows, restart the Wazuh Agent service from the Services management console or use PowerShell:

Restart-Service Wazuh

If the agent fails to start, review the agent logs for configuration errors before continuing.

Step 5: Verify Log Collection

Once the Wazuh Agent has restarted, confirm that MySQL events are reaching the Wazuh Manager and appearing in the Dashboard.

Verifying each stage of the data pipeline helps identify configuration issues early.

Check Agent Logs

The first step is to ensure the agent is successfully reading the MySQL log files.

On Linux, review the agent log:

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

Look for messages indicating that the configured log files have been opened and are being monitored.

If errors appear, verify:

File paths
File permissions
XML syntax
Log file existence

Check Manager Logs

Next, verify that the Wazuh Manager is receiving events from the agent.

Review the manager log:

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

You should see events arriving from the monitored MySQL server.

If no events appear, investigate:

Agent connectivity
Firewall rules
Agent registration
Manager availability

Confirm Events in the Dashboard

Finally, open the Wazuh Dashboard and search for events generated from the MySQL server.

Verify that you can see:

Authentication events
Error log entries
Slow query events
Administrative activity
Custom rule matches (if configured)

If events appear in the Dashboard, the integration is functioning correctly.

You can then begin refining detection rules and building custom dashboards for your database environment.

Step 6: Create Custom Detection Rules

While Wazuh includes many built-in detection rules, custom rules allow you to identify database activity that is unique to your organization.

For example, you may want to alert only when a privileged account performs certain actions or when a sensitive database is modified.

Detect Multiple Failed Logins

Repeated authentication failures often indicate:

Brute-force attacks
Password spraying
Credential stuffing
Misconfigured applications

A custom rule can count multiple failed login events from the same IP address or user account within a defined time window and generate a higher-severity alert when a threshold is exceeded.

Detect New Administrative Users

Database administrators are rarely created during normal application operations.

Consider generating alerts whenever events such as the following occur:

CREATE USER
ALTER USER
Administrative role assignments
New root-equivalent accounts

These events should typically receive medium- or high-severity classifications depending on your environment.

Detect Privilege Grants

Privilege changes are especially important because attackers often elevate permissions after gaining initial access.

Monitor statements such as:

GRANT
REVOKE
Role assignments
Global privilege changes

Unexpected privilege modifications should be investigated immediately, particularly outside of approved maintenance windows.

Detect Database Drops

Dropping databases or critical tables is a high-risk administrative action.

Useful detections include:

DROP DATABASE
DROP TABLE
Bulk schema deletions
Unexpected object removal

Generating immediate alerts for these operations can significantly reduce response time during destructive attacks or accidental administrative errors.

Detect Suspicious SQL Statements

Not every SQL statement warrants an alert, but some commands deserve closer scrutiny.

Examples include:

Large data exports
Mass DELETE operations
Unexpected UPDATE statements affecting many rows
SQL injection indicators
Access to sensitive tables
Schema modifications performed by non-administrative users

Correlating these events with authentication logs and endpoint activity can help distinguish legitimate maintenance from malicious behavior.

OWASP recommends monitoring unusual database activity as part of a layered defense strategy against injection attacks and unauthorized data access.

Detect Unexpected Configuration Changes

Configuration changes can weaken database security or indicate post-compromise activity.

Consider monitoring:

my.cnf
mysqld.cnf
SSL certificate files
Authentication plugins
Audit plugin configuration
Replication settings

Wazuh’s File Integrity Monitoring (FIM) can generate alerts whenever these files are created, modified, deleted, or have their permissions changed unexpectedly.

Monitoring Multiple MySQL Servers

As organizations grow, it’s common to manage dozens, or even hundreds, of MySQL servers across development, staging, production, cloud, and on-premises environments.

Wazuh is designed to scale with these deployments by collecting and correlating database events from multiple servers into a single management platform.

Centralized monitoring allows security analysts to identify patterns that may not be visible when reviewing individual database servers in isolation, such as coordinated attacks, widespread configuration changes, or repeated authentication attempts across multiple systems.

Agent per database server

The recommended deployment model is to install a dedicated Wazuh Agent on every server running MySQL.

Each agent independently monitors:

MySQL log files
Database configuration files
Operating system logs
Security events
File integrity changes

This approach provides local log collection while minimizing network traffic and reducing the risk of losing events during temporary connectivity issues.

For environments running multiple MySQL instances on the same host, a single Wazuh Agent can monitor multiple log files by defining additional <localfile> entries.

Centralized monitoring

One of Wazuh’s biggest advantages is its ability to consolidate security events from numerous database servers into a single platform.

Benefits include:

Unified security monitoring
Cross-server event correlation
Centralized alert management
Simplified incident investigations
Organization-wide compliance reporting
Historical event analysis

Rather than logging into each database server individually, security teams can investigate all MySQL activity from the Wazuh Dashboard.

This centralized visibility becomes especially valuable during incident response, where analysts often need to determine whether suspicious activity is isolated or affecting multiple systems.

Agent groups

Wazuh Agent Groups simplify the management of large deployments by allowing administrators to apply shared configurations to multiple agents.

For example, separate groups can be created for:

Production database servers
Development environments
Test systems
High-availability clusters
Reporting databases

Using groups helps ensure consistent monitoring policies across servers while reducing administrative overhead.

Labels and tagging

Labels provide additional context that makes searching and filtering MySQL events much easier.

Useful labels include:

Environment
Business unit
Database role
Geographic region
Cloud provider
Application owner
Compliance scope

Example labels:

Production
Development
Finance
Customer Portal
PCI
AWS
Azure

Analysts can use these labels to quickly isolate alerts from specific systems or environments during investigations.

Multi-environment deployments

Many organizations operate MySQL servers across several environments simultaneously.

Typical deployments include:

Development
Testing
Staging
Production
Disaster recovery
Hybrid cloud
Multi-cloud

Each environment typically has different security requirements and alert thresholds.

For example:

Development systems may generate lower-severity alerts for administrative changes.
Production systems may treat the same events as high priority.
Internet-facing databases may require stricter monitoring than internal reporting servers.

Using separate agent groups, custom rules, and environment-specific labels makes it easier to tailor monitoring policies without maintaining completely separate Wazuh deployments.

Integrating MySQL with Other Wazuh Modules

Although log monitoring provides valuable insight into database activity, combining MySQL monitoring with other Wazuh modules creates a much more comprehensive security solution.

Correlating database events with file integrity changes, vulnerability information, endpoint telemetry, and automated responses enables security teams to detect sophisticated attacks more effectively.

File Integrity Monitoring

MySQL security depends not only on monitoring database activity but also on protecting the files that control database behavior.

Wazuh’s File Integrity Monitoring (FIM) continuously watches important database-related files for unauthorized modifications.

This includes monitoring for:

File creation
File deletion
Content changes
Permission modifications
Ownership changes

Because many attackers attempt to alter configuration files after compromising a server, FIM provides an important additional layer of defense.

my.cnf monitoring

The MySQL configuration file (my.cnf or mysqld.cnf) contains critical security settings such as:

Authentication configuration
SSL settings
Logging options
Network binding
Plugin configuration
Replication settings

Unauthorized changes to these files can weaken database security or disable important monitoring features.

Adding these files to FIM allows Wazuh to generate alerts whenever they are modified unexpectedly.

Configuration change detection

Beyond monitoring the primary configuration file, organizations should also monitor:

SSL certificates
Audit plugin configuration
Startup scripts
Systemd service files
Database initialization scripts
Replication configuration

Detecting unauthorized configuration changes can help identify attackers attempting to establish persistence or disable security controls.

Vulnerability Detection

Running outdated database software significantly increases security risk.

Wazuh Vulnerability Detection compares installed software against vulnerability databases to identify known security issues affecting MySQL.

This enables administrators to prioritize patching before vulnerabilities are exploited.

Examples include:

Remote code execution vulnerabilities
Privilege escalation flaws
Authentication bypass issues
Denial-of-service vulnerabilities

Security researchers at the MITRE ATT&CK framework note that attackers frequently exploit unpatched software to gain initial access or escalate privileges, making timely vulnerability management an essential defensive practice.

Monitor vulnerable MySQL versions

Security teams should routinely verify:

Installed MySQL version
Patch level
End-of-life status
Vendor security advisories
Available updates

Oracle regularly publishes Critical Patch Updates (CPUs) addressing vulnerabilities in MySQL and other products.

Keeping database servers updated significantly reduces the attack surface.

Rootcheck

If an attacker compromises the operating system hosting MySQL, they may install rootkits or other persistence mechanisms that allow continued access to the server.

Wazuh Rootcheck helps detect indicators such as:

Hidden processes
Suspicious kernel modules
Unauthorized system modifications
Rootkit artifacts
Policy violations

Monitoring the underlying operating system provides another layer of protection beyond database activity alone.

Detect rootkits affecting database servers

Database servers are high-value targets because they often contain sensitive organizational data.

Compromising the operating system can allow attackers to:

Hide malicious processes
Manipulate database logs
Steal credentials
Disable security software
Access encrypted data

Correlating Rootcheck findings with MySQL authentication events can significantly improve incident investigations.

Active Response

For organizations requiring automated incident response, Wazuh’s Active Response module can take predefined defensive actions when high-risk database events occur.

Potential automated responses include:

Blocking malicious IP addresses
Updating firewall rules
Disabling compromised user accounts
Executing custom response scripts
Isolating affected systems (where supported)

Automated responses should always be tested thoroughly in a non-production environment before deployment.

Related Guide: How to Configure Wazuh Active Response

Automated defensive actions

Examples of automated workflows include:

Blocking repeated database brute-force attempts
Preventing connections from known malicious IP addresses
Alerting administrators after privilege escalation events
Executing scripts following unauthorized configuration changes
Triggering external SOAR or ticketing workflows

While automation can greatly reduce response times, organizations should carefully balance automation with operational continuity to avoid disrupting legitimate database users.

Best Practices

A well-designed Wazuh-MySQL deployment goes beyond simply collecting logs.

Following proven operational and security best practices improves detection accuracy, reduces administrative overhead, and helps ensure long-term reliability.

Enable Only Required Logs

While MySQL can generate extensive logging, collecting every available log is rarely necessary.

Focus on logs that provide the greatest security value, such as:

Error logs
Authentication events
Audit logs
Slow query logs (where appropriate)

Excessive logging increases storage requirements, consumes additional disk I/O, and may complicate investigations by generating unnecessary noise.

Protect Database Log Files

Database logs often contain sensitive information, including:

Usernames
IP addresses
Database names
SQL statements
Error details

Restrict access using the principle of least privilege and ensure only authorized administrators and monitoring services can read the files.

Protecting log integrity is equally important to prevent attackers from tampering with forensic evidence.

Rotate Logs Regularly

Database logs can grow rapidly, particularly on high-traffic servers.

Implement log rotation policies to:

Prevent disks from filling
Improve system performance
Simplify archival
Support retention requirements

After configuring rotation, verify that the Wazuh Agent continues monitoring newly created log files without interruption.

Related Guide: How to Configure Wazuh Log Retention

Tune Detection Rules

Every environment has different applications, users, and operational patterns.

Review and customize Wazuh rules to:

Prioritize critical alerts
Suppress expected activity
Detect organization-specific threats
Improve investigation quality

Fine-tuned detection rules help security teams focus on genuinely important events.

Reduce False Positives

Too many unnecessary alerts can overwhelm analysts and lead to alert fatigue.

Common ways to reduce false positives include:

Whitelisting trusted administrative accounts
Excluding scheduled maintenance windows
Adjusting alert thresholds
Creating environment-specific rules
Correlating multiple related events before generating alerts

Well-tuned detection policies improve both efficiency and confidence in security alerts.

Related Guide: How to Reduce False Positives in Wazuh

Monitor Privileged Accounts

Administrative accounts deserve heightened monitoring because they have the ability to modify databases, user permissions, and security settings.

Generate alerts for activities such as:

New administrator creation
Privilege changes
Password resets
Administrative logins outside normal hours
Unexpected schema modifications

Privileged account monitoring is a key recommendation in many security frameworks because these accounts are frequent targets for attackers.

Use Secure Authentication

Protect database access by implementing strong authentication controls, including:

Strong, unique passwords
Multi-factor authentication (where supported)
Encrypted client connections using TLS
Least-privilege access controls
Regular credential rotation

The OWASP Authentication Cheat Sheet provides practical guidance on secure authentication practices that complement database monitoring.

Keep MySQL Updated

Regularly applying MySQL security updates helps protect against known vulnerabilities and reduces the likelihood of successful attacks.

Establish a patch management process that includes:

Monitoring vendor security advisories
Testing updates in staging environments
Scheduling routine maintenance windows
Verifying successful upgrades

Keeping MySQL current is one of the most effective ways to reduce risk.

Keep Wazuh Updated

Maintaining an up-to-date Wazuh deployment ensures access to:

New detection rules
Decoder improvements
Security patches
Performance enhancements
Bug fixes
Compatibility updates

Updating both the Wazuh Manager and agents helps maintain reliable communication and consistent event processing across the environment.

Test Alert Rules Regularly

Detection rules should be validated periodically to ensure they continue to identify meaningful security events as applications, infrastructure, and attack techniques evolve.

A regular testing process should include:

Simulating failed login attempts
Creating test administrative users
Performing controlled privilege changes
Modifying monitored configuration files
Executing approved test SQL statements

Routine validation helps confirm that alerts are generated as expected and that changes to the environment have not unintentionally affected monitoring.

Related Guide: How to Test Wazuh Rules

Common Wazuh MySQL Integration Problems

Although integrating Wazuh with MySQL is straightforward, organizations may encounter issues during configuration, log collection, rule creation, or event analysis.

Most problems are related to incorrect log paths, permissions, agent connectivity, or insufficient logging configuration.

Understanding these common issues makes troubleshooting faster and helps ensure reliable database monitoring.

Logs Not Being Collected

One of the most common problems is that MySQL logs exist but Wazuh is not receiving any events.

Common causes include:

Incorrect <localfile> configuration
MySQL logging is disabled
Wrong log file location
Log files are empty
Wazuh Agent cannot access the files
Agent configuration was not reloaded after changes

To troubleshoot:

Verify that MySQL is actively writing logs.

Example:

tail -f /var/log/mysql/error.log

Confirm the configured path in ossec.conf.
Restart the Wazuh Agent after configuration changes.
Check the agent log:

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

Successful monitoring should show that the agent has opened and is reading the configured log files.

Permission Denied Errors

The Wazuh Agent requires permission to read MySQL log files.

If the agent cannot access the files, events will not be collected.

Common causes include:

Incorrect file ownership
Restrictive filesystem permissions
MySQL logs owned by a different user
SELinux restrictions
Windows service permission issues

On Linux, verify permissions:

ls -lah /var/log/mysql/

A common solution is granting the Wazuh Agent account read access to the log directory.

After changing permissions, restart the agent and confirm that collection resumes.

Incorrect Log File Path

Incorrect paths are another frequent cause of missing events.

MySQL log locations vary depending on:

Operating system
Distribution
Installation method
MySQL version
Custom administrator configuration

To identify active log locations, run:

SHOW VARIABLES LIKE '%log%';

Verify that the paths configured in ossec.conf exactly match the files generated by MySQL.

Common mistakes include:

Using /var/log/mysql/mysql.log when MySQL writes to /var/log/mysql/error.log
Monitoring rotated files instead of active logs
Misspelling directory names
Using Windows paths incorrectly

Missing Alerts

Sometimes Wazuh successfully collects MySQL logs but does not generate alerts.

Possible causes include:

No matching detection rules
Incorrect decoders
Unsupported log format
Events not containing expected patterns
Rule severity thresholds too high

To troubleshoot, test the event manually:

/var/ossec/bin/wazuh-logtest

Paste a sample MySQL log entry and verify whether Wazuh identifies a decoder and matching rule.

If no rule exists, create a custom rule based on your environment.

XML Configuration Errors

The Wazuh Agent configuration relies on XML syntax.

Even a small formatting mistake can prevent the agent from starting.

Common XML errors include:

Missing closing tags
Incorrect nesting
Invalid characters
Duplicate configuration blocks
Unsupported options

Example mistake:

<localfile>
  <location>/var/log/mysql/error.log</location>

The missing closing tag causes configuration validation failure.

Always validate configuration changes before restarting the agent.

Agent Not Connected

If the MySQL server’s Wazuh Agent cannot communicate with the manager, database events will never reach the analysis engine.

Common causes include:

Firewall restrictions
Incorrect manager address
Authentication failures
Network connectivity issues
Expired agent keys
Service failures

Troubleshooting steps:

Verify agent status:

systemctl status wazuh-agent

Test network connectivity.
Review agent logs.
Confirm the agent appears in the Wazuh Dashboard.

Duplicate Events

Duplicate MySQL events may appear when:

The same log file is monitored multiple times
Multiple agents collect identical logs
Log forwarding systems duplicate messages
Log rotation is configured incorrectly

To resolve duplicates:

Review all <localfile> entries
Remove duplicate monitoring configurations
Verify log forwarding pipelines
Check whether multiple monitoring tools collect the same source

Duplicate alerts can increase storage requirements and make investigations more difficult.

High Disk Usage

Database logs can consume significant storage, especially when verbose logging is enabled.

Common causes include:

General Query Log enabled permanently
Excessive audit logging
Missing log rotation
Long retention periods
Large SQL workloads

Solutions include:

Implementing log rotation
Adjusting retention periods
Collecting only required logs
Increasing storage capacity
Archiving older events

High CPU Usage from Query Logging

The General Query Log records every client connection and SQL statement, which can significantly increase database workload.

Symptoms include:

Increased CPU usage
Higher disk I/O
Slower query performance
Larger log files

Recommended practices:

Enable query logging only when required
Use Slow Query Logging for performance monitoring
Monitor production impact
Test logging changes before deployment

For high-volume databases, audit logging or selective query monitoring may provide better security visibility with less overhead.

Real-World Example

Scenario

A financial services company operates dozens of MySQL servers that store customer transaction data.

Because these databases contain sensitive financial information, the security team requires centralized visibility into database activity, including authentication attempts, privilege changes, suspicious SQL statements, and configuration modifications.

The organization deploys Wazuh Agents across all database servers and configures centralized monitoring for:

MySQL error logs
General Query Logs
Slow Query Logs
Audit logs
MySQL configuration files

The security team creates custom detection rules to identify high-risk activity, including failed authentication attempts, unauthorized administrative changes, and suspicious database operations.

Within days of deployment, Wazuh detects repeated failed login attempts originating from an unfamiliar external IP address.

Shortly afterward, the same source successfully authenticates using an administrator account outside the organization’s normal maintenance window.

A custom Wazuh rule immediately generates a high-severity alert containing:

Source IP address
Username
Authentication history
Affected database server
Event timeline

The security team investigates the alert and determines that the administrator credentials may have been compromised.

Because the event was detected quickly, analysts are able to disable the account and prevent unauthorized database access.

At the same time, Wazuh File Integrity Monitoring detects an unexpected modification to the MySQL configuration file.

The investigation reveals that the configuration change attempted to weaken database logging settings.

Administrators restore the approved configuration and confirm that monitoring controls remain active.

This combination of:

MySQL log monitoring
Custom detection rules
File Integrity Monitoring
Centralized dashboards
Automated alerting

allows the organization to detect threats earlier, reduce investigation time, and maintain stronger compliance controls.

Frequently Asked Questions (FAQ)

Question: Does Wazuh integrate directly with MySQL?

No. Wazuh does not typically connect directly to MySQL as a database client.

Instead, Wazuh monitors MySQL through:

Database log files
Audit logs
Configuration files
Operating system events

The Wazuh Agent collects these events and sends them to the Wazuh Manager for analysis.

Question: Which MySQL logs should I monitor?

The recommended logs depend on your security objectives.

Commonly monitored logs include:

Error Log
Audit Log
General Query Log
Slow Query Log
Binary Logs
Authentication-related logs

For most production environments, Error Logs and Audit Logs provide the highest security value.

Question: Can Wazuh detect SQL injection attempts?

Wazuh can help detect indicators associated with SQL injection attacks, especially when SQL activity appears in logs.

Detection may include:

Suspicious query patterns
Unexpected database errors
Abnormal application behavior
Repeated malformed requests

However, Wazuh is not a replacement for a Web Application Firewall (WAF) or secure application development practices.

Question: Does Wazuh support MariaDB?

Yes. Wazuh can monitor MariaDB using the same approach used for MySQL:

Collecting database logs
Monitoring audit logs
Tracking configuration changes
Creating custom detection rules

MariaDB Audit Plugin logs can also be monitored for additional security visibility.

Question: Can Wazuh monitor multiple MySQL servers?

Yes. Wazuh is designed for centralized monitoring across many endpoints.

Each MySQL server can run a Wazuh Agent that forwards database events to the same Wazuh Manager or cluster.

Related Guide: How to Set Up a Multi-Node Wazuh Cluster

Question: How do I monitor MySQL running inside Docker?

For MySQL containers, monitoring depends on the deployment architecture.

Common approaches include:

Installing the Wazuh Agent on the Docker host
Forwarding container logs to the host
Monitoring mounted MySQL log files
Collecting Docker events

Container environments should also monitor container configuration and runtime activity.

Related Guide: Fix Wazuh Docker Compose Deployment

Question: Can Wazuh monitor Amazon RDS MySQL?

Wazuh cannot install an agent directly on Amazon RDS because AWS manages the underlying operating system.

However, organizations can monitor RDS MySQL by collecting:

CloudWatch logs
Database audit logs
AWS activity logs

These events can then be forwarded into Wazuh for analysis.

Question: How do I reduce false positives?

Reduce false positives by:

Creating custom rules
Adjusting alert thresholds
Excluding approved maintenance activity
Whitelisting trusted users
Correlating multiple events

Regular rule tuning ensures analysts focus on meaningful security events.

Related Guide: How to Reduce False Positives in Wazuh

Question: Does Wazuh support automated response for MySQL threats?

Yes. Wazuh Active Response can execute automated actions when specific alerts occur.

Examples include:

Blocking malicious IP addresses
Running custom scripts
Disabling compromised accounts
Updating firewall rules

Organizations should test automated actions carefully before enabling them in production.

Question: Can Wazuh help with PCI DSS compliance?

Yes. Wazuh can assist organizations with PCI DSS-related security requirements by providing:

Centralized logging
Database activity monitoring
File integrity monitoring
Security alerts
Audit evidence

However, Wazuh is one component of a complete PCI DSS compliance program.

Question: How do I troubleshoot missing MySQL logs?

Start by checking:

Is MySQL logging enabled?
Does the log file exist?
Can the Wazuh Agent read the file?
Is the path correct in ossec.conf?
Is the agent connected?
Are rules matching the events?

Useful troubleshooting tools include:

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

and:

/var/ossec/bin/wazuh-logtest

Conclusion

Integrating Wazuh with MySQL provides organizations with centralized visibility into database security events, helping security teams detect unauthorized access, suspicious queries, privilege escalation, and configuration changes.

By configuring MySQL logging, deploying Wazuh Agents, monitoring database logs, and creating custom detection rules, organizations can transform raw database activity into actionable security intelligence.

The integration process includes:

Enabling the appropriate MySQL logs
Verifying log locations
Configuring Wazuh Agent collection
Validating event ingestion
Creating custom detection rules
Extending monitoring with additional Wazuh modules

A strong database security strategy requires continuous monitoring rather than periodic reviews.

Attackers often target databases because they contain valuable information, making early detection critical.

By combining MySQL monitoring with Wazuh capabilities such as:

File Integrity Monitoring
Vulnerability Detection
Rootcheck
Custom Rules
Active Response

organizations can build a stronger defense against database threats while improving compliance visibility.

As your environment grows, continue improving detection coverage by tuning rules, adding new log sources, and adapting monitoring policies to match evolving security requirements.