Integration of Juniper Firewall and Shopos Firewall in Wazuh

[Tengku Arya Saputra]

Hi team,

I'm having an issue. I've already integrated it into ossec.conf on Wazuh

<!-- Juniper Firewall -->

<remote>

<connection>syslog</connection>

<port>514</port>

<protocol>udp</protocol>

<allowed-ips>xxx.xx.xx.xxx</allowed-ips>

</remote>

<!-- Sophos Firewall -->

<remote>

<connection>syslog</connection>

<port>514</port>

<protocol>udp</protocol>

<allowed-ips>xx.xxx.x.xxx</allowed-ips>

</remote>

I’ve already integrated both, but they aren’t showing up in my Wazuh dashboard under Threat Intelligence... Are there any relevant decoders or rules? I haven’t found anything online.

[Olamilekan Abdullateef Ajani]

Hello,

One thing I noticed first is that you currently have two separate <remote> syslog blocks using the same UDP port (514). You should not define multiple syslog listeners on the same port like that. You can instead use a single <remote> block and allow both source IPs.

Were you able to verify the logs are reaching the Wazuh manager itself? We can also run TCPdump utility on  the manager, to capture events related to port 514 if the events are being seen on the manager. tcpdump -i any port 514.
Ref: https://wazuh.com/blog/monitoring-network-devices/

Also, even if the logs are reaching Wazuh correctly, they will not automatically appear in the Discover dashboard or Threat Intelligence section unless the logs are properly decoded and matched by rules.

For Juniper and Sophos, Wazuh does not provide complete native coverage for every log type out of the box, some logs may not get decoded, which explains the issue here. So custom decoders and rules are required.

What I would advise is to verify whether the logs are arriving at all by checking:

/var/ossec/logs/archives/archives.json

You can enable archives by following the prompt below:

Edit the /var/ossec/etc/ossec.conf file.
<ossec_config>
  <global>
    <logall>yes</logall>
    <logall_json>yes</logall_json>

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

cat /var/ossec/logs/archives/archives.json | grep "part of your log"

Verify that you have the logs, then disable archiving by setting the values to "no." If you don't, then the logs are not being captured, and you may need to test the connection and review the source entities.

If the logs are present there, then the issue is most likely decoder/rule-related rather than ingestion itself.

Please let me know what you find.

[Tengku Arya Saputra]

I have already configured it as follows:

  <remote>
    <connection>syslog</connection>
    <port>514</port>
    <protocol>udp</protocol>
    <allowed-ips>xxx.xx.xx.xxx</allowed-ips>

    <allowed-ips>xx.xxx.x.xxx</allowed-ips>
  </remote>


Now, the main issue is that I haven’t configured the decoder or the rules yet,

and I ran `cat /var/ossec/logs/archives/archives.json | grep “xx.xxx.1.xxx”`

root@xxxx:/var/ossec/etc# cat /var/ossec/logs/archives/archives.json | grep "xx.xxx.1.xxx"
{"timestamp":"2026-05-19T22:44:48.060+0700","agent":{"id":"000","name":"svr-waz-prd"},"manager":{"name":"svr-waz-prd"},"id":"1779205488.846203021","full_log":"1 2026-05-19T22:44:36.713+07:00 FW.JUN.DCS - - - - last message repeated 16 times","decoder":{},"location":"xx.xxx.1.xxx"}
{"timestamp":"2026-05-19T22:45:00.848+0700","agent":{"id":"000","name":"svr-waz-prd"},"manager":{"name":"svr-waz-prd"},"id":"1779205500.846322788","full_log":"1 2026-05-19T22:44:51.714+07:00 FW.JUN.DCS - - - - last message repeated 2 times","decoder":{},"location":"xx.xxx.1.xxx"}
{"timestamp":"2026-05-19T22:45:00.849+0700","agent":{"id":"000","name":"svr-waz-prd"},"manager":{"name":"svr-waz-prd"},"id":"1779205500.846322788","full_log":"1 2026-05-19T22:45:00.829+07:00 FW.JUN.DCS /usr/sbin/cron 35155 - - (root) CMD (newsyslog -X)","decoder":{},"location":"xx.xxx.1.xxx"}
{"timestamp":"2026-05-19T22:45:00.849+0700","agent":{"id":"000","name":"svr-waz-prd"},"manager":{"name":"svr-waz-prd"},"id":"1779205500.846322788","full_log":"1 2026-05-19T22:45:00.829+07:00 FW.JUN.DCS /usr/sbin/cron 35156 - - (root) CMD (   /usr/libexec/atrun)","decoder":{},"location":"xx.xxx.1.xxx"}
{"timestamp":"2026-05-19T22:45:06.729+0700","agent":{"id":"000","name":"svr-waz-prd"},"manager":{"name":"svr-waz-prd"},"id":"1779205506.846322788","full_log":"1 2026-05-19T22:45:06.714+07:00 FW.JUN.DCS /kernel - - - ifl_pfestat_add_async_sync_dependency: No dependency for this ifl","decoder":{},"location":"xx.xxx.1.xxx"}
{"timestamp":"2026-05-19T22:45:18.062+0700","agent":{"id":"000","name":"svr-waz-prd"},"manager":{"name":"svr-waz-prd"},"id":"1779205518.846323069","full_log":"1 2026-05-19T22:45:06.714+07:00 FW.JUN.DCS /kernel - - - ifl_pfestat_add_async_sync_dependency: No dependency for this ifl","decoder":{},"location":"xx.xxx.1.xxx"}

This confirms that the log has been added to the Wazuh archive, but here’s my point.

Can you tell me about the decoders and rules used by Juniper and Shopos? 

[Olamilekan Abdullateef Ajani]

Hello,

I see that you can see logs. But we need to clarify a few points before moving ahead.

