Assistance with RDS Authentication Logs, Decoders, and Rule Sets

73 views
Skip to first unread message

Arun Ramesh Hundaragi

unread,
Sep 10, 2025, 3:57:48 PM (9 days ago) Sep 10
to Wazuh | Mailing List

I am currently working on pulling RDS authentication logs from AWS. My setup is as follows:

  • I have an agent installed on an AWS host (same AWS account).

  • This agent is configured to collect CloudWatch logs for RDS.

  • The agent then forwards these logs to the Wazuh Manager for processing.

I need some assistance regarding decoders and rule sets for these logs:

  1. I would like to configure the rules so that RDS authentication failures (e.g., password authentication failed) are tagged with log level 8, since they indicate security-relevant events.

  2. All other general RDS logs should remain tagged at a lower severity, such as log level 5.

  3. I am also trying to understand better how exactly these RDS logs are parsed when they come from the agent to the Wazuh Manager, and whether there are existing decoders or rule sets already available for RDS logs that I could leverage instead of writing everything from scratch.

Could you please advise:

  • If there are any official or community-provided decoders/rules for RDS logs that can help with authentication failure detection?

  • If not, do you have recommended best practices for building custom decoders and rules to achieve the above (level 8 for auth failures, level 5 for general logs)?

Any guidance, examples, or references to documentation would be greatly appreciated.

currently using these "<decoder name="RDS">

  <prematch>^\.*Connect|Query|Quit</prematch>
</decoder>

<decoder name="RDS-1">
  <parent>RDS</parent>
  <regex>(\.*)</regex>
  <order>Action</order>
</decoder>

<decoder name="RDS-1">
  <parent>RDS</parent>
  <regex>(\w+) (\.*)\s</regex>
  <order>id user-action</order>
</decoder>

<decoder name="RDS-1">
  <parent>RDS</parent>
  <regex offset="after_regex">(\.*)</regex>
  <order>query</order>
</decoder>

<decoder name="RDS-1">
  <parent>RDS</parent>
  <regex offset="after_regex">\s(\w+)@(\.*)\son\s(\.*)\susing\s(\.*)</regex>
  <order>username srcip service protocol</order>
</decoder>

<decoder name="RDS-ERROR">
  <prematch>^\.* Aborted</prematch>
</decoder>

<decoder name="RDS-2">
  <parent>RDS-ERROR</parent>
  <regex>(\.*) (\.*\s\.*) (\.*) db:\s(\.*) user:\s(\.*) host:\s(\.*) </regex>
  <order>severity connection-action id db user host</order>
</decoder>
-----------------------------------------------------
and have rules- 

<group name="rds_logs">
 
  <rule id="100200" level="5" overwrite="yes" >
    <decoded_as>RDS</decoded_as>
    <description>Generic action in RDS logs</description>
    <options>no_full_log</options>
  </rule>

 
  <rule id="100201" level="5" overwrite="yes">
    <decoded_as>RDS</decoded_as>
    <description>User action in RDS logs</description>
    <options>no_full_log</options>
  </rule>

 
  <rule id="100202" level="5" overwrite="yes">
    <decoded_as>RDS</decoded_as>
    <description>Query in RDS logs</description>
    <options>no_full_log</options>
  </rule>

 
  <rule id="100203" level="5" overwrite="yes">
    <decoded_as>RDS</decoded_as>
    <description>User connection details in RDS logs</description>
    <options>no_full_log</options>
  </rule>

  <rule id="100204" level="5" overwrite="yes">
    <decoded_as>RDS-2</decoded_as>
    <description>Error details in RDS logs</description>
    <options>no_full_log</options>
  </rule>

</group>"

Thanks in advance for your help!


CONFIDENTIAL: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify DuploCloud, Inc. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

Olamilekan Abdullateef Ajani

unread,
Sep 10, 2025, 4:47:54 PM (9 days ago) Sep 10
to Wazuh | Mailing List
Hello Arun,

To test your custom decoders and rules, you need a sample log. This would also serve as a guide on different use cases or patterns you would like to match with your rules. I will suggest you get a sample log, you can also share it with me so I am able to properly analyze the rules and decoders you have created and make suggestions where necessary.
Beyond this, I will also suggest you check out the blogs below regarding capturing and monitoring RDS logs. There are sample rules you can also work with there, you can take them as a reference point.


Please let me know what you find so we can decide the next step.

Regards,

Arun Ramesh Hundaragi

unread,
Sep 11, 2025, 8:23:05 AM (9 days ago) Sep 11
to Wazuh | Mailing List

Hi, thanks for the pointers. I tried the links and the decoders provided, but importing/applying them keeps throwing a syntax error—even when I rewrite the regex and add them via the UI. Also, when you say ‘sample log,’ do you mean the raw RDS auth events as they appear in CloudWatch (original message/JSON), or some other format? I can share a few representative CloudWatch log lines if that’s what you need.

Olamilekan Abdullateef Ajani

unread,
Sep 11, 2025, 10:21:29 AM (9 days ago) Sep 11
to Wazuh | Mailing List
Hello Arun,

Did you follow the documentation regarding the integration aspect so the logs can be forwarded to wazuh? Could you confirm this by enabling archives and filtering for the logs, this is the first step.

You can enable the archive log by editing the /var/ossec/etc/ossec.conf file.
<ossec_config>
  <global>
    ----  
    <logall>yes</logall>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>

Then restart the Wazuh-manager.
systemctl restart wazuh-manager

cat /var/ossec/logs/archives/archives.json| grep -i -E "part of your log"
Verify that you have the logs, then disable archiving by setting the values to no.

You can share the logs captured from the file. If no, you can also share the raw log for decoder and custom rule creation.

Please let me know what you find



Arun Ramesh Hundaragi

unread,
Sep 16, 2025, 4:49:38 PM (3 days ago) Sep 16
to Wazuh | Mailing List

Hello Wazuh Support,

I am currently working on parsing Amazon RDS authentication logs with Wazuh 4.11.1.

Setup:
  • An agent is installed on an AWS host.

  • This agent is configured to collect CloudWatch logs for RDS.

  • The agent forwards these logs to the Wazuh Manager.

Goal:
  • Authentication failures (e.g., password authentication failed for user) should be tagged as log level 8 (security-relevant).

  • General RDS activity logs should remain at log level 5

{"timestamp":"2025-09-16T19:02:14.803+0000",
 "agent":{"id":"XXXX","name":"aws-agent"},
 "manager":{"name":"wazuh.manager"},
 "id":"1758049334.50490938",
 "cluster":{"name":"wazuh","node":"master"},
 "full_log":"2025-09-16 16:41:04 UTC:10.x.x.x(51838):dbuser@dbname:[30827]:FATAL:  password authentication failed for user \"dbuser\"",
 "decoder":{"parent":"auditd","name":"auditd"},
 "location":"/var/log/audit/audit.log"}

Current Configuration:

Decoders:

<decoder name="RDS">
  <prematch>^\.*Connect|Query|Quit|DEBUG</prematch>


</decoder>

<decoder name="RDS-1">
  <parent>RDS</parent>
  <regex>(\.*)</regex>
  <order>Action</order>
</decoder>

<decoder name="RDS-ERROR">
  <prematch>^\.* Aborted</prematch>
</decoder>


Rules:

<group name="rds_logs">

  <rule id="100200" level="5" overwrite="yes">
    <decoded_as>RDS</decoded_as>
    <description>Generic action in RDS logs</description>

  </rule>

  <rule id="100600" level="8">
    <decoded_as>RDS</decoded_as>
    <regex>FATAL:\s+.*password authentication failed for user</regex>
    <group>rds_logs,authentication_failed</group>
    <description>RDS: User authentication failure.</description>
  </rule>

</group>


Issue:

Even with these decoders/rules, some unrelated logs (for example, auditd/syscall style entries) are being matched and tagged under the same rules. This causes non-RDS data to be tagged incorrectly as log level 5 or 8.

Request for Guidance:
  • Are there any official or community-provided decoders/rules for RDS logs that can be used directly in Wazuh 4.11.1?

  • If not, could you advise on best practices for building custom decoders/rules so that only RDS logs are matched, and unrelated system/auditd logs are ignored?

  • Specifically, how can I refine the decoders/prematch so only CloudWatch RDS log patterns are handled?

Any guidance, examples, or documentation references would be greatly appreciated.

Thanks in advance for your support,

Olamilekan Abdullateef Ajani

unread,
Sep 17, 2025, 10:42:40 AM (3 days ago) Sep 17
to Wazuh | Mailing List
Hello Arun,

I believe some of the things you asked were answered in my previous response, however, I noticed you added a log in your reply. I have created a sample decoder and rule to trigger this event based on my own environment. This along with the wazuh ruleset documentation can be used as a guide going forward in ceating effective rules and decoders.

<decoder name="RDS">
  <prematch>Connect|Query|Quit|DEBUG|FATAL</prematch>

</decoder>

<decoder name="RDS-1">
  <parent>RDS</parent>
  <regex offset="after_parent">(\.+) for user \p(\w+)\p</regex>
  <order>Event_details,user</order>
</decoder>


RULES:

<group name="rds_logs">

   <rule id="100601" level="8">
    <decoded_as>RDS</decoded_as>
    <match>password authentication failed</match>

    <group>rds_logs,authentication_failed</group>
    <description>RDS: User authentication failure.</description>
  </rule>
</group>

I noticed you mentioned above that some unrelated events do trigger your RDS decoder and rules, an effective way of creating decoders and rules is to fine-tune it to your logs pattern and exclude unrelated events from being triggered by them.

I have also shared decoders and rules documentation below for your perusal, you can also make use of these in creating decoders and rules.


Please let me know if you still require further assistance on this

rdslogs.png
Reply all
Reply to author
Forward
0 new messages