ProxySG policy might be inadvertently configured to allow outbound request data to a restricted site, even though the client receives a "blocked" response status from the ProxySG appliance.
Consider the following scenario:
In this scenario, was the file prevented from being uploaded, or does it now reside on the file-sharing site?
The answer: it depends on how ProxySG policy is constructed and how the various policy layers might interact.
On the ProxySG appliance, a simple policy of the following form would result in the request to the file-sharing site being denied:
<proxy>
deny url.category="File Sharing"
allow
If this were the only policy on the appliance, the request would stop at the appliance and not be sent to the origin content server (OCS) for processing: all of the information required to process this policy is available at the time that the appliance receives the request from the client.
ProxySG policy, however, is rarely this straightforward. Consider the following policy:
<proxy>
deny url.category="File Sharing"
allow
<proxy>
deny http.response.apparent_data_type=exe
This policy blocks file-sharing sites as well as any incoming executable files. From the client’s perspective, the behavior of each transaction appears to be the same: they make the request and the browser presents a page indicating that the request is blocked. Yet in this case, the ProxySG appliance submits the request to the OCS, allowing the data outside of the organization. Why?
In this scenario, both <proxy> layers are evaluated for each request. The appliance can evaluate the first layer using only the information from the client request; however, the second layer requires that the appliance not only send the request to the OCS, but also receive the response from the OCS to determine the apparent data type of the response. Because the response data is needed to make a policy determination, the request data would be posted to the OCS. In many cases, this is not the intended behavior of the policy author.
Although the previous policy example can be rewritten to comprise a single layer that provides the expected behavior, this might not be possible or desirable in more complex policy. In such cases, include the access_server() property and set it to no to prevent subsequent connections to the OCS after the decision to deny the request.
If you are running SGOS 6.6.2.1 or later, use the Deny object in the Web Request Layer in the Visual Policy Manager (VPM) to block outgoing requests and application operations that contact the OCS. Using Deny in this policy layer—but not in other layers, such as the Web Access Layer—generates the CPL access_server(no). The following is a simple example of using the VPM to install policy to meet the organizational requirements described in the Overview of this article:
The generated CPL looks like the following:
If you are running an SGOS release prior to 6.6.2.1, you can install policy via inline CPL, policy files, or the CPL layer. The following is an example of policy modified to use the access_server(no) property:
<proxy>
deny url.category="File Sharing" access_server(no)
allow
<proxy>
deny http.response.apparent_data_type=exe
Whether you use the Web Request Layer or write CPL as shown above, if the rule in the first policy layer matches, the access_server(no) property prevents the appliance from connecting to the server; thus, the request is denied before the ProxySG appliance has enough information to evaluate the rule in the second policy layer. If the rule in the first layer doesn't match, the connection to the server is allowed and the rule in the second policy layer is applied. As a result, the policy behaves as intended, blocking access to file-sharing sites and all downloads of executables.
Refer to the Additional Information section for details and best practices for writing and organizing policy to prevent unwanted OCS connections.