ProxySG 6.6. Basic Student PDF

ProxySG 6.
6 Basic Administration
Student Guide
Copyright © 2017 Symantec Corporation. All rights reserved. Symantec and the Symantec Logo
are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and
other countries. Other names may be trademarks of their respective owners.
THIS PUBLICATION IS PROVIDED “AS IS” AND ALL EXPRESS OR IMPLIED CONDITIONS,
REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE
DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY
INVALID. SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL OR
CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE
OF THIS PUBLICATION. THE INFORMATION CONTAINED HEREIN IS SUBJECT TO CHANGE
WITHOUT NOTICE.
No part of the contents of this book may be reproduced or transmitted in any form or by any
means without the written permission of the publisher.
Symantec Corporation
World Headquarters
350 Ellis Street
Mountain View, CA 94043
United States
http://www.symantec.com
Lead Subject Matter Technical Contributors and

Course Developer
Experts Reviewers
Jim Rintoul
Table of Contents
Course Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Introduction to the Symantec ProxySG Secure Web Gateway . . . 3
ProxySG Security Deployment Options . . . . . . . . . . . . . . . . . . . . 19
ProxySG Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Exercise: Exploring the Management Console . . . . . . . . . . . . . . . . . . . 37
Traffic Interception Using Proxy Services . . . . . . . . . . . . . . . . . . 45
Exercise: Configuring Proxy Services and Listeners . . . . . . . . . . . . . . 57
Hypertext Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Exercise: Analyzing HTTP with Packet Captures . . . . . . . . . . . . . . . . . 77
Introduction to the Visual Policy Manager . . . . . . . . . . . . . . . . . 83
Exercise: Basic VPM Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Filtering Web Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Exercise: Basic Content Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Using Threat Intelligence to Defend the Network . . . . . . . . . . 127
Exercise: Using Threat Intelligence in Policy . . . . . . . . . . . . . . . . . . . 137
Ensuring Safe Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Exercise: Managing Downloads in the VPM. . . . . . . . . . . . . . . . . . . . . 153
Notifying Users of Internet Usage Policies . . . . . . . . . . . . . . . . 163
Exercise: Exception Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Access Logging on the ProxySG . . . . . . . . . . . . . . . . . . . . . . . . 187
Exercise: Access Logging Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
ProxySG Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
IPv6 in ProxySG Security Deployments . . . . . . . . . . . . . . . . . . . 225
3
Symantec Education Services — Symantec ProxySG 6.6 Basic Administration
4
Course Introduction
Introduction
The Symantec ProxySG 6.6 Basic Administration course is intended for students who wish to master the
fundamentals of the Symantec ProxySG. It is designed for students who have not taken any previous
training courses about the ProxySG.
Objectives
After completing this course, students will be able to:
• Describe the major Secure Web Gateway functions of the ProxySG
• Understand the network deployment options of a ProxySG
• Deploy a ProxySG in either explicit or transparent mode
• Use the Visual Policy Manager to write policies to manage web filtering.
• Use ProxySG access logs to generate reports
Prerequisites
This course assumes that students have a basic understanding of networking concepts, such as local-area
networks (LANs), the Internet, security, and IP protocols.
This course does not cover physical installation or network planning.
Applicable Software Versions

This course is based on version 6.6.5.x of the SGOS operating system that is used on the ProxySG.
Typographic Conventions
In this book, text appearing in this font generally is text that is part of a graphical user interface. This
includes text in labels, names of buttons and menus, and web page addresses that you type into a web
browser.
Text appearing in this font generally is text that is part of a command line interface. This includes
prompts, user input, and responses. This font also is used to show the content of some communication
protocols, such as headers, commands, and data between a client and a server.
In both cases, text that appears in italics like this or like this represents text that you should replace
with text specific to your deployment.
1
2
Module 1: Introduction to the Symantec
ProxySG Secure Web Gateway
Estimated Lecture Time

40 minutes
Module Summary
This module provides a basic introduction to proxy servers, the Symantec ProxySG, and the Secure Web
Gateway (SWG) functions of the ProxySG. The ProxySG is the centerpiece of Symantec’s complete web
security solution that defends against web- and network-based threats, enables cloud data protection, and
provides flexible business policy control across the enterprise and the cloud, including web, social, and
mobile networks.
The ProxySG provides the following functions: strong user authentication; Web filtering; deep inspection of
content for data loss or threats; security checks to the WebPulse collaborative cloud defense; inspection
and validation of SSL traffic; content caching and traffic optimization; bandwidth management; streaming
media splitting and caching; method-level controls per protocol; plus the ability to filter, strip, or replace
Web content.
Objectives
After completing this module, you will be able to:
• Describe the functions of a proxy server
• Differentiate proxy servers from firewalls
• Describe the key features and benefits of the Symantec ProxySG
• List the various ProxySG models
• Access online Symantec community resources
Related Activities
• Instructor-led Demo: Explore Symantec Enterprise Technical Support
Prerequisites
This module assumes that you have a basic understanding of these topics:
• Network devices such as routers, switches, and firewalls
• Fundamental Internet concepts
3
Slide Notes
Slide 1-1
Proxy servers
This slide shows at a high level the basic features and functionalities of proxy servers. While four key
features are shown, this is not an exhaustive list.
The basic technology behind proxy servers has been around for many years; a detailed definition of a proxy
server appears in the earliest RFC for the Hypertext Transfer Protocol (HTTP).
A proxy is defined in RFC 1945 as an “intermediary program which acts as both a server and a client for the
purpose of making requests on behalf of other clients. Requests are serviced internally or by passing
them, with possible translation, on to other servers. A proxy must interpret and, if necessary, rewrite a
request message before forwarding it. Proxies are often used as client-side portals through network
firewalls and as helper applications for handling requests via protocols not implemented by the user
agent.”
Proxies have expanded in features and functionalities to go above simple content caching and Network
Address Translation (NAT). In particular, the ProxySG has grown from an advanced caching device to a
complete security appliance.
4
Module 1: Introduction to the Symantec ProxySG Secure Web Gateway
Slide 1-2
Security needs proxy

Advanced Security Technologies All Require and Use Proxy
• The state of the art in security today includes technologies such as:
– Secure Web Gateway (SWG)
– Cloud Access Security Broker (CASB)
– Web Application Firewall (WAF)
– Advanced malware protection
– TLS/SSL Inspection
– Next-Gen Firewalls (yes even NGFWs have proxies built in)
– Load balancers
Not surprisingly, a number of security technologies including the latest ones, all require proxies to help
them in achieving their security levels. All of these shown, and even Next Generation Firewalls, use proxy
technology to get their jobs done.
5
Slide 1-3
Firewalls and proxies
• Eye-on-the-wire monitoring  Man-in-the-middle brokering

• TCP/IP pass-through  TCP/IP termination
• All ports, all protocols  Protocol-specific
• L3/L4 protocol-oriented  L7 user-identity-and content oriented
• L7 packet-level signature analysis  L7 file-level, full content analysis and
control
A firewall is fundamentally a router with extended support for multiple routing protocols (RIP, RIP-2, OSPF,
etc.), complex routing-table configurations (including ACLs), multiple physical interfaces, VLANs, Network
Address Translation, and so on.
Firewalls support extended feature sets designed to help detect anomalies in packet composition,
sequence, and volume, as well as analyze protocol traffic in real time based on any number of additional
capabilities to enhance intrusion prevention, denial-of-service protection and response, protocol analysis,
and even limited file extraction, scanning, and alerting.
A proxy is fundamentally NOT a router. In the course of performing its man-in-the-middle functions, a
proxy, by default, is designed to provide limited and rudimentary routing services related to its function and
depending on its deployment characteristics.
However, proxies are not designed to provide ‘edge routing’ (or network access point) functions for all
ports and protocols in the manner of a true edge router/firewall.
6
Slide 1-4
ProxySG features
• Negative day threat defense

• Strong user authentication
• Visibility into encrypted traffic
• Integration with the Latest ATP
• Control over web and cloud usage
• Accelerated cloud app performance
• Hybrid delivery model
• Unmatched performance and reliability
As the world’s most trusted Secure Web Gateway, used by over 70% of the Fortune 500, the ProxySG is a
foundational element of any enterprise’s security architecture. The ProxySG offers the following:
• Negative day threat defense—The ProxySG provides on-demand cloud intelligence and real-time web
content ratings to ensure the enterprise is protected from the latest threats.
• Strong user authentication—ProxySG has the broadest support for authentication vendors in the
industry, providing the ability to easily integrate new users and groups – even those using completely
different authentication technologies.
• Visibility into encrypted traffic—The ProxySG has an SSL Proxy that allows for visibility into SSL traffic,
so the ProxySG can securely send attachments and content for inspection services.
• Integration with the latest advanced threat protections across the Industry—ProxySG works
seamlessly with best-of-breed technologies, including anti-malware, anti-virus (AV), blacklist and
whitelist engines from a variety of vendors, as well as the static code analysis and sandbox brokering
found in Symantec Content Analysis. The ProxySG can securely enable data loss prevention with
certified DLP partners, via S-ICAP or standard ICAP.
• Control over web and cloud usage—ProxySG gives you control over your sensitive content. ProxySG
enables you to identify cloud apps and reduce the risks posed by non-sanctioned, “shadow IT”.
• Accelerated cloud app performance—The ProxySG provides content caching and traffic optimization to
ensure your critical cloud apps are there when your users need them. It offers advanced bandwidth
management, with streaming media splitting and method level controls, per protocol, to help you
optimize the overall performance, efficiency and capacity of your bandwidth investments.
• Hybrid delivery model—Symantec’s industry-leading web protection is available as an appliance
(ProxySG), virtual appliance (SWG VA), and cloud service (Web Security Service) – meeting the unique
security needs of any organization whether on-premises, in the cloud, or hybrid deployment.
• Unmatched performance and reliability—The ProxySG provides up to 1Gbps throughput for high
availability deployments. The hardware platforms and operating system (SGOS) were built for fast,
efficient web object processing, running year after year at performance levels beyond the competition.
7
Slide 1-5
SGOS overview
• Robust, reliable operating system built by Symantec Blue Coat
– Not based on any other OS
– Tailored for security, caching, and WAN optimization
– Used in ProxySG appliances
– Modified for use in CacheFlow appliances
• Appliance-style OS
– Customers do not add code to it
– Customers do not run programs on it
• SGOS version 6: 64-bit

– Increased capacity and capability
– Also runs on some legacy 32-bit appliances
– Future functionality might be only on 64-bit platforms
SGOS is not based on Windows, Linux, or any other operating system.

SGOS contains no general-purpose code, and it does not reuse code from other operating systems.
All ProxySG models currently sold by Blue Coat support SGOS version 6. However, some older models —
specifically, the ProxySG 210 and ProxySG 510 — are 32-bit platforms and run SGOS in 32-bit compatibility
mode.
SGOS has two primary modes in the CLI:
• Standard—Standard mode is the default mode when you first log in to the CLI. From standard mode,
you can view but not change configuration settings. This mode can be password protected, but it is not
required.
• Privileged—Privileged mode provides a set of commands that enable you to view, manage, and change
ProxySG appliance settings for features such as log files, authentication, caching, DNS, HTTPS, packet
capture filters, and security. You can cannot configure functionality such as SSL Proxy, HTTP
compression, and the like. The privileged mode subcommand configure enables you to manage the
ProxySG appliance features.
8
Slide 1-6
ProxySG models
+ SGVA Virtual Appliance
ProxySG technology is available across the entire spectrum of organizational needs, including a virtual
appliance model.
For specific information on currently available ProxySG models, see
https://www.symantec.com/products/web-and-cloud-security/secure-web-gateway-proxy-sg-and-asg.
9
Slide 1-7
Symantec Enterprise Technical Support
Symantec Enterprise Technical Support includes links to resources such as instructional CBTs, technical
webcasts, knowledge base articles, and customer forums.
This support page can be found at the following URL:
• https://support.symantec.com
10
Slide 1-8
ProxySG First Steps WebGuide
You can use this WebGuide to learn the most effective ways of deploying and using a ProxySG appliance to
secure your network. This webguide contains step-by-step instructions, as well as many video demos.
The WebGuide can be found at the following URL:
• https://origin-symwisedownload.symantec.com/resources/webguides/proxysg/security_first_steps/inde
x.htm
11
Slide 1-9
Symantec Blue Coat YouTube channel
Symantec Blue Coat maintains a dedicated YouTube channel with a wide variety of training videos and
tutorials.
You can find the Symantec Blue Coat channel at the following URL:
• https://www.youtube.com/playlist?list=PLgX31ZoFHGa86QF17eAAANUQxbZjD7yI0
12
Additional Resources
• Symantec Secure Web Gateway webpage—
https://www.symantec.com/products/web-and-cloud-security/secure-web-gateway-proxy-sg-and-as
g
• Recorded version of this module—
https://learn-central.symantec.com/Saba/Web_spf/NA1PRD0127/common/ledetail/cours0000000000
34410?context=user&learnerId=emplo000000000028290
13
Review Questions
1. Which of the following services are provided by the ProxySG? (Select all that apply)
a. Policy enforcement
b. Authentication support
c. Forensic analysis
d. Encrypted traffic management
2. True or false: A primary difference between a proxy server and a firewall is that a proxy is not
fundamentally a router.
3. True or false: Symantec maintains a YouTube channel where informational videos on the ProxySG are
posted.
4. SGOS is which of the following?
a. Linux-based
b. Windows-based
c. A custom-built operating system
d. A Symantec proprietary implementation of Unix
14
Instructor-led Demo: Explore Symantec Education Technical Support
Instructor-led Demo 1-1: Explore Symantec Education

Technical Support
Estimated Demonstration Time

15 minutes
Objective
• Introduce students to all the resources available at Symantec Education Technical Support.
Steps
1. From your desktop, launch a web browser and go to https://support.symantec.com.
2. In particular, explore the resources available under the following links:
a. Forums—See especially the ProxySG forum under Symantec Connect > Forums.
15
b. From the Support home page, you can search to find relevant articles, such as this example based
on a search of “ProxySG”.
c. ProxySG Fundamentals:
https://learn-central.symantec.com/Saba/Web_spf/NA1PRD0127/pages/pagedetailview/spage000
000000003161/elibrary/proxysg-fundamentals
16
Instructor-led Demo: Explore Symantec Education Technical Support
3. If time permits, explore the following:

a. Other areas of Symantec Education Technical Support
b. The ProxySG First Steps WebGuide—
https://origin-symwisedownload.symantec.com/resources/webguides/proxysg/security_first_ste
ps/index.htm
c. The Symantec Blue Coat YouTube channel—
https://www.youtube.com/playlist?list=PLgX31ZoFHGa86QF17eAAANUQxbZjD7yI0
17
18
Module 2: ProxySG Security Deployment
Options

30 minutes
Module Summary
In today’s complex network architectures, it seems there are limitless ways to deploy networking
equipment. This may be the case for some networking gear, but for web gateways there are only a few
proven deployment methodologies that are effective and provide complete security. In this module, we’ll
describe the three most common types of web gateway network deployments.
The three most commonly used deployment scenarios for web gateways are inline, explicit, and
transparent. Each one of these deployments has its advantages and disadvantages, which will be
discussed
Objectives
• Describe the three network deployment methods
• Describe the three possible roles of the ProxySG
Prerequisites
Before beginning this module, you should complete the following module:
• Introduction to the Symantec ProxySG Secure Web Gateway
19
Slide Notes
Slide 2-1
Inline
With an inline deployment, the web gateway is placed directly in the path of all network traffic going to and
from the Internet. If you choose an inline deployment, make sure your web gateway is capable of bypassing
network traffic that you don’t want processed by the web gateway. In many instances, you can choose to
either “proxy” (re-route) or “bypass” a specific protocol. If you “proxy” the protocol, it means the web
gateway will terminate the traffic from the client to the server locally, and re-establish a new connection
acting as the client to the server to get the requested information.
In this deployment, the ProxySG is usually deployed between the core switch and the edge router. Because
all outgoing Web requests are forwarded from the switch to the router, the ProxySG can be installed in the
path. This location in the network allows the ProxySG to have full visibility of all Web requests.
Inline Deployment Advantages
The upside of an inline methodology is the ease of deployment and the guaranteed assurance that all web
traffic will be re-routed to flow through the gateway. There is no chance of a user bypassing the controls
set by the administrator as long as the device is inline and is the only path available to the Internet. All
Internet-bound HTTP traffic will be processed and handled by the web gateway. Another advantage is the
ability to monitor all ports for call home traffic generated by malware and botnets on infected computers.
This awareness allows for remediation of infected systems lowering the risks of web access for an
organization.
Inline Deployment Disadvantages
The disadvantage of an inline deployment is a single point of failure. Even with technologies such as “fail to
wire”, which allows all traffic to flow through when a device fails, many organizations are uncomfortable
with a single device in the data stream to the Internet. Another disadvantage (really a side effect of this
being the most secure deployment methodology), is that with inline deployment there is the necessity to
manage all the protocols proxied by the web gateway. Because the web gateway is inline, all other
protocols (FTP, CIFS, etc) will need to be proxied or bypassed by the web gateway. The IT admin will need to
administer this list and the handling of each protocol used by the organization. This adds the highest level
of security for an organization.
20
Module 2: ProxySG Security Deployment Options
Slide 2-2
Explicit proxy
With an explicit proxy, the client browser is explicitly configured to send URL requests to the Proxy.
Explicit deployment is commonly used when a web gateway is deployed in a larger network, and the design
of the network requires there to be no single point of failure. Explicit deployment allows the web gateway to
be located on the network in any location that is accessible by all users and the device itself has access to
the Internet.
As mentioned, an explicit deployment uses an explicit definition in a web browser. To facilitate this kind of
deployment, an administrator can distribute PAC or WPAD files for the explicit proxy setup in end-user
browsers.
When using explicit deployment, it is extremely important to have the firewall properly configured to
prevent users from bypassing the proxy. The firewall needs to be configured to allow only the proxy to talk
through the firewall using HTTP and HTTPS. All other hosts/IP addresses should be denied. In addition, all
other ports need to be locked down to prevent end-users from setting up their own proxy internally that
tries to access the Internet via HTTP on a port other than the commonly used ones (80 and 443).
Explicit Mode Advantages
The main advantages of deploying a web gateway in explicit mode include narrowing the amount of traffic
processed by the web gateway (you can limit traffic to only HTTP-based traffic), and the ability to more
easily implement redundancy for web gateways in your environment. Explicit mode deployment for an
environment without an existing web gateway is also less disruptive to the network. The web gateway can
be placed anywhere in the network that is accessible by all end-users as long as the web gateway is able to
reach the Internet.
Explicit Mode Disadvantages
The disadvantage of explicit mode deployment involves IT administrative overhead as each client station
needs a configuration change in order to work properly. While there is some reduction in this overhead with
PAC and WPAD, any error in configuration of an end-user system will require a sysadmin to rectify the
situation. Also, in explicit mode, any hole in the network or firewall can be exploited by a knowledgeable
end-user to bypass the web gateway. In addition, for call home traffic analysis, port monitoring needs to be
done by a network device with access to all egress point network traffic. The explicit mode web gateway
can detect and block call home traffic only for protocols defined and managed, such as HTTP and HTTPS.
21
Slide 2-3
Transparent proxy
In a transparent proxy deployment, the client is unaware that there is a proxy in their network. Transparent
deployment allows a web gateway to be deployed in any network location that has connectivity, similarly to
an explicit mode deployment, reducing the need for a configuration change to the network to implement. In
addition, there is no administrative overhead to configure end-user systems, because the routing of HTTP
and HTTPS traffic is typically done by the router or other network device. Transparent deployment is often
used when an organization is too large for an inline deployment and does not want the added work and
overhead needed for an explicit deployment. Most transparent deployments rely on web Caching
Communications Protocol (WCCP), a protocol supported by many network devices. Alternatively
transparent deployment can be achieved using Policy Based Routing (PBR).
Transparent Deployment Advantages
The main advantages of deploying a web gateway in transparent mode include narrowing the amount of
traffic processed by the proxy, and the ability to more easily implement redundancy of the web gateway. In
addition, transparent deployment does not require changes to end-user systems.
Transparent Deployment Disadvantages
Transparent deployment does depend on the availability of either WCCP or PBR, and support for these by
the web gateway, typically available only on more sophisticated web gateways. Configuration can be
trickier as there needs to be compatibility of supported versions of WCCP between the router and the web
gateway. More in-depth network expertise is required to implement and deploy a transparent mode
deployment, which may not be a problem in larger organizations but could be an issue for smaller
organizations.
Explicit Vs. Transparent
An inline deployment is essentially a transparent deployment, since the client is not explicitly aware of the
Proxy.
The main areas where the ProxySG functions differently based on whether it is deployed explicitly or
transparently are related to authentication and SSL-encrypted traffic management. These topics will be
explored in much more detail later in this course.
22
Slide 2-4
Proxy roles
• Forward proxy: Proxy on the same network as clients
 Reverse proxy: Proxy on the same network as servers
 WAN optimizer
So far we’ve discussed using the ProxySG to proxy LAN users’ requests to an external server on the
Internet, providing additional functionality such as caching, anti-virus scanning, and enforcing security
policies. This is known as a forward proxy role, and it is this role that is the focus of this course.
A reverse proxy is used to manage Internet users’ requests to corporate-deployed Web servers. A reverse
proxy server serves as an additional layer of security to the publicly-accessed Web server, and can
significantly improve the performance of serving Web content to Internet users. In addition, a reverse proxy
role can be used to implement Web Application Firewall functionality to defend against threats such as SQL
injection and Cross-site Scripting attacks on corporate networks.
Finally, the ProxySG can be configured to optimize WAN network performance, combining protocol
acceleration, compression, object and byte caching, and quality of service to help accelerate key
applications such as file access, email, web, storage replication, and backup.
23
Supplemental Topics
Explicit Proxy Client Configuration
Manually configuring a client to use an explicit proxy is impractical for any organization but the smallest.
This method requires a lot of administrator time and, unless it is paired with good firewall rules, can be
easily bypassed.You can create a Proxy Auto-Configuration (PAC) file to distribute to the browser the proxy
configuration information from a remote JavaScript file rather than from static information entered
directly. It is even possible to specify which proxies each user can access. You can use a PAC file to create a
very basic fault-tolerant and load-balanced environment.
The PAC file can reside on a shared resource. One of the main advantages of the PAC file is that it allows
you to make changes to your proxy configuration without having to reconfigure each client. See Additional
Resources below for links to information about creating and editing PAC files.
Reverse Proxy Deployments