I found decoders and rules for Juniper and Sophos firewalls for your reference below, you can check them out. They are already bundled out of the box in your Wazuh manager, so there should not be an issue matching logs except in some rare occasions.
https://github.com/wazuh/wazuh-ruleset/blob/master/decoders/0490-junos_decoders.xml

https://github.com/wazuh/wazuh/blob/master/ruleset/decoders/0510-sophos_fw_decoders.xml

That said, following what you said regarding this being a firewall, the logs I expect are not what you shared, firewall logs would typically be traffic logs involving artifacts like IP fields, URLs, traffic flow, etc.

Example log flow for Juniper:
Sep 23 18:17:09 192.168.1.1 junos-flow: 2017-09-23T18:17:08.717Z sis-srx-ABN-01 RT_FLOW - RT_FLOW_SESSION_CREATE [ju...@2636.1.1.1.2.39 source-address="192.168.1.1" source-port="1080" destination-address="192.168.1.2" destination-port="8010" service-name="icmp" nat-source-address="192.168.0.1" nat-source-port="1008" nat-destination-address="192.168.0.2" nat-destination-port="8001" src-nat-rule-name="None" dst-nat-rule-name="None" protocol-id="1" policy-name="Templ-Firewall-monitoring" source-zone-name="untrust" destination-zone-name="trust" session-id-32="8xxx1" username="unauthenticated-user" roles="N/A" packet-incoming-interface="intf0.0" application="UNKNOWN"

and for sophos:
device="SFW" date=2019-10-09 time=17:19:06 timezone="+08" device_name="XG210" device_id=AAAAAAAA1234567 log_id=010101010101 log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" status="Allow" priority=Information duration=0 fw_rule_id=22 policy_type=1 user_name="" user_gp="" iap=0 ips_policy_id=9 appfilter_policy_id=0 application="DNS" application_risk=1 application_technology="Network Protocol" application_category="Infrastructure" in_interface="Port3" out_interface="Port2" src_mac=11:22:aa:bb:22:11 src_ip=11.22.33.44 src_country_code=R1 dst_ip=8.8.8.8 dst_country_code=USA protocol="UDP" src_port=60778 dst_port=53 sent_pkts=0  recv_pkts=0 sent_bytes=0 recv_bytes=0 tran_src_ip=11.22.33.44 tran_src_port=0 tran_dst_ip= tran_dst_port=0 srczonetype="DMZ" srczone="DMZ" dstzonetype="WAN" dstzone="WAN" dir_disp="" connevent="Start" connid="17709984" vconnid="" hb_health="No Heartbeat" message="" appresolvedby="Signature"

This is not what you shared, so please look further and ensure you ticked the right boxes, which ensures those logs are to be forwarded to Wazuh for decoding.

You can also refer to the blogs below as a reference:
https://moizuddinrafay.medium.com/sophos-firewall-integration-with-wazuh-siem-49fbda67f73b
https://wazuh.com/blog/monitoring-network-devices/
https://github.com/youngsecurity/Wazuh-Sophos-SOC

To learn more about decoders and rules, you can also refer to the documentation below:
https://wazuh.com/blog/creating-decoders-and-rules-from-scratch/
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/decoders.html
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html

With that, if after review, you still need me to assist in creating specific decoders for the logs you shared, please let me know. I just want us to be sure we are working with the right logs.

Regards,

[Tengku Arya Saputra]

I have already implemented these Junos decoders

https://github.com/wazuh/wazuh-ruleset/blob/master/decoders/0490-junos_decoders.xml

and the Junos rules are already available in Wazuh
https://blackhole.nmrc.org/code-testing/sast-testing/-/raw/da92e2c09b412b4dd5f62fe2b45173b42eec64f1/wazuh-master/ruleset/rules/0640-junos_rules.xml

but no logs appear in the Wazuh indexer/dashboard

I have already restarted the indexer, manager, etc.

Is there something wrong with this?

[Olamilekan Abdullateef Ajani]

Hello,

There are no problems with your setup. What you experience usually means, the actual traffic logs are not being captured. Like the example I shared is similar to what you should be seeing in the archives file. The key problem here is wrong log type being forwarded by your appliance.
What you need to do is verify the actual log format being sent by the firewall. The ones you shared are more like cron logs and kernel/system logs and they are not Juniper security flow/session logs. You need to review this from the source and confirm the firewall is forwarding: RT_FLOW logs, security policy logs, session create/close logs, traffic logs.

Check the archives.json for actual traffic logs, example: grep RT_FLOW /var/ossec/logs/archives/archives.json

Or for fields like  junos-flow, SFW, SOPHOS,. some of these should get a hit.

If nothing appears, the firewall is not forwarding the correct log category. So you need to review the sophos firewall and juniper log configuration again.

Please let me know what you find. You can also share the syslog configuration on those appliances.

Regards

[Olamilekan Abdullateef Ajani]

Hello,

There are no problems with your setup. What you experience usually means, the actual traffic logs are not being captured. Like the example I shared is similar to what you should be seeing in the archives file. The key problem here is wrong log type being forwarded by your appliance.
What you need to do is verify the actual log format being sent by the firewall. The ones you shared are more like cron logs and kernel/system logs and they are not Juniper security flow/session logs. You need to review this from the source and confirm the firewall is forwarding: RT_FLOW logs, security policy logs, session create/close logs, traffic logs.

Check the archives.json for actual traffic logs, example: grep RT_FLOW /var/ossec/logs/archives/archives.json

Or for fields like  junos-flow, SFW, SOPHOS,. some of these should get a hit.

If nothing appears, the firewall is not forwarding the correct log category. So you need to review the sophos firewall and juniper log configuration again.

Please let me know what you find. You can also share the syslog configuration on those appliances.

Regards