Configure Proxy Forwarding Control Using VPM Policy
Article ID: 173180
Updated On:
Products
Issue/Introduction
You want to send traffic to Web Security Service (WSS) via proxy forwarding and want to control the forwarding policy via VPM instead of CPL
Environment
ProxySG or ASG
Resolution
Follow the steps found here
Until you reach the section on creating policy for forwarding traffic to WSS
In VPM, in your Web Authentication Layer, add a rule to not authenticate traffic to specific WSS destinations
The combined object in the destination of the rule will have 3 WSS domains:
Create rules in your Web Access layer(s) which you will use to add the client IP, user, and group information to the headers for WSS forwarded transactions, and allow WSS control traffic:
Add a rule with WSSBypass (the same object you made for bypassing authentication for WSS destinations) as the destination and set the action to allow. This ensures WSS specific control traffic to Symantec WSS resources is allowed. Add another rule with the same destination object, then right click on it and select “negate”. Set the service object to the health check for WSS forwarders created earlier.
The action in this rule will be a combined action object consisting of three “Control Request Header” objects as seen below:
Adding this rule to the top of any web access layers will prevent the proxy from running through all of the policy in that layer if the traffic is going to be forwarded to WSS. This saves redundant processing and uses less resources on the proxy. If you want the rules in a layer to process on the proxy even if the traffic is going to be forwarded (could be less network traffic to WSS due to blocks happening on proxy, but uses more proxy resources) don’t add this rule to the layer. This rule must be matched in order for WSS to receive user, group, and client IP information so if you are opting not to use it to keep layers from processing locally that you put it into its own layer.
Next, add a forwarding layer or add rules to existing forwarding layer:
Add a rule to send direct the WSSBypass locations specified earlier using that combined object.
Add rules to send direct any sites you do not want to forward to WSS, and any local servers/subnets
Add a rule to send HTTP traffic to the 8443Secure forwarder you configured in the forwarding configuration of the proxy. Set the source object to whatever . The destination will be a server URL object as below (or a combined object using whatever trigger you want and the object shown below):
Add a rule to send HTTPS to the 8080 forwarder configured previously. The source object will be the AD group for users you want to send to WSS. The destination object will be a combined object that includes an HTTPS scheme server URL object (like the one for http but pick https) and a regex for URLs that start SSL: or TCP: (the actual value you will enter in the regex field is ^(SSL|TCP):
If you are performing SSL Interception on the proxy, you will add an object to source for the categories you are not decrypting. Then you will add a rule below this with the forwarder for 8084 and the same destination object for HTTPS Scheme and SSL|TCP: regex but won’t add the categories (this rule will be for traffic you ARE decrypting on the proxy) The additional rule assumes you don’t have a rule preventing the decryption from taking place on the local proxy when the traffic would be forwarded. If you are preventing the decryption rules when forwarding this rule is unnecessary.
Add a layer guard with a Health check service object for the WSS8080 forwarder (alternatively, add that service object directly to the forwarding rules. This would be useful if you have other forwarders, but leads to more unnecessary processing if you don’t)
There are some things that still can’t be achieved with VPM, so we will add a CPL layer to cover them.
Add a CPL layer with the following (taken from the cpl found here)
“
<Cache Cloud_Verify_Cached_Authorization> condition=!WSSBypass
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=!WSSBypass
; 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
define action WSSConnectHeaders
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
; 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,
; uncomment the line below:
<Forward SSLHeaders> group=Domain\WSSGroup "is_healthy.fwd.threatpulsehttp8080"=yes ; Guard Rule
[Rule Encrypted_traffic] proxy.port=(443, 8080) url.scheme=(https,ssl,tcp)
action.WSSConnectHeaders(yes)
“
The first section of this CPL sets a username of “Refresh User” for requests originating from the proxy itself and handles certain caching behavior to force verification of the resource. This is done in CPL because the trigger “has_client” isn’t available in VPM. The second part is for sending the user, group, and IP information in connect headers because there’s no set forward.http_connect header action in VPM.
Attachments
Feedback
