Configuring the web isolation feature on the ProxySG appliance

search cancel

Configuring the web isolation feature on the ProxySG appliance

book

Article ID: 201609

calendar_today

Updated On:

Products

ProxySG Software - SGOS

Issue/Introduction

The Symantec Web Isolation solution is a client-less solution that enables and protects users to browse the internet safely on any device using any browser. The zero footprint negates the need for software installation on clients. Starting in SGOS 7.3.x, you can easily configure the ProxySG appliance to forward HTTP and HTTPS requests to a Web Isolation service. You can then write policy to make decisions concerning the isolated traffic.

The default Symantec cloud Web Isolation service is pre-integrated with automatic defaults and requires minimal additional configuration on the appliance through Visual Policy Manager (VPM) or content policy language (CPL) policy.

Alternatively, you can configure the appliance with your existing dedicated cloud or on-premises isolation service. This requires more advanced configuration through the CLI and Web VPM or CPL policy.

Note: In this phase of Web Isolation, you can use the integrated Web Isolation solution with a dedicated web isolation service. In the future, the default Symantec cloud Web Isolation service will also be available for customers that do not have a dedicated web isolation service.

Warning: Isolation policy using the Isolate action is only available in the Web VPM. Its use is not supported with the Legacy Java VPM. Isolate actions will be removed when opening the Legacy Java VPM.

Resolution

Requirements to use Web Isolation

SGOS 7.3.x and later
(Optional) Management Center 1.1.3.1 and later
SSL interception policy to isolate HTTPS requests
(Custom isolation service only) Determine the following:
- FQDN or IPv4/IPv6 address of the isolation service host
- Port to use for proxying HTTP/S requests
- Whether or not to secure connections to the isolation server, including sensitive header information

Configuration Differences

Before proceeding, review the following comparison of the default cloud isolation service configuration versus the custom isolation service configuration.

Settings and options	Cloud isolation service	Custom isolation service
Configuration settings (service, device profile, server CCL)	These settings are pre-configured and do not require modification.	Configure the settings appropriately and as required for the on-premises service, using the CLI or (via Management Center) the ProxySG Admin Console.
Sending headers to the isolation service	Specify the headers to send to the isolation service using the CLI or (via Management Center) the ProxySG Admin Console.
Types of traffic to intercept	The cloud isolation service supports isolation of requests that are uncategorized and threat risk level 5 or higher.	There are no categorization or threat risk level restrictions for a custom isolation service.
Enabling isolation policy	Configure web isolation policy using VPM or CPL to: determine what traffic to isolate SSL intercept the traffic to isolate

Note: You cannot enable the cloud isolation service and a custom service at the same time.

Considerations and Limitations

Configure policy for HTTPS interception appropriately to ensure that the HTTPS requests you want to isolate are forwarded to the isolation service as intended.
If the default policy is DENY, you must allow the HTTPS requests you want to isolate by specifying the ALLOW rule and isolation rules in separate layers. In CPL, the isolation rules can be in the same layer as ALLOW if they are on the same line.
When policy includes rules for isolation and forwarding/SOCKS gateway forwarding, and a given request matches both isolation policy and forwarding policy, the ProxySG appliance sends the request to the Web Isolation service.
When policy includes rules for isolation and URL rewrite, and a given request matches both isolation policy and URL rewrite policy, the request might not be isolated. As a workaround, compose policy so that requests you want to isolate are not subject to URL rewrite rules.
Web Isolation is not supported for HTTPS reverse proxy transactions.
Web Isolation is a cloud-based service and does not have access to internal resources. Internal domains that are uncategorized and internal IP ranges must be bypassed from Web Isolation.

Upgrade/Downgrade Considerations

In version 7.3.6 and later, the default port is 443 instead of 8080. If you currently use the default web isolation service hostname and port, upgrading will change the port from 8080 to 443. If you then downgrade to version 7.3.5 or earlier, the configuration retains the port 443 setting. If you configured a custom web isolation service, issuing the #(config isolation) service cloud command in version 7.3.6 reverts the service to default settings, including the new default port. Issuing the command in versions up to 7.3.5, however, will reset the port to 8080. In this case, issue the #(config) isolation service isolation-jump.prod.fire.glass secure 443 command to use the default service.
If you are running version 7.1.x or 7.2.x and have an existing forwarding policy for an on-premises or cloud isolation service, you can continue to use your custom service after an upgrade to version 7.3.x. After an upgrade, specify the isolation server's hostname (and port, if applicable) using the following CLI command:


