Security Onion 3 suricata logs

[Charles Wilkerson]

Hello,

Has anyone been successful sending Security Onion 3 suricata logs to Wazuh? In my ossec.conf file on SO3 I added the following lines:

 <localfile>
    <log_format>syslog</log_format>
    <location>/nsm/zeek/logs/current/*.*</location>
  </localfile>


  <!-- SO3 rotates Suricata logs into timestamped files: eve-YYYY-MM-DD-HH:MM.j>
     The wildcard path captures all current and future rotation files automatic>
     Confirmed path: /nsm/suricata/eve-*.json -->
  <localfile>
    <log_format>json</log_format>
    <location>/nsm/suricata/eve-*.json</location>
    <label key="suricata.node">security-onion-3</label>
    <label key="suricata.source">so3-suricata</label>
  </localfile>

Zeek logs are showing in Wazuh but suricata is not. Any help with this is greatly appreciated.

[Bony V John]

Hi,

Please allow me some time, I'm working on this and will get back to you with an update as soon as possible.

[Bony V John]

Hi,

From the shared details, the <localfile> configuration looks fine. Please ensure that the file path mentioned in the <location> tag is the complete file path.

On the Wazuh agent, check whether the log file is being monitored properly:

cat /var/ossec/logs/ossec.log | grep -iE "Analyzing file"

After running the above command, if the log file is being monitored, it should show output similar to:

2026/05/18 09:23:28 wazuh-logcollector: INFO: (1950): Analyzing file: '/var/ossec/logs/active-responses.log'.
2026/05/18 09:23:28 wazuh-logcollector: INFO: (1950): Analyzing file: '/var/log/firewall1.log'.
2026/05/18 09:23:28 wazuh-logcollector: INFO: (1950): Analyzing file: '/var/log/firewall2.log'.

In your case, it should also show the /nsm/suricata/eve-*.json file path in the output.

If it is not showing, then check whether there are any error or warning logs:

cat /var/ossec/logs/ossec.log |  grep -iE "error|warn"

If there are any errors, please share the full output of the above commands with us for further analysis.

If there are no errors and the logs show that the file is being analyzed, then the next step is to verify whether the logs are reaching the Wazuh manager.

For that, we need to enable archives.json logging on the Wazuh manager. By default, it is disabled.

This helps confirm whether the events are being ingested into the Wazuh manager.

Note: - When archives.json logging is enabled, Wazuh will start logging all raw events ingested by the manager, which can significantly increase disk usage. After troubleshooting, please disable it again to avoid unnecessary disk consumption.

For taking logs from archives.json, first you need to enable log_all_json on Wazuh manager.
1. Enable logall_json on Wazuh Manager
Update the ossec.conf file on the Wazuh manager to enable logall_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.

If the command returns logs, it confirms that the events are being ingested into the Wazuh manager for analysis.

4. Disable logall_json

After collecting the logs, disable logall_json in the ossec.conf file to avoid excessive disk usage.

Please share a sample log collected from archives.json. This will help verify whether the logs match the default Wazuh decoders and rules or whether custom decoders and rules are required.

Also, please share the Wazuh manager /var/ossec/logs/ossec.log file so we can check whether there are any analysis or ingestion errors on the manager side.

You can also refer to the Wazuh documentation for creating custom decoders and rules.

[Charles Wilkerson]

Thank you. I have attached the output that you asked me to run.

--
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/tQ72FfpnKdk/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/c3935276-8619-4402-878f-bf9bd258e21bn%40googlegroups.com.

[Bony V John]

Hi,

From the shared details, there does not seem to be any error on the agent side related to monitoring. I replicated the same configuration on my end, and it is working fine. I have attached a screenshot for your reference.

Could you please follow the steps I shared earlier to check the archives.json file and verify whether the events are being ingested into the Wazuh manager?

This will help us confirm whether the events are reaching the manager. If they are being ingested, please share the sample logs with us so we can test them on our end and confirm whether any default rules are triggering for those events.

Also, please share some sample logs from the /nsm/suricata/eve-*.json file. Using those logs, we can verify the decoder and rules more accurately.