Setting Up Proxy Forwarding to WSS

Technical Requirements

This section provides a high-level set of technical requirements to perform this configuration.
  • Enable apps in the
    CloudSOC
    Store from the
    CloudSOC
    console. If you have not already done so, navigate to the
    CloudSOC
    Store and enable Gatelets for the SaaS apps that you use.
  • Deploy
    Symantec
    Secure Web Gateway (ProxySG or ASG appliance):
    • Minimum version: SGOS 6.7.x.
    • The corporate firewall must allow ports
      8080
      ,
      8443
      , and
      8084
      (if configured) from the Gateways to the WSS ingress IP addresses.
    • Know the egress IP address.
  • Check identity and authentication for WSS: If your WSS account is provisioned for
    CloudSOC
    Gateway (
    CloudSOC
    -only mode), then Auth Connector is not required. WSS does not require users or groups for policies. The on-premises ProxySG appliance provides the user/group information to
    CloudSOC
    .
    CloudSOC
    Gateway uses SpanVA to map users to groups.
  • Configure an existing gateway ProxySG or ASG appliance to forward HTTP/HTTPS traffic from downstream devices and clients to WSS. You must configure forwarding hosts in the Gateway that carry HTTP, HTTPS, and SSL traffic. The forwarding policy that is installed on the appliance directs traffic to the correct forwarding host as follows:
    • HTTP: Traffic must be forwarded on port
      8443
      (encrypted).
    • Unintercepted SSL: Traffic must be forwarded on port
      8080
      .
    • Intercepted SSL: A gateway appliance running SGOS 6.7.x or later supports the deployment option where the local proxy performs SSL interception and forwards the user authentication information in addition to traffic to the WSS on port
      8084
      .
  • Install the WSS root certificate and add it to the browser-trusted list if ProxySG is not set to intercept SSL. (See Install the Root Certificate).
  • Configure IP addresses. The best practice is one public IP for every 5000 users. For example, if you have 10,000 users on-premises whose connections must egress to WSS, then use two gateway proxies. Follow additional ProxySG setup guide for its IP address and port configuration.
  • Enable port randomization and ensure that Reflect Client IP is disabled.
  • Distribute the root certificate to endpoints.
    COMMENT: Ron said to remove this bullet, and make it an xref to proxySG info later in doc.

Enable the SSL Proxy Service on ProxySG

