What Are Applications and Services?

[kiwi]

Let's delve into the intriguing world of applications and services and explore how they interact. Picture it like this: you've got your applications and services, each playing a unique role in the cybersecurity orchestra. Now, let's break down the initial query: "What's the deal with applications and services, and how do they mingle?"

I'll try to illustrate the explanations provided with some practical examples.

Concept 1

Alright, so imagine a service on your Palo Alto Networks firewall as the guardian of TCP or UDP ports – classic firewall vibes. It's all about saying, "Hey, this port is open, that one's closed," without peeking beyond Layer 4.

Concept 2:

Applications take things up a notch. They're the rockstars of the Palo Alto Networks next-gen firewall, rocking Layer 7 inspection. They don't just settle for knowing which port is doing what; they dive deep, identifying the actual application in the data flow. It's like catching an imposter – if a session labeled as DNS suddenly throws an SQL query curveball, the firewall steps in and says, "Hold up, that's not normal!" and blocks it.

The two concepts above can be used in a variety of different ways, depending on the need of the administrator. Below, you will see four security policies that all do basically the same thing, but each in a different way.

For the following examples, each policy should be considered standalone in its own rule base as a normal policy is matched top to bottom, first hit, first serve.

1. 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
2. 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
3. An SQL packet sent over TCP port 80 will be allowed by policy #1, #2
   • none of the policies include SQL as an application, but policy #2 checks for a valid service port
4. 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

Sorting the Good from the Bad

Now, let's talk strategy. What's the winning play? Well, the recommendation is to typically roll with a lineup of applications (or an application filter) with services set to application default. Why? Because it not only slams the door on unnecessary ports but also keeps applications in check with normal port behavior. Alternatively, you can spice things up with a policy combo – some applications and specific services for those rogue non-default port scenarios (looking at you, internal HTTP on TCP port 5000).

Danger Zone: "Any" is a No-Go

But beware! Leaving applications or services (or both!) as 'any' is like playing with fire. Use it cautiously, perhaps during a transition from a different firewall. Picture it as a temporary phase – you create policy right above your 'any' rule, gradually adding identified applications from traffic logs until your sessions are aligned with the new policy. Once the transition is done, wave goodbye to the 'any'.

So there you have it – applications, services, policies, and a cybersecurity infrastructure where adhering to strategic measures within this framework ensures a more secure environment.

Thanks for taking time to read this blog.

Don't forget to hit that Like (thumbs up) button and don't forget to subscribe to the LIVEcommunity Blog.

Thanks @reaper for the original blog !

Stay Secure,
Kiwi out!