Best Practices for Application Policies?

[nugentec]

I was wondering if there is a best practices document for setting up a policy to control particular applications. I've already dug through the Skype tech document which tells to enable unknown applications. Are there any other applications that work better or require unknown applications to be enabled? To take it further, is there an application dependency list available? For example when creating a policy allowing bittorrent traffic out, the firewall prompts during the verification process that web-browsing should be enabled for bittorrent. Is there a document that will say “X application requires Y application to work correctly”. I would prefer not to find out during the verification process.

- FJ

[pantac]

hello Frank,

currently we do not have such a document as this, but this a great idea. I am currently pursuing the possibilities of producing such a document. This document would need to be live as we are continually updating application signatures with each content release.

Also a case has been created for this issue for tracking. It is case 7836. You can call into support and refer to it to get updates.

Thank you,

Stephen

[mjacobsen]

As a clarification, from our testing with current software and content, we no longer see any issue with Skype call quality when not allowing unknown traffic. We will work to get the tech note updated.

On the general topic of application dependencies, the system will show you these dependencies at the time of commit. We are looking at enhancing the policy workflow to make those dependencies more apparent when adding applications to a rule. Hopefully this will feel more natural than the current warnings. Let us know if you have thoughts about better ways to highlight these dependencies.

Mike

[nugentec]

Thanks for getting back to me. For the time being, do you have a list of applications that either require or benefit from allowing unknown-tcp, *-udp, *-p2p? Or in other terms, would creating a policy which allows the "unknown group" traverse the firewall, would it lead to the firewall identifying more applications? Are there any applications that cannot be identified without the "unknown group" being enabled? I need to make a case to my manager to whether or not we should allow the "unknown group" and having a list of applications that benefit from it would help my case.

As far as application dependencies, I would prefer to find out either while I'm editing the security rule base or beforehand from a document. I don't care to wait during the commit process. For my team and I its a personal preference.

I appreciate your help on this.

Thanks,

FJ

[mjacobsen]

The key with unknown-tcp and unknown-udp is that they indicate that we

are seeing an application we do not recognize. If you have an

application in use that falls into this bucket, then allowing unknown-

tcp or unknown-udp is important (assuming it is an application you

want going in and out). There shouldn't be any applications that we

have App-IDs for that benefit from allowing unknown traffic. For the

applications that we do not recognize, you have a few options. You can

submit the application to us and we will add an App-ID for it. If it

is an HTTP-based application you can write your own custom App-ID for

it. If it is served on a static port or IP, you can create an

Application Override rule for it. Finally, you can allow the unknown

traffic.

In general, if you have an open policy where you allow most

applications, then allowing the unknowns probably makes sense. If you

are trying to create a restrictive policy where you only allow a small

subset of applications, then blocking unknown applications is probably

a better fit. In many environments, we see customers starting out

allowing unknowns and then doing a little investigation on the types

of flows that are showing up as unknown to determine which of the

above options should be chosen for dealing with those flows.

Thanks for your feedback on the dependencies. We will continue down

the path of figuring out a way to make them apparent within the

context of rulebase edits.

Mike

[nugentec]

Thanks for your response Mike. It's what I need to help my manager make a few key decisions. However we are hung up on one of your responses. You stated "There shouldn't be any applications that we have App-IDs for that benefit from allowing unknown traffic." If this is the case, why is unknown-tcp a required application dependancy for applications like share-p2p and bittorrent? If the "unknown application group" is not used to identifiy applications like share-p2p, why is it a dependancy? Can you please clear this up for me?

Thanks,

FJ

[mjacobsen]

Good catch. What you have found are two examples of applications that

leverage our heuristic engine for identification. These applications

can utilize proprietary encryption and in some cases, we are not able

to identify them based on signature. In these cases, the heuristic

engine will watch for behavior patterns and identify the application

based on that. The heuristic engine kicks in when we have no positive

match based on known signatures (i.e. when the application is not

identified and shows up as unknown-tcp/udp). This is the reason for

unknown-tcp showing up as a dependency when you commit a policy

allowing bittorrent or share-p2p. If you didn't allow unknowns, the

portion of those apps that use proprietary encryption would not be

identified or allowed. So, my initial response was incorrect, there

are a handful of apps that will get identified by the heuristic engine

if we have declared them as unknown based on signature matches. If the

heuristic match does not happen right away, allowing unknown traffic

would be required for proper identification assuming you were wanting

to explicitly allow these applications.

Mike

[rps]

Another example is if you only want to allow browser-based im-services and add that as an allowed subcategory.

During commit it will bring you a warning that "msn2go" also needs "http" to be functioning.

However if I fullfill the request of the warning (and add "http" to the allowed application list) that would mean that I will allow ALL http based applications (which I dont want).

An expensive workaround would be to try to identify all applications which relations to http and put them on a block before the http + im-services allow row.

Wouldnt it be possible to extend the appid for msn2go to include whatever from http it needs to be functioning. But so it at the same time will block other http requests which isnt msn2go based?

The same would of course apply to bittorrent and the other appid's with dependencies...

[mjacobsen]

Allowing web-browsing does not allow all HTTP-based applications. Any applications that have specific App-IDs will need to be called out in addition to web-browsing. So in your example, you would not need the block rule ahead of the im-services rule. A rule that allows web-browsing and im-services would only allow unclassified HTTP traffic and specific IM apps covered in your im-services group.

Mike

[rps]

