rsyslog and Wazuh

[exe]

Greetings,

we want to use rsyslog to capture for example Sonicwall logs, but I'm a bit stuck right now.

I set up a rsyslog Server but don't know how to keep going from here on out.

We have multiple Sonicwalls but I just dont know how to set it up properly and test it to see that it really captures it.

I would really appreciate some guidance :D 

Thank you all, you are all doing an amazing job!

[Stuti Gupta]

Hi  exeteste,

You need to configure rsyslog on the endpoint where the Wazuh agent is installed. The installation steps for the Wazuh agent are here:
https://documentation.wazuh.com/current/installation-guide/wazuh-agent/index.html

To configure rsyslog, edit the file /etc/rsyslog.conf and add a rule to store logs from the SonicWall device into a specific file. For example:

# Store messages from the remote device
if $fromhost-ip startswith '<REMOTE_DEVICE_IP>' then /var/log/<FILE_NAME>.log
& ~

You can refer to this documentation for syslog forwarding:
https://documentation.wazuh.com/current/cloud-service/your-environment/send-syslog-data.html

After rsyslog starts storing the SonicWall logs into a file, configure the Wazuh agent to monitor that file using a localfile entry in ossec.conf. For example:

<localfile>
<log_format>syslog</log_format>
<location>/path/to/sonicwall/logfile.log</location>
</localfile>

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

Update the configuration with your correct log path and format, then restart the agent.

Once this is done, check the agent log to confirm the file is being monitored:

cat /var/ossec/logs/ossec.log | grep <log file name>

If the file is being monitored, check the Wazuh dashboard to see if alerts appear.
If you do not see any alerts or events, enable archives logging to confirm whether logs are being received.
Documentation:
https://documentation.wazuh.com/current/user-manual/manager/event-logging.html
Note: enabling archives.json consumes disk space and is not recommended for production environments.

If the logs appear in archives.json but not on the dashboard, the issue is most likely that no default decoders or rules match your SonicWall logs.  You need to create custom rules and decide based on those logs https://documentation.wazuh.com/current/user-manual/ruleset/index.html

Let me know if you need any further help.

[exe]

Hello Stuti,

first of all thank you for the detailed help. 

I would like to point out we are using kafka in between syslog an wazuh (we use grafana and our sys admin pushed us to use kafka) so you dont get confused as why the paths may be diffrent or the names.

I got to th point that i did: root@spielwiese:/var/ossec/etc# cat /var/ossec/logs/ossec.log | grep /opt/docker/rsyslog/data/syslog-0/00000000000000000000.log
And as a result I got:

2026/02/25 14:12:43 wazuh-logcollector: INFO: (1950): Analyzing file: '/opt/docker/rsyslog/data/syslog-0/00000000000000000000.log'.

But looking at the Wazuh dashboard I cant seem to find any alerts.

Now, if you could please help me with the archives log as i got lost in the documentation (sorry) and didnt know where to start and what to do.

Thank you again!

[exe]

Hello there,

i dont know if the last reply was sent, but to be safe i will send it again.

First of all thank you for your help, just a info we are using kafka between syslog and wazuh.

I did everything as you said and got to this point: root@spielwiese:/var/ossec/etc# cat /var/ossec/logs/ossec.log | grep /opt/docker/rsyslog/data/syslog-0/00000000000000000000.log

2026/02/25 14:12:43 wazuh-logcollector: INFO: (1950): Analyzing file: '/opt/docker/rsyslog/data/syslog-0/00000000000000000000.log'.

But in the dashboard i cant seem to find any alerts.

Now you pointed out i should try archives logging, but to be honest with you i somewhat got lost and dont know what to do (sorry)

If you could please help me further, this would be greatly appreciated!

Greetings

Noah

Stuti Gupta schrieb am Dienstag, 24. Februar 2026 um 09:00:11 UTC+1:

[Stuti Gupta]

No issues, let me explain this.

When the agent or manager starts monitoring and collecting logs using the localfile or syslog, it sends them to the manager for analysis. The manager tries to match the log pattern to default rules and decoders. These rules are responsible for generating alerts in the dashboard.

If the Wazuh dashboard is not showing alerts related to syslog-0/00000000000000000000.log, it may be because there are no matching default rules or decoders. To check whether the logs are at least reaching the manager, we need to enable the archives. The archives.log and archives.json files contain all events, even if they do not match any rule. If the log appears inside /var/ossec/logs/archives/archives.json but does not appear on the Wazuh dashboard, then it is clear that custom rules and, if needed, decoders must be created so alerts can be triggered.

