Palo Alto Networks’ firewall technology includes the capability to identify applications with App-ID and control the traffic based on Service (Ports). The recommended best practice is to use application-default for the Service when creating security policies that utilize App-ID. However, it’s possible to specify both App-ID and custom Services (Ports) in the same security policy rule.
There can be some complications or issues when using both App-ID and custom Services together:
Overlapping or Conflicting Rules
If a custom Service port overlaps with an App-ID that uses the same port, it can create conflicts in how traffic is identified and processed. The behavior might not be what you expect.
Complexity in Policy Management
Having both App-ID and custom Services can make the security policy more complex and harder to manage. The more complexity there is, the easier it is to make errors or overlook potential security risks.
Performance Overhead
Although Palo Alto firewalls are highly optimized, adding more layers of inspection, such as using both custom Services and App-IDs, can potentially result in some performance overhead.
Limitation of Application Features
When you specify a custom Service (port), you may limit the features and functionalities App-ID identifies. Some applications dynamically use multiple or switch ports, and by specifying a custom port, you may inadvertently block or allow traffic that should be handled differently.
Reduced Efficacy of App-ID
One of the main advantages of App-ID is its ability to identify applications regardless of the port being used. When you specify a Service, you are reducing the efficacy of App-ID’s port-agnostic identification capabilities.
Troubleshooting Difficulty
If you are having issues with traffic flow, having both App-ID and custom Service settings can make the troubleshooting process more complicated as you will have to consider both layers in your diagnosis.
Incomplete Security Posture
Some advanced features like SSL decryption, data filtering, and threat prevention profiles are often better utilized when App-ID is fully leveraged. Combining both might lead to a less-than-optimal security posture.
In general, application-default for the Service setting is recommended when using App-ID unless a specific use-case requires custom Services to be defined.
Example
This simplified example involves a single security policy rule that aims to allow HTTPS traffic but sets the Service port to 8080.
Rule Configuration:
- Allow App-ID: ssl (for HTTPS traffic)
- Service: TCP/8080
The Issue:
In this example, the App-ID is set to recognize SSL traffic, which typically operates over port 443. However, the Service is explicitly set to allow traffic over port 8080. This means that the firewall rule will only match SSL traffic specifically running over port 8080.
Any standard HTTPS traffic running over its default port 443 will not match this rule and thus will not be allowed through the firewall, defeating the purpose of specifying the App-ID for SSL. This misalignment can lead to unintended blocking of regular HTTPS traffic and can be confusing during troubleshooting.
Recommended Configuration:
- Allow App-ID:
ssl - Service:
application-default(which would dynamically set the Service port to 443 for HTTPS traffic as recognized by App-ID)
The rule will dynamically allow the default port for SSL traffic (port 443) based on what the App-ID SSL identifies by setting the Service to application-default. This aligns the App-ID and Service settings, ensuring traffic is allowed or blocked as intended.
In summary, the issue with the original rule is that it’s contradictory: It specifies that it’s looking for HTTPS traffic (typically port 443) but then explicitly limits that to port 8080, which is not the standard port for HTTPS. This can lead to unexpected behavior and difficulties in troubleshooting.
What about if the service is set to TCP/8080, TCP/8000, & TCP/123 and the APP-ID is SSL and APP-ID MS-SMS?
In a Palo Alto firewall, when you specify multiple App-IDs and multiple Service ports in a single rule, the rule will apply to the combinations of the specified App-IDs and Service ports.
Rule Configuration:
- Allow App-ID:
ssl, ms-sms(for HTTPS traffic and Microsoft Simple Mail Service) - Service:
TCP/8080, TCP/8000, TCP/123
What this Configuration Means:
This configuration is allowing:
- SSL traffic over ports 8080, 8000, and 123
- MS-SMS traffic over ports 8080, 8000, and 123
Here are some considerations for this setup:
1. Overlapping Rules
Both ssl and ms-sms are being allowed over the same ports, which can create confusion if you’re expecting only specific types of traffic over specific ports.
2. Non-Standard Ports
Both SSL (commonly over TCP/443) and MS-SMS (commonly over TCP/80 for HTTP or other specific ports) would be restricted to using ports 8080, 8000, and 123. If either application normally runs on different ports, this rule would block that traffic.
3. Complexity and Troubleshooting
Having multiple App-IDs and multiple Service ports in the same rule makes the firewall policy more complex and could make troubleshooting more difficult.
4. Reduced Efficacy of App-ID
As in the previous example, using custom Service ports means you are bypassing one of the key strengths of App-ID, which is the ability to identify applications regardless of the port.
5. Potential for Unintended Allowance or Blocking
Depending on other rules and the specific behavior of ssl and ms-sms, you could inadvertently block or allow traffic that you did not intend to.
6. Security Risks
Depending on the actual applications and their behaviors, specifying custom ports like this could potentially open up security risks, such as unauthorized applications sneaking through on the allowed ports.
Recommended Configuration:
If you have a very specific use-case requiring this combination of App-IDs and Service ports, this configuration might be warranted. Otherwise, the recommendation would generally be to simplify the rule and make use of application-default for the Service ports to allow App-ID to manage ports based on the recognized application.
By clearly understanding the intent behind each rule, and by leveraging the strengths of Palo Alto’s firewall features, you can create more effective and manageable security policies.