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. If you add Isolate actions to policy through the Web VPM, the actions are removed if you open the Legacy Java VPM.
Before proceeding, review the following comparison of the default cloud isolation service configuration versus the custom isolation service configuration.
Settings and options |
Configuration |
Configuration settings (service, device profile, server CCL) |
Default service: These settings are pre-configured and do not require modification. Custom service: 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 |
Default service and custom 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 |
Default service: The cloud isolation service supports isolation of requests that are uncategorized and threat risk level 5 or higher. Custom service: There are no categorization or threat risk level restrictions for a custom isolation service. |
Enabling isolation policy |
Default service and custom service: Configure web isolation policy using VPM or CPL to determine what traffic to isolate and SSL-intercept the traffic to isolate. |
Note: You cannot enable the cloud isolation service and a custom service at the same time.
default
keyring includes an invalid or expired CA certificate, some features might not function. For example, the appliance cannot download a database, and the event log contains messages such as "Policy compile had errors" and "Error: Keyring does not have a certificate authority's certificate: 'default'". To work around this issue, set the Web Isolation service to use a keying that includes a valid, non-expired CA certificate. See Step 2.
#(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.
#(config) isolation
#(config isolation) disable
The cloud isolation service comes with presets and thus requires minimal configuration.
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. In version 7.3.11.1 and later, the Admin Console and the CLI warn you if the service is configured to send headers in non-secure mode.
Alternatively, if you have Management Center version 1.1.3.1 or later:
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:
Settings Available for Custom Service
The following attributes are not yet supported in the cloud isolation service. These settings are functional only when and if implemented on the isolation service you use.
Attributes |
Description |
Read-only, prevent user from entering data |
Make isolated web pages read-only to the user. |
(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. |
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.
This example describes how to create the following VPM policy:
Note: If preferred, you can refer to the CPL for this example.
Log into the VPM:
Create policy objects for internal traffic:
Create policy objects for certain requests coming from authenticated users:
Click Apply Policy to install policy.
If Web Isolation does not occur as expected, review Troubleshooting.
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.
#(config) isolation
#(config isolation) enable
#(config) isolation
#(config isolation)
#(config isolation) service <hostname> {secure | non-secure} [<port>]
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:
#(config isolation) tunnel-ssl-device-profile <SSL_device_profile>
#(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.
#(config isolation) server-ccl <server_CCL_name>Otherwise, the appliance uses the bluecoat-isolation CCL.
#(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.
#(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.
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.
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:
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.
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
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.