Setting Up Proxy Forwarding to CloudSOC Gateway

Products

• CASB Gateway
• CASB Gateway Advanced

Issue/Introduction

Objective:

The objective of this document is to provide a general description on how to configure an intermediary network device to forward the traffic to Cloudsoc Gateway via Cloud SWG (formerly known as WSS  - Web Security Service -). 

This document is written in a brand-neutral language. 

Disclaimer:

This document is written on a best-effort basis to provide some level of guidance to the Cloudsoc customers. It is not intended to replace any vendor specific technical documentation.

Also, please be aware that each technology has its own specifics, make sure to work with your vendor support team for more detailed information and to get assistance for any technical issues.

Environment

Technical Requirements

Here are the required proxy capabilities:

• SSL Decryption
• User authentication (Active Directory)
• Inject custom HTTP headers with custom values
• Conditional forwarding

Network requirement:

• On-Prem proxy to be able to access Cloud SWG IP Range(s) over three ports (8080,8084,8443) 

Prerequisite

Cloudsoc is already integrated with CloudSWG / WSS - (Connecting CloudSOC with Cloud SWG (Formerly WSS))

Resolution

Define CloudSOC traffic:

Traffic to Include:

Each gatelet has a list of domains, those domains need to be grouped on one container to facilitate the configuration of the next steps.

• First make sure to enable the gatelets of interest on the CloudSOC store.
• Download the list of domains from the CloudSOC portal (Settings > Gateway > “Download domain name list”)
• Group the domains on one container on the proxy (Custom condition, or category …etc)

Please note that the proxy does not automatically sync the domains with CloudSOC nor with CloudSWG/WSS, this list of domains need to be updated manually whenever there is a change on the activated gatelets list (activate or deactivate)

Traffic to exclude:

WSS management traffic needs to be treated differently than the end user traffic, for this reason, these domains need to be defined on a separate container (Category, customer condition ..etc)

• CloudSWG/WSS Portal: portal.threatpulse.com
• Remote clients: ctc.threatpulse.com
• Authentication: auth.threatpulse.com

Also, the internal IP addresses (private IP addresses which are defined in RFC1918) need to be added to the exclusion list

Example from Symantec ProxySG 

; “semi colon” for comments
; 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  ; CloudSWG / WSS portal
    server_url.domain=ctc.threatpulse.com     ; Remote Clients
    server_url.domain=auth.threatpulse.com    ; Authentication
end

SSL Decryption:

The end user traffic destined to CloudSOC, needs to be decrypted in order for the proxy to add the user authentication details.

Use the traffic definitions created on step one to enforce the SSL decryption on it.

The logic of the configuration should satisfy this requirement:

If the traffic is destined to CloudSOC and if it is not one of the excluded domains then do the SSL decryption.

SSL Trust chain:

In order for the traffic to be SSL trusted end-to-end, there are two conditions to be considered:

1- End points (End user machines) need to trust the certificate used by the proxy for the SSL decryption. And it should be trusted as a root certificate. In other words, add the proxy SSL decryption certificate to the “Trusted Root Certificate” store of the endpoints.

2- The proxy needs to trust the WSS SSL Certificate as a Trusted Root Certificate, in other words, add the WSS SSL decryption certificate to the Trusted Root Certificate container of the proxy (Cloud SWG SSL Decryption Certificate FAQs and how to download it can be found )

Create a Location in CloudSWG/WSS Threatpulse portal:

Create a fixed Location in the Cloud SWG portal. A Location instructs the CloudSWG/WSS to accept incoming connections from the Proxy's Public IP address.

1. In the CloudSWG portal, navigate to Connectivity > Locations.

2. Click Add Location.

3. Enter the Location and the required information.

4. Click Save.

End user authentication:

User Authentication against the internal active directory:

The proxy infrastructure typically authenticates all the end users traffic against the on-prem active directory infrastructure. If that’s not the case then the interesting traffic of CloudSOC has to be authenticated separately.

Note that CloudSOC by default does not tolerate the unauthenticated users and it rejects their traffic by default, though CloudSOC can be configured to accept the unauthenticated users, like the case of the guest users, this is not covered here, please contact CloudSOC Support if needed.

Passing the end user authentication details to CloudSOC:

Once the end user session is authenticated, then the proxy needs to pass the authentication values to CloudSOC, this is done via custom HTTP headers. 

Header Name	Value	Format	comment
BC_Auth_User	User id	Base 64 encoded	Domain\User or User
BC_Auth_Groups	Groups	Base 64 encoded	comma separated list
Client-IP	Client IP Address	Plain text	For event reporting

This is normally done via policies where it uses the traffic defined on the first step.

The final logic of the policy would be:

If the traffic is destined to CloudSOC and if it is not one of the excluded domains then insert the three HTTP custom headers with the proper values as indicated in the table above.

Example from Symantec SWG / ProxySG

; Upon user authentication,
; pass the user-name and groups to Cloud SWG / WSS.
;
<Proxy Cloud_Auth> condition=!WSS_Proxy_Bypass_List
    authenticated=yes action.Auth_Cloud(yes)
; User and Group information are passed to CloudSWG / 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

Traffic Forwarding

The proxy needs to be configured to send the traffic conditionally based on the traffic protocol, this is done for two reasons, first to encrypt the end user data if it is sent plain text format, and second to handle each protocol differently (HTTPS, HTTP, TCL).

The proxy needs to handle three cases:

• Non-Decrypted SSL traffic: 

In case of the sessions where the end user traffic is sent encrypted over SSL or TCP protocol, traffic needs to be directed/forwarded to “proxy.threatpulse.net” over port 8080 using HTTP Protocol.the next hop type is “Proxy”

