Can't get rule to trgger alert in dasboard

[Perry Blalock]

I'm very new to Wazuh and want to write my own custom decoders and rules.  I'm in the newbie stage of the decoder and rule writing and started learning with the SOCfortress example here:  https://socfortress.medium.com/understanding-wazuh-decoders-4093e8fc242c

Unfortunately, no matter what I do I cannot get the example to trigger and alert in my dashboard.  In fact, everything works up to that point.  When investigating I find that when I run the wazuh-logtest, there's no entry generated in ether the archive.log, archive.json, or alerts log.  I've scoured this forum and the global internet with Google, tried many many suggestions, and still can't seem to pinpoint and fix the the problem.  I know the wazhu structure in generally working because I have it consuming syslogs from my cisco routers and switches with the default decoders and rules and they seem to work just fine.

I'd love some help and feedback, I can't move forward with this until I get past this baby step.

I believe I'm on the latest versions of the wazuh stack, here is what I'[m running:

wazuh-dashboard/stable,now 4.14.0-1 amd64
wazuh-indexer/stable,now 4.14.0-1 amd64
wazuh-manager/stable,now 4.14.0-1 amd64

Kind regards,

[hasitha.u...@wazuh.com]

Hi Perry

Please give me some time — I’ll replicate this on my end and get back to you as soon as possible.

[hasitha.u...@wazuh.com]

Hi Perry, Default decoders and rules (like those for Cisco syslogs) are working fine, so your main Wazuh setup is functional. It seems the issue is with custom log collection.

Let me explain how log analysis works from the log collection process:

First, you need to configure log collection:
Wazuh documentation – Log data collection

If you’re collecting logs from network devices or any non-agent source, there are two main methods:

• configure-rsyslog-client-to-send-events-to-wazuh

• forwarding-linux-logs-using-rsyslog

If you’re collecting logs through an agent, configure the log collection in the agent’s ossec.conf file:
/var/ossec/etc/ossec.conf

Example:

1. <localfile>
2. <location>/path/to/file.log</location>
3. <log_format>syslog</log_format>
4. </localfile>

For more details, refer to:

Wazuh – Log data collection

After applying the configuration, restart the Wazuh agent:
systemctl restart wazuh-agent

Note: The agent will only send new entries added to the log file after the restart.

If the agent is successfully reading the file, you’ll see a log entry similar to this in /var/ossec/logs/ossec.log:

2025/10/26 01:32:27 wazuh-logcollector: INFO: (1950): Analyzing file: '/path/to/file.log'.

Once you confirm the file is being analyzed, you can then verify whether your log matches any existing Wazuh decoders or rules using:
/var/ossec/bin/wazuh-logtest

https://documentation.wazuh.com/current/user-manual/ruleset/testing.html

If no match is found, you need to create custom decoders and rules.
Check these documents to learn more about regex and decoder syntax
Decoders Syntax
Regular Expression Syntax

To learn more about rules, you can refer to these guides.
Rules
Rules Syntax
Regular Expression Syntax

I have tested the guide and successfully received the dashboard

I believe you have not configured the log collection.
For testing purposes, please create a file in the Wazuh manager: touch /var/log/test.log

Then add the file path to the manager ossec.conf file to monitor that path.

nano /var/ossec/etc/ossec.conf

1. <localfile>
2. <location>/var/log/test.log</location>
3. <log_format>syslog</log_format>
4. </localfile>

Then add these decoders to the custom decoder creation file.

1. <decoder name="medium">
2.   <prematch>^Medium:</prematch>
3. </decoder>
4.  
5. <decoder name="medium_child">
6.   <parent>medium</parent>
7.   <regex offset="after_parent">^\s(\.+) is an awesome company, check them out at (https://\.+)</regex>
8.   <order>company,website</order>
9. </decoder>

After that, you need to add the custom rules to match and generate alerts.

1. <group name="medium,socfortress">
2.  <rule id="100021" level="5">
3.     <decoded_as>medium</decoded_as>
4.     <field name="company">SOCFortress</field>
5.     <description>Go check out $(company) at $(website)!</description>
6.   </rule>
7.  <rule id="100022" level="5">
8.     <decoded_as>medium</decoded_as>
9.     <field name="company">OpenSecure</field>
10.     <description>Go check out $(company) at $(website)!</description>
11.   </rule>
12.  
13.   </group>

Then you need to restart the manager to apply changes: systemctl restart wazuh-manager Then add the below sample log entry into that file: /var/log/test.log and check again in the dashboard. Medium: OpenSecure is an awesome company, check them out at https://www.opensecure.co Let me know if you have tried the same log or a different log pattern. If yes, please share. I will check further.

[Perry Blalock]

Great, thank you so much!  

-------------------

Perry Blalock
google mail

--
You received this message because you are subscribed to a topic in the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/J-RLxI3HWkY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wazuh/0d0751e0-a722-47f6-91e6-6f38a433a015n%40googlegroups.com.

[Perry Blalock]

Hello Hashita san,

This is great information and it succinctly summarizes and wraps it all up in one place.... exactly what I was hoping for.  I think that from your input, I should be able to move forward.  Thank you so much.

Perry

[Perry Blalock]

Hello Hashita san,

Everything you suggested works and the log entry line I echoed into the /var/log/test.log did generate an alert in the dashboard.  I am a little confused though.  First, why would I need to create a new syslog file location in the ossec.conf file when the syslogs I'm receiving from my Cisco IOS devices already register in the dashboard without the syslog file entry in the ossec.conf file?

More importantly, now that I get the dashboard to register the event from the test case, the SOCFortress stuff, by "manually" echoing the log entry into the created test.log file, how do I get other syslog type devices to "automatically" register alerts in the dashboard?  I'm not understanding that part.  My goal is that I have network devices from many vendors and they all support syslog but there are no default decoders and rules built in Wazuh for those specific devices and hence I want to build my own rulesets and ultimately have them trigger alerts via the dashboard and email those events - I already have the email alert notification setup and it works for some of the default rulesets I'm using.

Regards,

-------------------

Perry Blalock
google mail

--

You received this message because you are subscribed to a topic in the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/J-RLxI3HWkY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/wazuh/b84df1f3-9fee-4e2b-b2ad-3cf4feffa4f9n%40googlegroups.com.

[Perry Blalock]

Hello Hashita san,

Everything you suggested works and the log entry line I echoed into the /var/log/test.log did generate an alert in the dashboard.  I am a little confused though.  First, why would I need to create a new syslog file location in the ossec.conf file when the syslogs I'm receiving from my Cisco IOS devices already register in the dashboard without the syslog file entry in the ossec.conf file?

More importantly, now that I get the dashboard to register the event from the test case, the SOCFortress stuff, by "manually" echoing the log entry into the created test.log file, how do I get other syslog type devices to "automatically" register alerts in the dashboard?  I'm not understanding that part.  My goal is that I have network devices from many vendors and they all support syslog but there are no default decoders and rules built in Wazuh for those specific devices and hence I want to build my own rulesets and ultimately have them trigger alerts via the dashboard and email those events - I already have the email alert notification setup and it works for some of the default rulesets I'm using.

Regards,

[hasitha.u...@wazuh.com]

Hi Perry,

I am glad that the above information helps.

I’ve shared an example for localfile log collection. This means that if you want to collect logs from any application or log source that writes to a file, you can configure the agent’s ossec.conf file as shown below, to collect the logs from a file.

1. <localfile>
2. <location>/var/log/test.log</location>
3. <log_format>syslog</log_format>
4. </localfile>

However, for network devices, there are two options we recommend to collect logs.

1. Direct forwarding to the Wazuh manager by configuring a syslog listener on the manager side.

2. Alternatively, instead of forwarding directly to the manager, it’s often better to forward logs to a Wazuh agent using rsyslog and then configure log collection on the agent side.

In the first option, you can configure the Wazuh manager ossec.conf file to listen and collect logs from network devices.
Add the following configuration in between the <ossec_config> tags of the Wazuh server /var/ossec/etc/ossec.conf file to listen for syslog messages on TCP port 514:

1. <remote>
2.   <connection>syslog</connection>
3.   <port>514</port>
4.   <protocol>tcp</protocol>
5.   <allowed-ips>192.168.2.15/24</allowed-ips>
6.   <local_ip>192.168.2.10</local_ip>
7. </remote>

Where:
<connection> specifies the type of connection to accept. This value can either be secure or syslog.
<port> is the port used to listen for incoming syslog messages from endpoints. We use port 514 in the example above.
<protocol> is the protocol used to listen for incoming syslog messages from endpoints. The allowed values are either tcp or udp.
<allowed-ips> is the IP address or network range of the endpoints forwarding events to the Wazuh server. In the example above, we use 192.168.2.15/24.
<local_ip> is the IP address of the Wazuh server listening for incoming log messages. In the example above, we use 192.168.2.10.

Refer to remote - local configuration documentation for more information on remote syslog options.
For further details please refer to this: https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/syslog.html

  Regarding the second option — if you plan to collect logs from network devices through an agent and then forward them to the manager, you can configure rsyslog on the Wazuh agent to receive those logs. Rsyslog can listen for incoming logs from the network devices and write them to a file. Then, you can configure the Wazuh agent’s ossec.conf file with a localfile entry (as shown above) to collect those logs. For more details, please refer to this.  
Ref: https://documentation.wazuh.com/current/cloud-service/your-environment/send-syslog-data.html#rsyslog-on-linux

Let me know the update on this.

[hasitha.u...@wazuh.com]

Hi Perry

Additionally, once you have configured one of the log collection for network devices, then you can check the archives.json logs to verify logs reaching the manager. If it's receiving, then you can confirm with wazuh-logtest that those logs match any default decoder and rules; if not, you need to create custom decoders and rules.
By default, archives.json logs are disabled due to high resource utilization.

To capture the logs from archives.json, please follow these steps:
1. Enable log_all_json on Wazuh Manager
Update the ossec.conf file on the Wazuh manager to enable log_all_json.
2. Reproduce the Event
Trigger the event again to capture the relevant logs.
3. Extract Relevant Logs
Run the following command on the Wazuh manager:
       cat /var/ossec/logs/archives/archives.json | grep -iE "<related string>"
Replace <related string> with a relevant value from the log to filter the specific entries.
4. Disable log_all_json
After capturing the logs, disable log_all_json in the ossec.conf file to prevent excessive storage usage.
Share the sample log that you have taken from archives.json with us.
Ref: https://documentation.wazuh.com/current/user-manual/manager/event-logging.html#enabling-archiving

Warning
Keeping <logall_json>yes</logall_json> on can fill up your disk fast! Once you’re done troubleshooting, set it back to no in /var/ossec/etc/ossec.conf and restart the manager:
systemctl restart wazuh-manager

We recommend creating custom rules and decoders based on archives.json because in these logs we can see the field full_log, which is the one being parsed by analysis, one of the archives.json events should look like this (the field of interest is in bold):
{"timestamp":"2023-09-05T02:47:40.074+0000","agent":{"id":"001","name":"abc","ip":"10.0.2.29},"manager":{"name":"Server85"},"id":"1693882060.373586","full_log ":"Sep 5 03:10:19 Server91 dbus-daemon[676]: [system] Successfully activated service 'org.freedesktop.UPower","predecoder":{"program_name":"dbus-daemon","timestamp":"Sep 5 03:10:19","hostname":"Server91"},"decoder":{},"location":"/var/log/syslog"}
Ref: https://wazuh.com/blog/creating-decoders-and-rules-from-scratch/

Check these documents to learn more about regex and decoder syntax
Decoders Syntax
Regular Expression Syntax

To learn more about rules, you can refer to these guides.
Rules
Rules Syntax
Regular Expression Syntax

Hope this information helps to understand the flow of log collection till generating alerts from network devices.

[Perry Blalock]

Got it and understood, thank you for clarifying that..  I'm already consuming syslog messages on my Wazuh server (514.UDP), that's how I'm able to process and decode alerts from my Cisco devices on my Wazuh stack.  My oddball network devices that are generating syslogs and sending them to my Wazuh server are the ones needing custom decoders and rules.  I am able to track the received syslog messages from these devices on my Wazuh server by enabling the <logall> and <logall_json> in my ossec.conf and tailing /var/ossec/logs/archive/archive.json.  I'm assuming that once I develop the proper decoders and rules for these odd network device syslog outputs, then I'll start to ultimately get the dashboard entries from them  as well - of course, the custom decoders and rules are the hard part and super time consuming for me personally.  I've probed around looking for an easy way out of developing these, but not much available,  I did come across some guy on linkedin who claims he's developed on online tool that can specifically support writing the decoders and rules to work with Wazuh, but he says it's still in development.  Thank you so much my friend, you've been of great help.

-------------------

Perry Blalock
google mail

--

You received this message because you are subscribed to a topic in the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/J-RLxI3HWkY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/wazuh/9dfbbdf6-7fe6-4970-b77a-04857176e876n%40googlegroups.com.

[hasitha.u...@wazuh.com]

Hi  Perry

 I’m glad the information above helped clarify your query.
We can certainly assist you in creating custom decoders and rules. If you need assistance on them, please share a sample from your oddball network devices within the archives.json logs, and we’ll provide example decoders and rules accordingly.  

[Perry Blalock]

Hasitha san,

Thank you so much, you have been tremendously helpful and have given me enough information so far that I have just hit the "Ah Ha" junction and it's starting to come together like i had hoped.  I appreciate you've graciously offered to help me develop the custom rulesets, but I really need to do this myself, or at least try, and so far it's doing what I want.  I have been successful in building a working ruleset for one of my Zyxel network syslog entries and that's given me enough confidence to be dangerous and keep struggling forward.  So far, I've only gotten Wazuh to trigger on a successful login, place the alert in the dashboard, and send off an email alert.  This particular Zyxel is one of the simpler ones but does have more granular things to monitor, so I will use it to build and test more complex rulesets before moving on to more complex syslog formats from other devices.   I will not consume more of you generous time, now, but I will remember that you have offered 8-) 

Thanks gain.

[hasitha.u...@wazuh.com]

Hi Perry,

It sounds like you’ve made excellent progress already, especially with building your first working ruleset for the Zyxel syslog and successfully triggering alerts. Using it as a stepping stone to tackle more complex devices is a smart approach.

I completely understand wanting to tackle the custom rules yourself — that’s the best way to learn and gain confidence. Keep experimenting and refining; you’re clearly on the right path. And don’t worry, I’ll be here if you ever need guidance or a second pair of eyes down the road. Keep up the great work!