Yes but when I allow the sub category "im-services" (which is part of "browser-based" category) and try to commit then the commit is successful but I get a warning (within the popup of the commit window) that "msn2go" wants "http" before it can function (and as I interpret it this means that all applications within "im-services" are now allowed except "msn2go" because I didnt add "http" as application, however if I would add "http" (as the warning tells me to do) then it would be a bit to wide opening through the firewall).

[mjacobsen]

First, it is not just msn2go that requires http (or actually the app called web-browsing). The commit checking just presents the first issue is runs into. In this case, all of the apps in your browser-based IM group will require web-browsing in order to function. Without this, the HTTP decoding function does not occur and no HTTP-based applications will be allowed. In order for any of the HTTP-based applications to be allowed, there must be a rule allowing web-browsing. As I mentioned, this does not allow any otherwise classified App-IDs, only unclassified web-browsing traffic.

Mike

[rps]

Hmm I will verify this on monday because im pretty sure that "web-browsing" is already allowed in the same application filter that have selected the im-group, and yet during commit I get a warning that "msn2go" needs "http" to function.

This is with 3.0.6 with current of today (26 feb) threat/app db (170-something if im not mistaken).

[kbrazil]

As Mike stated, you need to allow the "web-browsing" application for web-based applications to function.  This allows the HTTP decoder to activate.  This only allows generic HTTP web-browsing and not other more-specific web applications we have signatures for.  You can further control the generic "web-browsing" application via URL filtering profile.

If you want to enable web-based IM you might want to create a policy that includes the IM and web-browsing applications, then add a URL filtering profile to that rule to block most categories of generic web-browsing that doesn't fit into an existing web application signature.  You might need to tweak the URL filtering profile a bit and make some exceptions depending on how restrictive you make it.

Cheers,

Kelly

[rps]

"web-browsing" is already allowed but it doesnt seem to work as expected.

I created an application filter named "SURF_browser-based" containing:

Technologies:
browser-based

Subcategories:
email
erp-crm
file-sharing
general-business
instant-messaging
internet-utility
office-programs
social-networking
storage-backup
web-posting

and assign it to a policy to allow the applications which are contained in the above subcategories (note how instant-messaging is included along with web-browsing which is in internet-utility if im not mistaken).

After commit the output is:

    * device: Rule 'SURF' application dependency warning:
    * - Application 'zimbra' requires 'http-proxy' allowed in the policy
    * - Application 'zimbra' requires 'http-proxy' allowed in the policy
    * - Application 'zimbra' requires 'http-proxy' allowed in the policy
    * - Application 'zimbra' requires 'http-proxy' allowed in the policy
    * - Application 'zimbra' requires 'http-proxy' allowed in the policy
    * - Application 'zimbra' requires 'http-proxy' allowed in the policy
    * - Application 'mobile-me' requires 'http-proxy' allowed in the policy
    * - Application 'mobile-me' requires 'http-proxy' allowed in the policy
    * - Application 'mobile-me' requires 'http-proxy' allowed in the policy
    * - Application 'mobile-me' requires 'http-proxy' allowed in the policy
    * - Application 'mobile-me' requires 'http-proxy' allowed in the policy
    * - Application 'mobile-me' requires 'http-proxy' allowed in the policy
    * - Application 'msn2go' requires 'http' allowed in the policy
    * - Application 'msn2go' requires 'http' allowed in the policy
    * - Application 'msn2go' requires 'http' allowed in the policy
    * - Application 'msn2go' requires 'http' allowed in the policy
    * - Application 'msn2go' requires 'http' allowed in the policy
    * - Application 'msn2go' requires 'http' allowed in the policy
    * - Application 'bebo' requires 'http-proxy' allowed in the policy
    * - Application 'bebo' requires 'http-proxy' allowed in the policy
    * - Application 'bebo' requires 'http-proxy' allowed in the policy
    * - Application 'bebo' requires 'http-proxy' allowed in the policy
    * - Application 'bebo' requires 'http-proxy' allowed in the policy
    * - Application 'bebo' requires 'http-proxy' allowed in the policy
    * - Application 'aim-express' requires 'aim' allowed in the policy
    * - Application 'aim-express' requires 'aim' allowed in the policy
    * - Application 'aim-express' requires 'aim' allowed in the policy
    * - Application 'aim-express' requires 'aim' allowed in the policy
    * - Application 'aim-express' requires 'aim' allowed in the policy
    * - Application 'aim-express' requires 'aim' allowed in the policy
    * - Application 'woome' requires 'rtmp' allowed in the policy
    * - Application 'woome' requires 'rtmp' allowed in the policy
    * - Application 'woome' requires 'rtmp' allowed in the policy
    * - Application 'woome' requires 'rtmp' allowed in the policy
    * - Application 'woome' requires 'rtmp' allowed in the policy
    * - Application 'woome' requires 'rtmp' allowed in the policy
    * - Application 'bigupload' requires 'ftp' allowed in the policy
    * - Application 'bigupload' requires 'ftp' allowed in the policy
    * - Application 'bigupload' requires 'ftp' allowed in the policy
    * - Application 'bigupload' requires 'ftp' allowed in the policy
    * - Application 'bigupload' requires 'ftp' allowed in the policy
    * - Application 'bigupload' requires 'ftp' allowed in the policy
    * Configuration committed successfully

Note the warning regarding msn2go which I feel is a bit odd since both web-browsing and msn2go are allowed...

[pantac]

RPS,

I will look into this issue on the support side.

If you have an active support contract can you send an email to support@paloaltonetworks.com and include the following information:

Pan device serial number

PanOS version installed

Content database installed

I will open a case to investigate.

Thank you.