Palo Alto App-ID - How Does It Work?

If you've ever worked with traditional Layer 4 firewalls, you might be familiar with configuring security policies based on TCP or UDP port numbers. For instance, to allow DNS, you'd create a policy for UDP/53, or for LDAP, a policy for TCP/389.

This approach is normal with firewalls like Cisco ASA. But it's 2024, and Next-Generation Firewalls (NGFWs) have become the standard, offering a more sophisticated way to manage security. Instead of relying solely on port numbers, NGFWs like those from Palo Alto Networks encourage defining security policies based on the actual applications termed 'App-ID'. For example, instead of specifying port numbers, a policy could simply be defined to allow 'DNS' and 'LDAP', focusing on the applications themselves.

Palo Alto App-ID Introduction

Okay, that sounds simple, so why continue reading you may ask? Well, while Palo Alto’s App-ID does work well most of the time, there are nuances that you need to understand. For applications like DNS, NTP, and LDAP, App-ID works very well. However, the most common applications involve SSL or web browsing, typically associated with ports 80 and 443.

Palo Alto provides App-IDs for both SSL and Web-Browsing (called ssl and web-browsing). You might think it’s enough to just allow these two and be done. Not so fast, because if you do that, you will have a lot of angry users come after you for blocking so many websites. The App-IDs named ‘ssl’ and 'web-browsing' will only cover the generic sites like apple.com, bbc.co.uk, and samsung.com, and if you try to access sites like Gmail, Facebook, and Reddit, they will not work because Palo Alto has more specific App-IDs for those sites and treats them as their own applications.

Here, if you search for 'facebook' under applications, you can see a specific App-ID for Facebook. So, if you want to allow access to Facebook, you need to specifically allow this App-ID.

You can also see under the Facebook container, there are individual sub-app-IDs listed. This allows you to fine-tune your policies by allowing or blocking specific actions within the parent App-ID. Please note that this may only work with SSL Decryption because most connections are encrypted HTTPS, so the firewall can't see exactly what's happening inside the HTTPS traffic.

How Does App-ID Work without SSL Decryption?

I mentioned earlier that the majority of websites now use HTTPS, meaning most user connections are encrypted. How, then, does Palo Alto identify a user’s attempt to access Facebook without decrypting the traffic?

Palo Alto can use various methods to try and ‘guess’ which website the client is trying to access. Just like any TCP session, the connection starts with a TCP 3-way handshake. During the handshake, neither the client nor the server indicates anything about Facebook, so the firewall has to allow a few packets for the handshake to complete.

But here it can get slightly complicated because the TCP session uses port numbers; for HTTPS, it would be 443. So, you must have a security policy that allows TCP port 443 but remember, I mentioned at the beginning of the article that we don’t want to use port numbers, right? Yes, of course, but when you allow the App-ID ‘ssl’, the firewall knows it uses TCP/443, so that’s how it allows the TCP handshake. So, if you don’t have a policy that allows ‘ssl’, then the traffic is simply denied.

Back to our Facebook example, after the 3-way handshake completes, the TLS handshake starts. During this handshake, the client hello includes the Server Name Indication (SNI) which might list ‘facebook.com’. This part is not encrypted, so the firewall can see it and potentially block the connection based on the presence of this unencrypted information.

Palo Alto Firewall For Absolute Beginners

In this blog post, we will cover the very basics of Palo Alto firewalls and how to get started. This blog post assumes you have a basic understanding of networking concepts

PacketswitchSuresh Vina

App-ID Traffic Classification

The firewall begins by identifying applications traversing the network using App-ID, which uses up to four techniques to determine the application, regardless of port, protocol, or encryption like SSL and SSH. The process varies depending on the application but generally follows this sequence.

1. Application Signatures - Initially, signatures identify the application by examining unique characteristics and transaction behaviours. This includes checking if the application runs on its default port or a non-standard one, such as using RDP on port 80 instead of its typical port 3389. If allowed by the policy, further analysis is conducted to identify sub-applications and scan for threats.
2. SSL and SSH Decryption - If the traffic is encrypted and a decryption policy exists, App-ID decrypts the traffic for further analysis. Without a decryption policy, SSL decryption won’t occur.
3. Application Protocol Decoding - This involves using decoders for known protocols to detect applications that might be tunnelling within them, applying context-based signatures for deeper analysis.
4. Heuristics - For evasive applications that signatures and decoders can’t detect, heuristic or behavioural analysis is necessary. This method identifies applications like peer-to-peer file sharing or encrypted VoIP, offering insights into otherwise hard-to-detect activities.

Let's Look at an Example

In this example, I have three security policies - one to allow ping, another for DNS, and finally one for SSL and web browsing. Here, you’ll notice that I didn’t use any port numbers. You can also see the service is set to ‘application-default’, which means if I try to use DNS on a non-default port, it won’t be allowed. So, the SSL has to be on port 443; if I try to use port 8443, it won’t work.

With this in place, if I try to access facebook.com, these will be the events.

1. The client first sends a SYN, the server responds with SYN-ACK, and the client responds with ACK.
2. During this phase, Palo Alto wouldn’t know which website the client will access, so the firewall has no choice but to allow a few packets until it can transition to a more specific App-ID.
3. As soon as the client sends a client hello with SNI in it, the firewall will be like ‘huh, hang on a second, you are trying to access Facebook’, so this is not a generic ‘ssl’; let me block this.
4. The subsequent packets will be denied.

Now, if I go and create a rule to allow ‘facebook-base’, the connection will succeed and the page will load.

Can I Only Block Facebook Posting or Chat?

Now the big question, as seen in our previous screenshot, there are multiple sub App-IDs within the Facebook container such as facebook-chat and facebook-posting. So, if I want to allow Facebook but block people from posting or chatting, can we do it without SSL Decryption? The answer is simply no.

There are hundreds of App-IDs like Google Drive upload/download, YouTube upload, or YouTube posting, and they won’t work properly without decrypting the traffic. Because everything happens within an encrypted channel, the firewall knows the user is on Facebook but can’t confidently identify exactly what the user is doing.

Depends on and Implicitly Uses

Another aspect to understand in App-ID is “Depends on” and “Implicitly Uses” and what exactly these terms mean. 'Depends on Applications' is a list of other applications that are required for this application to properly work. The 'Implicitly Use Applications' is a subset of 'Depends on Applications', whereby the dependent applications are implicitly allowed.

Implicitly Uses

Referring back to the facebook-base example, you can see it implicitly uses ‘ssl’ and ‘web-browsing’, and 'Depends on' is empty.

1. Depends on Applications is blank. This means that facebook-base does not require any other applications to be allowed in the same rule for it to function.
2. Implicitly Uses Applications lists SSL and web-browsing. This means that if you allow facebook-base, it will also implicitly allow SSL and Web-Browsing applications.

So, for argument’s sake, let’s say we only want to allow Facebook and block everything else (a bit extreme, right?). Since facebook-base implicitly allows SSL and web-browsing, does that mean users can access generic sites like bbc.co.uk or samsung.com? The answer is no. The firewall will let some packets through and try to identify the traffic. If it’s not facebook-base, then it will block the traffic.

Depends on

Now let’s focus on another App-ID called ‘salesforce-base’. Here, you see it ‘depends on’ ‘ssl’ and ‘implicitly allows’ web-browsing. We already covered implicitly allowed, so let’s focus on ‘depends on’.

When an App-ID says it ‘depends on’ another App-ID, we have to explicitly allow that App-ID in our security policy, otherwise the application may not function correctly. If you try to create a rule with the ‘salesforce-base’ App-ID, you will see ‘ssl’ in the ‘Depends on’ section. You have the option to add ‘ssl’ to the current rule. If you don’t allow it, the Salesforce app won’t work.

If you do allow ‘ssl’, you are effectively allowing access to all other ‘generic sites’. I hope you can see the implications here.

Most companies place 'ssl' and 'web-browsing' at the top of their security policy, allowing users to access generic sites. They then create more specific rules to permit access to particular sites like salesforce.com. Because 'ssl' was already allowed in the previous rules, there's no need to allow it again in the Salesforce rules. When a user tries to access salesforce.com, the connection may initially match the first rule with the 'ssl' rule and then transition to another rule as soon as the Salesforce App-ID is identified.

Managing Palo Alto App-ID Changes Using Threat Signature Indicators (TSID)

In this blog post, we will look at using Threat Signature Indicators (TSID) that will help you get an advanced indication of any impact on your traffic as a result of upcoming App-ID changes.

PacketswitchSuresh Vina