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 WSS (Web Security Service).
This document is written in a brand-neutral language.
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.
Here are the required proxy capabilities:
Cloudsoc is already connected with WSS (Connecting Cloudsoc with WSS)
Each gatelet has a list of domains, those domains need to be grouped on one container to facilitate the configuration of the next steps.
Please note that the proxy does not automatically sync the domains with Cloudsoc nor with WSS, this list of domains need to be updated manually whenever there is a change on the activated gatelets list (activate or deactivate)
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)
Also, the internal IP addresses (private IP addresses which are defined in RFC1918) need to be added to the exclusion list
; “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
; 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
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.
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 (WSS SSL Decryption Certificate FAQs and how to download it can be found )
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.
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.
|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.
; Upon user authentication,
; pass the user-name and groups to WSS.
<Proxy Cloud_Auth> condition=!WSS_Proxy_Bypass_List
; 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)" )
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:
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”
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”
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 (WSS), 2. The protocol, and 3. The TCP port user.
Here are the three hosts:
|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
|1||SSL and TCP||Host No 1|
|2||HTTPS||Host No 2|
|3||HTTP||Host No 3|
; 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
; Plaintext HTTP
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.
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”
; 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.
define action Cloud_Auth_Refresh_Traffic
set( request.x_header.BC_Auth_User, "UmVmcmVzaCBVc2Vy" )
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.
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:
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:
A second option would be to use the user “import” feature.
Here are the links from the knowledge base of Cloudsoc:
The third option is to modify the user account manually, this is typically used for testing.
The steps to follow are:
The final screen would look like this: