Key Takeaways
- Databases are the target, not the path. They hold the crown-jewel data, yet are often unmonitored. Database activity monitoring with Wazuh closes that gap.
- The hard part is enabling audit logging in each engine: the MySQL/MariaDB audit plugin or general log, PostgreSQL logging and pgAudit, and SQL Server audit or the error log.
- Wazuh collects and decodes these logs through the agent, parsing connections, queries, errors and privilege operations into structured, alertable fields.
- Priority detections: repeated failed logins, logins from unexpected hosts, GRANT and role changes, schema changes (DROP, ALTER) and signs of bulk data access or dumping.
- Balance depth against noise: full query logging is high volume, so decide what to audit based on sensitivity and tune collection to signal.
Why Databases Are the Blind Spot That Matters
Attackers rarely want a server for its own sake; they want the data on it, and that data almost always lives in a database. Customer records, credentials, financial data and intellectual property sit in MySQL, PostgreSQL and Microsoft SQL Server instances. Yet databases are frequently among the least monitored systems in an organisation, because audit logging is off by default and turning it on takes deliberate effort in each engine.
This is the blind spot that the most damaging breaches exploit. An attacker who reaches a database with stolen or escalated credentials can read or exfiltrate large volumes of data with activity that looks, to an unmonitored system, entirely normal. Database activity monitoring with Wazuh brings these systems into the SOC so that access, privilege changes and data movement are visible and alertable. This builds on the broader database activity monitoring approach and makes it concrete for the three most common engines.
Monitoring MySQL and MariaDB
MySQL and MariaDB do not audit by default. The most complete option is an audit plugin (the MariaDB Audit Plugin, which also works with MySQL, or MySQL Enterprise Audit) that records connections, queries and administrative actions to a log file in a structured format. Where a plugin is not available, the general query log and error log provide a lighter alternative, though the general log is verbose and better used selectively.
Point the Wazuh agent at the resulting audit or log file via the localfile configuration. Wazuh decodes the entries so you can alert on failed authentication, connections from unexpected source hosts, privilege statements like GRANT and REVOKE, user creation, and schema changes. For sensitive databases, the audit plugin is worth the setup because it gives reliable, parseable coverage of exactly who did what, which the general log does less cleanly.
Need Help Building These Detections?
Codesecure designs, deploys and tunes Wazuh-based SOC stacks (manager, indexer, dashboard, agents, custom rules, decoders and active response) for businesses across India, Singapore, UAE and Malaysia. ISO/IEC 27001:2022 certified delivery, named OSCP, CEH and CISSP consultants, fixed-price proposals.
See SOC and SIEM Services →Monitoring PostgreSQL
PostgreSQL has flexible logging controlled in postgresql.conf. At minimum, enable connection and disconnection logging and the logging of failed authentication, DDL statements and errors. For thorough auditing, add the pgAudit extension, which produces detailed, classified audit entries for reads, writes, DDL, roles and functions, far more useful for security than the default statement logging.
Configure the Wazuh agent to collect the PostgreSQL log files. With pgAudit enabled you get clean, structured records to alert on: authentication failures, role and privilege changes (GRANT, ALTER ROLE), schema modifications, and access to sensitive tables. As with MySQL, the trade-off is volume versus visibility: log connections, failures and privileged or DDL activity everywhere, and reserve detailed read/write auditing for the databases whose data genuinely warrants it.
Monitoring Microsoft SQL Server
Microsoft SQL Server provides SQL Server Audit, a built-in feature that records server and database-level actions to a file or the Windows event log. Configure audit specifications to capture logins (successful and failed), permission and role changes, schema changes and access to sensitive objects. Writing audit output to the Windows Security or Application event log lets the Wazuh agent collect it through the eventchannel format alongside the host's other Windows events.
Alternatively, SQL Server's error log captures login failures and some events with lighter setup, and can be collected as a file. Through either route, Wazuh parses the activity so you can detect brute-force logins against SQL accounts, privilege escalations via role changes, and structural tampering. Because many SQL Server boxes are Windows domain members, this database telemetry also correlates naturally with the Active Directory and host detections already in Wazuh.
The Detections That Matter
Across all three engines, a common set of detections delivers most of the value. Authentication anomalies: repeated failed logins (database brute force) and successful logins from unexpected hosts or at unusual times, especially for privileged accounts. Privilege changes: GRANT, REVOKE, role additions and new database users, which can indicate an attacker establishing access or escalating.
Structural tampering: DROP, ALTER and other DDL against production schemas outside change windows, which can signal destruction or manipulation. Data access and exfiltration signals: unusually large result sets, bulk export operations, or access to sensitive tables by accounts that normally never touch them. Mapping these to your risk, and to MITRE ATT&CK where relevant, keeps the detection set focused on what actually indicates compromise rather than every routine query.
Running Wazuh But Missing Attacks?
Whether you need custom rule development, active response playbooks, a detection coverage review against MITRE ATT&CK, or full tuning, our SOC lead is available for a 30-minute free scoping call. No obligation, no slideware.
Talk to a SOC Engineer →Managing Volume and Noise
The reason databases go unmonitored is often fear of the log volume, and that fear is reasonable. Full query logging on a busy database can generate enormous amounts of data, overwhelming ingestion and storage and burying signal in routine activity. The answer is to audit selectively rather than logging everything everywhere.
Decide what to audit based on data sensitivity. For every database, log connections, authentication failures and privileged or DDL operations, which are low volume and high value. Reserve detailed read and write auditing for the databases that hold regulated or crown-jewel data, where the volume is justified. In Wazuh, separate what you store from what you alert on: keep audit history for forensics and compliance, but alert only on the patterns that indicate real risk. This keeps database monitoring both affordable and effective, which is what makes it sustainable.
Frequently Asked Questions
How do I monitor MySQL with Wazuh?
Enable auditing in MySQL or MariaDB first, ideally with an audit plugin (the MariaDB Audit Plugin or MySQL Enterprise Audit) that records connections, queries and admin actions to a log file, or the general query log as a lighter option. Then point the Wazuh agent at that log file via localfile. Wazuh decodes it so you can alert on failed logins, privilege changes and schema modifications.
What do I need to monitor PostgreSQL with Wazuh?
In postgresql.conf, enable connection, disconnection, failed-authentication, DDL and error logging, and for thorough auditing add the pgAudit extension, which produces detailed classified audit entries. Configure the Wazuh agent to collect the PostgreSQL log files. You can then alert on authentication failures, role and privilege changes, schema modifications and access to sensitive tables.
How does Wazuh monitor Microsoft SQL Server?
Use SQL Server Audit to record logins, permission and role changes, schema changes and sensitive-object access, and write the audit output to the Windows event log so the Wazuh agent collects it through the eventchannel format. Alternatively collect the SQL Server error log as a file for lighter coverage of login failures. Wazuh parses the activity for brute-force logins, privilege escalation and tampering.
What are the most important database detections to build?
Across MySQL, PostgreSQL and SQL Server, prioritise three: failed-login bursts (database brute force) and logins from unexpected hosts; privilege changes such as GRANT, REVOKE, role additions and new users; and DDL (DROP, ALTER) against production schemas outside change windows. Add signals for bulk data access or export to sensitive tables to catch exfiltration.
How do I monitor databases without huge log volume?
Audit selectively based on data sensitivity. For every database, log connections, authentication failures and privileged or DDL operations, which are low volume and high value. Reserve detailed read and write query auditing for databases holding regulated or crown-jewel data. In Wazuh, separate what you store for compliance from what you alert on, so you keep forensic history without alerting on routine queries.
Can Codesecure set up database monitoring in our Wazuh?
Yes. Codesecure enables and tunes audit logging for MySQL, PostgreSQL and SQL Server, configures Wazuh collection and decoding, and builds the detections for failed logins, privilege changes, schema tampering and data access, balanced to control log volume. ISO/IEC 27001:2022 certified delivery with named OSCP, CEH and CISSP consultants across India, Singapore, UAE and Malaysia.
Monitor The Databases That Hold Your Crown Jewels
Codesecure enables audit logging and builds Wazuh detections for MySQL, PostgreSQL and SQL Server, covering failed logins, privilege changes, schema tampering and data exfiltration, tuned to control volume. Delivered by named OSCP, CEH and CISSP consultants.
