Firewall ✓ fields verified against sample logs

Palo Alto PAN-OS Log Fields: Reference With Examples

Published

One comma-separated line per firewall event: a session recorded by a security rule (TRAFFIC), a match on a threat-prevention profile (THREAT), an authentication attempt (AUTHENTICATION) and other log types on the same feed. The field order depends on the log type.

Sample record

1,2024/01/15 09:00:01,007200001111,TRAFFIC,end,2560,2024/01/15 09:00:01,203.0.113.10,10.0.0.100,0.0.0.0,0.0.0.0,allow-web,[email protected],,ssl,vsys1,outside,inside,ethernet1/1,ethernet1/2,traffic-log,2024/01/15 09:00:01,10001,1,52100,443,0,0,0x400000,tcp,allow,5120,2048,3072,30,2024/01/15 09:00:01,0,any,0,1234500001,0x0,,10.0.0.0-10.255.255.255,0,12,18,tcp-fin,0,0,0,0,,PA-VM,from-policy,,,0,,0,,N/A,0,0,0,0,6da2767d-a9ea-5b37-9450-6dd1696bc40a,0,0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,2024-01-15T09:00:01.000+00:00,,,,,,,,,,no,no,0,NonProxyTraffic,
1,2024/01/15 09:05:00,007200001111,TRAFFIC,end,2560,2024/01/15 09:05:00,203.0.113.11,10.0.0.100,0.0.0.0,0.0.0.0,allow-web,[email protected],,web-browsing,vsys1,outside,inside,ethernet1/1,ethernet1/2,traffic-log,2024/01/15 09:05:00,10002,1,60000,80,0,0,0x400000,tcp,allow,2048,1024,1024,10,2024/01/15 09:05:00,0,any,0,1234500002,0x0,,10.0.0.0-10.255.255.255,0,5,5,tcp-fin,0,0,0,0,,PA-VM,from-policy,,,0,,0,,N/A,0,0,0,0,6da2767d-a9ea-5b37-9450-6dd1696bc40a,0,0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,2024-01-15T09:05:00.000+00:00,,,,,,,,,,no,no,0,NonProxyTraffic,
1,2024/01/15 09:10:00,007200001111,AUTHENTICATION,0,2560,2024/01/15 09:10:00,vsys1,203.0.113.50,[email protected],,,auth-policy,1,1001,,auth-log,,,GlobalProtect,auth-success,1,1234500003,0x0,0,0,0,0,,PA-VM,1,,1aaea5f6-31b9-5ea5-ae9f-c8985e6c3186,2024-01-15T09:10:00.000+00:00,,,,,,,,,,,,,

From the LogTriage parser test corpus — synthetic data, no real hosts or users.

Explain this record field by field →

Field reference

