EdgeSWG is requesting resources for denied sites

Products

• ProxySG Software - SGOS

Issue/Introduction

EdgeSWG 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 EdgeSWG appliance.

Consider the following scenario:

• An organization's corporate policy forbids employees from uploading files to file-sharing sites.
• The organization's EdgeSWG 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 EdgeSWG policy is constructed and how the various policy layers might interact.
 

Cause

On the EdgeSWG 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.
 
EdgeSWG 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 EdgeSWG 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.
 

Resolution

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 EdgeSWG Admin Console, Visual Policy Manager (on the top right).
2. Add policy to block a specific category:
   1. Click Add Layer > Web Request.
   2. Click Add Rule. In this first rule, left click Destination and add a Request URL Category object with the File Storage/Sharing category selected. Then, left click Action and select Deny.
   3. Click Add Rule to add a rule below the first one. In this second rule, left click Action and select Allow Access to Server.
3. Add policy to block downloading of specific file types:
   1. Select Add Layer > Web Access.
   2. Click Add Rule. left click Destination and add an Apparent Data Type object with the EXE extension selected. Then, left click Action and select Deny.
4. Click Apply 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 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 EdgeSWG 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 Policy Best Practices for writing and organizing policy to prevent unwanted OCS connections.