• Decrypted HTTPS Traffic: 

In case of the sessions where the end user traffic is sent as HTTPS protocol, traffic needs to be directed/forwarded to “proxy.threatpulse.net” over port 8084, with the affinity enabled the Client IP Address, and the next hop type is “Proxy”

• Plain text - HTTP Traffic: 

If the traffic protocol is HTTP then the end user traffic needs to be sent to “proxy.threatpulse.net” over port 8443 over HTTPS, with the affinity enabled on the Client IP Address, the next hop is a “server”

Here is a summary of the above:

Protocol	Forward to	TCP Port	Affinity	Next hob type
SSL and TCP	proxy.threatpulse.net	8080		Server
HTTPS	proxy.threatpulse.net	8084	Client IP Address	Proxy
HTTP	proxy.threatpulse.net	8443	Client IP Address	Proxy

The implementation of the above depends on the proxy brand used, In some of the proxy brands, this is done in two steps:

1- define the forwarding host (forwarding destination), on this step three parameters are required: 1. The destination host (CloudSWG / WSS), 2. The protocol, and 3. The TCP port user. 

Here are the three hosts:

No	Destination	TCP Port	Protocol	Affinity
1	proxy.threatpulse.net	8080	HTTP
2	proxy.threatpulse.net	8084	HTTP	Client IP Address
3	proxy.threatpulse.net	8443	HTTP	Client IP Address

 

2- Configure the proxy to forward the traffic based on protocol to the appropriate forwarding host configured on the previous step 

No	Protocol	Forward to
1	SSL and TCP	Host No 1
2	HTTPS	Host No 2
3	HTTP	Host No 3

 

Example from Symantec SWG / ProxySG:

; 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)

Contents Caching

End user traffic

The recommendation is to leave the content caching enabled on the CloudSOC traffic, and also to keep the content freshness verification active. In this case, the proxy always confirms the freshness of the contents and at the same time avoids serving stale content.

Proxy caching control 

Some proxies run caching control tasks to ensure the freshness of the cached contents; This type of traffic is initiated by the proxy itself without the existence of any live user traffic. In this case the authentication can get in the way and to avoid those conflicts, the proxy can mark this traffic as authenticated by a special user id “Refresh User” , similar to the authentication process done before.

The logic of the policy here is

If the traffic is a cache freshness traffic, then mark the “BC_Auth_User” with the base64 value of “Refresh User” which is “UmVmcmVzaCBVc2Vy”

Example from Symantec SWG / ProxySG

<Cache> condition=!WSS_Proxy_Bypass_List
    always_verify(yes)
 
; 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.
; WSS_Proxy_Bypass_list = WSS Exclusion list.

<Cache> condition=!WSS_Proxy_Bypass_List
    has_client=false action.Cloud_Auth_Refresh_Traffic(yes)
 
define action Cloud_Auth_Refresh_Traffic
    set( request.x_header.BC_Auth_User, "UmVmcmVzaCBVc2Vy" )
end

User account mapping:

The final step in this process is to define the secondary user id on CloudSOC which should match the user name provided to the proxy during the on-prem authentication process. It is very important that the secondary user id matches exactly the user id.

Commonly in most of the Microsoft Windows environment, the authenticated user id format is the NetBIOS format [DOMAIN\USERID].

While in the Mac machines the authenticated user id format is [USERID] without the domain name.

The command line “whoami” can be executed at the endpoint to display the exact format of the user id.

The secondary user id can be assigned via the Active Directory Sync Service done via the on-prem SpanVA instance. It can also be modified via the user accounts bulk uploads, or it can be done manually.

Sync the secondary user id from AD directly

Assuming that SpanVA is already deployed and the AD Sync is working properly.

The secondary user id’s can be mapped to any of the populated LDAP attributes that were synced via SpanVA. 

Commonly , msDS-PrincipalName attribute is used as a secondary user id. Confirm this with your Active Directory team for confirmation.

The steps to map it the secondary user id to a specific LDAP Attribute are as follows:

1. Log in to CloudSOC Console 
2. Navigate to the settings screen (gear icon on the top left side)
3. Click on “CloudSOC SpanVA” , then on “SpanVA Setup” Tab
4. At the bottom of the screen, there is a section named “SpanVA Secondary User Attribute”
5. The dropdown populates all the available LDAP Attributes that can be used as a secondary user id.
6. Select the best option for you and save.

Note: if nothing is populated here, then SpanVA did not sync with AD, make sure that it sync’s at least once.

The final result would look like this:

Create or update the secondary user id via the bulk upload

A second option would be to use the user “import” feature.

Here are the links from the knowledge base of CloudSOC:

• Importing users and groups 
• Using batch edit to modify multiple users

Modify the secondary user manually

The third option is to modify the user account manually, this is typically used for testing.

The steps to follow are:

1. Login to CloudSOC console
2. On the top banner, click on “Users” then “Users”
3. Search or Locate the user account to be modified
4. Modify the secondary user id manually
5. Save

The final screen would look like this:

Additional Information

Note:

1. Authenticate Cloudsoc Users using their Primary ID's (Email Addresses) without the need for Secondary user id 

References:

1. Cloud SWG (formerly WSS) ingress and egress addresses 
2. Cloud SWG (formerly WSS) Root CA update Frequently Asked Questions (FAQs) 
3. Setting up Proxy Forwarding to CloudSOC using Symantec ProxySG 
4. Managing Users in CloudSOC
5. CASB to Cloud SWG Topography (The traffic flow description)