Access Denied error even though website is allowed by policy on ProxySG or ASG
search cancel

Access Denied error even though website is allowed by policy on ProxySG or ASG

book

Article ID: 167143

calendar_today

Updated On:

Products

Advanced Secure Gateway Software - ASG ProxySG Software - SGOS

Issue/Introduction

There are times when a site will be denied even when there is a rule to allow it.

For example:

Source= Group_1----->Destination=maps.google.com----->Action=Allow
 

There are times when some of the objects are pulled from other servers. In other words, if you are allowing maps.google.com and denying access to maps.gstatic.com, the the content on the page may not load because some of the objects on the maps.google.com page are actually hosted from maps.gstatic.com.

Resolution

Allowing the website alone may not be enough to allow all of the content to be displayed on a page since different

servers may be supplying the objects to fill out the page. To remedy this issue, allowing a site based on the Referer

header should address the issue.

For example, creating a second rule with a combined source object through VPM that contains the referer should fix the issue:

Source=Combined Source Object (Group_1 and Referer: maps.google.com)----->Destination=Any----->Action=Allow
 

Example policy trace:

        
    miss :     condition=__GROUP7    
    miss :     condition=__GROUP8    
    miss :     condition=__GROUP9    
    miss :     condition=__GROUP25    
    MATCH:     ALLOW condition=__GROUP16 url.domain=//maps.google.com/    
          
    MATCH:     ALLOW condition="Sample Management Maps"    
          
    MATCH:     client.address=X.X.X.X trace.request(yes) trace.rules(all) trace.destination(Test)    
  connection: service.name=HTTP client.address=X.X.X.X proxy.port=80
  time: 2010-03-11 21:03:37 UTC
  GET
http://maps.google.com/mapfiles/home3.html
Referer: http://maps.google.com/
 

          
    miss :     condition=__GROUP7    
    miss :     condition=__GROUP8    
    miss :     condition=__GROUP9    
    miss :     condition=__GROUP25    
    miss :     url.domain=//maps.google.com/    
    miss :     condition="__CondList1Sample Mgmt & Shipping Categories"    
    miss :     condition="__CondList1fuzzy General Exceptions"    
    MATCH:     exception(content_filter_denied)     
          
    MATCH:     ALLOW condition="Sample Management Maps"     
          
    MATCH:     client.address=X.X.X.X trace.request(yes) trace.rules(all) trace.destination(Test)    
  connection: service.name=HTTP client.address=X.X.X.X proxy.port=80
  time: 2010-03-11 21:03:38 UTC
  GET
http://maps.gstatic.com/intl/en_us/mapfiles/my_location_button.png
Referer: http://maps.google.com/
  user: name="ABUTEST\sample" realm=FUZZY

To create a Referer Header Object, perform the following steps within the Visual Policy Manager:

  • Right-click in the source field of the rule you want to use to allow the request
  • Select Set
  • Click the New button
  • Select Request Header...
  • Give the Request Header Object a desired name (ex: maps.google.com)
  • Select 'Referer' from the Header Name drop-down list
  • Type the referer domain name in the Header Regex field (ex: maps.google.com)
  • Click OK button

You can then use this object by itself as the source in the rule or add it to a Combined Source Object as suggested above. After setting any other criterion needed in the rule to fit your needs, you will need to install policy for the changes to take effect.

Note: After configuring policy to allow a specified referer as described above, (if configured correctly) all requests with a referer header consisting of the specified domain will be allowed. However, be advised that there are some third-party hosting domains that refer to content hosted by other domains. For example: maps.gstatic.com could potentially display content that is hosted by another third-party domain. This means that the referer header on subsequent requests may contain a domain other than what is specified in policy. For this reason, the use of referer header objects in policy may not always be effective without creating additional objects for the subsequent referers. Furthermore, referers have a potential of being dynamic. Therefore, the effectiveness of this policy cannot be guaranteed.