Setting Up Proxy Forwarding

Technical Requirements

This section provides a high-level set of technical requirements to perform this configuration.
Symantec
recommends using the WSS Agent connectivity method from the current
CloudSOC
Proxy Chaining instead of using Proxy Forwarding.
  1. Enable Gatelets for the SaaS apps that you use in the
    CloudSOC
    Store from the
    CloudSOC
    console. See the relevant
    CloudSOC
    Tech Notes for more information.
  2. 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.
    • Identify the egress IP address.
  3. 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.
  4. 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
      .
  5. 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).
  6. 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 the SSL Proxy Service on ProxySG

Perform the following procedure to enable configured HTTP services to handle SSL traffic.
  1. Log in to the ProxySG management console.
  2. Click the
    Configuration
    tab and navigate to
    Services
    , and then select
    Proxy Services
    .
  3. 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.
  4. 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
    .

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
    .

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)