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.
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?
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.
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...
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.
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).
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!