Unlike a forward proxy, which caches arbitrary content for clients, a reverse proxy serves specific content
on behalf of back-end servers. Reverse proxies are network servers or appliances that typically reside in
the DMZ between web applications and the Internet.
The reverse proxy is effectively a trusted processor for web servers, acting as a middleman between users
and the web applications they access. A reverse proxy protects web servers from direct Internet access and
off-loads from them computationally intensive processes to enhance performance.
To the outside world, the reverse proxy is the web server. For example, in the above diagram, all requests
going to the web server are directed to the proxy, even though the actual content resides on the back-end
server. When content is requested, the proxy either serves the content from its cache or gets the content
from a back-end web server.
If the reverse proxy is accelerating several different web servers, the proxy (or Layer 4 switch) maintains
web-server mapping so that content can be obtained from the correct server, thus achieving load
balancing. In most instances, SSL encryption is often not done by the web server itself, but by a reverse
proxy that is equipped with an SSL acceleration card.
Reverse proxy deployments are not covered further in this course. For more information, see the following
URL—
https://www.symantec.com/products/web-and-cloud-security/web-application-firewall-reverse-proxy.
WAN Optimization Deployments

When the ProxySG is used as a WAN optimizer, it’s called a MACH5 deployment. Symantec Blue Coat
MACH5 goes beyond traditional WAN optimization solutions and dramatically improves the performance of
virtually all applications and workflows – from file transfers to backups, email, databases, video, and cloud
applications. A cornerstone product of the Symantec Network Performance Optimization solutions, the
MACH5 S200, S400 and S500 families combine optimization features such as protocol acceleration,
compression, and caching to deliver high performance across IPv4 or IPv6 environments. And they deploy
at the network core or the branch to assure that every user, everywhere experiences the superior
performance they expect.
For more information, see the following URL—
https://www.symantec.com/products/web-and-cloud-security/network-performance-optimization/wan-o
ptimization-mach5
24
• The recorded version of this module is available at the following URL—
34411?context=user&learnerId=emplo000000000028290
This recorded module includes demos showing how to set up both explicit and transparent
deployments, and the use of PAC files to facilitate client browser configuration.
• Symantec Blue Coat whitepaper: “Secure Web Gateway Deployment Methodologies,” available at the
following URL—
https://www.symantec.com/content/dam/symantec/docs/white-papers/swg-deployment-methodologi
es-en.pdf
• “Creating an Explicit Proxy Server with PAC Files,” in the “Explicit and Transparent Proxy” chapter of
the SGOS Administration Guide. One version of this guide is available at the following URL—
https://symwisedownload.symantec.com//resources/sites/SYMWISE/content/live/DOCUMENTATION/1
0000/DOC10459/en_US/SGOS%206.7%20Administration%20Guide.pdf?__gda__=1496482915_11e1b97
d056f3097e7aa3f8d901096ae
• “How to create or edit a PAC file to use with ProxySG,” Knowledge Base article (KB1395) available at
the following URL—https://support.symantec.com/en_US/article.TECH242025.html
25
Review Questions
1. Which deployment method represents a single point of failure?
a. Inline
b. Explicit
c. Transparent
d. None of the above
2. In which type of physical deployment does a ProxySG have potential visibility to all traffic through the
use of a device such as a WCCP-capable router or a Layer 4 switch?
a. Inline
b. Explicit
c. Transparent
3. Name three methods by which client configuration can be performed in an explicit ProxySG
deployment.
a. Configure the user agent to point to the IP address or hostname of the ProxySG
b. Configure the user agent to use WPAD
c. Configure the user agent to point to the location of a PAC file
d. Use Symantec Management Center to configure the user agent
e. Configure forwarding hosts on the ProxySG
4. In which client connection type are user agents aware that a proxy has been deployed?
a. Transparent proxy
b. Inline proxy
c. Explicit proxy
d. In every connection type
5. In an explicit ProxySG deployment, the TCP packet sent from the client to the ProxySG would contain
what value as the destination IP address?
a. The IP address of the ProxySG
b. The IP address of the client
c. The IP address of the origin content server
d. The answer depends on whether client IP address reflection is enabled on this ProxySG
6. In a transparent ProxySG deployment, the TCP packet sent from the client to the ProxySG contains
what value as the destination IP address?
a. The IP address of the ProxySG
b. The IP address of the client
c. The IP address of the origin content server
d. The answer depends on whether client IP address reflection is enabled on this ProxySG
26
Module 3: ProxySG Management Console

40 minutes
Module Summary
The Management Console is part of an easy-to-use software suite in the ProxySG. It is the nerve center of
the ProxySG. You can write policies to control users within a network, authenticate users, report network
activity, and create a productive and safe work environment. You can also manage, configure, and upgrade
the ProxySG from any location using the Management Console.
The Management Console is a graphical user interface. Although you can use the command line interface
(CLI) to perform tasks, the Management Console is more user-friendly and time-saving. It has tabs, links,
buttons, windows, and other easy-to-use features to perform most configuration, management, and
monitoring tasks.
Objectives
• Describe the relationship between the Management Console and the ProxySG CLI
• Describe the primary function of the major areas of the Management Console
• Use the Management Console to access on-box help and Symantec product documentation
Related Activities
• Exercise: Exploring the Management Console
27
Slide Notes
Slide 3-1
Management Console structure
• Java 7 or higher must be enabled

for the HTTPS management
console.
• Ensure your browser includes and
has enabled TLS 1.1/1.2 support.
Web pages and Java applets reside on the ProxySG. Administrators issue web requests from a browser.
HTTPS is supported by default; HTTP can be enabled if desired. Port 8082 is the default; it can be changed
if desired.
The ProxySG acts as a web server on the management port.
The version of Java may change based on SGOS version. For more details, see the Release Notes.
28
Slide 3-2
Functional areas
Displayed is a quick overview of the functional areas of the Management Console.

The banner identifies the hardware model type, the appliance name, serial number, software version and
software license edition.
There are three menu tabs:
• The Statistics tab allows you to monitor various aspects of the ProxySG function and performance
• The Configuration tab contains the primary functionalities of the ProxySG
• The Maintenance tab contains information about licensing, appliance health, and other maintenance
areas.
29
Slide 3-3
Command generation
• Management Console works by generating CPL commands in the CLI
Content Policy Language (CPL) is a proprietary programming language specific to the ProxySG. It allows
you to express the policy rules that are enforced by the ProxySG. The Management Console operates by
generating CPL commands in the CLI.
Everything that can be done in the Management Console can be done in the CLI, but not vice versa.
30
Slide 3-4
Preview, Revert, and Apply
Shown are a few simple commands, as they appear in both the Management Console and the CLI.
• Preview shows the generated CLI commands that will be performed.
• Apply saves changes.
• Revert works only on changes that have not been applied, and works back only to the last apply; it is
not a continuing series, like Undo in many applications.
31
Slide 3-5
Concurrent access
There is no protection if two admins simultaneously try to change the same aspect of configuration. If two
admins change different areas, it might work OK. This is usually not a problem because multiple admins
often work in different areas of configuration, but this cannot be guaranteed.
In case of multiple admins making conflicting changes, the last one to commit them wins.
As a best practice, you should try to avoid having two admins managing policy at the same time.
However, the first person who made the change will not see that their change has been overruled until
they either refresh or relaunch their copy of the Management Console.
To help prevent this, restrict the people who have access to the Management Console.
Management Center can use locking to limit the number of concurrent admins.
32
Slide 3-6
Documentation
and Help
The Documentation link goes to the Symantec Product Documentation page. From there, you can find
reference guides as well as search for articles and other resources for any topics of interest. This link
requires an Internet connection to work properly because it retrieves documentation from Symantec, not
from the appliance.
The Help button accesses context-sensitive on-box help that is related to the page from which the button is
clicked. The help text is taken from the relevant manuals that can be viewed in full at the Documentation
link. The context-sensitive help is often more useful because it can quickly provide relevant information.
33
Supplemental Topics
Web Browser and Java Requirements
Specific SGOS versions have specific compatibilities with specific Web browser and Oracle Java JRE
versions. For example, for SGOS v6.6.x with clients running Windows 10, it is recommended to use Internet
Explorer 11 with Java 8 Update 101.
For more information about supported Web browsers and downloading JRE, refer to the current version of
the SGOS release notes, available at Symantec Product Documentation.
Updating Time Zones and Daylight-saving Rules

If a specific time zone is missing from the included list, you can update the list at your discretion. The list
can be updated by downloading the full time zone database from http://download.bluecoat.com/release/
timezones.tar. Also, the time zone database might need to be updated if the daylight-saving rules change
in your area.
Management Console in FIPS Mode

When the ProxySG is operating in Federal Information Processing Standards (FIPS) mode, the
Management Console loads only over a Transport Layer Security (TLS) version 1 secured connection. If
your Web browser uses JRE version 1.5 or earlier, you must explicitly enable TLSv1. JRE version 1.6
enables TLSv1 by default.
Microsoft Internet Explorer versions 6 and earlier do not have TLSv1 support enabled by default. To do so,
select Enable TLS 1.0 in IE’s advanced security options. Beginning in IE version 7, TLSv1 support is enabled
by default.
FIPS mode is enabled and disabled only from the command line interface, not the Management Console.
When you enable or disable FIPS mode, the ProxySG reinitializes, reboots, and will be out of service for up
to several minutes. Use these commands:
# fips-mode enable
# fips-mode disable
When operating in FIPS mode, many functions of the ProxySG appear and behave differently. FIPS mode is
not discussed further in this course. For more information on FIPS mode, refer to the document Using FIPS
Mode on the ProxySG, available at the following URL:
0/DOC10145/en_US/Using_FIPS_Mode_on_the_ProxySG.4.pdf?__gda__=1496567277_c2ce7bd3b3977649
33e86744fcc80df4.
34413
• “Accessing the ProxySG,” contained in the SGOS Administration Guide at the following URL:
d056f3097e7aa3f8d901096ae
• The latest version of the SGOS Release Notes, available at Symantec Product Documentation
(https://support.symantec.com/en_US/Documentation.html)
34
Review Questions
1. What client-side technology does the Management Console use?
2. What are the three main tabs of the Management Console?
3. In the Management Console, how can you determine the serial number of the ProxySG?
4. How does the Management Console perform commands on the ProxySG?
5. What happens if two administrators on separate web browsers both change the time zone of the
ProxySG?
6. If you click Revert three times in the Management Console, what happens?
7. When you click the Help button in the Management Console, what type of help can you expect to
receive?
35
36
Exercise: Exploring the Management Console
Lab 3: Exploring the Management Console
Estimated Exercise Time

20 minutes
Objectives
• Identify the major functional areas of the Management Console.
• Use the Management Console to perform additional configuration tasks following the initial
configuration.
• Understand the functions of the Preview, Revert, and Apply buttons.
Scenario
Some ProxySG deployments might require additional configuration to be deployed. In this exercise, you will
use the Management Console to perform additional general ProxySG configuration tasks.
Sections
This exercise contains the following sections:
• 3-1: Observe banner information
• 3-2: Configure NTP
• 3-3: Disable automatic logoff
• 3-4: Enable access logging
• 3-5: Explore the various Management Console tabs
Exercise 3-1: Observe Banner Information

1. To load the ProxySG Management Console from your desktop, open Internet Explorer and go to
https://10.10.2.2:8082. Click through any warnings that display to continue.
2. Enter the console credentials:
a. Username: admin
b. Password: train
Note: The username and password have been previously saved for convenience.
Again, click through any warnings that might display to continue.

3. Examine the banner at the top of the Management Console, and answer the following questions:
a. What model of ProxySG are you using?
b. What is the serial number of this ProxySG?
c. What version of SGOS is running on this ProxySG?
d. What edition of SGOS is running on this ProxySG?
37
3-2: Configure NTP

1. In the Management Console, go to Configuration > General > Clock, click the NTP tab, and click New.
2. In the Add List Item box, check IP Address, enter the address of the lab training server (10.10.2.5) and
click OK.
3. Highlight the entry you just made and click the Promote entry button until the new entry is on top.
Click Apply.
4. Click the Clock tab, make sure the Enable NTP box is checked, and click the Acquire UTC button.
38
5. In the Acquire UTC time dialog box, click OK.
Exercise 3-3: Disable Automatic Logoff

By default, the ProxySG automatically logs you out of the Management Console after 15 minutes and out of
the CLI after five minutes. This feature reduces the likelihood that an unauthorized person will change
settings if you step away for a few minutes. However, for training purposes, you will disable the automatic
logoff feature.
1. In the Management Console, go to Configuration > Authentication > Console Access.
2. Deselect Enforce Web auto-logout and Enforce CLI auto-logout.
3. Click Apply.
39
Note: To keep auto-logout but change the length of time before the ProxySG ends your Management
Console session, enter the time in the Web auto-logout (minutes) field. Valid values are between 5
minutes and 1,440 minutes (one day).
Exercise 3-4: Enable Access Logging

Access logs are raw text logs of client requests that pass through the ProxySG. They allow you to track Web
usage for a network, a department, or a specific user. By default, access logging is disabled on the
ProxySG. In this procedure, you will enable access logging, which will create access logs that you will use
later in this course.
1. In the Management Console, go to Configuration > Access Logging > General > Default Logging.
2. Select Enable Access Logging and click Apply.
Exercise 3-5: Explore Management Console Tabs

1. Go to Configuration > Policy.
40
a. Notice the Default Proxy Policy section, with its choices of Allow or Deny. This choice allows you to
set an overall policy of either allowing all web requests or denying all web requests not otherwise
allowed or denied by specific policies.
b. From the Visual Policy Section, launch the Visual Policy Manager.
c. Under the Policy menu in the VPM, try adding a Web Access layer.
Try right-clicking in the various fields, click Set and New, and see the choices that come up. Feel free
to create policies if you like, but don’t install them. You will be creating many policies in subsequent lab
exercises in this course.
41
If you added a layer, right-click in the layer’s tab at the top and delete the layer. Close out of the VPM
for now.
2. Next, go the Statistics tab and click through the various options.
a. Click System to see what information is available here.

b. Click Sessions > Active Sessions. This is where you can find out all the currently active sessions
that the ProxySG is managing, which can be especially useful when troubleshooting. Click the Help
button to get context-sensitive help.
42
Note: This context-sensitive Help button is available on many screens, so always look for it if you have a
question on a particular screen.
c. Click Advanced if you have time and explore the information available in the Advanced URL
section.
3. Finally, explore the various options under the Maintenance tab.
a. If time permits, click Service Information > Packet Captures. The ProxySG has a built-in capability
to take packet captures, which can be downloaded and opened in a utility such as Wireshark. This
capability will be used in various lab exercises later in this course.
4. As time permits, feel free to explore the various tabs and options further.
Lab Cleanup
No cleanup required.
43
44
Module 4: Traffic Interception Using Proxy
Services

40 minutes
Module Summary
The concept of the proxy service is one of the most important fundamentals of the ProxySG. This module
presents proxy services and the principal ways to configure and administer them. It is essential to fully
understand these concepts before continuing with the rest of this course.
The ProxySG lets you configure which traffic is to be intercepted. Services define the ports on which the
ProxySG listens for incoming requests. Each service can be applied to all IP addresses or limited to a
specific set of addresses and port combinations.
A variety of settings can be defined for each service. The ProxySG ships with a number of pre-defined
services, you can create additional services as needed, and services can be arranged into logical service
groups.
There are many services; however, all services can be divided into two groups: management services and
proxy services. This module presents proxy services; a short discussion of management services appears
in Supplemental Topics.
Objectives
• Understand the functions of proxy services, listeners, and proxy types
• Describe the three most common proxy services
• Explain how the intercept and bypass settings affect what happens to network traffic passing through
the ProxySG
• Explain the function of common global proxy service settings
Related Activities
• Exercise: Configuring Proxy Services and Listeners
45
Slide Notes
Slide 4-1
Proxy services overview
In Symantec ProxySG terminology, proxy service defines:

• Combinations of IP addresses and ports that the ProxySG matches against
• Whether to intercept or bypass matched traffic; if intercepted, which proxy service to use to process
the traffic
• Attributes that control what type of processing the ProxySG performs on the intercepted traffic
46
Module 4: Traffic Interception Using Proxy Services
Slide 4-2
Listeners
A proxy service listener specifies where a ProxySG service listens for traffic.
Four attributes comprise the listener:
• Source IP address—Typically “All”, which means any IP address that originates the request.
• Destination IP address—Transparent acts on connections without awareness from the client or server.
Explicit sends requests explicitly to a proxy instead of to the OCS.
• Port—A specific port or port range. All default ProxySG services are configured to their
industry-standard ports; for example, the Explicit HTTP service is configured to listen on ports 80 and
8080.
• Action—The action to take on traffic detected by this service.
❐ Intercept—The ProxySG intercepts traffic for this service and applies policy as applicable. (Traffic
must be intercepted before policy can be applied to it.)
❐ Bypass—Traffic for this service passes through the ProxySG without receiving any policy checks.
Each proxy service must have at least one listener, and each listener must be associated with exactly one
proxy service.
Only one listener match occurs. If multiple listeners are configured to match the same incoming traffic, the
last one generally wins.
47
Slide 4-3
Intercept and bypass
Actions define whether the ProxySG terminates and proxies traffic. The two possible actions are Intercept
and Bypass.
Proxy service listeners wait for incoming traffic that matches their configured parameters. When a match
is found, what happens next depends on whether the listener is set to Intercept or Bypass.
If a listener intercepts traffic, then the ProxySG terminates the client connection, performs actions such as
policy processing, and initiates a new connection to the traffic destination. Finally, the results of the
transaction are returned to the client; these results could be the server response, a modified server
response, an exception, or other traffic depending on the ProxySG configuration.
If the listener bypasses traffic, then the handling of the traffic differs on whether an explicit or transparent
proxy connection was used. For a transparent connection, the ProxySG passes the traffic through to the
original destination without any additional processing. For an explicit connection, the connection is
dropped because the destination IP address of the client request is the address of the ProxySG, not the
content server
48
Slide 4-4
Common proxy services
Three very common proxy services are:

• Explicit HTTP—When the ProxySG is deployed in explicit mode, this service is used to hand off matched
traffic to the HTTP proxy type.
• External HTTP—When the ProxySG is deployed in transparent mode, this service is used to hand off
matched traffic to the HTTP proxy type.
• HTTPS—Hands off matched SSL-encrypted traffic to the SSL proxy type, which intercepts, decrypts,
and re-encrypts HTTPS traffic so that policy can be applied to it.
49
Slide 4-5
Proxy service attribute settings
• Available settings depend upon the specific service
In addition to listener information, each service contains one of more settings that affect how the ProxySG
proxies the traffic.
An important attribute for HTTP and HTTPS services is the Detect Protocol option.
If protocol detection is enabled, the ProxySG inspects the first bytes sent from the client and determines
whether a corresponding application proxy is available to hand off the connection. For example, to enable
the ProxySG to detect the presence of SSL traffic, you must enable Detect Protocol on the Explicit HTTP
service so that the SSL traffic is handed off to the SSL proxy.
With Early Intercept enabled in the TCP/IP Settings section, during the three-way handshake the ProxySG
returns a server acknowledgment back to the client and wait for the client acknowledgement, which
completes the TCP three-way handshake, before the ProxySG connects upstream to the server.
50
Slide 4-6
Global proxy service settings
The following are global proxy service settings:

• Tunnel on protocol error—Some HTTP parsing errors might cause the ProxySG to issue an exception,
which could break applications. When this setting is enabled, the ProxySG tunnels non-HTTP traffic on
any HTTP service.
• Reflect client IP—This setting determines how the client IP address is presented to the origin content
server for all requests. This setting should be used with caution. Enabling this attribute allows the
ProxySG to connect to the origin content server using a source IP address and the IP address of the
client that made the request. You must ensure that the response from the OCS (note that the OCS
replies to the IP address of the client now) goes through the ProxySG; if there is a direct path between
the client and the OCS, you end up with asymmetric connections, and the client displays an error
because the connection setup does not terminate properly.
• Trust destination IP— If a client sometimes provides a destination IP address that the ProxySG cannot
determine, you can configure the ProxySG to allow that IP address and not do a DNS lookup. This can
improve performance, but it also potentially can cause a security issue.
• User Overflow Action—If you have more users going through the ProxySG than are allowed by your
license, you can configure overflow behavior.
51
Slide 4-7
Static bypass
• Only in transparent proxy mode

• Useful for troubleshooting
• No security is provided for bypassed traffic
• Firewall rules may need to be altered
The static bypass list instructs the ProxySG to skip processing requests sent from specific clients to
specific servers. This can be used only in transparent proxy mode.
You can use this list to allow protocol-incompliant traffic to pass through the ProxySG without a disruption
in service. Traffic that matches the static bypass list is not subject to service processing, and responses are
not cached.
Each entry in the list is a client-server pair, where each part can be a specific address, subnet, or “All.”
The ProxySG also supports dynamic bypass, but this feature is beyond the scope of this course. Information
is available in the SGOS Administration Guide.
52
Supplemental Topics
Custom Proxy Services and Service Groups
The ProxySG ships with dozens of pre-defined proxy services for common protocols and business
applications. These services contain listeners that are configured for the standard TCP ports used by each
service. However, your organization might have other network traffic that is not covered by one of the
pre-defined services. You can create custom services to process this traffic and identify it for reporting,
logging, and analysis.
Also, proxy services are organized by default into service groups based on Blue Coat recommendations for
intercepting and bypassing traffic. You can move services into other service groups, and you can create new
custom service groups. You might wish to do so if your ProxySG serves a specific purpose and you want a
custom group that contains only those proxy services.
For more information on custom proxy services and service groups, refer to the section “Creating Custom
Proxy Services” in the chapter “Managing Proxy Services” of the SGOS Administration Guide
(https://symwisedownload.symantec.com//resources/sites/SYMWISE/content/live/DOCUMENTATION/1000
0/DOC10459/en_US/SGOS%206.7%20Administration%20Guide.pdf?__gda__=1496482915_11e1b97d056f3
097e7aa3f8d901096ae)
Multiple Listeners
It is possible, and sometimes necessary, to have more than one service terminate connections that match
the same destination TCP port range. As long as the listeners have separate, nonoverlapping destination IP
addresses configured, you can create as many listeners as you want.
When a new connection is established, the ProxySG first finds the most specific listener destination IP
address. If a match is found and the destination port also matches, the connection is then handled by that
listener. If the destination port of the listener with the most specific destination IP address does not match,
the next most specific destination IP address is found; this process continues until either a complete match
is found or no more matching addresses are found.
For more information, refer to the topic “About Multiple Listeners” in the chapter “Managing Proxy
Services” of the SGOS Administration Guide.
Management Services
Management services are structured similar to proxy services. However, instead of defining how incoming
traffic is handled, management services are used by the administrator to communicate with the ProxySG.
There are five types of consoles:
• HTTPS console: This console provides access to the Management Console. It is created and enabled by
default. You can create and use more than one HTTPS console as long as the IP address and the port
match the existing console settings.
• HTTP console: This console also provides access to the Management Console. It is created by default
but not enabled because it is less secure than HTTPS. You can create and use more than one HTTP
console as long as the IP address and the port match the existing console settings.
• SSH console: This console provides access to the command line interface using an SSH client. It is
created and enabled by default. No action is required unless you want to change the existing SSH host
key, disable a version of SSH, or import RSA host keys.
• SNMP console: One disabled Simple Network Management Protocol listener is defined by default on
the ProxySG, which you can enable or delete as needed. You also can add additional SNMP services
and listeners. Discussion of SNMP support in the ProxySG is beyond the scope of this course.
53
• Telnet console: The Telnet console allows you to connect to and manage the ProxySG using the Telnet
protocol. This console service is not created by default because the passwords are sent unencrypted
from the client to the ProxySG. Also, a Telnet shell proxy service exists on port 23, the default Telnet
port. Because only one service can use a specific port, you must delete the shell service if you want to
create a Telnet console. If you want a Telnet shell proxy service in addition to the Telnet console, you
can re-create it later on a different port. Telnet is an insecure protocol and should be used only if SSH
cannot be used. Blue Coat does not recommend use of the Telnet console.
Early Intercept
When a proxy service can be configured for early intercept, this setting controls whether the ProxySG
responds to client TCP connection requests before connecting to the upstream server. When early
intercept is disabled, the ProxySG delays responding to the client until after it has attempted to contact the
server. If the Detect Protocol setting is enabled, then Early Intercept is selected automatically.
For more information, refer to “About Early Intercept” in the SGOS Administration Guide.
34414
• “Managing Proxy Services,” contained in the SGOS Administration Guide, available at the following URL:
d056f3097e7aa3f8d901096ae
54
Review Questions
1. What does each proxy service specify? (Select 2)
a. Proxy type
b. ProxySG SGOS version
c. Attributes
2. Which of the following is responsible for detecting incoming traffic that matches specific IP addresses
or subnets?
a. Listeners
b. Services
c. Proxies
d. TCP tunnels
3. Which of the following is NOT a component of a proxy service listener?
a. Source IP address
b. Destination IP address
c. Proxy type
d. Port range
4. What needs to be selected for the Explicit HTTP service to be able to hand off SSL traffic?
a. Enable ADN
b. Early Intercept
c. Port 443
d. Detect Protocol
5. True or False: Depending on the deployment mode, policy can still be applied to bypassed traffic.
6. What instructs the ProxySG to skip processing requests sent from specific clients to specific servers?
a. Static Bypass list
b. Restricted Bypass list
c. TCP Tunnel service
d. Internal HTTP service
55
56
Exercise: Configuring Proxy Services and Listeners
Lab 4: Configuring Proxy Services and Listeners

20 minutes
Objectives
• Understand how proxy services affect explicit and transparent client connections
• Use the Active Sessions display to identify proxied sessions
Scenario
The Management Console allows you to enable TCP listeners to intercept or bypass client connections.
ProxySG proxy services are divided into service groups: standard, bypass recommended, and tunnel
recommended. In this exercise, you will test explicit and transparent client connections when standard
HTTP services are set to Intercept.
During this exercise, you will be instructed to close and relaunch your web browser several times. This is
necessary because ProxySG configuration changes generally take effect only on new connections, so you
need to break and re-establish the connection between your browser and the ProxySG to observe how
configuration changes on the ProxySG affect browser responses.
Before You Begin

Make sure that you have performed the exercise “Explore the Management Console” earlier in this course.
This exercise assumes that your ProxySG is configured to match its state at the end of that exercise.
In the remaining exercises, you will use Internet Explorer to access the Management Console, and you will
use Firefox to test the effects of the ProxySG policies and settings.
Sections
• 4-1: Set the default proxy policy to Allow
• 4-2: Test explicit client connections with a service set to Intercept
• 4-3: Test transparent client connections with a service set to Intercept
57
4.1: Set the Default Proxy Policy to Allow

1. Launch the Management Console, and go to Configuration > Policy > Policy Options.
2. In the Default Proxy Policy section, make sure that Allow is selected. If not, select it and click Apply.
This instructs the ProxySG to allow all connections unless otherwise denied by policy. Because policy
has not yet been introduced in this course, no policy will exist in this exercise, so all intercepted traffic
will be allowed by default.
4-2: Test Explicit Client Connections with a Service Set to Intercept

1. Open the Firefox web browser.
2. Configure it manually to use your ProxySG as an explicit proxy for all protocols. Using Firefox as an
example, from the Tools menu select Options > Advanced > Network > Settings.
Note: An “Options” bookmark has been created on the toolbar for quick access to this Settings window,
as it will be used often in future exercises.
3. Check the Manual proxy configuration checkbox, enter the IP address of the ProxySG, and enter port
8080. Also enter the ProxySG’s IP address in the “No proxy for” field below.
4. In the Management Console, go to Configuration > Services > Proxy Services.

Expand the list of Standard services is not already expanded, scroll down to Explicit HTTP and set both
listeners to Intercept.
58
5. Click Apply.
6. Close and reopen Firefox, and connect to www.example.org.
7. Go to Statistics > Sessions > Active Sessions > Proxied Sessions, and click Show. The session
appears.
Note: You may see other sessions as well.
8. Scroll across the proxied session and identify the type of information being presented in the GUI. For
instance, hover over the Server field. You should see a pop-up appear with information about the
destination server and the client-supplied destination.
59
9. Now browse to https://www.example.org, and then examine Active Sessions again by clicking Show to
display the latest proxied sessions.
Because you went to an HTTPS URL, the port number shown is 443. Note that both HTTP and HTTPS
go to the ProxySG over port 8080.
60
4-3: Test Transparent Client Connections with a Service Set to Intercept

1. Open Firefox and configure it to not use a proxy.
2. In the Management Console, go to Configuration > Services > Proxy Services.

Expand the list of Standard services is not already expanded, scroll down and set the listeners for the
External HTTP and HTTPS services to Intercept and click Apply.
3. Click Apply.
4. Close and reopen Firefox and connect to info.cern.ch.
5. Go to Statistics > Sessions > Active Sessions > Proxied Sessions, and click Show.
Scroll over the Server information. This time, notice the customer supplied destination is the URL of
info.cern.ch, not the ProxySG, because this is a transparent deployment.
61
6. Scroll across the proxied session and notice that now under the Service Name the service used is
External HTTP.
Lab Cleanup
62
Module 5: Hypertext Transfer Protocol

40 minutes
Module Summary
Objectives
• Understand how a connection is initiated over the transport layer
• Identify the components of an HTTP URL
• Explain the two types of HTTP messages: request and response
• Identify common response codes
Related Activities
• Exercise: Analyzing HTTP with Packet Captures
63
Slide Notes
Slide 5-1
HTTP
• Definition
– “Application-level protocol with the lightness and
speed necessary for distributed, collaborative,
hypermedia information systems”
• Different versions available
– HTTP/0.9 (rarely encountered)
– HTTP/1.0 described in RFC 1945 (May 1996)
– HTTP/1.1 described in RFC 2616 (June 1999)
– HTTP/2 described in RFC 7540 (May, 2015)
HTTP is one of the most commonly used protocols. It was first described in 1996, and its latest update was
in 1999. Although HTTP was designed to deliver Web content and link-based text, it is now used to carry
many different types of content.
HTTP version 1.1: This is the current version of the protocol. A main difference between versions 1.0 and
1.1 is that version 1.1 enables persistent connections by default. Other differences include caching,
bandwidth optimization, error notifications, and security features.
Several client-server applications use HTTP as a communication protocol. MIME encoding translates
binary files into ASCII and enables HTTP to transfer binary files. Today, most Web downloads are not done
with FTP, but with HTTP directly from a Web browser.
64
Slide 5-2
HTTP
• The client always initiates the connection

• The server cannot initiate a connection
An HTTP transaction is always initiated by the client. The client sends a request to the server. The server
processes the request and returns a response. HTTP does not allow responses to be sent without a
previous request.
When the server needs to send more information than requested by the client, it must send instructions
about that information to the client. It is up to the client to decide whether those requests should be
initiated. For example, when a client downloads a Web page, the server returns the requested page
(object), which includes instructions for downloading objects (such as HTML links). After processing the
response, the client may or may not issue new requests for the objects listed in the links.
65
Slide 5-3
HTTP URL
["http:" "//" host_name [ :port ] [ abs_path [ "?" query ]]
• Host name is case-insensitive

– Even for UNIX-based Web servers
• Default port is 80
Most TCP-based protocols have well-known ports assigned to them. The default TCP port for HTTP is 80.
After specifying the hostname, you can specify the resource you want from the server (page, image, files,
and so on). You must specify the full path (as seen by the Web server) for that resource.
In the request, you can also pass parameters that a script (running on the Web server) can process and use
to return a specific page based on your previous selections.
Resources are separated from the hostname and from each other by the slash (/) character; parameters
are separated from the script name by the question-mark (?) character and from each other by the
ampersand (&) character.
Special characters in the URL are represented by their hexadecimal ASCII code, preceded by the
percent-sign (%) character.
66
Slide 5-4
HTTP messages
• Two types of messages

– Request
– Response
• Two parts of the message

– Headers
– Data
Both the request and the response are logically divided into two sections. The initial part contains
information relevant to the connection between the client and the server. The second part contains the
actual data.
The client and server must agree on a series of parameter and protocol specifications before any data can
be sent.
The ProxySG allows you to have granular control over request and response headers, thus controlling the
communication parameters between client and server.
67
Slide 5-5
Request methods
• GET
– Retrieves whatever information (in the form of an entity) is identified by the
URL
– Changes to a conditional GET if the request message includes an If-
Modified-Since or similar header
• HEAD
– Identical to GET except that the server MUST NOT return a message-body in
the response
The GET request method instructs the server to retrieve the information identified by the request URL. GET
is used to ask for a specific resource — when you click on a link, GET is used, regardless of whether the
linked resource is a file, a script, or other content.
If the URL refers to a script, such as PHP or Active Server Pages (ASP), the processed data is returned in
the response.
The GET method can be conditional, if the request message includes an If-Modified-Since,
If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. The conditional GET method is
intended to optimize the delivery of cached data by reducing the number of unnecessary connections to the
Web server.
Responses to a GET request are cacheable only if the request meets the requirements for HTTP caching as
defined by the protocol.
The HEAD request method is identical to the GET method, except that HEAD returns only the message
headers and not the message body. HEAD can be used to obtain metainformation about the entity; for
example, the validity and accessibility of hypertext links.
68
Slide 5-6
Request methods
• POST
– Designed to allow a uniform method to cover functions such as:
• Posting a message to a bulletin board, newsgroup,
mailing list, or similar group of articles
• Providing a block of data, such as the result of submitting
a form, to a data-handling process
• Extending a database through an append operation
• CONNECT
– Reserved for use with a proxy that can dynamically switch to being a tunnel
(such as SSL tunneling)
The POST request method is used to send data to the server to be processed in some way.
Unlike a GET request, the message body of a POST request contains a block of data.
The most common use of POST is to submit data to scripts such as those written in PHP and ASP. The
script receives the message body and decodes it.
You can use a POST request to send whatever data you want. The only stipulation is that the receiving
program must understand the format.
The CONNECT request method is used to direct Web proxies that provide SSL tunneling. CONNECT signals
the proxy to switch to an HTTP tunnel connection on TCP virtual port 443 to support secure HTTPS
connections.
69
Slide 5-7
Response codes
• 1xx—Informational
– 100 Continue, 101 Switching Protocols
• 2xx—Success
– 200 OK
• 3xx—Redirection
– 301 Permanent redirect, 304 not modified
• 4xx—Client error
– 400 bad request, 403 forbidden
• 5xx—Server error
– 500 Internal Server Error, 503 service unavailable
HTTP uses a set of response codes to communicate messages from the server to the client.
4xx response codes often are called “error” codes, but you should interpret the term “error” cautiously. For
example, authentication requests are handled using the 4xx messages. When a client requests a
password-protected resource, the server replies with a 401 message. Although that is not an actual error,
the client request is not fulfilled until authentication information is provided.
70
Slide 5-8
Requests and responses
Request
Response
The client issues a request specifying a method (GET), a resource, and the protocol version.
The resource is /, which indicates the root of the Web server. Web servers associate a default filename with
the root of a directory (index.htm, default.htm, welcome.html, and so on).
The Host field (mandatory for HTTP version 1.1) is useful when one or more virtual servers are associated
with the same IP address.
The server replies with a 200 OK message, indicating that the request is valid and has been accepted.
71
Slide 5-9
Parallel connections
• Most user agents open multiple, parallel connections to a server

• The connection limit used to be 2, but this has changed
• For example, IE 11 will now open up to 8 concurrent connections
• User agent typically manages connections differently based on
when proxy settings are configured
Most user agents, such as web browsers, will not make requests in a serial one-by-one fashion; instead,
they open multiple, parallel connections to a server.
For example, when downloading the HTML for a page, the browser might see two <img> tags in the page,
so the browser will open two parallel connections to download the images simultaneously.
The number of parallel connections depends on the user agent and the agent's configuration.
Parallel connections will obey the law of diminishing returns, as too many connections can saturate and
congest the network, particularly when mobile devices or unreliable networks are involved. Thus, having
too many connections can hurt performance. Also, a server can accept only a finite number of connections,
so if 100,000 user agents simultaneously create 100 connections to single web server, performance will
suffer.
72
Slide 5-10
Persistence in HTTP 1.1

• Single TCP connection sends and receives multiple HTTP requests/responses
• In HTTP 1.1, all connections considered persistent unless declared otherwise
• All modern web browsers use persistent connections
• Advantages include:
– Lower CPU and memory usage
– HTTP pipelining
– Reduced network congestion
– Reduced latency
– Errors reported without closing TCP connection
All modern web browsers use persistent connections, including Chrome, Firefox, IE, Opera, and Safari.
The advantages are even more important for secure HTTPS connections, because establishing a secure
connection needs much more CPU time and network round-trips.
73
Supplemental Topics
The idea of hypertext was first introduced by Tim Berners-Lee at CERN in Geneva, Switzerland. The
impetus behind his idea was the need for a better way of organizing long and complex documents. HTTP is
the application-layer protocol used to deliver Web-based content. The current version of HTTP (HTTP 1.1)
is described in RFC 2616. The original version (HTTP 1.0) is described in RFC 1945: “The Hypertext Transfer
Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed,
collaborative, hypermedia information systems.”
The most important part of the preceding paragraph is that HTTP is a Layer 7 protocol, indicating that it is
completely independent from the underlying network architecture.
Before going into more detail about HTTP and how it is supported on the Blue Coat ProxySG, it is important
that you know the key concepts of HTTP and its architecture:
• Uniform Resource Identifier (URI) and Uniform Resource Locator (URL): These indicate the resource to
which a method is to be applied. Messages are passed in a format similar to that used by Internet mail
and the Multipurpose Internet Mail Extensions (MIME).
• Connection: A transport-layer virtual circuit established between two application programs for the
purpose of communication.
• Message: The basic unit of HTTP communication, consisting of a structured sequence of octets and
transmitted via the connection.
• Request: A message containing an HTTP request.
• Response: A message containing the response to an HTTP request.
• Resource: A network data object or service that can be identified by a URI. This should not be confused
with the concept of a physical machine or with server (daemon) software.
• Client: A software application that sends requests to a server (see below) over an established
connection.
• Server: A software application that accepts connections from a client, process the requests it receives,
and sends back responses.
• Proxy: A software application (even appliances run a software application of some sort), which acts as
both a server and a client. The application acts as a server for the initial client and acts as a client for
the remote server. In fact, a proxy makes requests on behalf of other clients; this is why it is considered
both a client and a server. Client requests are serviced internally or are passed to another server. A
proxy can also translation-modify the request it receives from the client and send it to the server or to
other servers. Proxies can also be used as “helper applications for handling requests via protocols not
implemented by the user agent.”
• Gateway: A gateway is a server that acts as an intermediary for another server. Unlike a proxy, a
gateway receives requests as if it were the origin server for the requested resource; the requesting
client may not be aware that it is communicating with a gateway. Gateways are often used as
server-side portals through network firewalls and as protocol translators for access to resources
stored on non-HTTP systems.
• Tunnel: A tunnel is an intermediary program which acts as a blind relay between two connections.
Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may
have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed
connection are closed. Tunnels are used when a portal is necessary and the intermediary cannot, or
should not, interpret the relayed communication.
74
• Cache: A cache is a program’s local store of response messages and the subsystem that controls
message storage, retrieval, and deletion. A cache stores cacheable responses to reduce response time
and network bandwidth consumption for future requests for the same content. Any client or server
may include a cache (though a cache cannot be used by a server while it is acting as a tunnel). Any
given program may be capable of being both a client and a server; our use of these terms refers only to
the role performed by the program for a particular connection, rather than to the program’s
capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel —
changing behavior to address the needs of each request.
HTTP/2
HTTP/2 is the first new version of HTTP since HTTP 1.1. The HTTP/2 specification was published as RFC
7540 in May 2015. The standardization effort came as an answer to SPDY, an HTTP-compatible protocol
developed by Google and supported in Chrome, Opera, Firefox, Internet Explorer 11, Safari, and Amazon
Silk browsers.
From RFC 7540:
“The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the way HTTP/1.1 uses
the underlying transport ([RFC7230], Section 6) has several characteristics that have a negative overall
effect on application performance today.
In particular, HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP connection.
HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers
from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1 clients that need to make many requests
use multiple connections to a server in order to achieve concurrency and thereby reduce latency.
Furthermore, HTTP header fields are often repetitive and verbose, causing unnecessary network traffic as
well as causing the initial TCP [TCP] congestion window to quickly fill. This can result in excessive latency
when multiple requests are made on a new TCP connection.
HTTP/2 addresses these issues by defining an optimized mapping of HTTP's semantics to an underlying
connection. Specifically, it allows interleaving of request and response messages on the same connection
and uses an efficient coding for HTTP header fields. It also allows prioritization of requests, letting more
important requests complete more quickly, further improving performance.
The resulting protocol is more friendly to the network because fewer TCP connections can be used in
comparison to HTTP/1.x. This means less competition with other flows and longer-lived connections,
which in turn lead to better utilization of available network capacity. Finally, HTTP/2 also enables more
efficient processing of messages through use of binary message framing.”
75
Review Questions
1. True or false: An HTTP request made by a server to a client uses a GET request method.
2. What is the default TCP port for HTTP?
a. 443
b. 80
c. 43
d. 20
3. What is always included in both the request and response headers?
a. Information relevant to the connection between the client and the server
b. DNS query
c. Data
d. Cipher suite
4. When a server receives a GET request method, how does it know where to retrieve the requested
information?
a. The server examines the certificate of the requesting IP address.
b. The server must return a response message requesting the URL.
c. The GET request provides the URL.
d. None of these answers.
5. What is the purpose of the conditional GET request?
a. To optimize the delivery of cached data
b. To provide a measure of security
c. To determine whether the resource is permitted
d. To specify under what conditions an object is to be forwarded
6. How does a POST request method differ from a GET request?
a. A POST request originates from the server side.
b. A POST request cannot be encrypted.
c. The message body of a POST request contains a block of data.
d. None of these answers.
7. Which of the following are common elements of a GET request? (Select all that apply)
a. A method
b. A resource
c. The protocol version
d. The MAC address of the client user agent
76
Analyzing HTTP with Packet Captures
Lab 5: Analyzing HTTP with Packet Captures

30 minutes
Objectives
• Capture packet data using the ProxySG
• Use Wireshark to analyze HTTP requests in the captured area
Scenario
The ProxySG packet-capture capability is a useful tool for troubleshooting because it is the one place
where you can capture packets and see both the client’s request to the ProxySG and the ProxySG request to
the Web server on behalf of the client.
In this exercise, you will configure your browser to access the Web via the ProxySG while in transparent
proxy mode, capture a Web browser HTTP request, and analyze how it is processed by the proxy. Then you
will repeat the same steps while in explicit proxy mode.
Before You Begin

• Make sure the default proxy policy is Allow.
• Make sure the Explicit HTTP and External HTTP listeners are set to Intercept.
• If necessary, review the previous exercise for details on configuring Firefox for transparent and explicit
proxy mode.
Sections
• 5-1: Capture packets in transparent mode and analyze using Wireshark
• 5-2: Capture packets in explicit mode and analyze using Wireshark
• 5-3: Using various filter options (Optional)
77
5-1: Capture Packets in Transparent Mode and Analyze using Wireshark

1. Close and reopen Firefox, and configure it to use transparent proxy.
2. In the Management Console, go to Maintenance > Service Information > Packet Captures.
3. Click Start capture. The Start Capture dialog box displays.
4. Accept all of the defaults, click Start Capture, and click OK in the dialog box that appears.
5. Access www.example.org from your Web browser.
78
6. In the Management Console, from Maintenance > Service Information > Packet Captures, click Stop
capture, click OK in the dialog box that appears, and then click Show statistics. The packet capture
statistics Web page displays.
7. Click the Download link, and then click Open. Wireshark automatically launches and opens the packet
capture file.
8. Create an http display filter in Wireshark:
a. Enter http in the filter dialog box.
b. Click Apply.
9. Highlight the first GET / HTTP/1.1 request, and click the right-arrow sign next to Hypertext Transfer
Protocol to display details of the HTTP packet.
Note that the destination IP address of the request is the IP address of www.example.org.
Also note the format of the GET request in the Hypertext Transfer Protocol section; it does not contain
the URL requested.
79
10. Save the packet capture if you want to review it later, and close Wireshark.
80
5-3: Capture Packets in Explicit Mode and Analyze using Wireshark

1. Now configure Firefox to use explicit proxy mode, close and reopen Firefox, and repeat the steps given
in the previous section.
2. Download the packet capture into Wireshark as in the previous section, apply the “http” filter, highlight
the first GET request, and click the right-arrow sign next to Hypertext Transfer Protocol to display
details of the HTTP packet.
Note that the destination IP address is now that of the ProxySG, and the GET request in the Hypertext
Transfer Protocol section below now contains the requested URL.
3. In the top section of the window, select the line containing GET / HTTP/1.1, the request that the
ProxySG makes on behalf of the client. The destination IP address, GET request, and “X-BlueCoat-Via”
header are circled in the screen capture below.
81
4. Again, save the packet capture if you wish to review it later, and either close Wireshark or time
permits, explore the use of various Wireshark filters in the section below.
5-4: Using Various Filter Options (Optional)

Some common filter expressions for the Management Console and CLI are listed below. The filter uses the
Berkeley Packet Filter format (BPF), which is also used by the tcpdump program. A few simple examples
are provided.
Some filter options for the ProxySG packet capture
Filter Option Effect

port 8080 Capture packets to or from port 8080
ip host a.b.c.d Capture packets with IP address a.b.c.d
ip host a.b.c.d and ip host e.f.g.h Capture packets sent in either direction
between the two IP addresses a.b.c.d
and e.f.g.h
Some filter options for the Wireshark packet capture
Filter Option Effect

tcp.port == 80 Capture packets on http standard port 80
tcp.dstport == 8080 Capture packets with destination TCP port
8080
ip.dst == a.b.c.d Capture packets with IP address a.b.c.d
ip.dst == a.b.c.d && Capture packets with IP address a.b.c.d
http.request.method == "GET" and a GET request
Lab Cleanup
82
Module 6: Introduction to the Visual Policy
Manager

40 minutes
Module Summary
Although many organizations create Internet usage policies, they face challenges in configuring systems to
enforce written corporate policies. Only a secure proxy with an object-handling operating system can offer
the framework needed to identify and enforce policies across an entire enterprise with line-speed
performance.
The ProxySG policy processing engine provides a comprehensive policy architecture that spans all users,
content types, applications, and security services. This framework allows a security administrator to
control Web protocols and Web communications across the entire organization.
The Visual Policy Manager (VPM) is a graphical user interface to the ProxySG policy framework that allows
you to perform the most common policy-related tasks in a visual environment. This module introduces the
VPM and its key concepts.
Objectives
• Describe the relationship among the VPM, CPL, and the Management Console
• Describe the default processing order for policy layers and rules
• Describe triggers and actions that can be used in writing policy
• Identify the types of objects that the VPM supports
• Describe some of the best practices to be followed when using the VPM to create policy
Related Activities
• Exercise: Basic VPM Policy
83
Slide Notes
Slide 6-1
Policy concepts
Policy is the glue that binds the operation of the ProxySG SWG solution.
Administrators can create policy in either the VPM, directly in Content Policy Language (CPL), or a
combination of both. This course covers only the VPM; CPL is taught in the Advanced course.
The VPM is a visual interface to CPL. Policy created in the VPM is translated into CPL and stored on the
ProxySG for processing. This is similar to how the Management Console generates CLI commands to
perform its functions.
This also means that everything that can be done in the VPM can be done in CPL, but not vice versa.
The policy processing engine decides whether to allow or deny each transaction and, optionally, whether to
perform other actions as might be directed by policy. The policy processing engine starts with the default
policy on each transaction and, based on the policy in place, possibly changes that status. At the end of
policy processing, the traffic is permitted only if the policy evaluation status is Allow.
84
Module 6: Introduction to the Visual Policy Manager
Slide 6-2
VPM structure
When the VPM is launched, it reads the current state of the Management Console, including any changes
that have not been applied or reverted. Such changes are not reflected in what the VPM presents. The
Management Console and the VPM synchronize when Apply or Revert is clicked in the Management
Console.
Changes made in the Management Console after the VPM is launched are not reflected in the VPM until the
VPM is closed and relaunched.
The output of the VPM is two files: the VPM-XML file, which stores the visual state of the VPM user
interface; and the VPM-CPL file, which contains the CPL that is generated from the configuration in the
VPM.
CPL also can come from other sources. The administrator can write their own CPL (possibly based on code
that is shared among members of the Symantec Blue Coat community) and store it in other specific files on
the ProxySG.
The VPM-CPL file is combined with the other CPL files to form the policy that is the input to the ProxySG
policy processing engine.
85
Slide 6-3
VPM layers and rules
Each layer is one of several pre-defined types. Each layer type is designed to perform a specific type of
operation. The slide shows the most commonly used layer types.
Layers can be selectively enabled or disabled.
Multiple layers of the same type can (and often do) exist at the same time.
Unlike a firewall, all policy layers are evaluated before a decision is made whether to allow or deny. This
means that a decision made in one layer can be undone in a subsequent layer.
If CPL has been created from other sources, it is combined with the VPM-CPL file and evaluated as a single
unit. CPL is beyond the scope of this course.
86
Slide 6-4
VPM objects
Each rule is comprised of objects.

The objects are the individual elements of a rule you specify.
With the exception of No. (number), which indicates the order of the rule in the layer and is filled in
automatically, all objects are configurable.
To specify or edit an object settings, position the mouse in the appropriate object cell within a rule and
right-click to display the drop-down menu.
87
Slide 6-5
Triggers and actions
Triggers and actions are dependent on layer type; not all triggers and
actions are available across all layer types.
Good examples of triggers are user, group, source IP address, destination host name, destination category,
time of the day, day of the week, protocol, port, and so on. Good examples of actions are deny, allow,
redirect, modify access log, modify header, and so on.
Triggers represent the who, where, how, and when of a rule; actions represent the what.
The types of triggers and actions vary according to which layer type is being configured. For example, the
available trigger types and triggers in a Web Access layer differ from those in an SSL Intercept layer.
Action types can be actual actions that affect the traffic, or they can be tracking instructions that initiate
logging or notification.
88
Slide 6-6
Policy evaluation order

• Default proxy policy is the
starting point
• Rules in a layer are
evaluated in order until a
match is made
• Layers of the same type
are evaluated in order
• Layers of different types are
evaluated in logical order
– Example: Web
Authentication layers
before Web Access layers
Within a VPM layer, rules are evaluated in the order they appear from top to bottom. Rules can be moved
up or down by using the appropriate buttons in the VPM.
Evaluation starts with the default proxy policy (Allow or Deny).
If a rule misses, evaluation continues to the next rule in that layer.
If a rule matches, evaluation stops with that rule, and processing continues to the next layer. Once a rule
matches, all subsequent rules in that layer are ignored.
Layers of the same type (Web Access, Web Authentication, and so on) are evaluated in left-to-right order in
the VPM. In general, the layer evaluation order corresponds to the order in which they are shown in the
VPM Policy menu.
However, layers of different types are processed in a logical order that is based on the order in which
things happen when a user is trying to access content on a server. For example, a rule in a Web
Authentication layer would be processed before a rule in a Web Access layer, regardless of its order in the
VPM.
89
Slide 6-7
VPM layer guards

• One rule that can be above
all others in a VPM layer
• If the rule matches, the layer is
evaluated; if not, the layer is
skipped
• No other action associated with a
layer guard
• Useful for factoring out common
elements
• Can improve policy processing
efficiency
The same set of conditions or properties often appears in every rule in a layer. You can factor out the
common elements into layer guard expressions. This can help the ProxySG run more efficiently,
particularly when you have defined a large number of rules.
A layer guard is a single rule table that appears above the selected layer in the VPM. The layer guard rule
contains all of the columns available in the layer except for the Action and Track columns. These columns
are not required because the rule itself does not invoke an action other than allowing or not allowing policy
evaluation for the entire layer.
You cannot add a layer guard rule until you have created other rules for that layer.
By default, a layer guard rule is enabled, but you can disable a layer guard (which keeps the rule but does
not process it) or delete the rule completely from the VPM.
There is no corresponding actual “layer guard” statement in CPL. Instead, the VPM generates CPL code
that implements policy evaluation as specified by the layer guard. One difference is that layer guards
implemented in the VPM do not have actions directly associated with them, while it is possible to do so with
CPL.
90
Slide 6-8
VPM best practices

• Policy construction
– Express separate decisions in separate layers
– Be consistent with your model
• Policy integrity
– Use Allow with caution
• Policy optimization
– Use regular expressions only when necessary
– Place rules most likely to match at beginning of layer
– Use subnets when possible
– Use layer guards when appropriate
The ProxySG policy processing engine is a powerful and flexible tool. But with that power and complexity
comes the need to create policy that is easy to understand and maintain.
This material is excerpted from the Blue Coat technical brief on policy best practices. For more
information, see the “Policy Best Practices” technical brief listed in the Additional Resources section of
this module.
91
Supplemental Topics
Deny and Force Deny
In addition to the standard Deny action, there is another action called Force Deny.
In a Deny action, later rules that contain Allow can override the Deny action. The Force Deny rule
immediately denies the transaction and stops further layer and rule processing. This enables you to make
sure that a Deny action is not overridden.
Force Deny is also useful in preventing any unnecessary processing of requests that the administrator
does not intend to allow anyway.
More information about Force Deny, including examples, is contained in the technical brief “Policy Best
Practices,” available at the URL listed in the Additional Resources section below.
Policy and ProxySG Performance

In some large organizations that use the VPM, the installed policy is complex and consists of many layers,
with many rules in each layer. A poorly constructed policy can affect ProxySG performance and cause
delays in processing transactions. However, a well-written policy will not noticeably affect the user
experience.
The key is to create a logical policy that consists of the fewest statements, placing rules likely to match at
the beginning of a layer.
Support for IP Address Wildcards and Ranges

Policy supports wildcards and ranges in the following conditions:
• client.address=
• client.effective_address=
• dns.request.address=
• dns.response.a=
• proxy.address=
• request.header.Referer.url.address=
• request.header.header_name.address=
• request.x_header.header_name.address=
• server_url.address=
• session-monitor.attribute.attribute_name=
• streaming.rtmp.page_url.address=
• streaming.rtmp.swf_url.address=
• url.address=
• user.login.address=
The following definitions have also been extended to support wildcards and ranges:
• define subnet
• restrict rdns
The Symantec Enterprise Technical Support page has more information on specifying IP address wildcards
and address ranges:
• How can I use wildcard characters when specifying IP addresses in policy?—
https://support.symantec.com/en_US/article.TECH241521.html
92
• How do I specify a range of IP addresses in policy on ProxySG?—

• SGOS 6.x Visual Policy Manager Reference—
https://hypersonic.bluecoat.com/sites/default/files/tech_pubs/SGOSVisualPolicyManagerReference.p
df
• “You Want to Know About the Order in Which Policy Layers and Rules Should Be Applied”—
• “Policy Best Practices,” technical brief available at the following URL:
https://hypersonic.bluecoat.com/sites/default/files/tech_briefs/Policy_Best_Practices.1.pdf
93
Review Questions
1. If you use the VPM to create policy, can you also write your own CPL outside the VPM to create
additional policy?
2. What policy tasks require using the VPM and cannot be performed in CPL?
3. When policy created in the VPM is installed, what two files does the VPM update on the ProxySG?
4. What is the purpose of the VPM-XML file?
5. Are VPM rules grouped into layers, or are layers grouped into rules?
6. Can you have more than one Web Access layer active in the VPM at any given time?
7. What are the four types of VPM trigger objects?
8. In the VPM, a URL category such as “Travel” or “Hacking” is an example of what type of trigger?
9. When rules in a VPM layer are being evaluated, what causes evaluation to stop and proceed to the next
layer?
10. If the VPM has two Web Access layers, which one is evaluated first?
11. If the VPM displays a Web Access layer on the left edge and a Web Authentication layer to the right of
the Web Access layer, which one is evaluated first?
94
Exercise: Basic VPM Policy
Lab 6: Basic VPM Policy

30 minutes
Objectives
• Launch and use the Visual Policy Manager (VPM)
• Create layers in the VPM
• Specify some basic VPM triggers and actions
• Observe how policy in the VPM affects user requests
Scenario
You will create a two-layer policy that blocks all IP addresses, except your own IP address, from accessing
the cern.ch domain.
Before You Begin

• Verify that the default proxy policy on your ProxySG is set to Allow.
• Verify that Firefox is configured to use an explicit proxy.
Sections
• 6-1: Deny access to www.cern.ch and then to any domain of cern.ch
• 6-2: Create a rule to allow your client IP address
• 6-3: Create a rule to deny the Firefox user agent
95
6-1: Deny Access to www.cern.ch

1. Launch Firefox, and verify that you can access www.cern.ch. If you cannot, check your ProxySG
configuration against the “Before You Begin” section.
Note: It may redirect to home.cern; this is okay.
2. In Internet Explorer, open the ProxySG Management Console.

3. To launch the VPM from the Management Console, go to Configuration > Policy > Visual Policy
Manager, and click Launch. The VPM displays in a new window.
4. From the VPM menu bar, select Policy > Add Web Access Layer. The Add New Layer dialog box
displays.
5. In the Add New Layer dialog box, accept the default layer name, and click OK. The layer with a new
empty rule displays in the VPM.
6. Right-click the Destination field of the new rule, and then select Set. The Set Destination Object dialog
box displays.
7. In the Set Destination Object dialog box, click New and select Destination Host/Port from the
drop-down list. The Add Destination Host/Port Object dialog box displays.
8. In the Add Destination Host/Port Object dialog box:
a. In the Host field, enter www.cern.ch.
b. Select Exact Match from the drop-down list next to the Host field. Doing so causes this rule to
match a request to www.cern.ch.
96
c. Click Add, and then click Close.

9. In the Set Destination Object dialog box, click OK. Your VPM should look like this:
10. Click Install policy.

11. Close and relaunch Firefox, and try to access www.cern.ch.
Access is denied.
12. Try to access info.cern.ch. Access is allowed because info.cern.ch is not an exact match to
www.cern.ch.
13. Next, right-click the Destination field and select Edit.
14. In the Edit Destination Host/Port Object dialog box, enter cern.ch (without the www) and select
Domain from the dropdown list.
15. Click OK, and then click Install Policy.

16. Close and re-launch Firefox, and try to access info.cern.ch. Access is now denied.
97
6-2: Create a Rule to Allow Your Client IP Address

1. In the VPM, select Policy > Add Web Access Layer, and accept the default layer name.
2. Right-click the Source field of the new rule, and select Set from the drop-down list.
3. In the Set Source Object dialog box, click New and then select Client IP Address/Subnet from the
drop-down list.
4. In the Add Client IP/Subnet Object dialog box:
a. In the IP Address field, enter your client IP address: 10.10.2.101.
b. In the Prefix Length or Subnet Mask field, do not enter a value.
5. Click Add, click Close, and then click OK in the Set Source Object dialog box.
6. In the VPM, right-click the Action field of the rule, and select Allow from the drop-down list. Your
resulting VPM should look similar to this:
7. Click Install policy.

8. In your web browser, try to access info.cern.ch. Access is allowed.
6-3: Create a Rule to Deny the Firefox User Agent

1. Add a new Web Access layer.
2. Right-click in the Source field, click Set, then New, and select User Agent.
3. In the Set User Agent Object dialog box, select Firefox (Windows).
98
4. Click OK, and then OK again.

5. Your VPM should now look similar to this.
6. Click Install Policy.

7. Launch Firefox and browse to info.cern.ch. Access is denied, because the Web Access layer prevents
all Firefox user agents from accessing any content.
Note: A rule in each layer is matched, but because the third layer is the last rule that matches, it prevails
and the Firefox user agent is blocked.
Lab Clean-up
1. In the VPM, right-click each Web Access layer tab, and select Delete Layer from the drop-down list.
Click Install policy to accept the new empty policy.
2. Close the VPM.
3. Close Firefox.
99
100
Module 7: Filtering Web Content

40 minutes
Module Summary
Filtering web content is one of the primary functions of the ProxySG. Filtering allows you to categorize and
analyze Web content. With policy controls, content filtering can support your organization’s Web access
rules by managing or restricting access to Web content and blocking downloads from suspicious and
unrated Web sites, thereby helping protect your network from undesirable or malicious Web content.
This module introduces the main concepts of web filtering, as well as Symantec’s unique advantages
related to URL classification and policy enforcement.
Objectives
• Describe the main concepts of web filtering
• Describe the primary category databases
• Describe the category types available to policy
• Describe how Blue Coat WebFilter and WebPulse work together
Related Activities
• Exercise: Basic Content Filtering
101
Slide Notes
Slide 7-1
Web content filtering concepts

• Categories
• Databases
Content filtering is a method for screening access to web content. It allows you to control access to web
sites based on their perceived content. On the ProxySG appliance, using a content filtering database in
conjunction with policy allows you to manage employee access to web content and to restrict access to
unsuitable content. Restricting access or blocking web content helps reduce the risk of malware infections
caused by visiting questionable sites.
Content filtering categories comprehensively classify the vast and constantly growing number of URLs that
are found on the web into a relatively small number of groups or categories. These categories then allow
you to control access to web content through policy. A content filtering database has a pre-defined set of
categories provided by the content filtering vendor. Individual content filter providers such as Blue Coat
WebFilter, define the content-filtering categories and their meanings. Depending on the vendor, a URL is
listed under one or more categories. Each URL can support a maximum of 16 categories.
102
Slide 7-2
Application filtering
In addition to URL category filtering, you can filter content by Web application and/or specific operations or
actions done within those applications. For example, you can create policy to:
• Allow users to access all social networking sites, except for Facebook. Conversely, block access to all
social networking sites except for LinkedIn.
• Allow users to post comments and chat on Facebook, but block uploading of pictures and videos.
• Prevent the uploading of videos to YouTube, but allow all other YouTube operations such as viewing
videos others have posted. Conversely, prevent uploading and block access to some videos according
to the video’s category.
• Allow users to access their personal email accounts, but prevent them from sending email
attachments.
This feature allows administrators to block actions in accordance with company policy to avoid data loss
accidents, prevent security threats, or increase employee productivity.
This feature allows administrators to block actions in accordance with company policy to avoid data loss
accidents, prevent security threats, or increase employee productivity.
103
Slide 7-3
Content filter providers
A content filtering database has a pre-defined set of categories provided by the content filtering vendor.
The ProxySG supports several content filter providers. From the following options, you can use up to four
URL content filters in any combination:
• Blue Coat
❐ WebFilter—Blue Coat WebFilter provides both an on-box content filtering database and the
WebPulse service, a cloud-based threat-protection feature.
❐ Intelligence Services—This is a framework for the delivery of data feeds to Blue Coat platforms.
Multiple data feeds are entitled by subscription to an Intelligence Services solution bundle. These
data feeds are delivered and made available to the ProxySG appliance through the Intelligence
Services framework. You can obtain a license for one or more bundles, and also enable or disable
data feeds in your solution bundle as your requirements change.
Note: Blue Coat WebFilter is transitioning toward being replaced by the use of Intelligence Services.
More details on Intelligence Services will be provided in the next module.
• Local database—Create and upload your custom content filtering database to the ProxySG. This
database must be in a text file format.
• The Internet Watch Foundation (IWF) database—For information about the IWF, visit their website at
http://www.iwf.org.uk/.
• A supported third-party content filtering vendor database (Proventia, Optenet). You cannot use two
third-party content filtering vendors at the same time.
• YouTube—The appliance obtains video categories from the YouTube Data API v3.0. After you enable
Blue Coat categories for YouTube, you can reference these categories in policy to control YouTube
traffic. You must specify a valid server key for the YouTube API v3 to use Blue Coat categories for
YouTube.
See the following article for details: https://support.symantec.com/en_US/article.TECH245050.html
104
Slide 7-4
Policy categories
• User-defined
• Created and maintained on-box
• Typically used for whitelists and
blacklists
Copyright © 2016 Blue Coat Systems Inc. All Rights Reserved. 9
This slide shows an example of categories created in policy in the VPM. These categories are maintained
on-box, and are typically used for whitelists and blacklists.
105
Slide 7-5
YouTube categories
This slide shows an example of categories provided by the YouTube application. Any of these categories can
be referenced in policy.
106
Slide 7-6
Local category database
– User-defined
– Created and maintained off-box
– Typically used for allowed and denied
categories
The two main reasons to use a local database instead of a policy file for defining categories are:
• A local database in more efficient than policy if you have a large number of URLs
• A local database separates administration of categories from policy. This separation is useful for three
reasons:
❐ It allows different individuals or groups to be responsible for administering the local database and
policy.
❐ It keeps the policy file from getting cluttered.
❐ It allows the local database to share categories across multiple boxes that have different policy.
107
Slide 7-7
Blue Coat WebFilter categories
– 85 categories
– 50 languages
– Updated every
five minutes
(configurable)
– All categories
described at
sitereview.bluecoat.com
Blue Coat WebFilter, in conjunction with the WebPulse service, offers a comprehensive URL-filtering
solution. Blue Coat WebFilter provides an on-box content filtering database and WebPulse provides an
off-box dynamic categorization service for real-time categorization of URLs that are not categorized in the
on-box database. About 95% of the Web requests made by a typical enterprise user (for the English
language) are present in the on-box Blue Coat WebFilter database, thereby minimizing bandwidth usage
and maintaining quick response times.
WebPulse dynamic categorization includes both traditional content evaluation, for categories such as
pornography, as well as real-time malware and phishing threat detection capabilities. WebPulse services
are offered to all customers using Blue Coat WebFilter.
108
Slide 7-8
WebPulse transaction flow
This diagram shows the hybrid (on-box/off-box) nature of WebFilter.

1. A client makes a request.
2. The request is matched against the WebFilter database installed on the local ProxySG. There is a 95%
success rate; 95 of every 100 URLs requested are found in the local database (provided that it is kept
up-to-date). The WebPulse cache is also checked for a match.
3. If the URL is not available in the current database or the WebPulse cache, WebFilter queries the
external database. This database contains the most up-to-date list of websites and is what will become
the new available list on the next scheduled download.
In this simplified example, a real-time categorization is returned if WebPulse has a high confidence level in
the categorization.
109
Slide 7-9
System categories
 None
• URLs that are not categorized by WebFilter/WebPulse
 Pending
• Background categorization is being performed in
WebPulse
 Unavailable
• No database downloaded
 Unlicensed
• No categorization because WebFilter license expired
Several system categories exist to handle special cases.

Category “None” refers to sites that are not categorized, or it is returned when no content filter has been
enabled on the ProxySG. This is not necessarily an error condition; for example, sites on a corporate
intranet would not be categorized in WebFilter. Administrators can create local categories to classify such
sites if necessary.
Category “Pending” is returned when background dynamic categorization is enabled and the first
high-level categorization attempt did not produce an acceptable confidence level. Administrators can
create policy to define whether they wish to allow or deny traffic to pending sites.
Category “Unavailable” usually is associated with some type of error, such as the lack of a downloaded
database or other system error.
“Unlicensed” is actually a condition within category “Unavailable” (relevant for authors of CPL but not in
the context of this module). This condition is set when the WebFilter support contract has expired.
When “Unavailable” or “Unlicensed” conditions occur, exceptions are usually returned to clients. This
often leads to many calls from users to their IT staff.
110
Slide 7-10
Application and operation controls
In addition to URL category filtering, you can filter content by Web application and/or specific operations or
actions done within those applications.
111
Supplemental Topics
Internet Watch Foundation
The Internet Watch Foundation (IWF) is a nonprofit organization that provides organizations with a list of
known child pornography URLs. The IWF database features a single category called IWF-Restricted, which
is detectable and blockable using policy.
The IWF database can be enabled in tandem with WebFilter and a local database.
Use of the IWF database might be mandated or restricted by local laws. You are responsible for knowing
and obeying the laws for the locations in which your ProxySG is used and accessed.
For more information on IWF, visit their Web site at www.iwf.org.uk. For information on configuring the
ProxySG to use the IWF database, refer to the section “Configuring Internet Watch Foundation,” in the
SGOS 6.4 Administration Guide.
Dynamic Categorization Theory

The chart at right shows one example of some of the
mathematical theory behind dynamic categorization in
WebPulse.
The following fields are highlighted:
• Probability: The normalized probability calculated
from each token (such as a word on the page)
represents the probability that the entire page is in
language Y and it belongs to category X. In the
example shown above, the page is very likely to be
in English. The normalized probability is 1.00; in
other words, the categorization service is
convinced that it indeed is English. Also, this is
page very likely belongs to the category
Sports/Recreation/Hobbies. Pages are first
categorized by language and then by category.
• Threshold: This is the normalized minimum probability value for a given category to reach the
designated precision and recall values.
• Precision (Accuracy): This determines how accurate the service is. For instance, out of 100 sites that
the service marked as Pornography, how many are correctly categorized? If the service claims 100
pages to be category X and 85 of them actually are category X, then the precision is 0.85.
• Recall (Coverage): This defines the ability of the categorization service to catch all of the sites in a
certain category. If the service has processed 100 sites that are in the pornography category, how many
were categorized correctly? A recall value of 0.85 means that out of 100 pages that actually are
category X, the service categorizes 85 of them correctly. The goal for a tool such as dynamic
categorization is to find a sweet spot where the precision is high enough without compromising the
recall value. The recall and precision value move in opposite directions; when one gets better, the
other one gets worse. WebFilter aims for 85% to 90% precision. Blue Coat has by far the fewest false
positives in any published testing of content filtering vendors.
The dynamic categorization service does not return a categorization to the requesting ProxySG unless the
recall and precision value are within specific parameters that Blue Coat defines.
You do not need to understand the mathematics of conditional probability or dynamic categorization to
effectively administer the ProxySG. But this brief survey of techniques can give you an appreciation of the
processing that takes place to categorize every URL that is submitted to WebPulse.
112
Blue Coat WebFilter Category List

The Blue Coat WebFilter database contains website ratings representing billions of web pages, published
in more than 50 languages, and organized into useful categories to enable customers to better monitor,
control, and secure their web traffic.
Blue Coat is continually revising and updating categories. To view the current list of WebFilter categories,
go to http://sitereview.bluecoat.com/categories.jsp.
WebFilter Rating Site

Occasionally due to the nature of a website, WebFilter can place a site in the wrong category.
To test how WebFilter rates a web site, Blue Coat provides an online tool. The URL is
http://sitereview.bluecoat.com/sitereview.jsp. This URL also provides descriptions of each WebFilter
category and test pages that has been assigned each category, so that administrators can test their
content filtering policy without actually accessing content that might be objectionable or illegal.
Site review allows users to request a review and, if appropriate, a change to a site’s rating.
For more information, refer to the article “How to Submit a Request to Review the Category Associated to a
Web Site,” available at the following URL: https://support.symantec.com/en_US/article.TECH242154.html.
Selective Categorization
If dynamic categorization is disabled, the ProxySG does not contact WebPulse when a category match for a
URL is not found in the on-box database. However, you can use policy to enable conditional dynamic
categorization.
For example, you could disable dynamic categorization and block access to unrated sites for most users.
Then, you would create policy to perform dynamic categorization of unrated sites for a specified user or
group.
By enabling conditional dynamic categorization, you can control access to unrated content to a specified
user group only and prevent suspicious content from entering your network.
Deny Policy
A Web Request Layer has been added to the Visual Policy Manager. It supports new Deny objects that allow
you to block outgoing requests and outbound application operations.
113
• “Filtering Web Content,” chapter in the SGOS Administration Guide
d056f3097e7aa3f8d901096ae
• “How Do I Find Out the BCWF Subscription Status on the ProxySG Appliance?”
114
Review Questions
1. Where is the WebFilter database stored? (Select two)
a. On the ProxySG
b. At various Blue Coat data centers around the world
c. At third-party data centers
d. On clients’ mobile devices
2. What does it mean if a URL is categorized by WebFilter as “Pending”?
a. The ProxySG waits before applying policy to the request.
b. Background categorization is being performed in WebPulse
c. An exception is being sent to the client.
d. The URL is for a site that has not been categorized by WebFilter.
3. True or False: The on-box WebFilter database is checked only if the off-box database returns a
category of “None”.
4. True or False: A local database can be used as an alternative to or in combination with either an on-box
or off-box WebFilter database.
5. What allows WebPulse to provide real-time revisions to the WebFilter database?
a. Dynamic categorization
b. Creating a local database
c. Configuring application controls
115
116
Exercise: Basic Content Filtering
Lab 7: Basic Content Filtering

30 minutes
Objectives
• Enable the Blue Coat category database and explore the categories available
• Explore the use of policies based on categories to control web usage
Scenario
You will enable Intelligence Services and select Blue Coat as a content provider, then use the Visual Policy
Manager (VPM) to create policies that block website access, and then block a category but allow a specific
web application.
Before You Begin

• Ensure that your default proxy policy is Allow
• Ensure that Firefox is configured to use an explicit proxy
Sections
• 7-1: Enable Blue Coat as a provider
• 7-2: Create and test web access policies
• 7-3: Create and test an application control policy
117
7-1: Enable Blue Coat as a Provider

1. In the Management Console, go to Configuration > Content Filtering > General.
2. Select the Blue Coat checkbox and click Apply.
3. Go to Configuration > Content Filtering > Blue Coat, confirm that Intelligence Services is selected
from the Data Source dropdown list.
4. A download should be in progress. Wait a few minutes and click Refresh Status to confirm that the
download is successful. If need be, wait a bit longer and continue to click Refresh Status until the
download is complete.
118
5. Enable WebPulse by going to Configuration > Threat Protection > WebPulse and if Enable WebPulse
service is not selected, select it and click Apply.
Symantec recommends that you enable WebPulse to protect against web-based threats and malware.
6. Test the installation by providing a URL for the database to categorize. Go to Configuration > Content
Filtering > General, and in the URL field of the Diagnostics section, enter https://www.symantec.com
and click the Test button.
A new web browser window shows that the URL is correctly classified as belonging to the
Technology/Internet category provided by Blue Coat.
7. If time permits, test other URLs.
7-2: Create and Test Web Access Policies

1. Launch the VPM and create a new Web Access Layer.
2. Right-click in the Destination field and click Set.
3. In the Set Destination Object dialog box, click New and select Request URL Category.
4. In the Add Request URL Category Object dialog box, do the following:
a. Name the object IT-Security-Categories.
b. Expand the Blue Coat categories and check the following:
• Dynamic DNS Host
• Malicious Outbound Data/Botnets
119
• Malicious Sources/Malnets
• Phishing
• Proxy Avoidance
• Spam
• Suspicious
5. Click OK, and OK again.

6. Right-click in the Action field and click Set.
7. In the Set Action Object dialog box, scroll down (if necessary), select Force Deny, and click OK.
120
Your VPM should look similar to the following:
8. Click Add Rule to add another rule.

a. Name the object HR-Policy-Categories.
• Child Pornography
• Extreme
• Gambling
• Piracy/Copyright Concerns
• Pornography
• Violence/Hate/Racism
121

13. In the Action field of Rule 2, confirm the default action Deny.
14. Click Add Rule to add another rule.

a. Name the object Bandwidth-Categories.
• Audio/Video Clips
• File Storage/Sharing
• Games
• Mixed Content/Potentially Adult
122
• Radio/Audio Streams
• Software downloads
• TV/Video Streams

19. In the Action field of Rule 3, confirm the default action Deny.
20. Install the policy.

21. Launch a web browser and go to http://testrating.webfilter.bluecoat.com/Spam.
Access is denied, based on Rule 1.
22. Go to http://testrating.webfilter.bluecoat.com/Gambling.
23. Go to http://testrating.webfilter.bluecoat.com/Games.
123
Note: All Blue Coat categories can be tested by using a similarly formatted path.
7-3: Create and Test an Application Control Policy

1. Go to Configuration > Application Classification > General and check Enable Blue Coat Application
Classification on this device and click Apply.
2. Create a new Web Access layer. Right-click the Destination field and select Request URL Category.
3. Expand the Blue Coat heading and select Auctions.
4. Click OK. Make sure the Action is Deny, and install the policy.
5. In your browser, attempt to go to www.ebay.com. You are blocked, based on the rule you just created.
6. Now, add another Web Access layer.
124
7. Right-click in the Destination field, click Set, then New, and select Application Name.
8. In the Add Request Web Application dialog box, name the object “ebay”, type “Ebay” in the Name field,
and select Ebay.
9. Click OK.
125
10. Set the Action set to Allow.


12. In your web browser, go to www.ebay.com. Access is allowed.
Lab Cleanup
1. In the VPM, right-click each Web Access layer tab, and select Delete Layer from the drop-down list.
Click Install policy to accept the new empty policy.
2. Close the VPM.
3. Close Firefox.
126
Module 8: Using Threat Intelligence to
Defend the Network

30 minutes
Module Summary
This module describes the Symantec Global Intelligence Network, and how Intelligence Services work to
defend the network.
Objectives
• Understand Intelligence Services as provided by the Global Intelligence Network
• Understand Geolocation and Threat Risk Levels and how they can be used in policy
Related Activities
• Exercise: Using Threat Intelligence in Policy
127
Slide Notes
Slide 8-1
Symantec Global Intelligence Network
The Symantec Global Intelligence Network is a collaborative cloud infrastructure that collects, processes
and distributes content and threat intelligence on a worldwide scale. As a web security partner to more
than 15,000 of the world’s largest enterprises, including over 70% of the Fortune Global 500 companies,
Symantec has the ability to dynamically analyze and categorize new content, as soon as it is introduced.
With more than 200 threat analytics engines, the Global Intelligence Network can process more than one
billion web and file requests daily, in 55 languages. It is the most advanced real-time content and threat
categorization network available today.
The Global Intelligence Network is also managed and backed by a team of the industry’s most seasoned
researchers and security experts from Symantec Labs. The team has developed effective algorithms for
identifying, categorizing and blocking malicious content and malnet infrastructures before an attack can
occur, making the Global Intelligence Network an integral part of Symantec’s “negative-day” security
capabilities. When a zero-day attack starts, the negative day defenses are already in place to eliminate the
threat.
128
Module 8: Using Threat Intelligence to Defend the Network
Slide 8-2
Intelligence Services
• URL content categories
(“News/Media”,
“Entertainment”)
• URL security categories
(“Malicious Sources/Malnets”,
“Phishing”
• Basic web application definitions
(“Office online”, “Gmail”)
• Geolocation
• Threat risk levels
The Intelligence Services, powered by the Global Intelligence Network, help enterprises stop attacks as
they occur and keep malicious threats out of the network. Through the highly accurate intelligence feeds,
enterprises are able to identify and stop 99.99% of threats at the gateway, so they never have a chance to
enter the network. This reduces the resources and capital typically required to support locally deployed
content analysis and sandboxing solutions – customers can eliminate much of the $1.27M1 operational
costs due to false alarms.
Intelligence Services are offered on supported Symantec products via a subscription license:
• BCIS Standard—Includes URL content and security categories as well as basic web application
definitions. These are equivalent to the Blue Coat WebFilter categories. Note that the Blue Coat
WebFilter subscriptions are being phased out in preference for Intelligence Services subscriptions.
• BCIS Advanced—Includes the above, as well as GeoIP and Threat Risk Level policy gestures. These will
be described in more detail in subsequent slides.
129
Slide 8-3
Data
feeds
Multiple data feeds are entitled by subscription to an Intelligence Services solution bundle.
This slide shows the various options available.
130
Slide 8-4
Geolocation
To comply with local regulations, assist with traffic analysis, or reduce the risk of fraud and other security
issues, you may need to know the origin of traffic in your network, or restrict outbound connections to
specific countries.
With the Intelligence Services Advanced Bundle you have access to the Symantec GeoIP database of
countries, which can all be used as triggers in policy.
131
Slide 8-5
Threat risk levels

10
“Risk Levels”
Dozens of “Risk
Groups”
Hundreds of “Risk Factors”
Every URL (categorized or uncategorized) will have a risk level.
This service, also available only with the Intelligence Services Advanced Bundle, analyzes a requested
URL's potential risk and summarizes it in the form of a numeric value.
You can reference these values in policy to protect your network and your users from potentially malicious
web content.
Threat Risk Levels are calculated based on numerous factors that measure current site behavior, site
history, and potential of future malicious activities.
To have the Threat Risk Levels feature return both risk levels and category information for requests, the
ProxySG appliance must have a valid Intelligence Services Advanced Bundle license.
Although it is not required, Symantec recommends that you also enable the WebPulse categorization
service on the appliance.
132
Slide 8-6
Descriptions of threat risk levels

Level Description
Low The URL has an established history of normal behavior and has no future
(Levels 1-2)
predictors of threats; however, this level should be evaluated by other layers
of defense (such as Content Analysis and Malware Analysis).
Medium-Low (Levels 3-4) The URL has an established history of normal behavior, but is less
established than URLs in the Low group. This level should be evaluated by
other layers of defense (such as Content Analysis and Malware Analysis).
Medium The URL is unproven; there is not an established history of normal behavior.
(Levels 5-6)
This level should be evaluated by other layers of defense (such as Content
Analysis and Malware Analysis) and considered for more restrictive policy.
Medium-High The URL is suspicious; there is an elevated risk. This is the recommended
(Levels 7-9)
block level.
High (Level 10) The URL is confirmed to be malicious.
The Threat Risk Levels service assigns threat risk levels to URLs according to specific criteria, as shown by
this table.
133
Slide 8-7
Advanced ProxySG policy example

Risk
CAS Scan Warn Modify-on-the-fly Selective Block
Level
0 None None None
1 None None None

All Binaries, always…
Block EXE, JARs
2 None None
(except some trusted categories)
3 None None Block all EXE, JARs
4 None Some Block above + PDFs, Archives

(other file types
at higher levels) Disable JS
5 None Block above + POSTs
components
Warning page Remove active
6 Block above
content
7
8 Block All Requests

(Levels are for investigational information/prioritization, and advanced threat hunting)
9
10
This slide shows an example of how you might write policies to manage the various threat risk levels.
134
• “Symantec Intelligence Services”—
https://www.symantec.com/content/dam/symantec/docs/data-sheets/intelligence-services-en.pdf
135
Review Questions
1. How many languages does the Global Intelligence Network include in its URL analyses?
a. Only English
b. less than 10
c. less than 30
d. over 50
2. Which threat risk level would likely be assigned to an unproven URL without an established history of
normal behavior?
a. Low
b. Medium-Low
c. Medium
d. High
3. Which services are included in the Intelligence Services Advanced Bundle?
a. Content categories
b. Geolocation
c. Threat risk levels
d. All of the above
4. True or false: The Geolocation feature allows you to block URL requests only from countries who allow
this service.
136
Exercise: Using Threat Intelligence in Policy
Lab 8: Using Threat Intelligence in Policy

20 minutes
Objectives
• Enable geolocation and threat risk protection on the ProxySG
• Create and test policies that use geolocation and threat risk levels as triggers
Scenario
In this lab you will enable geolocation and threat risk protection on the ProxySG, then create and test
policies that block websites from a specific location, and that block traffic at or above a specified threat
risk level.
Before You Begin

• A valid Intelligence Services subscription for threat risk levels must be in place.
• Verify that your default proxy policy is Allow.
Sections
• 8-1: Enable geolocation
• 8-2: Create and test geolocation policy
• 8-3: Enable threat risk protection
• 8-4: Create and test threat risk level policy
137
8-1: Enable Geolocation

1. Go to Configuration > Geolocation > General, check the Enable Geolocation functionality on the
device checkbox, and click Apply.
2. If you like, you can test this by entering an IP address; for example, 188.184.64.53.
You should see Switzerland (CH).
Note: If Geolocation IP address lookup fails, go to the Download tab and click Download Now. This may
take minute or two to download.
8-2: Create and Test Geolocation Policy

1. Add a rule to the Web Access layer.
2. Right-click in the Destination field, click Set, New, and select Resolved Country.
138
3. In the Add Resolved Country Object dialog box, name the object “Switzerland” and scroll down in the
Country field to select Switzerland (CH).
139

5. Leave the Action set to Deny.
7. Now, in your browser, navigate to info.cern.ch. Access is blocked, based on the rule you just created.
8. Delete the layer you created in the VPM and install the blank policy.
8-3: Enable Threat Risk Protection

1. Go to Configuration > Threat Protection > Threat Risk Levels, and check the Enable Threat Risk
lookups on this device checkbox, and click Apply.
2. Click the Download tab and watch the progress of the download.
3. When the download is complete, test various URLs by entering them into the URL field and clicking
Lookup.
140
4. Try entering the name of the training server (server.example.com) to see what threat risk level it is
given.
8-4: Create and Test Threat Risk Level Policy

1. In the VPM, add a Web Access layer.
2. Right-click the Destination field of the new rule, and then click Set in the drop-down list. The Set
Destination Object dialog box displays.
3. Click New, and then select Request URL Threat Risk Level from the drop-down list. The Add Request
URL Threat Risk Level Object dialog box displays.
4. From the Threat Risk Level between dropdown list, select 8 and 10.
5. Click OK, and then click OK again.

6. Leave the Action set to Deny.
141

8. To test the policy, go to sitereview.bluecoat.com. Click the Categories dropdown and select Test
Pages. Scroll down and click Malicious Sources/Malnets.
Access is denied, based on the policy you created.
9. On the same page, click Informational.

Access is allowed.
10. Finally, go to Statistics > Threat Risk Details.

Explore the information available on this page.
142
Lab Clean-up
1. Delete all policy layers and install the blank policy.
2. Close Firefox.
143
144
Module 9: Ensuring Safe Downloads

30 minutes
Module Summary
As users download seemingly safe content such as music files, they can also unknowingly download
hidden viruses, Trojans, or malware. When you add the time and resources lost while employees browse
and download content, you can see that organizations cannot afford to overlook the problems posed by
user downloads.
In this module, you will learn how HTTP is used to send data over the web. HTTP content types are based
on Multipurpose Internet Mail Extension (MIME) types, but MIME types are not unique to HTTP. They
originally were developed to deliver non-text email attachments but now are used in many other
applications as well.
Content types are important because they can be used to identify the content and block a download if
necessary.
On the ProxySG, policy— in both the VPM and in CPL—provides tools that you can use to manage
downloads.
Blocking malicious downloads is just one component of a total malware prevention plan. Combined with
WebPulse and the Content Analysis System (CAS), Blue Coat provides complete malware protection.
Objectives
• Describe how malware can be transmitted via HTTP
• Explain the methods, advantages, and disadvantages of file type detection
• Describe some of the considerations in deciding what content to block as possible malware sources
Related Activities
• Exercise: Managing Downloads in the VPM
145
Slide Notes
Slide 9-1
Malware
• HTTP transmission vectors
– Compromised files
– Deceptive files
– Active content
• Complete malware solution
– WebFilter: Block access to known malware hosts
– VPM and CPL: Detect and block malicious files
– ProxyAV: Perform heuristic analysis and signature scanning
• Impacts on ProxySG performance and web content
– Apply the strictest rules to the content most likely to be bad
– Active content is an important part of many websites
This slide gives an overview of how malware can be transmitted over HTTP. Compromised files can contain
malicious content that has been inserted by intruders; deceptive files can present themselves as having a
type different from their actual content; and active content such as scripts can exploit browser
vulnerabilities.
HTTP is not the only possible malware transmission vector, nor does a ProxySG need to handle all of the
burden of malware detection and prevention. Blue Coat WebFilter should be familiar to users.
The more checking for malware that occurs on the ProxySG, the more CPU power is used. Administrators
should strike the proper balance for their organization between checking for malware and ProxySG
overhead.
Similarly, blocking all active content usually is no longer a reasonable strategy for preventing malware.
Active content is a significant component of most modern websites, so administrators must create rules to
prevent overblocking of web content.
146
Slide 9-2
File type detection
• ProxySG can detect

file types by inspecting:
1. Filename extension
2. HTTP content type
3. Apparent data type (most effective, most costly)
• Use policy to make the decision to allow or deny
The ProxySG provides a high-performance and flexible way to create and enforce user download policies.
You can block by:
1. File extension types: For example, you can configure the ProxySG to block users from downloading .exe
files.
2. HTTP content types: For example, you can configure the ProxySG to block all (or only some) audio or
image files based on the MIME type contained in the Content-Type header for an object.
3. Apparent data type: The apparent data type refers to special data located at the beginning of a file that
is used to indicate its type. The ProxySG scans these data files to determine whether the special data is
present.
You also can create policies that specify when and where downloads are blocked. For example, you can
block users from downloading video files from any news sites during work hours.
147
Slide 9-3
Hidden file types
• Malicious content often

is represented as a safe
file type
• Policy based only on file
extension OR MIME-type would not detect
Because a content server usually determines the content type of a file solely based on its extension, you
can get a mismatch between the actual file and its content type. Your browser might even download a
certain file with a content type that matches the file extension.
Files with a given extension and a well-defined content type are not always what they seem to be. In the
slide, you should point out how the content type described in the Content-Type header does not match the
actual file type. The content is set to text, but the file quite obviously is a GIF.
If your policies deny access to GIF files based solely on file extension or content type, this particular file
would be accepted because it does not match such policies.
148
Slide 9-4
Apparent data types
• ProxySG determines actual file type by reading up to

the first 255 bytes of a data stream
• Most accurate way to detect actual file content
• Pre-defined support for 23 file types
• Can detect and block “drive-by” malware installation
• Most resource-intensive detection technique
If you open a PDF file with either WordPad or a debugger, you see that the files begin in the same way. All
PDF files being with the following header: %PDF-1.4 or 25 50 44 46 2D 31 2E 34 in hexadecimal.
The first four bytes are usually enough.
Malicious executable content can be misrepresented as safe file types such as .jpg or .gif. Blocking such
content makes use of policy tests comparing the claimed file type to the actual initial data in the files.
The ProxySG provides Apparent Data Type triggers that support 23 file types.
149
Slide 9-5
Mobile malicious code

• Active content can exploit vulnerabilities in web browsers
– Applets (Java)
– Plug-ins
– Objects (ActiveX controls, images, applets, embedded docs)
– Scripts (JavaScript, VBScript)
• VPM: Strip Active Content action object
• Use with caution; can significantly affect Web 2.0 content
– Use only on riskiest websites
– Combine with WebFilter categories (such as “Suspicious”)
With increasing amounts of active content on many web pages, executable files are no longer the only
vector by which malware travels.
Mobile malicious code exploits vulnerabilities in the browser (or other client applications) through
malicious JavaScript, VBScript, Flash, or ActiveX modules.
Protection against these can take several forms from stripping all active content from pages, to selectively
“defanging” malicious code methods, and/or signature/heuristic scanning.
The safest option that still allows access to web pages is sanitizing the HTML to remove all active content;
however, this has significant impact on today's interactive Web 2.0 sites. Due to the risk of over-blocking,
this option should be applied in conjunction with Intelligence Services to occur only on the riskiest, least
business-oriented sites. Any exceptions can then be handled by whitelisting.
150
Supplemental Topics
Rewriting Active Content to Remove Malware
An added layer of protection against malware can be created by attempting to “defang” malicious active
code inserted into web pages.
Certain aspects of the typical malware infector are uncommon in normal web pages. This can be used
against them to prevent their code from executing if it reaches a web browser. Two techniques for this in
CPL are script string rewriting and script injection.
However, string rewriting is a CPU-intensive action and should be deployed with care. This level of
protection usually is only needed for external resources and can be disabled for websites within a trusted
network. Without an understanding of where your data is coming from (a trusted or untrusted site) these
mechanisms introduce delay for the user and can over block legitimate code from trusted sources.
• SGOS Content Policy Language Reference—
0000/DOC10350/en_US/6.6_CPL_Guide.pdf?__gda__=1496930274_f743f275a90b504122e79018e9a776
0f
151
Review Questions
1. Identify three methods by which the ProxySG can detect the type of a file that is downloaded.
2. Of the methods that the ProxySG uses to detect file type, which one is usually the most accurate?
3. What is one drawback to using apparent data type to detect the file type?
4. Which detection method would not detect a mismatch between the file name and its content type?
5. To detect the apparent data type of a downloaded file, do you need to use CPL, or can the VPM be used?
6. A downloaded file is named file.jpg and identifies as an HTTP Content-Type of text/plain, but is actually
a Windows executable file. How would the ProxySG handle this file?
152
Exercise: Managing Downloads in the VPM
Lab 9: Managing Downloads in the VPM

20 minutes
Objectives
• Use the VPM to detect and block content based on apparent data type
• Create policy to strip active content
Before You Begin

• This exercise requires that WebPulse is enabled and the Intelligence Services database has been
downloaded and enabled on your ProxySG.
Sections
• 9-1: Create and test policy based on apparent data type
• 9-2: Create policy to strip active content
153
Symantec Education Services — ProxySG Basic Administration Training Course v6.6
9-1: Create and Test Policy based on Apparent Data Type

1. In the VPM, add a new Web Access layer.
2. Right-click in the Destination field of the new rule, click Set, then New, and then select Combined
Destination Object.
3. In the Add Combined Destination Object dialog box, click New and select Apparent Data Type.
154
4. In the Add Apparent Data Type Object dialog box, name the object “EXE” and then scroll down to select
EXE.
5. Click OK.
155
6. In the Add Combined Destination Object dialog box, select EXE and move it to the top right.
7. Click New, and select Request URL Category. In the dialog box, name the object uncategorized, and
under the System heading, scroll down and select none and unavailable.
156
8. Click OK.
9. Select the uncategorized object and move it to the lower right.
157
10. Click New one more time, and select Request URL Threat Risk.
11. In the Add Request URL Threat Risk Object dialog box, select between 4 and 10.
12. Click OK.

13. Select the Threat Risk Level object you just created and move it to the bottom right.
158
14. Click OK, then OK again, allow the default Action as Deny and Install the policy.
Your VPM should appear similar to the following.
15. To test the policy, try to download an executable file that has been renamed with a text file extension.
Browse to server.example.com, or use the bookmark in the Firefox toolbar.
16. In the downloads directory, select putty.txt.
159
The download is denied, because even though the file is labeled as a .txt file, the ProxySG determines
that it is actually an .exe file and blocks it as per the policy you just created.
9-2: Create Policy to Strip Active Content

1. Add a new rule to the first Web Access layer.
2. Right-click in the Destination field of the new rule, click Set, then New, and select Request URL
Category.
3. In the Add Request URL Category Object dialog box, name the object Gray-Area-Categories, click the
plus sign next to Blue Coat to expand the list, and check the following categories:
❐ Hacking
❐ News/Media
❐ Placeholders
❐ Potentially Unwanted Software
❐ Scam/Questionable/Illegal
160

5. Right-click in the Action field of the new rule, click Set, then New, and select Strip Active Content.
6. In the Add Strip Active Content Object dialog box, click the Select All button.
7. Click OK and then click OK again.

Your VPM should appear similar to the following.
161

9. Test the policy by browsing to www.cnn.com. Confirm that active content has been stripped.
10. If time permits, try testing other news sites, such as www.bbc.com and notice the same result.
Lab Clean-up
1. Right-click the policy layer tab and select Delete Layer from the drop-down list. Click Install policy to
accept the new empty policy.
2. Close the VPM.
3. Close Firefox.
162
Module 10: Notifying Users of Internet
Usage Policies

30 minutes
Module Summary
The ProxySG can do more than let you control users’ Internet activities. It also allows you to explain your
organization’s Internet usage policies clearly and at the most effective time — when users try to access
questionable or forbidden pages.
Notifying users about policy when they use the Internet is a good practice, particularly when you block
access to certain types of content. Even if you install content-filtering software and write a strict Internet
usage policy, you may not see a gain in productivity unless you also tell users why they cannot view some
Web pages.
Users who cannot access a site might think a network problem has occurred and make unnecessary calls
to your organization’s help desk. However, you can prevent that problem by creating custom notification
pages. These pages appear in users’ browsers and tell them why access to certain sites is forbidden or why
access to other sites is officially discouraged even if it is allowed.
The ProxySG allows administrators to create exceptions and notification pages through the Visual Policy
Manager (VPM) instead of requiring them to write advanced Content Policy Language (CPL).
This module introduces the various kinds of notification pages and briefly explains how they are created.
Objectives
• Explain the function and various components of built-in and custom exception pages
• Describe the function of Notify User objects
• Identify the types of pages that can be sent to users by using Notify User objects
• Describe splash pages and coaching pages using Notify User objects in the VPM
Related Activities
• Exercise: Exception Pages
163
Slide Notes
Slide 10-1
Exception pages
• Configure in Management Console or CLI
• Sent when certain conditions or
transaction failures occur
• Built-in and user-defined
• More than 50 built-in exceptions
• Install definitions from Remote URL,
Local File, or Text Editor
• View Current Exceptions, Default
Exceptions Source, Exceptions
Configuration, and Results of Exceptions
Load
Exception pages are sent in response to certain ProxySG client requests, such as denial by policy, failure to
handle the request, and authentication failure.
Exception pages are returned to users based on policy rules defined by the ProxySG administrator.
Exceptions are configurable in either the Management Console or the CLI. This module uses the
Management Console; information on using the CLI is included in the Supplemental Topics.
164
Module 10: Notifying Users of Internet Usage Policies
Slide 10-2
Built-in exceptions
• Contents can be customized

• Cannot be deleted
• Cannot create new built-in exceptions
In the diagram:
1. A client sends a request that is intercepted by the ProxySG.
2. The request fails for any of more than 50 reasons. Possible reasons include a policy denial on the
ProxySG, authentication errors, or problems with the HTTP request that originated from the client or
ProxySG.
3. The ProxySG returns an exception page to the client.
There are more than 50 built-in exceptions; a complete list can be found in the SGOS Visual Policy Manager
Reference—
https://hypersonic.bluecoat.com/sites/default/files/tech_pubs/SGOSVisualPolicyManagerReference.pdf
However, built-in exceptions cannot be deleted, and you cannot create new built-in exceptions.
There is not a one-to-one correlation between exceptions and HTTP response codes. For example, many
conditions can cause an HTTP 503 (service unavailable) to be returned, but the ProxySG can differentiate
among the causes and report an appropriate exception to the client.
165
Slide 10-3
Exceptions list
• Structured Data Language (SDL) format
– Hierarchy of key/value pairs
– Access via Management Console or CLI
• Best practices
– Every list must begin with a definition for exception.all
– All definitions must be enclosed by exception.all and its accompanying
closing parenthesis
– Keep the definition strings under the enclosed parentheses short, no longer
than one line if possible
– Download the existing list, modify it with a text editor, and upload the
revised version
On your Management Console, go to Configuration > Policy > Exceptions. In the View Exceptions section,
select Current File, and click View.
The exception installable list uses the Structured Data Language (SDL) format. This format provides an
effective method to express a hierarchy of key/value pairs.
The Management Console allows you to create and install exceptions through a text editor, local file, or a
remote URL.
Additionally, you can create or edit an exception through the CLI. This is covered as a Supplemental Topic.
The default exceptions can be viewed at (and restored from) https://proxyIPaddr:8082/
exceptions_default.txt.
166
Slide 10-4
Exception hierarchy
• Children inherit properties from their

parents
• User-defined exceptions inherit
properties from exception.user-
defined.all
• exception.user-defined.all
inherits properties from
exception.all
Exceptions are stored in a hierarchical model, and parent exceptions can provide default values for child
exceptions.
The exceptions file has a tree structure with the root being exception.all and then a main branch
called exception.user-defined.all.
All built-in exceptions are leaves directly off the root. The slide shows the two most common built-in
exceptions that a user is likely to see. Under user-defined, the slide shows how you could create an
denied page in Italian and one possibly in Chinese.
A key point: Exceptions are not required to have their entire contents defined separately for each exception.
The user-defined.all exception is the parent of all user-defined exceptions, but it is also a child of the
all exception. Configuring exception.user-defined.all is only necessary if you want certain fields
to be common for all user-defined exceptions, but not common for built-in exceptions.
167
Slide 10-5
Exception definitions
Item Purpose Substitution variable
Identifier The name of the exception $(exception.id)

Defines the appearance of the
Format exception (such as HTML or simple –
substitutions)
Short title to be displayed (such as
Summary $(exception.summary)
“Access Denied”)
Expanded text describing
Details $(exception.details)
the reason for the exception
Tells the user about possible causes
Help $(exception.help)
and solutions
Contact Site-specific contact information $(exception.contact)
HTTP-Code HTTP response code to use –
This slide shows where the components of an exception page appear when the user sees it, as well as
substitution variables that can be used to refer to each component.
The Format field, which is the body of the exception, is not available as a substitution. But it usually
contains other variable substitutions.
Pre-defined and user-defined exceptions contain the same components.
Fields other than Format must be fewer than 8,000 characters. If they are longer than this, they are not
displayed.
168
Slide 10-6
VPM action—Return Exception
• Return customized exception pages triggered by specific policy matches

• Default response is HTTP 403
• Cannot be deleted if in use by policy
• Messages can contain HTML, image links, JavaScript
Even though more than 50 pre-defined exceptions are available, you might want to create a user-defined
exception so that users can received highly customized pages based on specific policy matches.
The slide shows a simple VPM example in which two user-defined exceptions are returned: one that
explains the no-hacking policy, and another that explains the time-of-day restrictions on travel websites.
Otherwise, user-defined exceptions work the same as the pre-defined exceptions shown in the previous
slide.
169
Slide 10-7
Substitution Variables
• Customize the exception message presented to users

• Variable types
– Parts of the exception definition (ID, summary, details, etc.)
– HTTP request data (method, URL, ProxySG name, user, etc.)
<html>
<title>$(exception.id): $(exception.summary)</title>
<body><pre>
Request: $(method) $(url) $(proxy.name) $(user.name)
Details: $(exception.details)
Help: $(exception.help)
Contact: $(exception.contact)
</pre></body>
</html>
This slide shows a simple Format field in which the exception substitution variables have been used to
create a detailed exception page.
Experienced ProxySG users might recognize that substitution variables are also part of CPL.
Other substitution variables include username, IP address, time, date, and so on. More information is
contained in the Supplemental Topics for this module.
170
Slide 10-8
Notify user objects
• Splash pages
• Coaching pages
• Directly configure in Web Access
layer of VPM only
• Not available in CLI
• Require user action to proceed
Notify User objects display a notification page in the user’s Web browser. A user must read the notification
and click an Accept button before accessing the Web content. Notify User objects are directly configurable
only in the VPM. It is possible to write CPL code that performs the function of a Notify User object (in fact,
CPL is generated from the VPM), but the resulting CPL is large and difficult to read or troubleshoot. Notify
User objects cannot be administered in the CLI.
The key point is to make sure that you understand the difference between exceptions, which generally
report failures to display requested content, and notifications, which require the user to take specific action
(clicking on an Accept button or link, for instance) to view the requested content.
171
Slide 10-9
Notify User objects in the VPM
• Displays intermediate web page in user’s browser

– Splash (compliance) page: Delivers message to users
– Coaching page: Warns about accessing specific content
• Display intervals can be configured

• Requires enabled cookies in user’s browser
• HTTP only
A Notify User object is an Action object that can be created as part of a rule in the VPM.
This action displays a notification page in the user’s web browser. A user must read the notification and
click an Accept link or button before being allowed to access the web content.
There are two types of pages that a Notify User object can display:
• Splash page (also called a compliance page in some documentation): This page ensures employees
read and understand the company’s Acceptable Use Policy before Internet use is granted.
• Coaching page: Displays when a user visits a website that is blocked by content filtering policy. This
page explains why the site is blocked, the consequences of unauthorized access, and a link to the site if
business purposes warrants access.
For both types of pages, the administrator can configure the display interval.
The implementation of Notify User objects uses cookies in the user’s web browser, and only HTTP is
supported.
172
Slide 10-10
Notify User object components
Item Substitution variable

Name Short identifier used only in the VPM
Title Title of page displayed to user; no HTML allowed

Main text of page to be displayed; HTML allowed;
Body
must contain an Accept link or button (default available)
Notify mode Defines how often to display the page
Notify users
Defines how often to redisplay the page to the same user
again
This slide presents the options that are available when configuring a Notify User object in the VPM.
A notify mode of Notify once for all hosts uses a virtual notify URL that defaults to notify.bluecoat.com.
The consequences of changing this URL, and other considerations of specifying notify modes, are
discussed in the Supplemental Topics.
173
Slide 10-11
Splash page
This slide is a detailed step-by-step look at how splash pages work.

Key point: Splash pages are not triggered by an attempt to access specific web content. Instead, the Accept
link or button can be thought of as a “speed bump” that requires users to acknowledge some condition or
some part of the organization’s AUP.
Splash pages are very versatile, enabling administrators to deliver any kind of message at a specific time
without blocking or limiting access to a resource.
Typically, a compliance notification is displayed each time a browser is opened, but you can configure a
time condition to display the page at specific intervals or times of the day, week, or month.
174
Slide 10-12
Coaching page
This slide is a detailed step-by-step look at how coaching pages work.

Be sure you understand the difference between an exception page and a coaching page. Both appear when
a resource is forbidden; however, a coaching page allows users to access the resource temporarily.
A coaching page is configured to display each time a user visits a new Web page that is barred by content
filtering policy; however, you can also configure this page to appear at different time intervals.
175
Supplemental Topics
Substitution Variables in Exception Pages
In addition to the substitution variables shown in the “Exception Definitions” table, other variables are
available to further customize the exception text. Some common variables include:
• $(client.address): The IP address of the requesting computer
• $(user): The authenticated username of the requester.
• $(url.host): The requested URL.
• $(categories): The content-filtering category of the requested URL.
Substitution variables are used in advanced Content Policy Language, which is outside the scope of this
course, but the same variables can be used in exception definitions. For a complete list of substitution
variables, refer to the SGOS Content Policy Language Reference, available at BlueTouch Online.
Also, the following non-CPL substitution variables can be used in exception page definitions:
• $(exception.last_error): For certain requests, the ProxySG determines additional details on
why the exception was issued. This substitution includes that extra information.
• $(exception.reason): This substitution is determined internally by the ProxySG when it
terminates a transaction and indicates the reason that the transaction was terminated.
Creating Exception Pages in the CLI

In addition to using the VPM, you can create exception pages by using the command line interface (CLI).
Generally, you enter configuration mode and perform the exceptions command, and then you use a
separate command to define each component of the exception.
For more information, refer to the section “#(config) exceptions” in the SGOS 6.x Command Line Interface
Reference— https://hypersonic.bluecoat.com/sites/default/files/tech_pubs/65CLIRef.pdf
Specifying Options in Notify User Objects

When creating a Notify User object, each of the available notification modes can cause problems under
some conditions.
• Notify once for all hosts: This option uses a virtual notify URL that defaults to notify.bluecoat.com. This
virtual URL should not need to be changed in most cases, but if you must change it from the default
value, you must observe the following rules:
❐ The URL consists must be an HTTP domain name or IP address; a port number is optional.
❐ Do not use a hostname that is explicitly defined as a trusted site on Internet Explorer 6 for
Windows XP, Service Pack 2.
❐ Only use domain names that contain dots.
❐ In transparent proxy deployments, the domain name must be DNS-resolvable to an IP address that
is in the range of destination IP addresses that are routed to the ProxySG.
Also, this option might cause users to experience some noticeable web browsing slowness.
• Notify only once for related domains: This option interferes with some web advertising banners. In
some cases, the notification page appears inside the banner. In other cases, banner ads are disabled
by JavaScript errors. To fix these problems, do not serve notification pages for URLs that belong to the
Blue Coat WebFilter categories Web Advertising, Advertising, or Web Ads.
• Notify on every host: In addition to breaking banner ads, as described above in the previous option, this
option might cause JavaScript errors on some websites.
176
For more information, refer to the section “Notify User,” in the “Action Column Object Reference” of the
SGOS 6.x Visual Policy Manager Reference—
https://hypersonic.bluecoat.com/sites/default/files/tech_pubs/SGOSVisualPolicyManagerReference.pdf
• “Creating Notification Policies: Coaching, Splash, and Compliance,” technical brief available at the
following URL—
000/DOC9819/en_US/Creating_Notification_Policies-_Coaching,_Splash,_and_Compliance.f.pdf?__gd
a__=1496931413_451e2a97fb97cb239967ef773332164e
• “Custom Exception Pages for ProxySG”—
000/DOC9820/en_US/symc_tb_Custom_Exception_Pages.pdf?__gda__=1496931503_7818c0f29cbc7f3
419815d25edbc3800
• “Defining Exceptions,” in the SGOS 6.x Visual Policy Manager Reference—
df
• “Notify User,” in the “Action Column Object Reference” of the SGOS 6.x Visual Policy Manager
Reference—
df
177
Review Questions
1. What are the two types of ProxySG exceptions?
2. When the ProxySG sends an exception page to a client, where does it get the text of the exception
page?
3. How do you create a new built-in exception on the ProxySG?
4. From where does the exception exception.user-defined.all inherit its properties?
5. In the VPM, what type of object is a Notify User object?
6. After receiving a splash page from the ProxySG, how often will a user receive a subsequent splash
page?
178
Exercise: Exception Pages
Lab 10: Exception Pages

20 minutes
Objectives
• Change the default exception format
• View properties of the exception page
• Create policy that displays various exception details
Scenario
Exception pages on the ProxySG allow you to warn, advise, and block users based on their attempts to
access particular websites. These pages give administrators a great deal of flexibility in terms of how
much control they can exert over their user community. When a user is denied access to a particular
website, for example, the administrator can send a customized message to the user, explaining the reason
for this action.
In this exercise, you will change the default exception format. You will then create a policy to generate this
exception.
Before You Begin

• This exercise requires that the Intelligence Services database has been downloaded and enabled on
your ProxySG.
Sections
• 10-1: Load a pre-defined exception file
• 10-2: View current exceptions
• 10-3: Create a policy to deny access to a category
• 10-4: Customize details of a built-in exception page
179
10-1: Load a Pre-Defined Exception File

1. In the Management Console, go to Configuration > Policy > Exceptions.
2. In the Install Exceptions Definitions from: section, select Local File from the drop-down list, and click
Install.
3. From the Documents folder, select custom_exceptions.txt, and click Open.
4. Confirm that the file installs successfully.
180
10-2: View Current Exceptions

1. In the View Exceptions section, select Exceptions Configuration from the dropdown menu and click
View.
2. In the Built-in Exceptions section, scroll down to policy-denied, and click View Sample HTML.
3. Inspect the various components of the message.

a. Access Denied — Exception summary
b. (policy_denied) — Exception ID
c. Your system policy has denied access to the requested URL.— Exception details
d. For assistance... — Exception contact
4. Click Back in your browser to return to the Built-in Exceptions page, scroll down to policy-denied, and
click View Expanded Settings. Notice the information available here.
181
5. Return to the Management Console.
10-3: Create a Policy to Deny Access to a Category

1. Launch the VPM.
2. Add a Web Access Layer.
3. In the Destination field, click Set, and then New, and select Request URL Category.
4. Under the Blue Coat heading, select Proxy Avoidance. Click OK, and then OK again. Leave the Action
as Deny.

6. In Firefox, navigate to sitereview.bluecoat.com, click the Category dropdown and select Test Pages.
Scroll down and select Proxy Avoidance. Make sure the exception page displays.
7. Now, to test the custom file you installed earlier, go back to the VPM, right-click the Action field, click
Set, New, and select Return Exception.
182
8. In the Add Return Exception Object dialog box, check User-defined exception: and select
table_exception from the dropdown list. This will pull the custom exception file you installed earlier
from the repository of user-defined exceptions.
10. Now in Firefox, go back to sitereview.bluecoat.com and test Proxy Avoidance again.
Notice how much more information is displayed to the user.
183
10-4: Customize Details of a Built-in Exception Page

1. Right-click the Action field of the Web Access layer you created, select Set, and then click New.
2. Near the top of the list that displays, select Return Exception.
3. In the Add Return Exception Object dialog box:

a. In the Name field, give the object a unique name.
b. In the Built-in Exception list, scroll to select policy_denied.
c. In the Details section, write the following (make sure that you do not add spaces in the variable):
Access to $(exception.category) is prohibited. You were denied by
$(proxy.name).
4. Click OK, then OK again, and click Install Policy.

5. In your browser, go back to sitereview.bluecoat.com, select the Category dropdown and select Test
Pages. Scroll down and select Proxy Avoidance. You can see your custom message displayed.
184
By using the Return Exception object, you can customize the details field of your exception while
keeping the rest of the fields set to their default values.
Lab Clean-up
1. In the VPM, remove the policy layer that you created and install the blank policy.
2. Close Firefox.
185
186
Module 11: Access Logging on the ProxySG

30 minutes
Module Summary
Access logging on the ProxySG allows you to track traffic for the entire network or specific information on
user or department usage patterns. Each time a user requests a resource, the ProxySG saves information
about that request to a file for later analysis.The information stored is called a log. In addition to web policy
management, content filtering, and web content virus scanning, companies can implement monitoring
schemes through the access logging feature. Access logging gives companies the ability to audit all traffic
for both external and internal content requests.
Access logs can be directed to one or more log facilities, which associate the logs with their configured log
formats and upload schedules.
Stored data can be automatically uploaded to a remote location for analysis and archival purposes. Uploads
can take place using HTTP, FTP, or one of several vendor-specific protocols. Once uploaded, reporting
tools such as Symantec Reporter can be used to analyze log files. These logs and reports generated from
them can be made available in real time or on a scheduled basis.
Reporter is a full-featured tool with many options and possible uses that are beyond the scope of this
course.
Important: The use and content of ProxySG access logs might be subject to legal restrictions in your
jurisdiction. Consult your legal adviser. You are responsible for ensuring that your use of the
ProxySG is in compliance with all appropriate laws.
Objectives
• Describe, at a high level, how the ProxySG performs access logging
• Describe the components of a ProxySG access log facility
• Identify default log facilities and log formats
• Describe common use cases for periodic and continuous uploading of access logs
Related Activities
• Exercise: Access Logging Policy
187
Slide Notes
Slide 11-1
Access logging
Access logging is enabled or disabled in the Management Console or through the CLI.
When the ProxySG intercepts transactions between a client and a server, access logging causes
information about the transaction to be stored in log facilities, subject to the general access logging
parameters and any policy that has been written to customize access logging.
The ProxySG periodically or continuously uploads data stored in the log facilities to an external location
that is defined by the administrator. This location can be as simple as an FTP server, or a client such as
Blue Coat Reporter.
The administrator then can use external reporting tools, such as Reporter, to process and analyze the data
stored in the logs.
188
Slide 11-2
Log facility
Log facility—Raw access log, log format, log update schedule, and general log configuration settings
Log rotation helps prevent logs from growing too large.

The ProxySG periodically creates a new log file and archives the older one without disturbing the current
log file.
189
Slide 11-3
Protocols and default log facilities
This slide discusses the various protocols and their associated log facilities on the ProxySG. Note that a
single log facility can be associated with several protocols.
If you use reporting tools other than Reporter, you need to use the specific log format for that vendor. Use
of reporting tools from sources other than Symantec is beyond the scope of this course.
You can associate a log facility with a protocol at any time. But if you have a policy that defines a protocol
and log facility association, that policy will override any settings that you make.
Multiple access log facilities are supported in the ProxySG, although each access log supports a single log
format. You can log a single transaction to multiple log facilities through a global configuration setting for
the protocol that can be modified on a per-transaction basis through policy.
190
Slide 11-4
Log formats and log types
This slide shows the recommended log format you should associate with these log facilities when using
Reporter to obtain optimum performance.
Most content is HTTP content and uses the main log facility, which uses the ELFF-compatible log format
bcreportermain_v1, designed for use with Symantec Reporter.
Secure content such as SSL and HTTPS uses the bcreporterssl_v1 format, which contains only fields that
do not reveal private or sensitive information.
If you also use Reporter, you can use Reporter’s Page View Combiner (PVC) feature in conjunction with the
main log. When a user goes to a web page, that page often sends out requests for more content, either
from the same server or from different servers. Rather than regarding each of these requests as separate
requests, PVC combines all of these related page requests into one.
Other log formats include formats that are compatible with Websense, SurfControl, and SmartReporter.
These formats are beyond the scope of this course.
191
Slide 11-5
ELFF definitions
• One or more strings, each with one of these formats:
– Machine-independent identifier, such as date or time
– Prefix and identifier, separated by dash, such as c-ip
– Prefix and HTTP header name in parentheses, such as rs(content-type)
Protocol Default Log Facility
c client
s server (ProxySG)
r remote (origin content server)
sr server to remote
cs client to server
sc server to client
rs remote to server
This slide discusses the components of an ELFF string. The key point is to note the meaning of C (client), S
(ProxySG), and R (remote server). Examples appear on the next slide.
In the context of ELFF strings, the ProxySG is viewed as the server.
192
Slide 11-6
ELFF strings: Examples
• c-ip: IP address of the client

• rs(Content-Type): Value of the HTTP Content-Type
header from the OCS to the ProxySG
• cs(User-Agent): Value of HTTP user agent header from
client to ProxySG
• x-virus-id: Identifier of a virus if one was detected
This slide shows an example of the main log format.

The SGOS Administration Guide contains definitions for all the fields.
193
Slide 11-7
Sample log
• Log file header
• One entry for each logged transaction
This slide discusses some key points about the structure of an access log. The file shown in the slide is a
main access log using bcreportermain_v1 format.
The header must exist in all log files. If the header is missing, Reporter does not process the file and the
data it contains.
You can fix a log file by manually copying and pasting the headers from a properly formatted log file.
The #Remark header contains the serial number and the IP address of the ProxySG that created it; this is
important information when you are troubleshooting a multi-proxy environment.
Log files must have valid headers. Reporter does not process log files that do not contain valid headers.
You can manually re-create the header if you have log files that would otherwise be valid. Files without a
header can appear when you change log formats without interrupting access logging first.
194
Slide 11-8
Log upload schedule
The ProxySG allows you to upload access log files periodically or continuously to a remote server.
The upload schedule feature of the ProxySG allows to configure the frequency of the access logging upload,
time between connection attempts, and time at which the log is uploaded.
With periodic uploading, the ProxySG transmits log entries on a scheduled basis, such as once a day or at
specific time intervals. The log entries are batched, saved to disk, and then uploaded to a remote server at
a particular time.
Periodic uploading is advised when you do not need to analyze the log entries in real time.
In continuous uploading, the ProxySG continuously streams new access log entries to the remote server
from its memory. Continuous uploading can send log information from a ProxySG farm to a single log
analysis tool. This allows you to treat multiple ProxySG appliances as a single entity and to review
combined information from a single log file or series of related log files.
When you configure the ProxySG for continuous uploading, it continues to stream log files until you stop it.
In this context, streaming refers to the real-time transmission of access logs files using a specified upload
client.
If the remote server is unavailable to receive continuous upload log entries, the ProxySG saves the log
information on the ProxySG disk. When the remote server is available again, the ProxySG resumes
continuous uploading.
Logs can be uploaded in plaintext or using gzip compression. Although Reporter can decompress log
entries that are uploaded continuously, Symantec recommends using plaintext when analyzing logs in real
time.
195
Slide 11-9
Log upload clients
Symantec supports several upload clients for the appliance, including FTP and HTTP.
You can also create a custom SurfControl client.
As of SGOS 6.6.2, you can use Kafka as a new access log upload client. The logs are relayed to a cluster of
one or more servers over a mutually authenticated channel.
196
Slide 11-10
Access logging in the VPM

• Implemented as action objects that override default access log setting in
Management Console
• Modify access logging
– Do (or do not) log this transaction in a specified log
– Enable or disable all access logging
• Override access log field
– Do (or do not) include field in the log entry
– Rewrite value to a different ELFF string
For most organizations, the default access log settings are sufficient. However, you can introduce a very
detailed level of customization.
You can use the VPM to define additional details of the information, which is stored in the access log. For
instance, you can disable monitoring of certain users (such as the executive management and Human
Resources). Similarly, you can disable logging of traffic to certain URLs because there might be little
information to gain in logging access to internal and organization-related sites.
Also, you can create a custom log facility, where you record very specific parameters, and create a policy to
log the traffic from a certain source, or to a certain destination or both in that log facility. If you are
investigating a user (or access to a specific resource), sometimes it is faster to gather the information
about the target user (or location) in a separate access log. This allows you to run reports much more
efficiently because you do not have to sort through your entire organization’s data.
197
Supplemental Topics
Appliance Identifier
As of SGOS 6.6.2, you can identify the ProxySG appliance for a given log entry. Display the compact
identifier of the ProxySG through the new CLI command:
>show appliance-identifier
The appliance identifier is the same as the value returned in the access log and policy substitution
x-bluecoat-appliance-identifier.
Support for Apache Kafka

As of SGOS 6.6.2, you can use Kafka as a new access log upload client to upload logs from the ProxySG
appliance to Symantec Reporter or Symantec Hosted Reporting Service. The logs are relayed to a cluster of
one or more servers over a mutually authenticated channel.
To use Apache terminology, the ProxySG appliance is the producer, Reporter/Hosted Reporting Service is
the consumer, and the cluster of servers is the broker.
To use Kafka as the upload client:
• The ProxySG appliance must be able to access the Kafka broker.
• The Reporter/Hosted Reporting Service server must be available.
For more information, see the SGOS Administration Guide — Configuring the Upload Client.
Integration with Security Analytics Platform

The ProxySG appliance has an access log format to support integration with the Symantec Security
Analytics Platform. You can configure the new bcsecurityanalytics_v1 log format to send appropriate log
entries to the Security Analytics Platform.
The new log format is available in the Management Console in Configuration > Access Logging > Formats.
For more information, see the SGOS Administration Guide — Creating Custom Access Log Formats—
097e7aa3f8d901096ae
Set Application Name in Policy and Access Log Fields

You can now set a custom name for the application associated with a URL. This value of this property
populates the WebPulse access log field x-bluecoat-application-name when traffic matches and access
logging is enabled.
<proxy>
url.domain=company.com application.name(<app_name>)
where <app_name> is the application name.
Creating a Custom Log Facility

Although the predefined log facilities are sufficient for most deployments, you also can create a custom log
facility. To create a custom log facility:
1. Choose a log format, or create a custom format.
2. Create a log name, and assign a format.
3. Assign a protocol to the log facility.
4. Configure the upload client.
198
5. Configure the upload schedule, rotation schedule, and general settings.

For more information, refer to the chapter “Creating and Editing An Access Log Facility” in the SGOS
Administration Guide—
097e7aa3f8d901096ae
Signing and Encrypting Access Logs

During the uploading process, access logs can be digitally signed and encrypted for security.
You can digitally sign access logs to certify that a particular ProxySG wrote and uploaded this log file.
Signing is supported for both content types — text and gzip — and for both upload types — continuous and
periodic. Each log file has a signature file associated with it that contains the certificate and the digital
signature for verifying the log file.
The signature file has the same name as the access log file but with a .sig extension; that is,
filename.log.sig if the access log is a text file, or filename.log.gzip.sig if the access log is a gzip file. If you
use Reporter to analyze the access logs, decrypt the access logs using a command-line decryption tool
(such as OpenSSL) before loading them into the database.
You can digitally sign your access log files with or without encryption. If the log is both signed and
encrypted, the signing operation is done first, meaning that the signature is calculated on the unencrypted
version of the file. You must decrypt the log file before verifying the file. Attempting to verify an encrypted
file fails.
For more information, refer to the chapter “Configuring the Upload Client” in the SGOS Administration
Guide—
097e7aa3f8d901096ae
Transaction Information in Access Logs

This diagram describes the
transaction that occurs between a
client and a server and how access
logs keep a record of information
that was served from a cache or
entirely from RAM, or when the
information was obtained from the
origin content server.
When the client first requests
information (an object), the
ProxySG checks with the cache to
determine whether the requested
object can be served from there. If
the object is present in the cache,
then TCP_HIT is recorded in the
access log and the object is sent to
the client. If the object was entirely present in the RAM, it is served from the RAM and TCP_MEM_HIT is
recorded in the server action field in the access log.
If the object was present in the cache but the virus-scanner-tag-id did not match the current
scanner tag, the object is rescanned by sending it to the ProxyAV. The server action field in the access log
then records the action as TCP_RESCAN_HIT. The object is sent to the client after the virus scanning.
199
If the requested object is not found in the cache or the RAM, the request is sent to the origin content server
to retrieve the object. If the requested object was not present in cache at all, the action is recorded as
TCP_MISS.
Usually when objects are obtained from the OCS, the ProxySG saves a copy in its cache. If the object
returned from the origin server is not cacheable, the action is saved as TCP_NC_MISS. To speed delivery of
requested objects, the ProxySG can serve cached objects while requesting for fresher content from the
origin server. In this case, the action gets recorded in the access log as TCP_PARTIAL_MISS.
Actions are also logged in the access log when objects are delivered to the client. When the object is
successfully delivered to the client, the action is logged as ALLOWED. When policies in the ProxySG deny
the object from being delivered to the client, the action is logged as DENIED. When access to the requested
object is denied by a filter, the action is logged as TCP_DENIED.
Note that all content that contains a “?” in the URL (query string) is considered dynamic content and not
worth caching. This is the most common example of non-cacheable content.
• “Configuring Access Logging,” in the SGOS Administration Guide—
d056f3097e7aa3f8d901096ae
• “Configuring Access Logging on the ProxySG to an FTP Server and to Reporter”—
200
Review Questions
1. What are the five components of a log facility?
2. By default, HTTP traffic that is logged is recorded to which log facility?
3. By default, what log format is associated with the main log facility?
4. What does the ELFF string c-ip represent?
5. If an access log file has no header, how does Blue Coat Reporter process the file?
6. When uploading access logs, which type of upload uses the least disk space on the ProxySG: periodic
or continuous?
7. If you have configured continuous uploading of access logs and the ProxySG is unable to reach the
upload destination, what happens to the log entries?
8. In the VPM, access logging is controlled by which type of objects?
9. True or false: Access logging is disabled by default, and you must configure the ProxySG to intercept
the protocols that you wish to log.
201
202
Exercise: Access Logging Policy
Lab 11: Access Logging Policy

20 minutes
Objectives
• Use the Visual Policy Manager (VPM) to create policy that affects how the ProxySG generates access
log entries, and the contents of those log entries.
• Use the Management Console to view access logs in real time.
Scenario
Because the main access log contains all user transactions, it’s sometimes hard to find specific
information you may be seeking because there are so many transactions appearing from all users.
This exercise demonstrates how to create a duplicate access log, either for troubleshooting purposes or to
track an individual IP client.
In some cases, there may be a requirement to exclude specific client IP addresses (such as the address of
the CEO) from the access log. In the last section of this exercise, you will disable access logging for a
specific client IP address.
Before You Begin

Sections
• 11-1: Create a duplicate access log
• 11-2: Create and test the policy
• 11-3: Exclude a specific client IP address from the access log
203
11-1: Create a Duplicate Access Log

1. In the Management Console, go to Configuration > Access Logging > Logs, and click New.
2. In the Create Log dialog box, enter the following:

❐ Log Name: test
❐ Log Format: bcreportermain_v1
204
3. Click OK, and Apply. Click No if a warning dialog box appears.
11-2: Create and Test the Policy

1. Launch the Visual Policy Manager and create a Web Access layer.
2. Right-click in the Source field and select Client: 10.10.2.101 (this object was created in an earlier
exercise) and click OK.
3. In the Action field, click Set, and in the Set Action Object dialog box, click New and select Modify
Access Logging.
205
4. In the Add Access Logging Object dialog box, check Enable logging to: and select test from the
dropdown list.

7. To test the policy, go to Statistics > Access Logging > Log Tail, select main from the Log dropdown list,
and click Start Tail.
206
8. Launch Firefox and navigate to several websites.

9. Click Stop Tail.
10. Verify that traffic is being logged.
11. Now go to Statistics > Access Logging > Log Tail, select test from the Log dropdown list, and click
Start Tail.
12. Again, in Firefox navigate to several websites.
13. Verify that traffic is being logged.
207
14. Click Stop Tail and then Clear Tail.
11-3: Exclude a Specific Client IP Address from the Access Log

1. Delete the contents of the Action field of the Web Access layer, click Set, and in the Set Action Object
dialog box, click New and select Modify Access Logging.
2. In the Add Access Logging Object dialog box, enter a meaningful name in the Name field if desired, and
check Disable all access logging:.
3. Click OK and OK again, and install the policy.

4. To test the policy, go to Statistics > Access Logging > Log Tail, select main from the Log dropdown list,
and click Start Tail.
5. Close and reopen Firefox, and confirm that no logging is taking place.
208
6. Next, select test from the Log dropdown list, click Start Tail, refresh your browser, and confirm that no
logging is taking place.
Lab Clean-up
1. In the VPM, delete the Web Access layer you created and install the blank policy.
2. Close Firefox.
209
210
Appendix A: ProxySG Initial Configuration

40 minutes
Module Summary
After you have physically installed a new ProxySG, the next step is to configure the operating software of
the appliance so that it can begin filtering and optimizing network traffic. This process involves making
several key decisions about how the appliance will be deployed and what it will be expected to do. This
module describes the methods that you can use to initially configure a new ProxySG.
Objectives
• Access the ProxySG and perform initial configuration
• Describe the two SGOS editions and various license types
• Understand the optional capabilities available with SGOS
Related Activities
• Instructor-Led Demo: ProxySG Initial Configuration (Optional)
Prerequisites
Before beginning this module, students should complete these modules:
• ProxySG Security Deployments
211
Slide Notes
Slide 12-1
Initial configuration access methods
There are three access methods for the ProxySG:

• A direct connection via a serial cable to the serial console
• From the front panel of the appliance, and
• Using Symantec Management Center, which is a unified management environment that provides
visibility and management across the portfolio of Symantec Blue Coat products, spanning cloud and
on-premise.
In this training, we will describe the serial connection method.
212
Module Appendix A:: ProxySG Initial Configuration
Slide 12-2
Initial Configuration Steps: SWG

• Setup type
• Solution
• Interface addressing
• VLAN configuration (if
needed)
• IP address, subnet mask,
gateway, DNS server
• Passwords
• Console
• Enable
• Serial port access
Before you begin the initial configuration, you will want to have the following information ready:
• For Setup Type:
Are you using Management Center for the configuration, or will you be configuring the ProxySG
manually?
• For Solution:
Do you intend to use the ProxySG for WAN optimization, or as a Secure Web Gateway?
• For the interface:
You will need to decide whether VLAN configuration is needed.
You will need to be ready to assign an IP address, subnet mask, default gateway, as well as specify a
DNS server.
• For Passwords:
You will assign a console username and password, as well as an enable password to enable
administrative credentials.
Decide whether to secure the serial port with a password for added security.
• For SGOS Edition:
For WAN optimization, choose MACH5 Edition; for Secure Web Gateway, choose Proxy Edition.
When the configuration is complete, you will be able to access the ProxySG through a web browser, using
the address you’ve just assigned.
213
Slide 12-3
Access control
Physical security is the most important aspect of securing any device in the network.
This diagram shows the possible settings you can control to secure administrative access to the ProxySG.
If you forget all the passwords (built-in admin, front panel, and serial console), you cannot access the
ProxySG and will need to use the appliance’s reset button or, if it is a legacy model without a reset button,
return it to Symantec. Therefore, it is recommended to not set a serial console password; the ProxySG does
not have a password recovery option.
214
Slide 12-4
SGOS editions
Proxy Edition MACH5 Edition
(Security) (Acceleration)
Full Proxy Edition Acceleration Edition

Alternate names
Full SWG functionality Yes No
Full WAN Op functionality Yes Yes
Default behavior Deny connections Allow connections
ProxySG VA support Yes Yes
This table compares the two SGOS editions. The Proxy Edition is for SWG deployments, although the Proxy
Edition can also perform some WAN optimization functions.
215
Slide 12-5
SGOS license types

License type Properties Expires?
 SGOS base license for 60 days
 Ships with all new physical ProxySG appliances
Trial  Either Proxy Edition or MACH5 Edition can be chosen Yes
 SGOS user limit is unlimited
 reset-trial command can be used up to twice
 Temporary, can be requested from Symantec or
reseller
Demo  Extend evaluation period Yes
 Existing customer evaluation of additional features
 Duration set by Symantec or reseller
 Permanently unlocks purchased features
Permanent No
 User limits enforced, even if trial period still valid
Subscription  ProxySG VA only Yes
The table lists the main license types and characteristics of each:
New ProxySG physical appliances ship with a 60-day Trial license. (Trial licenses are not available on
virtual appliances.) All licensable components for the trial edition (Proxy Edition or MACH5) are active and
available to use. In addition, the Base SGOS user limit is unlimited. The undocumented and hidden
command reset-trial allows you to start a new 60-day trial period. You can use the command up to two
times. If your trial expires, then you can reset it by using this command from the CLI and then rebooting the
ProxySG. The 60-day period resets when the ProxySG is rebooted after issuing this command. Restoring a
ProxySG to factory defaults does not reset the number of trial license resets; even if you restore the
ProxySG to factory defaults, you can only reset the trial license a maximum of two times.
A temporary Demo license can be requested to extend the evaluation period, or to allow existing customers
to evaluate additional functionality that they have not purchased.
A Permanent license for hardware platforms permanently unlocks the software features you have
purchased. When a permanent license is installed, any user limits imposed by that license are enforced,
even if the trial period is still valid.
Virtual appliances require a Subscription-based license.
216
Slide 12-6
Optional capabilities
License type Properties
 Separate licenses for Intelligent Services bundles that

include desired data feeds must be purchased
Intelligence
Services  Services include Content Categories, Security Categories,
URL Threat Risk Levels, Geolocation, and Basic Web
Application Controls
Encrypted Tap  Requires SSL and Encrypted Tap license
CachePulse  Requires subscription
Flash streaming  Additional cost
Powered by the Global Intelligence Network, Blue Coat Intelligence Services deliver fast, real-time global
content categorization to empower advanced threat defenses and support ongoing enterprise compliance.
More information on these options is presented in the WebFilter, WebPulse, and the Global Intelligence
Network training module.
Encrypted Tap works with the SSL Proxy service to offer complete visibility into SSL traffic handled by the
ProxySG. More details on Encrypted Tap are available in the Introduction to Encrypted Traffic Management
training module.
The CachePulse technology delivers real-time intelligence for effective content categorization and
caching.
The ProxySG offers a number of proxies for streaming media. The ProxySG's streaming proxies are able to
improve the quality of streaming media, reducing artifacts such as frozen playback and dropped frames.
217
Slide 12-7
Unit reset and restart commands

restore-defaults …
Confirmation ProxySG IP SGOS license

needed configuration addresses edition
Yes Reset Reset Reset

factory-defaults
force No Reset Reset Reset
keep-console Yes Reset Saved Saved
restart [subcommands]…
• # restart abrupt—Reboots the system abruptly, according to the version of the ProxySG that is
currently installed. Reboots the system abruptly, according to the version of the ProxySG that is
currently installed. Restart abrupt saves a core image.
• # restart regular—Reboots the version of the ProxySG that is currently installed
• # restart upgrade—Reboots the entire system image and allows you to select the version you
want to boot, not limited to the new version on the system.
The factory-defaults setting goes all the way back to manufactured status, which means the only
access is through the serial console or the front panel (if one is available on your ProxySG model).
The keep-console setting keeps configured IP addresses so the ProxySG can continue to be accessed
via web browser.
The force setting restores everything to factory defaults without prompting for confirmation.
218
Slide 12-8
IPv6 Deployment
• IPv6 support is enabled by default
• Initial configuration requires an IPv4 address
• IPv6 address for each interface is automatically generated but can be changed later
ProxySG initial setup requires specification of an IPv4 address.

An IPv6 address is automatically obtained and can be changed in the Management Console later.
IPv4 address must be specified during initial configuration, but IPv6-specific parts might need to be done
in the Management Console afterward.
219
Supplemental Topics
VLAN Configuration
During initial configuration of the ProxySG, you can specify that the appliance is part of a non-native Virtual
Local Area Network (VLAN). Configuration of VLANs is not covered in this course, but information on this
topic can be found at the following sources:
• “Configuring Adapters and Virtual LANs” chapter in the SGOS Administration Guide. One version of this
guide is available at the following URL—
d056f3097e7aa3f8d901096ae
Requiring a PIN for the Front Panel

On ProxySG appliances that have a front panel display, you can create a four-digit PIN to protect the system
from unauthorized use. The PIN is hashed and stored. You can create a PIN only from the command line
interface. To create a front panel PIN after initial configuration:
#(config) security front-panel-pin PIN
where PIN is a four-digit number.
To clear the front-panel PIN:
#(config) security front-panel-pin 0000
This also means that you cannot use 0000 as your PIN.
Console Access Control

During initial configuration, you have the option of preventing workstations with unauthorized IP addresses
from accessing the CLI and Web-based management interfaces. If this option is not enabled, all
workstations are allowed to access the CLI and Web-based management interfaces. You also can add
allowed workstations later to the access control list.
You have the ability to disable the built-in administrative account and enforce the use of directory-based
accounts. This is an important option for accounting and auditing purposes. You do not want to share the
same administrative account among different users, and you do not want to create and maintain additional
accounts outside your directory.
The ProxySG allows you to use any realm that supports basic authentication credentials — such as
Microsoft Active Directory, Novell eDirectory, or another Lightweight Directory Access Protocol realm — to
validate users before they can access the graphical user interface or the CLI.
Initial Configuration With Symantec Management Center

After a ProxySG has been assigned an IP address, the appliance can be registered with Symantec
Management Center, where multiple appliances can be configured and managed from a central location.
You cannot use Management Center to assign an IP address to a ProxySG.
For more information, refer to “Using Management Center to Manage ProxySG Systems” in the SGOS
Administration Guide.
Expanded training in the use of Symantec Management Center is available from Symantec and from
Authorized Training Centers.
Multi-Tenant Policy
Multi-Tenant Policy allows multiple distinct groups of users to enforce unique and common sets of policy
while sharing the same ProxySG appliance. This feature is supported in both forward and reverse proxy
deployments, and you manage it solely from the Command Line Interface (CLI). Multi-tenant policy offers
the following key benefits:
220
• Unique and global policies—Enforce unique policy for subsets of users while maintaining global policy
for all users with a single VPM, local, central, and forwarding policy.
• Scalable policy—If your organization deploys multiple ProxySG appliances and your user traffic is
processed globally, you can install the same policy criterion and tenant policy on each appliance in the
organization. Regardless of which appliance processes a user's traffic, they are always subjected to
the same policy.
Important: Enabling Multi-tenant policy automatically disables support for Blue Coat's Cloud/ProxySG
appliance hybrid policy feature, Universal Policy.
As your ProxySG appliance processes user requests, those requests are parsed for specific information
(criterion) to determine if the user should be subjected to a specific tenant policy. You require a separate
license from Blue Coat to use multi-tenant policy. For more information, see the Multi-Tenant Policy
Deployment Guide at the following URL:
0/DOC10360/en_US/Multi-Tenant%20Policy%20Deployment%20Guide_0.pdf?__gda__=1496483192_d0f9d
116d5e5764acfb7aa092e75986e
Routing Domains
The Routing Domain feature allows you to segregate network interfaces into distinct groups that allow
traffic to be forwarded to only one of the other interfaces in that group. Routing Domain configurations
include distinct routing and gateway details. Manage this feature solely from the CLI. For more
information, see Creating Multiple Logical Networks on a Single ProxySG Appliance with Routing Domains at
the following URL:
0/DOC10349/en_US/Routing%20Domain%20Deployment%20Guide%20SGOS%206.6.x.pdf?__gda__=14964
83317_173bbd2643b0ee63c17d728554744701
Link Aggregation
Use the Link Aggregation feature to bundle multiple physical interfaces into one logical aggregate
interface. This allows increased throughput and network resiliency. Link aggregation is accomplished
using the industry-standard IEEE 802.1AX Link Aggregation standard. Switch support and switch
configuration are required.
For more information, see the following:

• SGOS Administration Guide—Configuring Adapters and Virtual LANs—
d056f3097e7aa3f8d901096ae
• Command Line Interface Reference—Privileged Mode Configure Commands—
0000/DOC10456/en_US/CommandLineInterface.pdf?__gda__=1496483583_882d546ee80fe99521f31ba
3452d8420
Interface Shutdown
Until the 6.6.x release, all ProxySG appliance interfaces were always up; whenever an Ethernet cable was
connected to an interface, the link came up. For additional security, you now have the option to disable any
interface not actively in use.
By default, all interfaces are enabled (not shutdown).
221
Configuring Interface Shutdown

1. To shutdown an interface, from the Management Console, select Configuration > Network > Adapters
> Adapters tab.
2. Select an adapter/interface to configure:
3. Click Configure Interface x:x. The Configure Interface window opens.
222
4. Tick Enable Interface #:# to use that interface.

Clearing the tick disables the interface; you will see a warning message, and ‘Disable requested’
appears as the Link State.
Note: If the interface you are disabling is in use by the Management Console, you will see the following
message:
If you lose connection to the Management Console, reconnect with an active IP address.
5. Click OK to close the window.
6. Click Apply to save changes to the adapter/interface settings.
CLI Commands
Interface shutdown adds two new CLI commands to the following config command:
#(config) interface interface_number
#(config interface interface_number) disable
Disables the specified interface.
#(config interface interface_number) enable
Enables the specified interface.
223
34412
• The ProxySG QuickStart Guide is the reference card that is shipped with all new appliances. Here is an
example for the ProxySG S500 model—
0000/DOC10305/en_US/ProxySG-S500_QSG.pdf?__gda__=1496483709_aa3febcda9185062a1c51aa6d1
25f597
Review Questions
1. True or false: Symantec Management Center cannot be used to configure a ProxySG until an IP
address has been assigned to the ProxySG by either the front panel or the serial console.
2. Which SGOS edition is designed for Secure Web Gateway deployments?
3. Can a ProxySG automatically get its own IPv4 address during initial configuration?
4. If you lose the password to the setup console, what methods can be used to regain access to the setup
console?
5. True or false: When you issue the CLI command restore-defaults factory-defaults, the
ProxySG keeps its configured IP address so it can continue to be accessed.
6. A newly-shipped ProxySG appliance contains what kind of license?
a. Trial
b. Demo
c. Permanent
d. Provisional
224
Appendix B: IPv6 in ProxySG Security
Deployments
Internet Protocol version 4 (IPv4), specified in 1980 and 1981, was the first widely deployed version of the
protocol that is used for communicating across a packet-switched internetwork. IPv4 uses a 32-bit address
space, which allows a theoretical limit of about 4.3 billion addresses. (Many of these addresses are
reserved, so the actual limit is somewhat less.)
With the rapid growth in the number of Internet-connected devices, the IPv4 address space has become
insufficient. Even with the use of techniques such as network address translation (NAT), the IPv4 address
space is expected to be exhausted in the early 2010s.
This situation led to the development of Internet Protocol version 6 (IPv6), which has a 128-bit address
space. This leads to a theoretical limit of about 2128 (or about 3.4 x 1038) addresses, which is expected to
provide an endless supply of addresses. In theory, IPv6 allows each person on the planet to have their own
network that is as large as the current Internet.
IPv6 was first specified in 1996, but its deployment continues to be limited, although the pace of
deployment is accelerating due to the impending exhaustion of available IPv4 addresses. Managing the
conversion from IPv4 to IPv6 poses challenges for IT organizations, especially because existing IPv4
devices and applications must continue to function during the conversion.
All major computer operating systems now support IPv6. Beginning with version 5.5 of the SGOS operating
system, the Symantec Blue Coat ProxySG supports IPv6 in Secure Web Gateway deployments, and
introduction of additional IPv6 capabilities is planned for future releases.
IPv6 Addressing
An IPv6 address consists of eight 16-bit fields, each of which is expressed as a hexadecimal string, such as
this:
fe80:0000:0000:0000:02d0:83ff:fe04:eb0a
Within each field, leading zeros can be omitted:
fe80:0:0:0:2d0:83ff:fe04:eb0a
And a series of consecutive zero fields can be omitted a maximum of once per address:
fe80::2d0:83ff:fe04:eb0a
Some special addresses are reserved:
• Loopback address: 0:0:0:0:0:0:0:1 or ::1
• Unspecified address: 0:0:0:0:0:0:0:0 or ::
When entered in a Web browser, an IPv6 address is enclosed in square brackets:
http://[fe80::2d0:83ff:fe04:eb0a]/index.html
IPv6 Address Scopes

The IPv6 address structure is similar to that of IPv4, containing a subnet prefix and interface identifier. The
following figure shows the main components of an IPv6 address:
225
However, IPv6 addresses are much more structured than those in IPv4. The top bits of an IPv6 address
determine its scope:
• Multicast: A device sends a single packet to multiple destinations.
• Link-local unicast: This is similar to automatic configuration in IPv4. A device is connected to the
Internet, and it generates an address and starts communicating with all nodes on the same physical
network segment.
• Site-local unicast: This address is allowed to communicate with all nodes in an organization, but it
cannot be used to communicate outside the organization boundary. This address type has been
deprecated and should not be in wide use; link-local addresses can be used to achieve the same
functionality.
• Global scope unicast: This address can communicate with anyone.
In IPv6, addresses must have the same scope in order to communicate with each other. (For example, a
link-local address cannot communicate with a global scope address.) When an IPv6 device connects to the
network, it has to join all of these groups in order for IPv6 to function properly.
For routing, a global scope unicast address can have a global prefix:
IPv6 Packet Header

The following diagram shows the format of IPv4 and IPv6 packet headers:
226
Appendix B: IPv6 in ProxySG Security Deployments
With only eight fields plus options and a fixed length of 40 bytes, the IPv6 header is considerably simpler
than the IPv4 header. Fields in the IPv6 header include:
• Version: The version of Internet Protocol (in this case, always 6).
• Traffic class: Packet priority.
• Flow label: Intended for quality of service management, but currently not used in most
implementations due to a lack of standardization.
• Payload length: Size of the payload in octets.
• Next header: Specifies up to six extension headers, which then follow the IPv6 header in distinct order:
hop by hop options header, routing header, fragment header, destination options header,
authentication header, and encapsulated security payload.
• Hop limit: Similar to the time-to-live field of the IPv4 header.
• Source address and destination address: 128-bit IPv6-style addresses.
IPv6 Support on the ProxySG

SGOS supports the use of IPv6 addresses with many of the Blue Coat Secure Web Gateway protocol proxies
and features including HTTP, HTTPS, SSL, DNS, TCP-Tunnel, Telnet, advanced forwarding, active sessions,
and the FTP application layer.
For these protocols, the ProxySG Management Console, the command line interface, the Visual Policy
Manager, and Content Policy Language allow the use of IPv6 addresses.
Because the Web Cache Communication Protocol (WCCP) does not support IPv6, WCCP-related
commands and configuration screens on the ProxySG do not allow IPv6 addresses.
IPv6 Service Features in SGOS 6.5

SGOS 6.5 contains support for additional IPv6 infrastructure services, and will flesh out the IPv6 support
for remaining services. SGOS 6.5 contains new IPv6 support for the following services:
• The ProxySG appliance can make Network Time Protocol (NTP) queries to an IPv6 NTP server.
• Users can make Simple Network Management Protocol (SNMP) queries to the ProxySG appliance's
IPv6 address.
227
IPv6 Support Enhancements in SGOS 6.5

SGOS 6.5 contains additional IPv6 support. The ProxySG appliance can now:
• Upload archive configurations to remote IPv6 servers.
• Upload access logs to an IPv6 server for FTP and HTTP clients.
• Send messages to IPv6 syslog servers.
• Send email event notifications using an SMTP gateway that has an IPv6 address.
• Retrieve IPv6 MIBs.
IPv6 Support in Attack Detection in SGOS 6.6.2

IPv6 is now supported in Attack Detection. No CLI changes are required; you can simply now specify IPv6
addresses. IPv6 entries are displayed for client/server commands and when viewing statistics.
228

ProxySG 6.6. Basic Student PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ProxySG 6.6. Basic Student PDF

Uploaded by

Copyright:

Available Formats

ProxySG 6.

Lead Subject Matter Technical Contributors and

Applicable Software Versions

Estimated Lecture Time

Security needs proxy

Firewalls and proxies

• Eye-on-the-wire monitoring  Man-in-the-middle brokering

• Negative day threat defense

• SGOS version 6: 64-bit

SGOS is not based on Windows, Linux, or any other operating system.

+ SGVA Virtual Appliance

Symantec Enterprise Technical Support

ProxySG First Steps WebGuide

Symantec Blue Coat YouTube channel

Instructor-led Demo 1-1: Explore Symantec Education

Estimated Demonstration Time

3. If time permits, explore the following:

Estimated Lecture Time

 Reverse proxy: Proxy on the same network as servers

Reverse Proxy Deployments

WAN Optimization Deployments

Estimated Lecture Time

Management Console structure

• Java 7 or higher must be enabled

Displayed is a quick overview of the functional areas of the Management Console.

Preview, Revert, and Apply

Updating Time Zones and Daylight-saving Rules

Management Console in FIPS Mode

Lab 3: Exploring the Management Console

Estimated Exercise Time

Exercise 3-1: Observe Banner Information

Again, click through any warnings that might display to continue.

3-2: Configure NTP

5. In the Acquire UTC time dialog box, click OK.

Exercise 3-3: Disable Automatic Logoff

Exercise 3-4: Enable Access Logging

Exercise 3-5: Explore Management Console Tabs

a. Click System to see what information is available here.

Estimated Lecture Time

Proxy services overview

In Symantec ProxySG terminology, proxy service defines:

Intercept and bypass

Common proxy services

Three very common proxy services are:

Proxy service attribute settings

• Available settings depend upon the specific service

Global proxy service settings

The following are global proxy service settings:

• Only in transparent proxy mode

Lab 4: Configuring Proxy Services and Listeners

Estimated Exercise Time

Before You Begin

4.1: Set the Default Proxy Policy to Allow

4-2: Test Explicit Client Connections with a Service Set to Intercept

4. In the Management Console, go to Configuration > Services > Proxy Services.

Note: You may see other sessions as well.

4-3: Test Transparent Client Connections with a Service Set to Intercept

2. In the Management Console, go to Configuration > Services > Proxy Services.

Estimated Lecture Time

• The client always initiates the connection

["http:" "//" host_name [ :port ] [ abs_path [ "?" query ]]

• Host name is case-insensitive

• Two types of messages