#(config) isolation
#(config isolation) service <hostname> {secure|non-secure} [<port>]

Alternatively, if you have Symantec Management Center, you can use the ProxySG Admin Console 1.1.3.1 to configure the hostname, port, and secure/non-secure mode.

If you have configured web isolation with forwarding hosts, you can disable the Web Isolation service to allow forwarding-based isolation to work as intended. The command to disable the service is available in version 7.3.4:

#(config) isolation
#(config isolation) disable

If you are upgrading from 7.1.x or 7.2.x, have an existing forwarding policy for an on-premises isolation service, and want to use Symantec’s cloud isolation service, you must first remove the existing policy. Then, follow the steps in Configure the Cloud Web Isolation Service.

Configure the Cloud Web Isolation Service

The cloud isolation service comes with presets and thus requires minimal configuration.

Step 1: Send HTTP headers to the isolation service

You can send originating client IP address, authenticated user, or authenticated group details in the HTTP headers of traffic forwarded to the isolation service.

In the CLI, issue the following command:


#(config isolation) send {authenticated-user | authenticated-groups | client-address}

You can send one or more of the available headers. For best security, enable Web Isolation in secure mode when sending headers.

Alternatively, if you have Management Center version 1.1.3.1 or later:

Launch the ProxySG Admin Console.
In the Admin Console, select Administration > Data Services > Isolation.
In the Isolation section, for Include Headers, select one or more of the options:

User: Authenticated user (X-Authenticated-User).
Group: Group of the authenticated user (X-Authenticated-Groups).
Client Address: Originating client IP address (X-Forwarded-For).

Select Save to apply the changes.

Step 2: Create Web Isolation policy

To enable or disable Web Isolation in policy rules, use the Web VPM or CPL. These instructions are for the Web VPM.

To create Web Isolation policy:

Log in to the ProxySG Management Console.
In the Management Console, select Configuration > Policy > Visual Policy Manager and click Launch VPM.
Alternatively, go to https://<IP_address>:8082/Secure/Local/console/mc_vpm.html.
In the Web VPM, click Add Layer. The Add a Layer dialog displays layer types.
Note: If the default policy is DENY, add an ALLOW rule to a separate layer.
Select one of the layers that supports the Web Isolation action object: Web Access or Web Request. Then, click OK.
Click Add rule. The new rule is added to the layer.
In the policy rule, under Action, select Set and click Add a new object. In the list of objects, select Web Isolation.

Specify the isolation behavior for traffic matching this policy rule:

Select Do not isolate to disable web isolation. This option is selected by default.
Select Isolate to enable web isolation.
Specify additional behavior when isolation is enabled (note that only the If the isolation service is unavailable setting is functional in the initial release):

Attribute	Description	Availability
Read-only, prevent user from entering data	Make isolated web pages read-only to the user.	These attributes are functional only when and if implemented on the isolation service you use. These attributes are not yet supported in the cloud isolation service.
(Available when the previous option is selected) Allow user to override read-only	Allow the user to override read-only pages.
Show a web isolation border	Display an indication that the requested web page was isolated.
Do not log connection details	Do not log details about isolated traffic in the isolation service log. Note: For access logging on the ProxySG appliance, see Troubleshooting.
If the isolation service is unavailable	Specify the behavior if the isolation service is unavailable: Fail closed, deny the request (recommended): Deny the request. Fail open, continue without web isolation: Process the request and send it directly to the origin content server.	Always supported.

Click Apply > Set to save the object.
Make other policy changes as needed and then click Apply Policy to install policy.

Note: Make sure to exclude all internal traffic from web isolation. Add a rule that includes internal IP ranges and domains and set it to Do not isolate. See the following Example for more information.

Example: Write isolation policy in the Web VPM

This example describes how to create the following VPM policy:

Specify internal IP addresses and domains.
Disable Symantec Web Isolation for requests matching these internal sites.
Specify requests from authenticated users for certain categories of URLs.
Enable Symantec Web Isolation for requests matching these users and categories, and block requests if the isolation service is unavailable.
Set a policy ID to determine the frequency of policy rule hits in access logs.

