Index › Traffic Classification
Revision Guide · Certified Next-Generation Firewall (NGFW) Engineer

Traffic Classification

← Back to full guide index

~3 min read
Prerequisites: Foundations — understand single-pass architecture before these three classification engines.

App-ID 03

NGFWPrisma AccessNo license required

Learning objectives

  • Explain why App-ID classifies by signature/decoder/heuristic instead of trusting port numbers
  • Describe the order of operations App-ID follows within a single session (policy match → signature → decryption → decoder → heuristic)
  • Identify the operational risk of new App-IDs shipping in content updates against broad "allow any application" rules

App-ID is Palo Alto's patented traffic classification engine. It determines what application is actually running — regardless of port, protocol, or evasive encryption (SSH/SSL) — rather than trusting the port number.

Why

Attackers and legitimate apps alike hop ports or hide inside allowed protocols (e.g. instant messaging tunneled over HTTP). Port-based rules can't distinguish "port 443 web browsing" from "port 443 BitTorrent."

How

Layered classification: (1) traffic first hits Security policy; (2) application signatures identify the app and whether it's on a non-standard port; (3) if SSL/SSH is detected and a decryption rule matches, the session is decrypted and signatures are re-applied on plaintext; (4) protocol decoders validate conformance and detect apps tunneling inside another protocol; (5) for evasive traffic that defeats signatures, heuristics/behavioral analysis makes the final call. Once identified, policy decides: block, allow-and-scan, restrict features, or apply QoS.
App-ID classification flow from policy match through signatures, decryption, decoders, and heuristics.
App-ID classification flow from policy match through signatures, decryption, decoders, and heuristics.

Pros

  • Sees through port-hopping and protocol tunneling that port-based ACLs miss
  • No separate license — core to every NGFW
  • Feeds Policy Optimizer, which finds port-based rules you can safely convert to App-ID rules

Cons

  • New App-IDs ship in content updates — existing "allow all apps" rules can silently start (or stop) matching new traffic, so you must review new App-ID impact each release
  • Custom/internal apps need manual App-ID objects or they show up as "unknown-tcp/udp"
  • Heuristic identification for very evasive apps is probabilistic, not exact

Exam Trap

App-ID re-evaluation on decryption is often missed: a session first classified as "unknown" or as the wrapper protocol can be reclassified mid-session once SSL/SSH decryption exposes the real application, and Security Policy is re-checked against the new App-ID — the exam expects you to know classification isn't necessarily final at session start.

Self-check: App-ID
Q1. A vendor's internal application isn't in Palo Alto's App-ID signature database. What happens to it in Security Policy and traffic logs by default?
A: It shows up as unknown-tcp or unknown-udp until you create a custom App-ID object (or application override) for it — port-based rules alone won't give it a proper identity.
Q2. After a content update ships new App-IDs, a previously-working "allow any application" rule starts blocking traffic that used to pass. Why?
A: The traffic is now matched by a newly-introduced, more specific App-ID that a different, more restrictive rule higher in the rulebase catches — this is why Palo Alto recommends reviewing new App-ID impact before installing each content release.

Source: ngfw/administration/app-id/app-id-overview

User-ID 04

Learning objectives

  • List the identity sources User-ID can build its IP-to-username mapping from
  • Explain why shared/NAT'd IPs (Citrix, proxies) require special handling
  • Describe how Security rules reference users/groups once User-ID is populated

User-ID maps network activity to an actual user identity instead of just an IP address, by pulling from directories (AD/LDAP), authentication logs, captive portal, GlobalProtect, and terminal server agents.

Why

An IP address doesn't tell you who did something — DHCP leases change, users share machines, and incident response needs "which person" not "which socket." Effective policy and forensics both need identity.

How

The firewall builds an IP-address-to-username map from sources like domain controller security logs, LDAP/AD group lookups, Terminal Server (Citrix/RDP) agents, captive-portal authentication, and GlobalProtect. Security rules can then reference users or AD groups directly ("allow Finance-group to use Concur").
Identity sources feeding the User-ID IP-to-username table and user-based policy.
Identity sources feeding the User-ID IP-to-username table and user-based policy.

Pros

  • Policy and logs are attributable to people, drastically speeding incident response
  • Works with existing AD/LDAP — no separate identity store to maintain
  • Mappings can be shared across virtual systems via a "User-ID hub"

Cons

  • Depends on correct agent placement/permissions on domain controllers — misconfiguration causes stale or wrong mappings
  • Shared/NAT'd IPs (Citrix, proxies) need special handling (Terminal Server agent) or mappings become unreliable
  • Large environments need a deliberate "large-scale User-ID" design, not just default settings

Exam Trap

User-ID mappings are IP-based and time-limited — a stale mapping (e.g. a DHCP lease reassigned to a different user) will misattribute traffic until it times out or is refreshed, so User-ID accuracy depends on mapping timeout tuning, not just agent deployment.

