Policy inadvertently allows outbound request data to a restricted site although client receives a "blocked" response status from ProxySG appliance
Last Updated May 13, 2017
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 126.96.36.199 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:
In the ProxySG Management Console, select Configuration > Policy > Visual Policy Manager.
Click Launch to open the VPM.
Add policy to block a specific category:
Select Policy > Add Web Request Layer.
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.
Click Add Rule to add a rule below the first one. In this second rule, right click Action and select Allow Access to Server.
Add policy to block downloading of specific file types:
Select Policy > Add Web Access Layer.
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.
Click Install Policy. The appliance installs the VPM policy.
The generated CPL looks like the following:
define condition RequestURLCategory url.category=("File Storage/Sharing") end condition RequestURLCategory
; this is the Web Request Layer <Proxy> condition=RequestURLCategory Deny access_server(no) Allow access_server(yes)
; this is the Web Access Layer <Proxy> http.response.apparent_data_type=(executable) Deny
If you are running an SGOS release prior to 188.8.131.52, you can install policy via inline CPL, policy files, or the CPL layer. The following is an example of policy modified to use the
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.
As a best practice, always use the
Deny object in the
Web Request Layer, or the
access_server(no) property in CPL, with any policy designed to block access to the OCS. Doing so eliminates the risk of unintended policy interactions that allow the request to proceed to the OCS.
When doing so, however, be aware that the location of
access_server(no) relative to policy which relies on information only available in the OCS response could produce an error at compile time. For example, policy written as follows triggers a compilation error:
Response-based policy and access_server(no) appear within the same layer.
Within this layer, the response-based policy and access_server(no) appear within the same rule, or access_server(no) appears in a rule later than response-based policy.
Symantec thanks Terrence "tuna" Gareau for highlighting the unintended consequence of misconfigured policy and his assistance with troubleshooting and testing this issue.
Imported Document ID: 000032877
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe