Reference: Proxy Forwarding Policy

The

Web Security Service

Proxy Forwarding connectivity method requires policy that routes web traffic to the service. Specifically, the policy achieves the following:

To protect credential information in page headers, the policy forwards HTTP traffic over a secure service.

The policy forwards HTTPS and SSL traffic over the standard proxy service.

The policy ignores all other traffic.

The following Content Policy Language (CPL) is a template that includes CPL you must append to the existing

ProxySG

appliance Local policy file.

Notes

The lines that begin with a semi-colon (

;

) are CPL comments that provide information about the purpose of each policy construct.

The forwarding host names are examples. You must enter the hosts that you defined in the Proxy Forwarding configuration topic.

For easier copy and pasting and saving, right-click this ProxyForwardingCPL link and save the text file locally.

;;; $module=proxy_forwarding.cpl; $version=5;
;
; Template for the Web Security Service Proxy Forwarding access method
; Version Date: 20200828
;
; This template can be installed on appliances running SGOS version 6.5.10 or greater.
; IMPORTANT: This template contains sample policy. You might need to
; customize it for your location.
;
; The purpose of this policy is to decide what traffic should be sent to
; the Web Security Service (the Cloud), and how that traffic
; gets forwarded.
; In most cases, it's easier to specify what not to route, such as:
;  - Internal traffic should not be forwarded
;  - WSS management portal traffic.
;     While it is difficult to inadvertently lock yourself
;     out of administrative access, you can safely bypass it.
;
; Because of the restrictions on the type of condition referenced from
;  CPL layers, define the bypass list twice--once for use in
;  <Proxy> and <Cache> layers and once for use in <Forward> layers.
; These conditions unavoidably identify the same traffic,
; and should be maintained in parallel.
;
; The bypass list definition for use in <Proxy> and <Cache> layers
; uses url conditions.
;
define condition WSS_Cloud_Proxy_Bypass_List
    url.host.is_private=yes                   ; internal traffic
    ; Add any other public IPs that are not to route to WSS
    url.domain=portal.threatpulse.com         ; WSS portal
    url.domain=ctc.threatpulse.com            ; Remote Clients
    url.domain=auth.threatpulse.com           ; Authentication
end
; The bypass list definition for use in <Forward> layers
; uses server_url conditions.
;
define condition WSS_Cloud_Forward_Bypass_List
    server_url.host.is_private=yes            ; internal traffic
    health_check=yes                          ; Normally, don't forward health checks
    ; And any other additions required to keep it in line
    ;  with the above WSS_Cloud_Proxy_Bypass_List
    server_url.domain=portal.threatpulse.com  ; WSS portal
    server_url.domain=ctc.threatpulse.com     ; Remote Clients
    server_url.domain=auth.threatpulse.com    ; Authentication
end
; Upon user authentication,
; pass the user-name and groups to WSS.
;
<Proxy Cloud_Auth> condition=!WSS_Cloud_Proxy_Bypass_List
    authenticated=yes action.Auth_Cloud(yes)
; User and Group information are passed to WSS in
;  special headers added to the request.
;
define action Auth_Cloud
    set( request.x_header.BC_Auth_User, "$(user:encode_base64)" )
    set( request.x_header.BC_Auth_Groups, "$(groups:encode_base64)" )
end
define action WSS_Forward_Connect_Headers
   set( forward.http_connect.x_header.BC_Auth_User, "$(user:encode_base64)" )
   set( forward.http_connect.x_header.BC_Auth_Groups, "$(groups:encode_base64)" )
   set( forward.http_connect.header.Client-IP, "$(client.address)" )
end
; If you plan to use WSS to enforce
;  appropriate use policies (content filtering and application control),
;  then you must either disable caching or ensure that you always
;  verify access requests with WSS.

; Recommended: leave caching on, and use always_verify().
;
<Cache Cloud_Verify_Cached_Authorization> condition=!WSS_Cloud_Proxy_Bypass_List
    always_verify(yes)      ; check for authorization
; In SGOS 6.1, has_client= is available in <Cache> layers,
; which provides the ability to mark the system (mostly refresh traffic) with
; a specific userID. This feature is not available in
; previous releases of SGOS (such as 5.x).
; This template marks the traffic with the userID "Refresh User"
; by setting the BC_Auth_User header to the base-64
; encoded version of that string.
;
<Cache Cloud_Tag_System_traffic> condition=!WSS_Cloud_Proxy_Bypass_List
    ; it is a system request (mostly refresh)
    has_client=false action.Cloud_Auth_Refresh_Traffic(yes)
define action Cloud_Auth_Refresh_Traffic
    set( request.x_header.BC_Auth_User, "UmVmcmVzaCBVc2Vy" )
end
; Forward the desired traffic to the cloud.
;  - Do not forward traffic on the bypass list
;  - Generally, do not forward health checks
;  - Because HTTP traffic has user and group information added, it is sent
;       over a secure tunnel
; - unintercepted HTTPS traffic is forwarded directly
;    NOTE: User authentication information may be passed, but in cleartext.
;
; In SGOS 6.4.x, forwarding can be based on the server_url.category
; and this provides an opportunity to separate unintercepted SSL from
; intercepted SSL, which can be authenticated to the cloud service.
;
define condition SSL_Unintercepted_category
    ; portal authentication
    server_url.domain=auth.threatpulse.com
    ;
    ; this is a typical unintercepted category list
    ; it should be modified to match your local interception policy
    ;
    server_url.category=(Brokerage/Trading, Finance, Health)
    ;
    ; exempt this to get the style sheets for exception pages
    server_url.domain=portal.threatpulse.com
end
<Forward Cloud> condition=!WSS_Cloud_Forward_Bypass_List
  [Rule Encrypted_traffic] proxy.port=(443, 8080) url.scheme=(https,ssl,tcp)
    ; Unintercepted SLL
    condition=SSL_Unintercepted_category forward(WSSHTTP8080)
    ; In SGOS 6.5, Authentication headers can be added to the CONNECT request
    ; for unintercepted SSL, but are forwarded in plaintext.
    ; To forward authentication headers with the CONNECT request,
    ; comment out the previous rule and uncomment the line below:
    ;
    ; condition=SSL_Unintercepted_category action.WSS_Forward_Connect_Headers(yes) forward(WSSHTTP8080)
    ; Intercepted SSL
    forward(WSSInterceptedHTTPS8084)
  [Rule Plaintext_traffic]
    url.scheme=http forward(WSSSecure8443)
; For reporting purposes, forward the client IP addresses rather than the ProxySG
; appliance IP address.
;
<Proxy Forwarding_Client_IP>
    action.Forwarding_Client_IP(yes)
define action Forwarding_Client_IP
    set( request.header.Client-IP, "$(client.address)" )
end

Next Step

Return to Verify Connections.

About Proxy Forwarding