Re: Parse Traffic, System, Config log to Wazuh 4.12

[Bony V John]

Hi,

To validate the Syslog forwarding configuration on a Palo Alto device, you can refer to the following official Palo Alto documentation to ensure your setup is correct: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClRxCAK

Before checking the archives.json file on the Wazuh manager, you should confirm whether logs are being received at the network level.

On the Wazuh manager server, run the following command to capture incoming logs from the Palo Alto firewall:

tcpdump -i any src host <network-device-ip> and dst port 514

Replace <network-device-ip> with the actual IP address of your Palo Alto device.

Let it run for a while and monitor if any traffic is captured.
If output is visible, it means the logs are reaching the Wazuh manager.

Note: Ensure that port 514 is open and listening on the Wazuh manager to accept Syslog traffic.

Once log traffic is confirmed, verify the Wazuh manager’s syslog configuration in the ossec.conf file, located at: /var/ossec/etc/ossec.conf

It should look similar to this:  

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>tcp</protocol>
  <allowed-ips>192.168.2.15/24</allowed-ips>
  <local_ip>192.168.2.10</local_ip>
</remote>

allowed-ips: Replace with the IP of your Palo Alto device.

local_ip: Replace with the IP address of your Wazuh manager server.

Ensure the protocol (TCP/UDP) matches on both the Wazuh manager and Palo Alto device configurations.

You can refer this Wazuh syslog configuration documentation for more details.

After confirming both network and configuration-level setup, check if the logs are being ingested:

cat /var/ossec/logs/archives/archives.json | grep -iE "<related string>"

Replace <related string> with a keyword, device name, or IP address related to the Palo Alto device to locate matching logs.  

On Tuesday, July 8, 2025 at 9:20:44 AM UTC+5:30 Yap Toni wrote:

Hi Team,

I'm trying to parse my Paloalto log (Traffic, System, and Config) to Wazuh 4.12.

However, after I check the archive

"tail -f /var/ossec/logs/archives/archives.json | grep alto"

nothing prompt out which means it doesn't accept the log from Palo alto.

I have tried to parse the log to another syslog server. They able to retrieve it.

Please help me. 

Thanks

[Bony V John]

Hi,

In Wazuh, port 1514 is used for agent communication with the Wazuh manager. Wazuh agents use this port to forward their logs.
However, in your case, you're forwarding logs to the Wazuh manager as syslog, so you need to use port 514, which is dedicated for syslog ingestion.

From your tcpdump output, it appears that syslog messages are being forwarded from the IP address 172.18.2.31.

In your current ossec.conf, you've set the <allowed-ips> like this:

<allowed-ips>10.0.0.0/8</allowed-ips>
<allowed-ips>172.16.0.0/12</allowed-ips>
<allowed-ips>192.168.0.0/16</allowed-ips>

Although you're using CIDR blocks, it's best to explicitly specify the sender’s IP if you’re troubleshooting or setting up a more restrictive config. Since your Palo Alto device has the IP 172.18.2.31, you should use:  

<remote>
  <connection>syslog</connection>
  <port>514</port>

  <protocol>udp</protocol>
  <allowed-ips>172.18.2.31/24</allowed-ips>
  <local_ip>172.18.3.111</local_ip>
</remote>

In the above configuration, I have set the <protocol> to udp because, based on your Palo Alto device configuration, it appears that UDP is being used. You must use the same protocol on the Wazuh manager side as configured on the Palo Alto device.  

Note: For syslog connections, only one protocol per <remote> block is allowed. If you want to support both TCP and UDP, you need to create separate <remote> blocks for each.  

I have also set the <allowed-ips> value to the IP address you used in the tcpdump command.
In the <local_ip> field, I assume you've added the correct IP address of your Wazuh manager.  

Ensure there's proper network connectivity between the Wazuh manager server and the Palo Alto device.  

After updating the configuration, restart the Wazuh manager:  

systemctl restart wazuh-manager

Then, wait a few minutes and check the logs in archives.json to confirm log reception:  

cat /var/ossec/logs/archives/archives.json | grep -i "172.18.2.31"

For more details about these configuration tags, please refer to the Wazuh remote configuration documentation.  

On Tuesday, July 8, 2025 at 11:17:38 AM UTC+5:30 Yap Toni wrote:

Hi,

I have added the line:

  <remote>
    <connection>syslog</connection>
    <port>514</port>

    <protocol>udp,tcp</protocol>
    <allowed-ips>10.0.0.0/8</allowed-ips>
    <allowed-ips>172.16.0.0/12</allowed-ips>
    <allowed-ips>192.168.0.0/16</allowed-ips>
    <local_ip>172.18.3.111</local_ip>
  </remote>

But still do not receive the logs.

On Tuesday, July 8, 2025 at 12:24:07 PM UTC+7 Yap Toni wrote:

