Printer Friendly Page

Tips & Tricks: How to Create an Application Override

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. 

 

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

 

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.
    2015-10-05 tnt 1.jpg

  2. Name the 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.
    2015-10-05 tnt 2.jpg

  3. Optional Step: This just adds another layer ot detail that is not always needed.
    Go to Advanced > Defaults, and select Port to list the ports in the application.
    The example shows the ports being listed in the application:
    2015-10-05 tnt 3.jpg
    After selecting Port as the parameter, click Add and insert protocol and port, as required. In this example, we don't need a signature, so go ahead and click OK to complete this custom application.

  4. To create an Application Override policy, go to Policies > Application Override, then click Add:
    2015-10-05 tnt 4.jpg

  5. Under the General tab, enter a name for the policy. The example uses Telnet_Override.
    2015-10-05 tnt 5.png

  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.
    2015-10-05 tnt 6.png

  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.
    2015-10-05 tnt 7.png

  8. Go to Protocol/Application and select the Protocol, enter the Port number, and select the custom application created.
    2015-10-05 tnt 8.png

Using the Custom App, Verifying, and Testing

Now create either a 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.
    2015-10-05 tnt 9.jpg

  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

Please let us know if this helps, or if you have any comments below. 

 

 

 

Comments

Please note that Step 3 is optional from my experience, you could even keep it as none.

This is a good paper, BUT it fails to mention a VERY important part. When creating the FW rule, aka, Security Policy, in the Application Tab enter your Custom Application and leave the Service in Service/URL Category as "application-default". Failure to do so will cause your FW to drop the traffic.

It would also be helpful if this article covered or linked to information for when the Signatures tab would be used.

It is important to note that traffic permitted by a rule using an app override will NOT be inspected for threats.

What timeout values will be applied? Will it use default tcp and udp timeout values or do I need to specify values?

the timeouts associated with the custom app

if they are left blank, the system global setting (show session info) will be used

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

 

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)

Just tested this on port 80 and 443 and came up with some interesting results in the lab. I need to understand the order of operation for this as the app override took precedence over the policy for the destination instead of what is in the policy.

I looked through DOC-1628 and it comes close. See testing below

 

( This is all lab so I can break things at will, do not do this on production- Panos 7.0.12)

1) I setup the new applications web_override and ssl_override

2) setup the application override policies ( Note the server 10.1.10.1 only listens on port 443.

                Web_Overide>source zone=trust>Destination Zone = untrust > any address> protocol=tcp, port 80

                SSL_Override>source zone=trust>Destination Zone = untrust > address 10.1.10.1> protocol=tcp, port 80

3) I used one policy with the following ( I put it at the top of the rule set with allow rules below this one to allow browsing via appid, browsing works fine until I break it)

               Override_Web> Source zone=trust>Destination Zone = untrust > address 10.1.10.1, Applicaton=Web_Override and SSL_Override> Service= TCP-80 and TCP-443

 

Results - port 443 worked great to 10.1.10.1, All port 80 traffic was blocked by the Override_Web Policy. I then edited the Web_Override application override and put in the address 10.1.10.1 and all traffic on port 80 passed to the proper rules under Web_Override.  

 

I am moving on to breaking other things BUT here is the reason I am testing, We have at times a need to override applications for testing total capable throughput for network / load testing. Also looking to implement these for some latency sensetive applications.  


QUESTIONS

1) thoughts on the scenario below

2) Anyone have numbers (Throughput, latency etc) on doing an applicaton override. Also if I were to disable app-id on a lower end firewall say (5020) what would the expected through put actually be ( 10GB?).  I may have to do this until I get funding for new firewalls but I am running some big inline IPS's behind them.

 

Signed: TacoBell

Hi @billyemoore

might i suggest you ask this in the discussion forum , you'll reach a larger audience that way :) (as it's more of an experimental nature than a question about the article)

 

a few questions

1)                SSL_Override>source zone=trust>Destination Zone = untrust > address 10.1.10.1> protocol=tcp, port 80

this policy has port 80 for ssl or is that a typo ?

 

2) did you set the override_web policy to deny ? (this could explain why ssl worked fine)

 

3) security policy is checked multiple times over the course of a session's lifetime:

    1st pass when the SYN packet comes in and we can ONLY check source zone/ip-dst zone/ip - dst port (so we skip app check in the policy)

    2nd pass when we know the app

    xnd pass if the application changes for some reason

 

4) the discussion forum might help getting numbers on app-overridden platform throughputs 

 

5) not sure what you mean by "app override took precedence over the policy for the destination"

I understand how this example works, but I don't really follow the reasoning behind it.  The net effect of the example shown above is to allow the traffic on Port 23 with no content ID scanning, correct?

 

So why not just create a rule with "Any" application and port 23 service?

 

What is the real advantage of this, other than to be able to say that you have "appified" a rule?

 

 

Hi @jeff.gass

 

so the example goes that a company may be producing their own applications and one of their apps uses port 23 and the firewall's App-ID identifies the traffic as temenos-T24

 

from the moment app-ID identifies the application the logs will start to reflect this application, which is not a big deal, but application behavior will also be enforced

if the custom built application then starts behaving differently, App-ID will identify this as suspicious/malicious (app evasion technique) and will drop the connection

 

creating a custom app will fix that particular issue

in many cases it helps 'beautify' reporting as it becomes more clear which connections (and bandwidth consumption) are related to a home grown app, sometimes it helps prevent unexpected behavior because the app behaves differently than the firewall expects 

i Guys, I still cant understand why not just use a port number?  Whats the benefit to creating the custom app?  Sorry Reaper your explanation didit help me understand fully. Thanks


hi @ngeorgaki

 

it depends on your needs

 

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 2 additional steps:

 

1. a custom app can help you finetune 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 buit do not behave like applicationX

eg. 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

 

 

tl;dr the Palo Alto Networks firewall is a layer7 firewall that inspects sessions for application behavior, app override forces inspection to stop at layer4 for a specific flow

 

 

hope this helps

 

Hi @reaper

 

Thank you, that helped!

 

 

So if I have this right creating the override will firstly separate the custom app from being classified as something generic in reporting as "web-browsing" for example. It might now be known as "Staff-Intranet" or something similar.

And secondly, because we trust this application and as such trust its behaviour, if we didn’t override and left it to just a service port then if the app did do something non-standard (but legitimate) the Palo's inspection may block the session deeming it suspicious.

 

Very nice indeed :) 

You don't need the override necessarily for the first bit. If you build your own webpage and a custom app that triggers on a specific signature, the custom app will do that without an override

 

the rest is spot on :)

Thanks @reaper  Great help :)

@jdelio,

 

It is great article, thank you for that. But I think there is something very important that it is not mentioned here. From other documents I understand that Application Override to custom application will force the firewall to bypass Content and Threat inspection for the traffic that is matching the override rule. But I just saw another document that says - if you select predefined application in the application override the Layer 7 inspection is still enforced...

 

"When overriding to a custom application, there is no threat inspection that is performed. The exception to this is when you override to a pre-defined application that supports threat inspection. "

 

 

@Alexander.Astardzhiev, you make a VERY valid point. This is true. The minute you have an application override, the Content and Threat inspection is bypassed.  I will make sure to add this as a note to this Tips and Tricks. Thanks again, You will be noted as a contributor when I am done.

Regarding this part:

 

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