Field Type Meaning Why it matters for security
TRAFFICe.g. TRAFFIC log type value (4th comma-separated field) Marks the line as a session record written by a security rule; the addresses, ports, rule name, user, application, byte counts and session end reason follow it. Branch the parser on this value first — after the shared prefix, positions mean different things in each log type.
THREATe.g. THREAT log type value (4th comma-separated field) Marks a threat-prevention match on a session, with the subtype in the next field (`vulnerability` and `virus` in the samples). Where exploit, malware and spyware detections live; the threat name, category, severity and direction sit where a traffic line keeps its byte counts.
AUTHENTICATIONe.g. AUTHENTICATION log type value (4th comma-separated field) An authentication attempt; the sample lines carry the virtual system, source address, user, authentication policy, the requesting service and the result. The feed in which GlobalProtect and captive-portal credential guessing appears.
ende.g. end subtype value (5th field of a TRAFFIC line) The session was logged when it finished; the samples also show `drop` for discarded traffic. Only end-of-session records carry the final byte and packet counts for the connection.
drope.g. drop subtype value (5th field of a TRAFFIC line) The firewall discarded the traffic; in the malicious sample this is a connection to port 22 that matched a deny rule. Many drop records from one source address across distinct destination ports within minutes is port scanning.
allowe.g. allow action value (31st field) The matching security rule permitted the session. An allowed session from the internet to a management port or an unexpected application is an exposure, not noise.
denye.g. deny action value (31st field) The matching security rule blocked the session; the rule that did it is named earlier in the line (`deny-all` in the malicious sample). Read it with the rule name to see whether a specific control or a catch-all rule stopped the traffic.
blocke.g. block action value (31st field of a THREAT line) Threat prevention stopped traffic that matched the signature named later in the line. Profiles set to alert only log the match without stopping the session, so always read the action before assuming a detection was a block.
tcp-fine.g. tcp-fin session end reason value (47th field of a TRAFFIC line) The session closed normally through a TCP FIN exchange. A normal close on suspicious traffic means the connection ran to completion and data moved.
policy-denye.g. policy-deny session end reason value (47th field of a TRAFFIC line) The session ended because a security rule denied it. Separates rule blocks from normal closes when you reconstruct what a source address actually achieved.
not-applicablee.g. not-applicable application value (15th field) App-ID never identified the traffic because the session was discarded before inspection; it appears on the denied session in the malicious sample. On such lines the application tells you nothing — pivot on destination port and rule name instead.
criticale.g. critical severity value (35th field of a THREAT line) Severity carried by the matching signature, the highest of the PAN-OS severity levels. Triage order, but only together with the action value — a critical match that was alerted on was not stopped.
client-to-servere.g. client-to-server direction value (36th field of a THREAT line) Direction of the detected attack; here the client sent the matching content toward the server. Inbound client-to-server hits on a published service are attacks against you; matches in the opposite direction describe content returned to an internal host.
auth-faile.g. auth-fail event value (21st field of an AUTHENTICATION line) The authentication attempt failed; the benign sample shows the successful counterpart, `auth-success`. Repeated failures from one source address, especially for generic names such as `root`, are credential guessing against the VPN.
GlobalProtecte.g. GlobalProtect client/service value (20th field of an AUTHENTICATION line) The service that requested the authentication; both sample authentication lines come from GlobalProtect. Tells you which front door the attempts were aimed at when several authentication paths exist.

Have one of your own records? Paste it into the log line explainer and each field is explained from this table, with times, codes and addresses decoded — in your browser.

What it records

Each line is one event from a Palo Alto Networks firewall, written as comma-separated values with no field names in the line itself — meaning comes from position and from the literal values listed above. The first field is reserved for future use and should be ignored; it is followed by the receive time, the firewall serial number, and then the log type: TRAFFIC, THREAT, AUTHENTICATION and other types such as SYSTEM, CONFIG, HIP-MATCH and GLOBALPROTECT, all arriving on the same syslog feed. The next field is the subtype — end or drop in the samples for traffic, vulnerability and virus for threats.

A TRAFFIC record is the session as the security rule saw it: source and destination address and port before NAT, the NAT addresses and ports, the rule name (allow-web, deny-all), the User-ID user, the App-ID application, the source and destination zones and interfaces, byte and packet counts in each direction, and the session end reason. A THREAT record describes a profile match on a session — the threat name such as SQL Injection - Generic, its category, severity and direction, plus the content release that produced it (AppThreat-0-0 in the sample). An AUTHENTICATION record covers an authentication attempt, with the virtual system, source address, user, authentication policy, the requesting service (GlobalProtect) and the result auth-success or auth-fail.

Where to get it

  • Syslog forwarding. Attach a log forwarding profile to security rules and point it at a syslog server profile; the firewall sends the comma-separated payload behind a syslog header. Threat, authentication and system logs are forwarded through their own profiles or through Device → Log Settings.
  • Panorama. Firewalls forward to Panorama, which can forward on to a SIEM. In that feed the serial number field is how you identify the originating firewall.
  • Web interface. Monitor → Logs shows each log type with its own column set and can export the selected view to CSV for offline work.
  • CLI. show log traffic and the equivalent commands for other log types are useful for spot checks on one firewall during an incident.

