New Application vs Application override

Reply
Highlighted
L3 Networker

New Application vs Application override

Hi all,

is there any difference between creating a new application and creating application override policy? as per I understand a new application doesn't required configuring application override policy, and configuring application override policy is required only when you over existing application based on a new port or signature.

assume i have a client connecting to a server on port 9152, i can configure a new application that uses tcp port 9152. but if i have clients connecting to a server on port 443 which appears as ssl application in the monitoring dashboard, and i want to change the application, all i want to do is to create a new application that uses port tcp/443 with parent app ssl, and create application override policy based on the new app..  am i correct??

please advise..

thanks


Accepted Solutions
Highlighted
L5 Sessionator

Hello, all,

 

If I may clarify difference between concepts here: Creating a new application, with another parent application, can and will be used for both clasiffication and in reporting. For example: if you would customize your zabbix application inhouse so it does polling on some port other than standard, you could create a new application with parent "zabbix" and name it "zabbix-other_ports" or something similar and suggestive of the change. Than, in your reporting and logs you would see this still as a zabbix rather than (perhaps) an unknown application.

 

Application override is a concept where you practically excuse traffic from inspection in higher layers. It should be used with care because you are effectively allowing some traffic to circumvent inspection in the firewall. You should need to create following only in cases where your firewall is not working as expected - for example, for some VoIP services or Video Conferencing that is expecting reverse connections and those ports aren't properly opened by firewall after the initial call establishment. So, in my humble opinion, only if something is not working as expected it should be allowed to circumvent inspection and such rules should always be tightened - for example, you create new application (I always create new application and do not have real application as it's parent) and than use it in application override.

Furthermore, when creating app override policy it is mandatory to define protocol and port(s), but it is also possible to pick only one between TCP and UDP. Therefore, I always create dummy application (with signatures as "none") and than define ports when I am creating an app override. At the end, I always want to very precisely specify source and destination network(s) and zones for which this traffic will be using app override, to allow "no inspection" only to traffic that really needs it.

 

In your case, if you do need app override, I would create a new app and call it "ssl-override" without parent app and without signature, and than I would go ahead and use it in the newly created application override with ports TCP 443, and than define source zone and network from which your users come from and destination as that DMZ along with the IP address of the destination server. That way, only traffic between this server and users in the local network will "not" be inspected in higher layers, while all other traffic will be inspected.

 

Using application override to offload some traffic from the firewall... while effective, is really not a complete solution in my opinion - of course, sometimes it has to be done, but one needs to be careful what is one offloading, perhaps some reorganization of traffic and inspection can help but generally resizing is better solution if possible :)

 

Hope this helps,

regards

 

Luciano

View solution in original post


All Replies
Highlighted
L4 Transporter

Hello,

 

With a custom applicaton, you can enforce threat prevention and make use of app-id properly. 

 

An app override rule causes the layer 7 inspection on the defined port to be by passed and all traffic on that port is classified as the application that you specify. 

 

Personnally I would go for making a custom application or submit an application request. An app overide should only really be used whilst you wait for a new application to come in with a content update or you are still working on the custom application. It should be used as a quick work around rather than a full solution due to the security concerns of having potentially unwanted traffic/applications being classed as the app override app. I definitly would not recommend the use of an app overide on port 443.

 

hope this helps,

Ben

Highlighted
L5 Sessionator

Hi

 

Common usage for app override can be:

   - Either easily creating new apps (which don't need L7 analyze) or more accurate classification (VoIP)

   - Offload your palo. Got customer with hundreds and hundreds of Zabbix session, on all session, palo try to do “App-Id” which introduce high load from CPU point of view.

 

Hope help.

 

V.

Highlighted
L5 Sessionator

Hello, all,

 

If I may clarify difference between concepts here: Creating a new application, with another parent application, can and will be used for both clasiffication and in reporting. For example: if you would customize your zabbix application inhouse so it does polling on some port other than standard, you could create a new application with parent "zabbix" and name it "zabbix-other_ports" or something similar and suggestive of the change. Than, in your reporting and logs you would see this still as a zabbix rather than (perhaps) an unknown application.

 

Application override is a concept where you practically excuse traffic from inspection in higher layers. It should be used with care because you are effectively allowing some traffic to circumvent inspection in the firewall. You should need to create following only in cases where your firewall is not working as expected - for example, for some VoIP services or Video Conferencing that is expecting reverse connections and those ports aren't properly opened by firewall after the initial call establishment. So, in my humble opinion, only if something is not working as expected it should be allowed to circumvent inspection and such rules should always be tightened - for example, you create new application (I always create new application and do not have real application as it's parent) and than use it in application override.

Furthermore, when creating app override policy it is mandatory to define protocol and port(s), but it is also possible to pick only one between TCP and UDP. Therefore, I always create dummy application (with signatures as "none") and than define ports when I am creating an app override. At the end, I always want to very precisely specify source and destination network(s) and zones for which this traffic will be using app override, to allow "no inspection" only to traffic that really needs it.

 

In your case, if you do need app override, I would create a new app and call it "ssl-override" without parent app and without signature, and than I would go ahead and use it in the newly created application override with ports TCP 443, and than define source zone and network from which your users come from and destination as that DMZ along with the IP address of the destination server. That way, only traffic between this server and users in the local network will "not" be inspected in higher layers, while all other traffic will be inspected.

 

Using application override to offload some traffic from the firewall... while effective, is really not a complete solution in my opinion - of course, sometimes it has to be done, but one needs to be careful what is one offloading, perhaps some reorganization of traffic and inspection can help but generally resizing is better solution if possible :)

 

Hope this helps,

regards

 

Luciano

View solution in original post

Highlighted
L3 Networker

Thanks Lucky, that helped me alot..

Highlighted
L3 Networker

Thanks Vince..

appreciated

Highlighted
L3 Networker

Thanks Ben,

 

Regards.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!