07-22-2011 07:58 AM
In most cases, I would not recommend leaving the service/port definition as "any", particularly on inbound rules. For inbound rules, there is not really a good reason to wait to drop a session based on App-ID when you know you don't want the traffic coming in on that port in the first place. As a general rule, inbound policy should always include "application-default" or the specific port you know you have the service running on. For outbound rules, it is best to have the firewall policy reflect what your intention is. For example, if you want to allow users to run web-browsing or ssh on random ports, use "any" in the service column and they will be allowed to do that. I wouldn't necessarily recommend that, but the key is the write the policy that is appropriate for your environment. When you are protecting servers, allowing traffic on random ports is almost always a bad idea. When you are protecting users, it may still be a bad idea, but that will largely depend on your environment and the risk you are willing to allow and the threat protection you are employing on the outbound (and inbound response) traffic. Generally speaking, the smaller you can get the surface area of exposure, the better you can manage the risk. App-ID allows you to do that in important ways, but it doesn't mean you should increase the port-based surface area just because you can.
Mike
07-22-2011 04:33 AM
Probably a mix of both, as PA doesn't know about all possible applications.
For web filetering rules, application based is good.
Now for datacenter/production needs ... what would happen if suddendly after an APP ID update , it won't recognize MSSQL protocol ? In addition, many apps aren't running on officially supported ports.
07-22-2011 07:58 AM
In most cases, I would not recommend leaving the service/port definition as "any", particularly on inbound rules. For inbound rules, there is not really a good reason to wait to drop a session based on App-ID when you know you don't want the traffic coming in on that port in the first place. As a general rule, inbound policy should always include "application-default" or the specific port you know you have the service running on. For outbound rules, it is best to have the firewall policy reflect what your intention is. For example, if you want to allow users to run web-browsing or ssh on random ports, use "any" in the service column and they will be allowed to do that. I wouldn't necessarily recommend that, but the key is the write the policy that is appropriate for your environment. When you are protecting servers, allowing traffic on random ports is almost always a bad idea. When you are protecting users, it may still be a bad idea, but that will largely depend on your environment and the risk you are willing to allow and the threat protection you are employing on the outbound (and inbound response) traffic. Generally speaking, the smaller you can get the surface area of exposure, the better you can manage the risk. App-ID allows you to do that in important ways, but it doesn't mean you should increase the port-based surface area just because you can.
Mike
08-05-2011 08:49 PM
No solution can identify apps before the TCP 3 way handshaking completes. For traditional fw, the port based policy can make traffic deny decision by the syn packet which contains port no./service and IP information.
For PA, if you choose "any" for service, that means you are ignoring the port no. check and we will allow a lot of first few packets from connections coming in/ sending out until we identify the app after we receive the fourth or later packets. So in order to make PA to be really "more secure" than a traditional fw and allowing less packets that we should not allow than a traditional fw, you should put at least application-default for a policy.
08-11-2011 11:49 PM
Thanks Jones. I have a more clear understanding now. 
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