Parsing pitfalls

  • Field order is per log type. Field 32 holds total bytes in a traffic line; in the threat lines of the sample it is the URL or file name slot, empty, with the threat name at 33. Branch on the log type before mapping anything.
  • Reserved fields. Several positions are marked for future use, including the first. They hold values (the samples show 1 and 2560) that mean nothing to an investigator.
  • Commas inside values. Threat names, rule names, URLs and custom fields can contain commas, in which case the value is quoted. A naive split(",") shifts every later field on exactly the lines you care about most — use a CSV reader that honours quoting.
  • Location fields are not always places. For private addresses the location appears as an address range, as in 10.0.0.0-10.255.255.255, not a country code.
  • Repeat count. One record can stand for several identical sessions collapsed together, so counting lines undercounts connections.
  • Trailing empties. Lines end with long runs of empty fields and a trailing comma. Do not drop empty trailing fields or index from the end of the line.
  • not-applicable and N/A. Both appear as literal values (application and URL category respectively) and are not nulls.

Detection ideas

  • Credential guessing on the VPN: repeated AUTHENTICATION lines ending in auth-fail from one source address, especially for generic names — the malicious sample shows root failing on GlobalProtect.
  • Detected but not blocked: THREAT lines with severity critical or high whose action is an alert rather than block.
  • Exploit and malware hits: THREAT subtypes vulnerability and virus against internet-facing hosts, pivoting on the threat name to find every host the same signature fired for — the same material the PAN-OS CEF threat-prevention rule works on when the firewall emits CEF instead.
  • Scanning: one source address with many deny or drop traffic records across distinct destination ports in minutes.
  • Follow-on activity from a known-bad source: take the source address of a threat log and list every TRAFFIC record for it; in the malicious sample the address that triggered the SQL injection signature then tries port 22 and fails with session end reason policy-deny.
  • Exfiltration: large bytes-sent counts from one internal host to an external destination it has no history with, on an application that does not match the destination port.

Sending PAN-OS Native CSV to an LLM

One megabyte of this format is about 690,985 tokens on current Claude models and 530,842 on GPT models, measured with the models' own tokenizers — so a gigabyte sent raw to Claude Sonnet 5.5 costs about $1,382 in input tokens alone (prices of 2026-10-24). Estimate your own volume →

Detections and guides for PAN-OS Native CSV

Frequently Asked Questions

Why do my TRAFFIC and THREAT logs disagree at the same field position?
Because PAN-OS uses one comma-separated line format per log type, with a shared prefix and then type-specific fields. In a traffic log the fields after the action are byte and packet counts; in a threat log the same positions hold the URL or file name, the threat name, category, severity and direction. Parse on the log type field first, then apply that type's field list.
How do I tell whether a threat was actually blocked?
Read the action value of the THREAT log together with the session end reason of the matching TRAFFIC log. An action of `block` and a session end reason of `threat` mean the firewall stopped it, while an alert-only action means the signature matched and the traffic was allowed to continue, which is common on profiles left in alert mode.
Which of the timestamps should I use when correlating with other logs?
The samples contain several — the receive time, the generated time, the session start time and, near the end of the line, a high-resolution timestamp written in ISO 8601 with a UTC offset such as `2024-01-15T09:00:01.000+00:00`. The earlier timestamps carry no offset, so use the ISO value where it is present, or normalise the firewall's local time zone before joining feeds.
How do fields get added between PAN-OS releases?
New fields are appended to the end of the line, which is why the sample records end with long runs of commas and a trailing comma. Parsers that assume a fixed field count, or that index from the end of the line, break on upgrade; index from the start and ignore unknown trailing fields.

Analyze a PAN-OS Native CSV file in your browser

The free analyzer detects this format, parses every field above and flags attack patterns — the file never leaves your machine. For threat-intel enrichment and an AI-written incident report, run it through LogTriage.

Open the free analyzer → Analyze your own logs

Investigating something right now? LogTriage checks every address in the file against threat intelligence and writes the incident report: 10 analyses a month free. The incident pack adds the in-depth AI analysis and files up to 100 MB: 25 analyses for $19, one payment, no subscription. Pricing