Hi Bony,

Thank you for replying.

According to wazuh/etc/ossec.conf at main · wazuh/wazuh · GitHub, the port is 1514

  "<remote>
    <connection>secure</connection>
    <port>1514</port>
    <protocol>tcp</protocol>
  </remote>"

And the settings in PAN is:

Name: Wazuh_syslog

Servers Name:  Wazuh_Syslog

Syslog Server: 172.18.3.111

Transport: UDP

Port: 514

Format BSD

Facility: LOG_USER

And when i do the tcp dump, i able to retrieve the log:

tcpdump -i any src host 172.18.2.31 and dst port 514

12:22:28.843733 ens160 In  IP 172.18.2.31.52914 > idtjmmm-waz01.syslog: SYSLOG user.info, length: 705
12:22:28.843833 ens160 In  IP 172.18.2.31.52914 > idtjmmm-waz01.syslog: SYSLOG user.info, length: 708

But when I cat the archives.json, it is empty.

root@waz01:/home/wazuh# cat /var/ossec/logs/archives/archives.json | grep -iE 172.18.2.31
root@waz01:/home/wazuh#

[Bony V John]

Hi,

In Wazuh, there are default rules available for Palo Alto logs, and based on your log format, if it is supported, then the default rules will trigger alerts based on the logs. If your logs have only severity levels such as informational or low, then those alerts will not show on the Wazuh dashboard. This is because, in Wazuh, the rule ID 64501 has only level 2, and by default, Wazuh will not show alerts on the dashboard when a rule is triggered with a rule level below 3. This behavior is controlled by the log_alert_level configuration in the Wazuh manager ossec.conf file.

If you need to trigger alerts on the Wazuh dashboard for informational or low severity logs, then you need to modify the default rules in Wazuh as shown below:

<group name="paloalto,">

  <rule id="64501" level="3" overwrite="yes">
    <if_sid>64500</if_sid>
    <field name="severity" type="pcre2">(?i)^(?:informational|low)$</field>
    <description>Palo Alto $(type): $(severity) event.</description>
  </rule>

<group>

Save the above rule in the local_rules.xml file. We have modified the default rule 64501 using the overwrite attribute and increased the level from 2 to 3 to show alerts on the Wazuh dashboard.

You can refer to the Wazuh default decoder modification documentation for more details.

Also, if you need further assistance, please share the full logs of the event from the archives.json file. You can refer to this Wazuh documentation for enabling the archives.json file.

On Friday, July 11, 2025 at 9:40:57 AM UTC+5:30 Yap Toni wrote:

Hi,

How can I parse all the Palo alto traffic log to Wazuh although it is rule.level 0,1,2?

Thank you

On Wednesday, July 9, 2025 at 7:40:24 AM UTC+7 Yap Toni wrote:

Hi Bony,

Thank you. It seems working fine now.

I added this line in /var/ossec/etc/ossec.conf

  <remote>
    <connection>syslog</connection>
    <port>514</port>
    <protocol>udp</protocol>

    <allowed-ips>paloalto_ip</allowed-ips>
    <local_ip>wazuh_server_ip</local_ip>
  </remote>

Regards,

Toni

[Bony V John]

Hi,

Could you please share the sample logs from the Wazuh archives.json file for this event, so we can test it from our side and assist you better?

For taking logs from archives.json, first you need to enable log_all_json on Wazuh manager.
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.

On Friday, July 11, 2025 at 1:09:18 PM UTC+5:30 Yap Toni wrote:

Hi,

Thank you for the reply. I already able to receive the traffic log to Wazuh.

May I know how to do parse the URL filtering logs as well? I have set the rules, but still unable to show it on dashboard

  <rule id="100014" level="5">
    <decoded_as>paloalto</decoded_as>
    <field name="pa.type">THREAT</field>
    <field name="pa.ctype">url</field>
    <description>Palo Alto URL Filtering: Accessed $(url) (category: $(category)) from $(pa.sip) to $(pa.dip). Action: $(action).</description>
    <group>paloalto,url_filtering,web_monitoring</group>
  </rule>

[Bony V John]

Hi,

Based on the shared log, it seems that you have another child rule with rule ID 100010. I have reviewed the custom rule you shared in the previous thread, and when I compared it with the decoded fields from the shared log, I noticed that you used the <decoded_as> tag instead of the <if_sid> tag to map your custom rule.

In this case, you should use the <if_sid> tag to properly link your custom rule to its parent rule. This ensures that the alert triggers correctly, especially since a default rule is already available in Wazuh for this type of log, and you should use that rule ID as the parent.

I have tested the following updated rule, and it works fine in my environment:  