Self-check: User-ID
Q1. Why can't a Citrix/RDP terminal server environment rely on standard domain-controller-log-based User-ID mapping alone?
A: Many users share the same source IP (the terminal server's IP), so a plain IP-to-username map can't distinguish them — a Terminal Server (Citrix/RDP) agent that assigns per-session port ranges per user is required.
Q2. Can two virtual systems on the same firewall share User-ID mappings?
A: Yes — mappings can be shared across vsys via a "User-ID hub" vsys, rather than each vsys independently collecting the same identity data.

Source: ngfw/administration/user-id

Content-ID 05

Learning objectives

  • Explain why Content-ID runs after App-ID/User-ID in the classification pipeline
  • List the services Content-ID drives (Threat Prevention, URL Filtering, file/data filtering, DNS analysis)
  • Identify which of Content-ID's capabilities are free vs. subscription-gated

Content-ID is the stream-based content-inspection engine that runs threat prevention, URL filtering, file/data-filtering, and DNS-based protections on the already-classified traffic — in real time, without waiting for the whole file to buffer.

Why

Knowing "this is Dropbox traffic from Bob" isn't enough — you also need to know if the payload contains malware, exploits, sensitive data, or a malicious URL. Content-ID supplies that content-level inspection layer.

How

Once App-ID/User-ID classify a session, Content-ID applies IPS signatures, antivirus, anti-spyware/C2 detection, URL categorization, file-type/data filtering, and DNS analysis to the stream, using uniform threat/content signatures updated via dynamic content updates.
Content-ID applies parallel content and threat checks to classified traffic before a verdict.
Content-ID applies parallel content and threat checks to classified traffic before a verdict.

Pros

  • Stream-based scanning avoids the latency of full file buffering
  • One engine drives Threat Prevention, URL Filtering, and DLP-style data filtering consistently
  • Signature/content updates are centrally managed and pushed on a schedule you control

Cons

  • Most of Content-ID's real power (Threat Prevention, URL Filtering, DNS Security) is subscription-gated
  • Signature-based detection still needs WildFire/ML add-ons to catch genuinely novel malware

Exam Trap

Content-ID inspects the stream in real time, but it can only see what App-ID has decrypted for it — if a decryption policy exempts a category (e.g. banking), Content-ID's threat/URL/file inspection is blind to that traffic regardless of how the Content-ID profiles themselves are configured.

Self-check: Content-ID
Q1. Why does Content-ID run stream-based inspection instead of buffering the whole file first?
A: Buffering the entire file before scanning would add significant latency; stream-based inspection lets Content-ID scan and act on content as it flows, avoiding that delay while still applying threat/content signatures.
Q2. A firewall has Threat Prevention enabled but no WildFire subscription. What's the practical gap?
A: Threat Prevention catches known malware/exploits via signatures, but genuinely novel (zero-day) files won't be sandboxed/detonated for a behavioral verdict — that requires WildFire.

Source: ngfw/administration/content-id

Module Quiz

1. An engineer reviews Traffic logs and finds sessions for a custom internal application with no matching App-ID signature. Which application value will the firewall assign by default?

Unrecognized traffic that was actually allowed through and evaluated is logged as unknown-tcp/unknown-udp until a custom App-ID object or Application Override is created; not-applicable is reserved for sessions denied before an application match could be performed.

2. A user is running an instant-messaging application deliberately tunneled inside HTTP to evade port-based controls. Which App-ID classification mechanism is responsible for identifying the true application in that case?

Protocol decoders validate protocol conformance and are specifically designed to detect applications tunneling inside another allowed protocol.

3. A session is initially classified as ssl by App-ID. Partway through the session, the firewall applies a Decryption policy rule and begins decrypting the traffic. What happens to the App-ID classification at that point?

Once decryption exposes plaintext, App-ID re-applies signatures against the newly-visible content and updates the classification, which is why decryption materially improves App-ID accuracy.

4. Multiple users share a single source IP address on a Citrix XenApp/RDP terminal server, and User-ID mappings are coming back ambiguous. Which identity source should the engineer deploy to resolve this?

Because many users share one source IP on a terminal server, the Terminal Server agent allocates a distinct source port range per user session so mappings stay unambiguous.

5. Which two of the following are valid, commonly used methods for a Palo Alto Networks firewall to collect User-ID mapping information? (Choose two.)

The Windows User-ID agent and the XML API are both valid mapping-collection methods (along with GlobalProtect, syslog parsing, and server monitoring). External dynamic lists and dynamic user groups are policy objects, not mapping sources.

6. A host is reassigned a new DHCP lease, but the firewall continues attributing its traffic to the previous user for several minutes. What is the underlying cause?

User-ID mappings are IP-based and time-limited; a stale entry persists and continues to misattribute traffic until it times out or is refreshed by the mapping source.

7. Content-ID inspects traffic as a continuous stream rather than buffering an entire file before scanning it. What is the primary operational benefit of this design?

Stream-based scanning acts on data as it flows through the dataplane, avoiding the latency of full-file buffering that some competing engines require.

8. A Decryption policy rule exempts traffic to banking and healthcare URL categories from SSL decryption for compliance reasons. What is the effect on Content-ID's Threat Prevention and URL Filtering inspection for that exempted traffic?

Content-ID can only inspect what has actually been decrypted; decryption exemptions intentionally create inspection blind spots as a documented trade-off for privacy/compliance.

9. A firewall has a Threat Prevention license but not WildFire. A genuinely novel, never-before-seen executable crosses the firewall. What capability gap results?

Threat Prevention covers known signatures (AV, IPS, anti-spyware); WildFire is specifically what adds cloud sandbox detonation and a verdict for files with no existing signature.
← FoundationsEncrypted Traffic →