COMMENT: See Ron's comment about this section.
Perform the following procedure to enable configured HTTP services to handle SSL traffic.
See Configure SSL Proxy Services in an Explicit Deployment for more information.
  1. Obtain the PAC file for your ProxySG. The text of the PAC file will look similar to the following example.
    unction FindProxyForURL(url, host) { if( url.substring(0, 5) == "http:" ) { return "PROXY 192.168.1.209:
    8080
    ; DIRECT"; } else if( url.substring(0, 6) == "https:" ) { return "PROXY 192.168.1.209:
    8080
    ; DIRECT"; } else if( url.substring(0, 4) == "ftp:" ) { return "PROXY 192.168.1.209:
    8080
    ; DIRECT"; } else { return "DIRECT"; } }
  2. Read the PAC file to find the port number to which HTTP and HTTPS traffic is redirected. In the preceding example, the port is 8080 (shown in bold).
  3. Log in to the ProxySG management console.
  4. Click the
    Configuration
    tab and navigate to
    Services
    , and then select
    Proxy Services
    .
  5. Edit the
    Service
    , and mark the checkbox for
    Detect Protocol
    to ensure that the Detect protocol setting is enabled on all configured HTTP services, such as Explicit HTTP.
  6. On the right panel, in the Predefined Service Groups area, expand
    Standard
    and then expand
    Explicit HTTP
    .
  7. For the
    All-Explicit:port
    entry that matches the redirect port, change the setting from Bypass to Intercept.
  8. Click
    Apply
    to save the configuration.

Install the WSS Root Certificate

Install the WSS root certificate on the appliance and add it to the browser-trusted if ProxySG is not setup for SSL interception. This is required if the ProxySG appliance is forwarding any SSL traffic regardless of where the termination occurs.
Step 1: Obtain the WSS Root Certificate
  1. In the WSS portal, navigate to
    Policy
    , and then select
    TLS/SSL Interception
    .
  2. Expand the
    TLS/SSL Interception Certificate
    area.
  3. Click
    Download
    .
  4. Click
    Save File
    and save the certificate to an internally accessible location.
  5. Open the file with a text application, such as notepad.
  6. Copy the contents to the clipboard.
Step 2: Upload the Certificate to the ProxySG Appliance
  1. In the ProxySG Management Console, select
    Configuration
    , and then select
    SSL
    .
  2. Select
    CA Certificates
    from the navigation menu, and then select
    CA Certificates
    tab.
  3. Click
    Import
    , and do the following:
    1. Name the certificate. If you are replacing an existing certificate, then enter a different name.
    2. Paste the certificate from the clipboard into the
      CA Certificate PEM
      area.
    3. Click
      OK
      .
  4. Click the
    CA Certificate List
    tab.
  5. Select
    browser-trusted
    , and do the following:
    1. Click
      Edit
      .
    2. Locate and select the WSS root certificate.
    3. Click
      Add
      to move it to the browser-trusted field.
    4. If you are replacing the certificate, then select the old certificate and select
      Remove
      to remove the old one from the list.
    5. Click
      OK
      .
  6. Click
    Apply
    to enable the changes.
If you require more information about appliance certificate management, the see SGOS 7.2 Admin Guide (Chapter 65)

Create a Server Forwarding Host for HTTPS (Port 8443).

The forwarding host forwards HTTP traffic with an encrypted connection to the
Symantec
WSS.
  1. In the ProxySG Management Console, select the
    Configuration
    , and then select
    Forwarding
    .
  2. Select
    Forwarding Hosts
    , and then select
    Forwarding Hosts
    tab.
  3. Click
    New
    . The Management Console displays the Add Forwarding Hosts dialog.
  4. Create the WSS host by doing the following:
    1. Enter an Alias name the host. For example:
      WSSSecure8443
      .
    2. Enter the WSS Host name
      proxy.threatpulse.net
      unless you were given another service point name.
    3. Select
      Server
      .
    4. Clear the
      Ports: HTTP
      option.
    5. Enter
      8443
      in the Ports: HTTPS field.
    6. In the
      Host Affinity Methods
      field, select
      Client IP Address
      .
    7. In the
      Host Affinity Methods SSL
      field, select
      Client IP Address
      .
    8. Click
      OK
      to close the dialog.
  5. Click
    Apply
    .

Create a Proxy Forwarding Host for Unintercepted SSL (Port 8080)

The forwarding host forwards HTTPS, SSL, and TCP traffic to the WSS. Installed policy directs the traffic over port
8080
. If configured, then WSS intercepts SSL for policy inspection. This step is necessary to allow the ProxySG to trust WSS when it forwards HTTPS traffic.
  1. Remain on the Forwarding Hosts tab, and click
    New
    . The Management Console displays the Add Forwarding Hosts dialog.
  2. Create the WSS host by doing the following:
    1. Enter an Alias name for the host. For example:
      WSSHTTP8080
      .
    2. Enter the WSS Host name
      proxy.threatpulse.net
      (unless you were given another service point name).
    3. Select
      Proxy
      .
    4. Enter
      8080
      in the Ports: HTTP field.
    5. Click
      OK
      to close the dialog.
  3. Click
    Apply
    .
  4. If your ProxySG appliance deployment does not intercept SSL traffic locally, proceed to
    Step 6
    .

Create a Proxy Forwarding Host for Locally Intercepted SSL Traffic (Port 8084).

If your gateway ProxySG appliance is running SGOS 6.7.x or later and you have configured it to intercept some SSL traffic for local inspection and user authentication forwarding, then configure a forwarding host for port
8084
.
  1. Remaining on the Forwarding Hosts tab, click
    New
    . The Management Console displays the Add Forwarding Hosts dialog.
  2. Create the WSS host by doing the following:
    1. Enter an Alias name the host. For example:
      WSSInterceptedHTTPS8084
      .
    2. Enter the WSS Host name
      proxy.threatpulse.net
      (unless you were given another service point name).
    3. Select
      Proxy
      .
    4. Enter
      8084
      in the Ports: HTTP field.
    5. In the 
      Host Affinity Methods
      HTTP
      field, select
      Client IP Address
      .
    6. Click
      OK
      to close the dialog.
  3. Click
    Apply
    .

Configure a Content Policy Language Forwarding Policy

Follow the procedure in this section to create a Content Policy Language  (CPL) forwarding policy.
The policies in ProxySG are like an Access Control List (ACL) with source/destination and action. In this policy, you set the destination to the set of domains listed in the Domain of Interests file you downloaded from
CloudSOC
. You set the policy action to forward traffic to the forwarding host.
  1. Use a text editor to open the Gatelet domain list file or PAC file you downloaded from
    CloudSOC
    .
    The
    CloudSOC
    PAC file is used by existing proxy chaining customers.
  2. Open the
    CloudSOC
    domain list file or PAC file with a text editor so that you can copy SaaS service URLs from it.
  3. In the ProxySG Management Console, navigate to
    Configuration
    , then select
    Policy
    , and then select
    Visual Policy Manager
    .
  4. In the Visual Policy Manager area, click
    Launch
    .
  5. In VPM, select
    Policy
    , and then select
    Add CPL Layer
    .
  6. Use the contents of the
    CloudSOC
    domain list file to create a CPL policy layer that chains your SaaS services to the
    CloudSOC
    Gateway according to the following example.
    This annotated code sample chains Office 365, Dropbox, and an Okta developer instance to the
    CloudSOC
    gateway. Modify it as necessary to suit your needs:
    COMMENT: See Ron's comment about CASB and
    CloudSOC
    .
    ; Description: Defines the Office365 related ; Server URL domains that must be chained to ;
    CloudSOC
    Gateway. define condition CASB_Office365_protected_server_url server_url.domain="office365.com" server_url.domain="evernote.com" server_url.domain="sharepoint.com" server_url.domain="live.com" server_url.domain="login.microsoftonline.com" server_url.domain="outlook.com" server_url.domain="outlook.office.com" end ; ; Description: Defines the Dropbox related ; Server URL domains that must be chained to ;
    CloudSOC
    Gateway. define condition CASB_Dropbox_protected_server_url server_url.domain="dropbox.com" end ; define condition CASB_Okta_protected_server_url ; Description: Defines the OKTA (SSO) related ; URL domains that must be chained to ;
    CloudSOC
    Gateway. server_url.domain="securletbeatle.oktapreview.com" end ; ; Description: Defines a placeholder ; for the set of all Server URL domain conditions. define condition CASB_scan_required_server_url condition=CASB_Dropbox_protected_server_url condition=CASB_Office365_protected_server_url condition=CASB_Okta_protected_server_url end ; ; Description: Defines the forwarding layer that ; forwards traffic to
    CloudSOC
    Gateway and ; applies the forwarding action ; for all traffic matching the server url domain condition. ; Note 1 : ElasticaGW is defined in the "Forwarding Host" ; Note 2 : Set forward.fail_open to "no" or "yes" based on your ; requirements. <Forward> condition=CASB_scan_required_server_url \ forward(ElasticaGW) forward.fail_open(yes)
    COMMENT: See Ron's comment about <Forward>.
  7. Select
    File
    , and then select
    Install Policy
    on ProxySG Appliance to put the new forwarding policy into effect.
  8. Select
    File
    , and then select
    Exit
    to close the Visual Policy Manager.

Update the Proxy Forwarding Policy

The
Symantec
WSS Proxy Forwarding connectivity method requires policy that routes web traffic to the WSS service. The policies in ProxySG are like an Access Control List (ACL) with source/destination and action. In this policy, you set the destination to the set of domains listed in the Domain of Interest file you downloaded from
CloudSOC
. You set the policy action to forward traffic to the forwarding host. Specifically, the policy achieves the following:
  • To protect credential information in the headers, the policy forwards HTTP traffic over a secure connection.
  • The policy forwards HTTPS and SSL traffic in encrypted form.
  • The policy ignores all other traffic.
The following is the CPL template that should be appended to the existing ProxySG appliance local policy file.
  • The lines that begin with a semi-colon (
    ;
    ) are CPL comments that provide commentary regarding the purpose of each policy construct.
  • The forwarding host names are examples. You must enter host names that you defined in the preceding sections.
For easier copying, pasting and saving, right-click this ProxyForwardingCPL link and save the text file locally.
;;; $module=proxy_forwarding_cloudsoc.cpl; $version=1; ; ; ; Template for the Web Security Service Proxy Forwarding access method ; for
CloudSOC
-only customers ; ; Version Date: 20201123 ; ; ; This template can be installed on appliances running SGOS version 6.7.10 or later. ; 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_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_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_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_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)" ) set( request.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_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_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 ; Edit the following list to reflect the
CloudSOC
domains of interest ; define condition
CloudSOC
_Forward_List ; List the set of domains associated with enabled
CloudSOC
gatelets ; For example: ; server_url.domain="office365.com" ; server_url.domain="evernote.com" ; server_url.domain="sharepoint.com" ; server_url.domain="live.com" ; server_url.domain="login.microsoftonline.com" ; server_url.domain="outlook.com" ; server_url.domain="outlook.office.com" end ; Forward all
CloudSOC
domains of interest to WSS, as well as some domains ; needed by WSS itself. It should not be necessary to edit this list. ; define condition WSS_Forward_List condition=
CloudSOC
_Forward_List server_url.domain=notify.bluecoat.com end ; Enable SSL interception for all
CloudSOC
domains of interest ; <SSL-Intercept
CloudSOC
> condition=WSS_Forward_List ssl.forward_proxy(https) ; 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 ; <Forward Cloud> condition=WSS_Forward_List condition=!WSS_Forward_Bypass_List ; Unintercepted SSL url.scheme=(ssl, tcp) forward(WSSHTTP8080) ; Intercepted SSL url.scheme=https forward(WSSInterceptedHTTPS8084) ; Plaintext HTTP url.scheme=http forward(WSSSecure8443)