Updated sample rule:

 <rule id="100614" level="5">
    <if_sid>64501</if_sid>
    <field name="type">THREAT</field>
    <field name="threat_content_type">url</field>
    <description>Palo Alto URL Filtering: Accessed $(url_filename) (category: $(category)) from $(source_address) to $(destination_address). Action: $(action).</description>
    <group>paloalto,url_filtering,web_monitoring</group>
  </rule>

In the above rule:

• I have set 64501 (a default Palo Alto rule) as the parent using <if_sid>.

• If you already have another custom rule (e.g., rule ID 100010) that processes this event, you can use that rule ID instead in <if_sid>.

• I also corrected the field names in both the <field> tags and the <description> to match the decoded log format.

You can refer to the Wazuh rules syntax documentation for more details about writing custom rules.

I have attached a screenshot of my testing for your reference.

On Friday, July 11, 2025 at 2:51:20 PM UTC+5:30 Yap Toni wrote:

Hi,

This is the sample log

{"timestamp":"2025-07-11T09:07:58.480+0000","rule":{"level":3,"description":"[Local] Palo Alto THREAT: informational event.","id":"100010","firedtimes":55353,"mail":false,"groups":["paloalto"]},"agent":{"id":"000","name":"waz01"},"manager":{"name":"waz01"},"id":"1752224878.5335780267","full_log":"Jul 11 16:07:58 PAN-01 1,2025/07/11 16:07:58,1234567890,THREAT,url,2818,2025/07/11 16:07:58,192.168.3.224,203.190.242.211,0.0.0.0,0.0.0.0,Internet Users,local\\inot,,ssl,vsys1,LAN trust,INET2 untrust,ethernet1/2,ethernet1/4,Wazuh_Log_Forwarding,2025/07/11 16:07:58,1378708,1,20041,443,0,0,0xb400,tcp,alert,\"www.detik.com/\",(9999),news,informational,client-to-server,7507834763533584840,0x0, 192.168.0.0-192.168.255.255,Indonesia,,,0,,,0,,,,,,,,0,0,0,0,0,,PAN-01,,,,,0,,0,,N/A,N/A,AppThreat-0-0,0x0,0,4294967295,,\"news,low-risk\",aa2d244b-4924-4bdf-a029-ccd8fb0d33fe,0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0,2025-07-11T16:07:58.457+07:00,,,,encrypted-tunnel,networking,browser-based,4,\"used-by-malware,able-to-transfer-file,has-known-vulnerability,tunnel-other-application,pervasive-use\",,ssl,no,no,,,NonProxyTraffic,,false,0,0,,,,0","predecoder":{"timestamp":"Jul 11 16:07:58","hostname":"PAN-01"},"decoder":{"parent":"paloalto","name":"paloalto"},"data":{"action":"alert","receive_time":"2025/07/11 16:07:58","serial_number":"1234567890","type":"THREAT","threat_content_type":"url","generated_time":"2025/07/11 16:07:58","source_address":"192.168.3.224","destination_address":"203.190.242.211","nat_source_ip":"0.0.0.0","nat_destination_ip":"0.0.0.0","rule_name":"Internet Users","source_user":"local\\inot","application":"ssl","virtual_system":"vsys1","source_zone":"LAN trust","destination_zone":"INET2 untrust","inbound_interface":"ethernet1/2","outbound_interface":"ethernet1/4","log_action":"Wazuh_Log_Forwarding","session_id":"1378708","repeat_count":"1","source_port":"20041","destination_port":"443","nat_source_port":"0","nat_destination_port":"0","flags":"0xb400","ip_protocol":"tcp","url_filename":"\"www.detik.com/\"","threat_id":"(9999)","category":"news","severity":"informational","direction":"client-to-server","sequence_number":"7507834763533584840","action_flags":"0x0","source_location":"192.168.0.0-192.168.255.255","destination_location":"Indonesia","pcap_id":"0","url_index":"0","report_id":"0","device_group_hierarchy_level_1":"0","device_group_hierarchy_level_2":"0","device_group_hierarchy_level_3":"0","device_group_hierarchy_level_4":"0","device_name":"PAN-01","tunnel_id_imsi":"0","parent_session_id":"0","tunnel_type":"N/A","threat_category":"N/A","content_version":"AppThreat-0-0","sctp_association_id":"0","payload_protocol_id":"4294967295","url_category_list":"\"news","rule_uuid":"low-risk\"","http_2_connection":"aa2d244b-4924-4bdf-a029-ccd8fb0d33fe","dynamic_user_group_name":"0","partial_hash":"0","high_resolution_timestamp":"2025-07-11T16:07:58.457+07:00","application_subcategory":"encrypted-tunnel","application_category":"networking","application_technology":"browser-based","application_risk":"4","application_characteristic":"\"used-by-malware","application_container":"able-to-transfer-file","application_saas":"has-known-vulnerability","application_sanctioned_state":"tunnel-other-application"},"location":"172.18.2.31"}