Note: If preferred, you can refer to the CPL for this example.

Log into the VPM:

Log in to the ProxySG Management Console.
In the Management Console, select Configuration > Policy > Visual Policy Manager and click Launch VPM.

Create policy objects for internal traffic:

To create VPM objects for internal domains and servers, select Operations > View All Objects.
In the All Objects list, select Add a new object and add the following objects from the list (use the search function if needed):
- Destination IP Address & Subnet: Specify an internal IP Address. Create one object for each IP address/subnet to exclude from isolation.
- Request URL: Specify an internal URL (can be a URL or an IP address). Create one object for each URL/address to exclude from isolation.
In the All Objects list, select Add a new object > Combined Destination Object and combine objects created in the previous step. In this example, you want to create distinct combined objects for internal servers and two sets of internal domains:
- Add all Destination IP Address & Subnet objects to a combined object you name internal_servers.
- Add all Request URL objects specifying domains to a combined object you name internal_destinations1.
- Add all Request URL objects specifying IP addresses to a combined object you name internal_destinations2.
- Add internal_destinations1 and internal_destinations2 to a combined object you name do_not_isolate_internal_destinations.
Add a Web Access layer. Select Add Layer > Web Access > Add.
In the Add New Web Access layer dialog, enter a layer name and click OK.
In the layer rule, under Destination, select Set and click Add a new object. In the list of objects, select the internal_servers combined object.
Under Action, select Set and click Add a new object. In the list of objects, select Web Isolation. Set the object to Do not isolate.
Click Apply > Set to save the object.
Add another rule to the layer. under Destination, select Set and click Add a new object. In the list of objects, select the do_not_isolate_internal_destinations combined object.
Under Action, select Set and click Add a new object. In the list of objects, select Web Isolation. Set the object to Do not isolate.
Click Apply > Set to save the object.

The Web Access Layer has the following rules configured:

Create policy objects for certain requests coming from authenticated users:

Select Add Layer > Web Access > Add to add another Web Access Layer.
In the layer rule, under Source, select Set and click Add a new object. In the list of objects, select Authenticated User and click Apply > Set.
Under Destination, select Set and click Add a new object. In the list of objects, select Request URL Category. Name the object categories_to_isolate, select categories, and click Apply > Set.
Under Action, select Set and click Add a new object. In the list of objects, select Web Isolation.
Specify the isolation behavior for traffic matching this policy rule.
Click Apply > Set to save the object.
Under Track, select Set and click Add a new object. In the list of objects, select Policy ID. Enter a policy ID and click Apply > Set.

The Web Access Layer has the following rule configured:

Click Apply Policy to install policy.

If Web Isolation does not occur as expected, review Troubleshooting.

Configure a Custom Web Isolation Service

Configuring a custom isolation service requires more advanced configuration through the ProxySG CLI (or ProxySG Admin Console) and VPM/CPL. These instructions are for the CLI and CPL.

Step 1: Enable the custom Web Isolation service

(Version 7.3.4 and later) If the Web Isolation service was disabled previously, make sure that it is enabled before configuring Web Isolation policy. Otherwise, policy compilation warnings occur, such as "Warning: 'isolate' Isolation service is disabled; it must be enabled in order to use the isolate action using the CLI isolation->enable command"; in addition, the appliance will return exception pages for traffic matching the isolation rules.

#(config) isolation
#(config isolation) enable

(All versions) Configure the service using the ProxySG CLI:

Log in to the CLI and enter #(config) mode.
Enter isolation mode:
```
#(config) isolation
#(config isolation)
```
Specify the isolation service hostname and port, and whether or not to wrap HTTP/S requests inside an SSL tunnel:
```
#(config isolation) service <hostname> {secure | non-secure} [<port>]
```
where:
- hostname: Hostname or IPv4/IPv6 address for the custom isolation service.
- secure: Send HTTP/S requests wrapped inside an SSL tunnel to the isolation server. To use this option, you must ensure that the isolation service supports SSL tunnel termination, and specify an SSL device profile to secure the SSL tunnel to the isolation service.
- non-secure: Do not use an SSL tunnel to the isolation server. If you currently use non-secure mode for an-premises service and want to change to a cloud service that supports SSL termination, specify secure mode.
  Note: Specifying non-secure means that HTTP/S requests are not sent inside an SSL tunnel. If you forward headers using the #(config isolation) send command, the headers are not encrypted.