To check this, we first need to enable the archives because they are disabled by default due to high disk space usage. To enable them:

Edit the Wazuh manager configuration file at /var/ossec/etc/ossec.conf and set logall and logall_json to yes:

<ossec_config>
<jsonout_output>yes</jsonout_output>
<alerts_log>yes</alerts_log>
<logall>yes</logall>
<logall_json>yes</logall_json>
...
</ossec_config>

Note: enabling archives.json uses a lot of disk space and is not recommended in production. Disable it again after the issue is resolved.

Then restart the Wazuh manager using: systemctl restart wazuh-manager

After this, check whether new entries from the monitored log file appear using:
cat /var/ossec/logs/archives/archives.json | grep

If the log is present, you can create the required custom rules and decoders based on the full_log field. This field contains the actual log monitored by Wazuh.https://documentation.wazuh.com/current/user-manual/ruleset/index.html

If you need help creating custom rules or decoders, share the logs and remove any sensitive information.

[exe]

Hello Stuti,

thank you again for your explanation, it really helped me understand the pipeline better.

I would like to clarify our architecture, as I believe this is where my confusion came from:

We are running two separate environments (both in Docker via Portainer):

• "spielwiese" → this is where rsyslog is collecting the logs and forwarding them into Kafka

• "siem01" → this is where the Wazuh manager, indexer, and dashboard are running

On the "spielwiese" system, the logs are written into a Kafka topic directory:

/opt/docker/rsyslog/data/syslog-0/

This directory contains files such as:

• *.log

• *.index

• *.timeindex

So this appears to be Kafka broker storage rather than a plain-text syslog file.

On the Wazuh side ("siem01"), I configured a localfile pointing to:

/opt/docker/rsyslog/data/syslog-0/00000000000000000000.log

Wazuh reports:

"Analyzing file: '/opt/docker/rsyslog/data/syslog-0/00000000000000000000.log'"

However:

• I do not see any alerts in the dashboard

• I do not see meaningful entries in archives

Given this setup, I now suspect two possible issues:

1. The file I configured is a Kafka segment file, not a plain syslog file

2. The file is physically located on a different host ("spielwiese"), not on the Wazuh manager ("siem01")

Could you please confirm:

1. Is it supported to use Kafka segment files as a localfile source in Wazuh?

2. If not, would the correct approach be to consume the Kafka topic into a plain-text log file first and then let Wazuh monitor that file?

3. Alternatively, would it be better to forward logs directly from rsyslog on "spielwiese" to the Wazuh manager on "siem01" via syslog?

Thank you again for your help!

[exe]

Here is what the folder looks like now if that helps:

root@spielwiese:/opt/docker/rsyslog/data/syslog-0# ls -l
total 504004
-rw-r--r-- 1 spielwieseadmin spielwieseadmin    822576 Apr  8 14:05 00000000000004596285.index
-rw-r--r-- 1 spielwieseadmin spielwieseadmin 459398376 Apr  8 14:05 00000000000004596285.log
-rw-r--r-- 1 spielwieseadmin spielwieseadmin        10 Apr  1 14:05 00000000000004596285.snapshot
-rw-r--r-- 1 spielwieseadmin spielwieseadmin   1138464 Apr  8 14:05 00000000000004596285.timeindex
-rw-r--r-- 1 spielwieseadmin spielwieseadmin        10 Apr  4 22:59 00000000000005071860.snapshot
-rw-r--r-- 1 spielwieseadmin spielwieseadmin  10485760 Apr  9 09:55 00000000000005621348.index
-rw-r--r-- 1 spielwieseadmin spielwieseadmin  54472982 Apr  9 09:56 00000000000005621348.log
-rw-r--r-- 1 spielwieseadmin spielwieseadmin        10 Apr  8 14:05 00000000000005621348.snapshot
-rw-r--r-- 1 spielwieseadmin spielwieseadmin  10485756 Apr  9 09:55 00000000000005621348.timeindex
-rw-r--r-- 1 spielwieseadmin spielwieseadmin        26 Apr  8 14:05 leader-epoch-checkpoint
-rw-r--r-- 1 spielwieseadmin spielwieseadmin        43 Feb 25 13:05 partition.metadata

[exe]

To add to this, we are also implementing Grafana and the time (somehow) needs kafka, thats why we thought it would be the best move to save time and ressources to js use that as well.

exe schrieb am Donnerstag, 9. April 2026 um 10:08:52 UTC+2: