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:

• An organization’s corporate policy forbids employees from uploading files to file-sharing sites.
• The organization’s ProxySG appliances include policy designed to:
  • Block the "File Sharing" category.
  • Prevent downloading of executable files.
• When an employee attempts to upload a file to a file-sharing site, the browser presents an exception page indicating that the site is blocked.  

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:

1. In the ProxySG Management Console, select Configuration > Policy > Visual Policy Manager.
2. Click Launch to open the VPM.
3. Add policy to block a specific category:
   1. Select Policy > Add Web Request Layer.
   2. Click Add Rule. In this first rule, right click Destination and add a Request URL Category object with the File Storage/Sharing category selected. Then, right click Action and select Deny.
   3. Click Add Rule to add a rule below the first one. In this second rule, right click Action and select Allow Access to Server.
4. Add policy to block downloading of specific file types:
   1. Select Policy > Add Web Access Layer.
   2. Click Add Rule. Right click Destination and add an Apparent Data Type object with the EXE extension selected. Then, right click Action and select Deny.
5. Click Install Policy. The appliance installs the VPM policy.

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.