What is the difference between applications and services and how do they interact? A service on the Palo Alto Networks firewall, is a TCP or UDP port as it would be defined on a traditional firewall or access list. Read more on LIVEcommunity.
Last week, community member @jdprovine posted an interesting question regarding services and how they interact with applications.
Jdprovine Discussion Post - Services
@BPry and @Raido_Rattameister promptly teamed up and provided a flurry of detailed information to clarify the difference between a 'service' and an 'application'.
I'll try to illustrate the explanations provided with some practical examples:
To start from the beginning, let's first review the original question:
What is the difference between applications and services and how do they interact.
A service on the Palo Alto Networks firewall, is a TCP or UDP port as it would be defined on a traditional firewall or access list. It simply defines which port is open or closed and does not look beyond layer4.
An application is what makes the Palo Alto Networks Next Generation Firewall so powerful: it goes into layer 7 inspection to ascertain which application is active in a data flow and will enforce 'normal' behavior onto it (eg. a session identified as DNS that suddenly send an SQL query is abnormal and will be blocked).
The above 2 concepts can be used in a variety of different ways, depending on the need of the administrator.
Below you will see 4 security policies that all do basically the same thing, but each in a different way.
For the following examples, each policy will be considered as standalone in its own rulebase as normally policy is matched top to bottom, first hit first serve.
a DNS packet sent over UDP port 53 will be allowed by all 4 policies
- this is legitimate traffic and all of the policies match on either the application or the port
a DNS packet sent over TCP port 80 will be allowed by policies #1, #2 and #3 but will be blocked by policy #4
- in rule #4 each application is forced to use it's own port where the other policies simply list which ports or applications are allowed
an SQL packet sent over TCP port 80 will be allowed by policy #2
- none of the policies include SQL as an application, but policy #2 only checks for a valid service port
an HTTP packet sent over TCP port 8888 will only be passed by policy #1
- policy #1 does not enforce any ports so as long as the application requirement is met, the traffic will pass on any port
So what is good and what is bad?
The recommended policy will either be a set of applications (or an application filter) with services set to application-default, as this will not only shut unnecessary ports but will also ensure applications are using normal ports. Or a policy with some applications and a few services, in case an application is expected to use a non-default port (internal http on TCP port 5000 for example)
Leaving applications or services (or worse, both) as 'any' is not recommended and should only be used under strict supervision. It may be necessary to use this type of policy in a transitional period when migrating from a different firewall.
Good practice in this case is to create a second policy right above the one that uses 'any' in services or applications, where all the applications you are able to identify from traffic logs are added gradually. eventually all sessions will start to match the second rule and the original one can be deleted
Lastly, to gain visibility on service, or port, usage by applications rather than just the applications, a custom report may also come in handy:
As usual, I hope this was helpful! Feel free to leave any comments or questions below.
Thanks to @jdprovine, @BPry and @Raido_Rattameister for the inspiration! 😉