Tips & Tricks: How to Create an Application Override

[jdelio]

 

What is an Application Override?

Application Override is where the Palo Alto Networks firewall is configured to override the normal Application Identification (App-ID) of specific traffic passing through the firewall.  As soon as the Application Override policy takes effect, all further App-ID inspection of the traffic is stopped and the session is identified with the custom application. 

Please note that this is different from a traditional "Custom Application" as a Custom Application normally uses a signature and any traffic passing through the firewall would be identified as such, and not need an Application Override.

Example Use Scenario

You might ask why we'd ever need to override the normal application identification process. In some cases, customers build their own custom applications to address specific needs unique to the company. For these applications, we may not have signatures to properly identify the expected behavior and identify the traffic with a known application. In such cases, we recommended creating an application override to allow easier identification and reporting, and to prevent confusion.

Let's look at a typical scenario where you might use an Application Override policy. If you, for example, have a custom application that uses TCP Port 23, but traffic passing through the firewall is identified as temenos-T24, and the misidentification causes confusion about the traffic, then an Application Override can be implemented to correctly identify the traffic. 

What You'll Need for Setup:

To configure an Application Override, go to Policies > Application Override in the WebGUI. For setup, you'll need the following:

• Custom Application to be used in the Application Override policy (recommended)
• Application Override policy
• Security Policy that allows the newly created Custom Application through the firewall

Special Note about Content and Threat inspection

Application Override to a custom application will force the firewall to bypass Content and Threat inspection for the traffic that is matching the override rule. The exception to this is when you override to a pre-defined application that supports threat inspection. 

When you setup a rule in Application Override for a pre-defined application, the firewall has been configured to not do any application identification, but it will continue to do content threat inspection. Since the firewall is forced to apply the application to any session that matches the default ports for the pre-defined application, any application handled by the rules will be assumed to be this pre-defined application. You may not get the results you expect. Palo Alto Networks does not recommend setting up an app-override rule for a pre-defined application

Steps

To configure a new Custom Application for Telnet, which uses TCP Port 23:

1. Create a new Custom Application for the traffic in question.  From the WebGUI, go to Objects  > Applications, then click Add in the lower left.
   
2. Name the new application (in this case, something other than Telnet, which is already used). The example uses Telnet_Override as the name. Also, select values for Category, Subcategory, and Technology.
   
   
   
3. Optional Step: This just adds another layer to detail that is not always needed.
   Go to Advanced > Defaults, and select Port to list the ports in the application.
   The example here shows TCP port 23 being listed in the application:
   
   After selecting Port as the parameter, click +Add and insert protocol and port, as required. I used TCP/23. In this example, we don't need a signature, so go ahead and click OK to complete this custom application.
   Note: A Custom Application can use a signature to ID traffic without using an Application override, but that can be covered in a separate article.
   

    

4. To create an Application Override policy, go to Policies > Application Override, then click Add:
   
   
   
5. Under the General tab, enter a name for the policy. The example uses Telnet_Override.
   
   

    

6. Go to Source and add the Source Zone. Specify a Source Address (see example) if the source is a static address; otherwise, leave as Any.
   

   

    

   
   
7. Go to Destination, and add the Destination Zone. Specify a Destination Address (see example) if the destination is a static address; otherwise, leave as Any.
   

   

8. Go to Protocol/Application and select the Protocol, enter the Port number, and select the custom application created. Then hit OK.
   
9. Here is what it will look like after that new Application Override rule is created. 
   
   
   

Using the Custom App, Verifying, and Testing

Now in order to use this new Application override, you need to create a new Security Policy to allow this new application through the firewall, or modify an existing rule.

1. To create a new rule, go to Policies > Security and click Add in the lower left. Create the Security Policy for the zones the traffic will pass through using the custom application. Specify the ports that will be used in the Service. All new sessions will be detected with the new custom application. Allow the traffic.
   
   
   
2. Now commit and test. Traffic should use Telnet_Override as the application instead of either Telnet or  temenos-T24 as discussed earlier.
   
   
3. After committing the policy, run the following command via the CLI to view session details.
   > show session all filter application Telnet_Override

Additional Information
Note: Once an override is configured for an application, it must be assigned to any and all pre-existing rules that leverage the application. If not, once the override is in place the policies with old Application will break.

Some questions:

Q: About the timeouts associated with the custom app.

A: If they are left blank, the system global setting (show session info) will be used.

Q: In this example, if you were to also have to allow the same behavior from the untrust server to the trust server, would it require a second custom App?  (Since you apply the to/from in the app override, but in the security policy you are select the custom app not the app override?)

A: You'll need to create a second app override policy to match the direction of the session if it is initiated in the opposite direction (no need to create an app override policy for returning packets)

Q: I still cant understand why not just use a port number?  What's the benefit to creating the custom app? 

A: If you have created your own internal application that behaves like an application AppID can identify, you will be fine and the connections will be fine. Only the logs will reflect some standard application (eg http, telnet, ....)

There's two additional steps:

1. A custom app can help you fine-tune your logging and reporting as they will reflect your homebrew application instead of it's parent application. As long as there's no problems with the connections themselves, the custom app will simply help identify your custom app in logs and reports.

2. Application override will ensure AppID does not break your application in case it does not behave like anything it can identify: AppID will try to protect you from misbehaving applications by interrupting sessions that have been identified as applicationX, but do not behave like applicationX, e.g. you built something that sends out some http syntax and then switches to SQL queries and also chucks in some DNS queries, maybe even some GRE over TCP. AppID might not be happy with that and drop packets because the behavior is not normal. If you create a custom app and set your sessions to override to this custom app, we'll stop inspecting the sessions for 'normal' behavior.

My thanks to @reaper for his Q&A help with this one.

Thanks for taking time to read my blog.
If you enjoyed this, please hit the Like (thumb up) button, don't forget to subscribe to the LIVEcommunity Blog area.

As always, we welcome all comments and feedback in the comments section below.

Stay Secure,
Joe Delio
End of line