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.