Hey folks, diving into Palo Alto NGFW for the first time and the terminology is throwing me a bit. Coming from other firewalls, the whole "service" vs. "application" distinction seems unique here. I've been mapping it out in a spreadsheet to wrap my head around it, but I'd love a gut-check from the community.
From my tinkering so far:
* A **Service** feels very "traditional firewall" – it's about ports and protocols (TCP/UDP) and maybe ICMP. Think `service-tcp-443` or `service-udp-53`. It's a layer 3/4 thing.
* An **Application** is the modern, Palo Alto magic – it's about identifying the actual software or web app (like `ssl`, `facebook`, `netflix`, or `ms-office365`) regardless of what port it's running on. This is layer 7.
My big "aha!" moment was realizing you can have an application (like `ssh`) running on a non-standard port (not 22), and the App-ID will still catch it. But if you only define a service for port 22, you'd miss that.
So, my practical question: In a security policy, when do you lean on one over the other? Do you still use Services for legacy internal stuff or non-App-ID capable traffic, and Applications for everything else? Would love to see how you all structure your rulebases.
— alex
Data > opinions
You've got the gist. Your policy approach is correct.
Use Services for:
* Legacy internal apps with no App-ID.
* Any custom protocol you define yourself.
* Simple port/protocol rules for non-L7 traffic (e.g., a generic "allow TCP/8443 to server pool").
Use Applications for everything else. The App-ID engine is the primary security control. Build your rules using `application` and then optionally refine with `service` if you need to restrict to a specific port, even for well-known apps. This blocks the app if it tries to jump ports.
Never rely solely on a Service object for a common internet app. Palo Alto's value is in identifying the actual application, not just the port it's using today.
Five nines? Prove it.
Glad you're looking at the spreadsheet. That's the right instinct, because the marketing gloss on "App-ID magic" hides the practical mess.
You can't always use applications for everything else. The App-ID database is a black box, frequently lags behind real-world app updates, and can break legitimate traffic with a signature update. It's not a primary control, it's a heuristic filter with a high false-positive rate on custom or obscure internal apps.
Your SSH example is the trap. Yes, it can catch SSH on port 2222. It can also, and often does, mis-categorize a custom management daemon as SSH because the traffic looks similar. Relying on it means trusting Palo's opaque classification over your own knowledge of your network. Use services for anything you actually understand.
Prove it