Implementing PostgreSQL Login Monitoring Use Cases in Wazuh (DAM Compliance)

[Chandra pal singh Chauhan]

Hi Team,

We have PostgreSQL in place, and for compliance purposes we require a DAM (Database Activity Monitoring) solution. Due to pricing constraints, we are planning to monitor database-level logs using Wazuh.

During my research, I found an approach for PostgreSQL integration via the Wazuh agent. However, the default rules provided are not sufficient and do not fully match our requirements.

Our key use cases are as follows:

1. Alert when a database user successfully logs in.

2. Alert when a database user login fails.

3. Alert when an existing database user has repeated login failures.

4. Alert when a non-existing database user attempts to log in.

Could you please guide us on how to implement these specific use cases in Wazuh, including any custom decoders or rules that may be required?

Thank you for your support.

Best regards,
Chandra

[Javier Sanchez Gil]

Hi Chandra,

Yes, this is a feasible approach in Wazuh and it is commonly implemented as a log-based DAM (Database Activity Monitoring) use case.

At a high level, the recommended approach is:

• Enable PostgreSQL authentication logging (successful connections, failed logins, and attempts using non-existing users). Without proper database logging, these use cases cannot be implemented.

• Collect PostgreSQL logs with the Wazuh agent, using log file monitoring or syslog/journald.

• Create custom decoders (if needed) to extract relevant fields such as database user, database name, source IP, and authentication result.

• Create custom rules to generate alerts for:

  • Successful database logins (audit visibility).

  • Failed login attempts.

  • Repeated login failures using frequency and timeframe (brute-force / password spraying detection).

  • Login attempts using non-existing database users (user enumeration).

• Suppress trusted or expected activity (for example health-checks or monitoring probes) using rules with level 0, to avoid unnecessary noise.

Please note that this approach provides database-level monitoring based on logs.

Relevant documentation:

• Log collection:
  https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/index.html

• Decoders (overview):
  https://documentation.wazuh.com/current/user-manual/ruleset/decoders/index.html

• Decoder XML syntax:
  https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/decoders.html

• Rules (overview):
  https://documentation.wazuh.com/current/user-manual/ruleset/rules/index.html

• Rules XML syntax and correlation:
  https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html

• Custom rules and testing:
  https://documentation.wazuh.com/current/user-manual/ruleset/testing.html

If you can share a few sample PostgreSQL log lines (successful login, failed login, and non-existing user), the required decoders and rules can be tailored precisely.

[Chandra pal singh Chauhan]

Hello Javier,

I have also attached some more logs for login success.

[Chandra pal singh Chauhan]

Hello  Javier,

Sorry for the delay response and i have attached the logs files for your reference. 

On Thursday, January 29, 2026 at 4:58:31 PM UTC+5:30 Javier Sanchez Gil wrote:

[Chandra pal singh Chauhan]

Dear Team,

Please look into this on priority basis.

[Javier Sanchez Gil]

Hi Chandra,

Thanks for sharing the consolidated PostgreSQL log file — I’ve reviewed the complete set of logs from all files.

All authentication-related entries in the logs correspond to successful connections, for example:

LOG: connection authorized: user=<user> database=<db>

From these events, Wazuh can reliably detect and alert on:

• Successful database logins

• Database user and database name

• Source IP or local connections

• SSL/TLS usage (useful for compliance)

However, after reviewing the full log set, there are no entries related to authentication failures, such as:

• Password authentication failed

• Login attempts with non-existing users

• role does not exist or similar errors

Because these events are not present in the logs, the following DAM use cases cannot be implemented yet:

• Alert on failed login attempts

• Alert on repeated login failures

• Alert on login attempts using non-existing users

To fully cover those scenarios, PostgreSQL must be configured to log authentication failures in addition to successful connections. In practice, this usually requires:

• Enabling connection logging:

  • log_connections = on

  • log_disconnections = on

• Using a log_line_prefix that includes user, database and source IP, for example:

  • log_line_prefix = '%m %u@%d %r [%p] '

• Verifying that authentication failures (FATAL messages such as password authentication failed or role does not exist) are not being filtered out by the logging destination (file, syslog, or CloudWatch in the case of RDS).

Once those authentication failure log entries are available, Wazuh can handle the detection using custom rules and frequency-based correlation.

[Chandra pal singh Chauhan]

Hi Javier,

Thank you for the explanation. I understand what you are trying to convey.

Could you please help me by creating some custom rules, as I already have a decoder configured for this use case? Additionally, I would appreciate your guidance on handling authentication failure events using the decoder below.

I am currently using the following decoders:

<decoder name="postgres_audit">
    <parent>windows-date-format</parent>

    <prematch>AUDIT</prematch>

    <regex>(\S+ \S+ \w+):(\d+.\d+.\d+.\d+)\((\d+)\):(\w+):\p(\d+)\p:LOG: (\.+)AUDIT: (\w+),(\d+,\d+),(\.+),(\.+),"(\.+""\.+"""),(\.+)</regex>
    <order>timestamp, srcip, srcport, user, pid, log_level, audit_type, session_info, action, command, sql, extra</order>
</decoder>

<decoder name="postgres_database">
    <parent>windows-date-format</parent>
    <prematch>database</prematch>
    <regex>(\S+ \S+ \w+):(\d+.\d+.\d+.\d+)\((\d+)\):(\w+):\p(\d+)\p:LOG:(\.+)connection authorized: user=(\.+) database=(\.+)</regex>
    <order>timestamp, srcip, srcport, user, pid, log_level, user, database</order>

</decoder>  

If I replace connection authorized with connection failed (or the corresponding message observed in the logs for failed authentication attempts), will this decoder work correctly for detecting failed login attempts?

Please let me know if additional modifications or a separate decoder would be required for this scenario.

Thanks,