- port: Port for the isolation server. If unspecified up to version 7.3.5, port 8080 is the default for secure and non-secure connections. In version 7.3.6 and later, port 443 is the default for secure and non-secure connections.

Step 2: Configure custom Web Isolation service settings

Note: If you use Management Center, you will be able to use ProxySG Admin Console 1.1.3.1 or later to configure these settings.

The Web Isolation settings are set to the cloud isolation service defaults. In the CLI, configure different settings if:

You specified secure in the previous step. You must also specify an existing SSL device profile to use for securing the HTTP/S requests to the isolation service over a secure tunnel. This device profile specifies the client certificate and the CA to use for validating the certificate from the isolation service SSL tunnel terminator:
```
#(config isolation) tunnel-ssl-device-profile <SSL_device_profile>
```
Note: This device profile is not used to validate the isolated traffic. After the SSL tunnel to the isolation service is terminated, the HTTP/S requests are forwarded to the isolation service and the ProxySG appliance will use the bluecoat-isolation or specified server-ccl to validate the isolation proxy certificate.
See #(config isolation) server-ccl <server_CCL_name> for more information.
You want to use an existing SSL keyring other than the default for SSL interception:
```
#(config isolation) issuer-keyring <keyring>
```
Specify a keyring that contains the correct certificate for SSL interception for your deployment. Otherwise, the appliance uses the default keyring. The specified keyring is used for SSL interception of Shared Isolation Domains.

