Forum Discussion
Palo Alto Global Protect Logs Missing Most information
Hi all,
I've integrated Palo Firewall with MS Sentinel.
For most log type (Traffic, Threat, System), everything is working fine.
But for GlobalProtect log type, it's missing almost all valuable values (no username, authentication status (failed or success), Portal Name, Gateway Name, etc...
I used to following URL to defines CEF format.
https://github.com/pemontto/Palo-Alto-CEF/blob/master/10.0/globalprotect.txt
PS: PANOS version 11.x
Any idea ??
Regards,
HA
- HA13029
Take a look at this;
https://live.paloaltonetworks.com/t5/globalprotect-discussions/pan-os-9-1-globalprotect-cef-format/m-p/378425
Looks like the GP CEF format needs a dummy field to have the required 7.
Stumbled across the info here;
https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/PaloAlto-PAN-OS/Data%20Connectors/readme.md
"Modify the default CEF header format to make sure we always have 7 fields in CEF header as Sentinel log analytics agent can only parse fixed header (7 fields in header) a. > For example, log types “Global Protect” have only 6 fields, and SCTP only have 5 fields in the default configuration. We can introduce dummy fields to make sure we have 7 fields"
Haven't made the change on our side yet, so can't confirm this is the smoking gun, but it looks promising.
6 Replies
Hi All,
I am facing an issue in Global protect VPN logs, other logs from palo alto is coming through CEF, but Global protect is throug syslog and it is storing in syslog table and developing a parsing and developing a use cases is a pain full now, as per my understanding Global protect must support CEF formatHi
My custom log CEF format is the following if it can help you...
CEF:0|Palo Alto Networks|PAN-OS|$sender_sw_version|$type|$subtype|1|rt=$receive_time PanOSDeviceSN=$serial PanOSLogTimeStamp=$time_generated PanOSVirtualSystem=$vsys PanOSEventID=$eventid PanOSStage=$stage PanOSAuthMethod=$auth_method PanOSTunnelType=$tunnel_type PanOSSourceUserName=$srcuser PanOSSourceRegion=$srcregion PanOSEndpointDeviceName=$machinename PanOSPublicIPv4=$public_ip PanOSPublicIPv6=$public_ipv6 PanOSPrivateIPv4=$private_ip PanOSPrivateIPv6=$private_ipv6 PanOSHostID=$hostid PanOSDeviceSN=$serialnumber PanOSGlobalProtectClientVersion=$client_ver PanOSEndpointOSType=$client_os PanOSEndpointOSVersion=$client_os_ver PanOSCountOfRepeats=$repeatcnt PanOSQuarantineReason=$reason PanOSConnectionError=$error PanOSDescription=$opaque PanOSEventStatus=$status PanOSGPGatewayLocation=$location PanOSLoginDuration=$login_duration PanOSConnectionMethod=$connect_method PanOSConnectionErrorID=$error_code PanOSPortal=$portal PanOSSequenceNo=$seqno PanOSActionFlags=$actionflags PanOSTimeGeneratedHighResolution=$high_res_timestamp PanOSGatewaySelectionType=$selection_type PanOSSSLResponseTime=$response_time PanOSGatewayPriority=$priority PanOSAttemptedGateways=$attempted_gateways PanOSGateway=$gateway
Ingestion into Sentinel is working fine (stored into CEF Table).
Regards,
HA
- HA
Did you ever find an answer to this? We are seeing the same thing.
Confirmed character count and no oddities with character returns with copy/pasting.- Hi,
No chance to get an answer....
What I can say is the traffic is correctly parsed by another log solution (Wazuh).
It would be nice to get parsed correctly by Sentinel too...
Regards,
HA- HA13029
Take a look at this;
https://live.paloaltonetworks.com/t5/globalprotect-discussions/pan-os-9-1-globalprotect-cef-format/m-p/378425
Looks like the GP CEF format needs a dummy field to have the required 7.
Stumbled across the info here;
https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/PaloAlto-PAN-OS/Data%20Connectors/readme.md
"Modify the default CEF header format to make sure we always have 7 fields in CEF header as Sentinel log analytics agent can only parse fixed header (7 fields in header) a. > For example, log types “Global Protect” have only 6 fields, and SCTP only have 5 fields in the default configuration. We can introduce dummy fields to make sure we have 7 fields"
Haven't made the change on our side yet, so can't confirm this is the smoking gun, but it looks promising.