After specifying a different keying for SSL interception, or if you change back to the default keyring, clear both the ProxySG cache (using # clear-cache command) and the browser cache.

Note: To isolate HTTPS requests, enable SSL interception and write policy that includes SSL intercept rules for the traffic you want to isolate. SSL intercept policy should use this keyring for the isolated traffic.
If not using cloud, specify a CCL to validate the isolation server certificate used for isolated requests.
For instructions on creating a CCL and adding CA certificates to the list, refer to “Managing CA Certificate Lists” in the SGOS Administration Guide.
```
#(config isolation) server-ccl <server_CCL_name>
```
Otherwise, the appliance uses the bluecoat-isolation CCL.
Note: See #(config isolation) tunnel-ssl-device-profile <SSL_device_profile> to specify the device profile used to secure connection to the isolation service.
You want to send originating client IP address, authenticated user, or authenticated group details in the HTTP headers of traffic forwarded to the isolation service:
```
#(config isolation) send {authenticated-user | authenticated-groups | client-address}
```
You can send one or more of the available headers. For best security, enable Web Isolation in secure mode when sending headers.
To disable sending headers, use the following command:
```
#(config isolation) no send {authenticated-user | authenticated-groups | client-address}
```
Tip: After you configure a custom service, you can use the #(config isolation) service cloud command to revert to default settings if needed.

Step 3: Verify Web Isolation

To display the current Web Isolation configuration, use #(config isolation) view CLI command. The following is an example of what the configuration might look like:

#(config isolation) view

Issuer keyring: default
Server CCL: bluecoat-isolation
Service: isolation.company.com secure 443
Tunnel SSL device profile: bluecoat-isolation-tunnel
Attributes sent in requests:
Authenticated user: no
Authenticated groups: no
Client address: no

Tip: Using the command > show isolation provides the same information.

Examples: Write Web Isolation CPL

See below for an example of web isolation policy in CPL. The web VPM Web Isolation object provides the same Web Isolation policy as the CPL, except for the following gestures which have no VPM equivalent:

You can use the isolated= condition to test if Web Isolation was enabled for a transaction (based on the isolate() property/Web Isolation object) and status of the Web Isolation service. The condition tests yes if the service status is healthy and the request is isolated; it tests no if the service status is not healthy, or is healthy but the request is not isolated.
You can use the set() action to set or substitute isolated request headers. Refer to the Content Policy Language Reference for details on supported headers.

See the CPL below for examples of usage.

Note: The properties in bold text will be functional in a future release.

; internal servers and addresses to exclude from isolation

define condition do_not_isolate_internal_destinations
  condition=internal_destinations1
  condition=internal_destinations2
end condition do_not_isolate_internal_destinations

define subnet internal_servers
  <list_of_IP_addresses>
end subnet internal_servers

define condition internal_destinations1
  url.domain="internal1.company.com"
  url.domain="internal2.company.com"
end condition internal_destinations1

define condition internal_destinations2
  url.domain="199.81.216.140"
  url.domain="204.135.8.16"
  ...
end condition internal_destinations2


; request categories to isolate

define condition categories_to_isolate
  url.category=(<list_of_categories>)
end condition categories_to_isolate

; do not isolate traffic to the specified destinations
<Proxy>
  condition=do_not_isolate_internal_destinations isolate(no)
  url.address=internal_servers isolate(no) 

; isolate authenticate user requests to sites with the specified categories
<Proxy>
  authenticated=yes condition=categories_to_isolate isolate(yes) isolate.fail_open(no) 

; SSL-intercept requests matching the specified condition
; and using the default keyring
<SSL-Intercept>
 condition=ssl_intercept_list ssl.forward_proxy(https) ssl.forward_proxy.issuer_keyring("default")

; when condition is met, isolate traffic using the specified settings
<Proxy>
  condition=isolation_match_criteria isolate(yes) isolate.read_only(yes) \
    isolate.read_only.allow_override(no) isolate.display_banner(yes) isolate.disable_logging(no) \
      isolate.fail_open(no) action.set_isolation_header(yes)

; block uncategorized requests that weren't isolated
<SSL>
condition=non_isolation_uncategorized deny

; define condition for traffic to SSL-intercept
define condition ssl_intercept_list
 <list_of_categories_and_other_criteria>
end condition ssl_intercept_list

; define condition for isolating HTTP and HTTPS traffic
; HTTPS sites must be SSL-intercepted for isolation to work
define condition isolation_match_criteria
 <list_of_urls_and_other_criteria>
end condition isolation_match_criteria

; define action to set the specified isolation header as x-client-address substitution
define action set_isolation_header
  set(isolate.http_connect.header.x-Forwarded-For,"$(x-client-address)")
end action set_isolation_header

; define condition for non-isolated URLs to block
define condition non_isolated_uncategorized
 url.category=none isolated=no
end condition non_isolated_uncategorized

If Web Isolation does not occur as expected, review Troubleshooting.

Remove or Disable Web Isolation Policy

Up to version 7.3.3, you can simply uninstall Web Isolation policy if you no longer want to use it.

In version 7.3.4 and later, you must uninstall the Web Isolation policy and then disable the service. Disabling the service before removing policy will return exception pages for traffic matching the isolation policy rules. Disable the service using the CLI:

#(config) isolation
#(config isolation) disable

Troubleshooting

If you encounter browser error messages or other unexpected behavior after making configuration changes, clear both the ProxySG cache (using # clear-cache command) and the browser cache and test the configuration again.
If the default policy is DENY and isolation policy only works when you change the default to ALLOW, you must specify an ALLOW rule and isolation rules in separate layers. In CPL, the isolation rules can be in the same layer as ALLOW if they are on the same line, as in the following example:
<Proxy>
condition=do_not_isolate_internal_destinations isolate(no) ALLOW
If users receive exception pages for requests that should be isolated, see the previous section Remove or Disable Web Isolation Policy.
If Web Isolation policy does not behave as expected, you can review the access log to check if requests are isolated. In the Management Console, select Configuration > Access Logging > Formats. Create a new log format or edit an existing one, and add the x-isolated access log field to it. If policy includes the isolated= gesture, the access log will indicate yes or no as well as the protocol and URL for the transaction.
If there are issues with isolating HTTPS requests, check if policy is configured correctly to intercept the HTTPS traffic that you want to forward to Web Isolation.
You can also check the health status of the Web Isolation service. In the Management Console, select Statistics > Health Checks. On the Health Checks tab, look for the iso.server health check. The following example shows a failed health check:

A failed health check might indicate an error in configuration. Review the steps in Configure the Cloud Web Isolation Service or Configure a Custom Web Isolation Service.

Attachments

Feedback

thumb_up Yes

thumb_down No