Secure Web Gateway

11.2.6 Administration for

On Premise Appliances

Student Guide
PN: SWG-1126-SG1
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and
brands are the property of these companies or may be claimed as the property of
others. Copyright © 2022. March 2022
 Table of Contents

Module 1: Welcome ....................................................................................................................................................................................................... 1-1

Module 2: Solution Overview .................................................................................................................................................................................. 2-1
Module 3: Planning ........................................................................................................................................................................................................ 3-1
Module 4: Installation .................................................................................................................................................................................................. 4-1
Module 5: System Configuration ........................................................................................................................................................................ 5-1
Module 6: Policy Overview ....................................................................................................................................................................................... 6-1
Module 7: Rules, Rule Sets, and List Configuration ................................................................................................................................ 7-1
Module 8: Global Threat Intelligence and URL Filtering ..................................................................................................................... 8-1
Module 9: Media Type Filtering and Data Loss Prevention ............................................................................................................. 9-1
Module 10: Malware Scanning .............................................................................................................................................................................. 10-1
Module 11: Authentication and Account Management ..................................................................................................................... 11-1
Module 12: HTTPS Scanning ..................................................................................................................................................................................... 12-1
Module 13: Quota Management and Coaching ..................................................................................................................................... 13-1
Module 14: Web Caching, Next Hop Proxies, Progress Pages, and Block Pages.............................................................. 14-1
Module 15: Logging ........................................................................................................................................................................................................ 15-1
Module 16: Dashboards and Reports............................................................................................................................................................... 16-1
Module 17: Content Security Reporter ............................................................................................................................................................. 17-1
Module 18: Reverse Proxy and Internet Content Adaptation Protocol (ICAP) .................................................................. 18-1
Module 19: Advanced Management ................................................................................................................................................................ 19-1
Module 20: Basic Troubleshooting .................................................................................................................................................................... 20-1
Module 21: Advanced Threat Defense Overview and Integration ............................................................................................. 21-1

i
ii
Secure Web Gateway Administration for On
Premise Appliances

Module 1: Welcome

1
 Introductions
Introductions
 Name
 Responsibility
 Product experience
 Expectations

Welcome to the Secure Web Gateway Administration for On Premise Appliances course. This first
module provides an overview of course design, logistics, and helpful resources, as well as
provides the opportunity for the instructor to learn about you and your training expectations.

2
 About the Course
Design, Document, and Implement Use Cases
Through lecture, hands-on labs, and class discussions, you will learn use case methodology
and create use cases to gain better visibility to your environment, protecting and limiting
exposure to threats and vulnerabilities.
 Prerequisites:
 Working knowledge of Windows and system administration, network technologies
 Basic understanding of computer security, command line syntax, malware/anti-
malware, virus/anti-virus, and web technologies
 Resources:
 Student and Lab guides
 Virtual lab environment
 Course evaluation

Duplication of course materials is strictly prohibited by copyright.

Design, Document, and Implement Use Cases

Through lecture, hands-on labs, and class discussions, you will learn use case methodology and
create use cases to gain better visibility to your environment, protecting and limiting exposure to
threats and vulnerabilities.

Prerequisites:
Working knowledge of Windows and system administration, network technologies
Basic understanding of computer security, command line syntax, malware/anti-malware,
virus/anti-virus, and web technologies
• Resources:
• Student and Lab guides
• Virtual lab environment
• Course evaluation

3
 Course Objectives
After completing this course, you will be able to:
 Compare Secure Web Gateway for On Premise
Appliances concepts, identify Web Gateway appliances
and their features, and describe the Web Gateway
component architecture.
 Recognize effective navigation of the Secure Web
Gateway for On Premise Appliances dashboard and
create custom data views.
 Review how to make rules, rule sets, lists and related
components according to analysis, identify events for
immediate action, delayed action or no action, and
perform solution’s operation and performance analysis to
maximize the usefulness of Secure Web Gateway for On
Premise Appliances output.

After completing this course, you will be able to:

• Compare Secure Web Gateway for On Premise Appliances concepts, identify Web Gateway
appliances and their features, and describe the Web Gateway component architecture.
• Recognize effective navigation of the Secure Web Gateway for On Premise Appliances
dashboard and create custom data views.
• Review how to make rules, rule sets, lists and related components according to analysis,
identify events for immediate action, delayed action or no action, and perform solution’s
operation and performance analysis to maximize the usefulness of Secure Web Gateway for
On Premise Appliances output.

4
 Time and duration:
Course Agenda
 Start time: 9:00 A.M.*
 End time: 5:00 P.M.*
Day 1  Duration: 4 days
* May vary.

1 Welcome 80 minutes

2 Solution Overview 35 minutes

3 Planning 45 minutes

4 Installation 80 minutes

5 System Configuration 90 minutes

6 Policy Overview 30 minutes

7 Rule, Rule Sets and List Configuration 90 minutes

5
 Time and duration:
Course Agenda
 Start time: 9:00 A.M.*
 End time: 5:00 P.M.*
Day 2  Duration: 4 days
* May vary.

8 Global Threat Intelligence and URL Scanning 60 minutes

9 Media Type Filtering and Data Loss Prevention 65 minutes

10 Malware Scanning 90 minutes

11 Authentication and Account Management 120 minutes

12 HTTPS Scanning 90 minutes

6
 Time and duration:
Course Agenda
 Start time: 9:00 A.M.*
 End time: 5:00 P.M.*
Day 3  Duration: 4 days
* May vary.

13 Quota Management and Coaching 90 minutes

Web Caching, Next Hop Proxies, Progress Pages and

14 85 minutes
Block Pages

15 Logging 60 minutes

16 Dashboards and Reports 45 minutes

17 ePO Integration 30 minutes

7
 Time and duration:
Course Agenda
 Start time: 9:00 A.M.*
 End time: 5:00 P.M.*
Day 4  Duration: 4 days
* May vary.

18 Reverse Proxy and ICAP 60 minutes

19 Advanced Management 90 minutes

20 Basic Troubleshooting 90 minutes

21 ATD Overview and Integration 60 minutes

8
 Acronyms and Terms in this Course
Secure Web Gateway for On Premise Appliances (SWG)
• APAC: Asia and Pacific ▪ MTA: Mail Transfer Agent
• CLI: Command Line Interface ▪ MTU: Maximum Transmission Unit
• DHCP: Dynamic Host Configuration Protocol ▪ MWG: McAfee Web Gateway
• DNS: Domain Name Server ▪ SWG: Secure Web Gateway
• EMEA: Europe, Middle East and Asia ▪ NTLM: New Technology LAN Manager
• Trellix ePO: Trellix ePolicy Orchestrator ▪ NTP: Network Time Protocol
• FTP: File Transfer Protocol ▪ Regex: Regular Expression
• HA: High Availability ▪ SMTP: Simple Mail Transfer Protocol
• HTML: Hypertext Markup Language ▪ SNMP: Small Network Management Protocol
• HTTP: Hypertext Transfer Protocol ▪ SSH: Secure Socket Shell
• HTTPS: Hypertext Transfer Protocol – Secure ▪ SSL: Secure Socket Layer
• ICAP: Internet Content Adaptation Protocol ▪ TCP: Transmission Control Protocol
• IP: Internet Protocol ▪ URL: Uniform Resource Locator
• LAN: Local Area Network ▪ VRRP: Virtual Router Redundancy Protocol
• LDAP: Lightweight Directory Access Protocol ▪ WCCP: Web Cache Communication Protocol
• TEG: Trellix Email Gateway ▪ Webwasher: Former name of Web Gateway
• MLOS: McAfee Linux Operating System ▪ WPAD: Web Proxy Autodiscovery Protocol

9
 Service Portal
Single point of access to valuable
resources and tools
 Knowledge Center: Search for
documentation, technical articles,
and other resources for your
products.
 Patches and Downloads: Obtain
patches, hotfixes, and product
downloads as well as manage
product licenses.
 Support Tools: Run Virtual Technician
or other diagnostic tools to help
solve problems.
 Customer Community: Collaborate
and engage in ongoing
conversations with other product
users.

https://supportm.trellix.com

Single point of access to valuable resources and tools

Knowledge Center: Search for documentation, technical articles, and other resources for your
products.
Patches and Downloads: Obtain patches, hotfixes, and product downloads as well as manage
product licenses.
Support Tools: Run Virtual Technician or other diagnostic tools to help solve problems.
Customer Community: Collaborate and engage in ongoing conversations with other product
users.

10
 Skyhigh Security Cloud Hub
Online document repository for Skyhigh Security Cloud

The Skyhigh Security Cloud Hub menu is organized by functional area to assist with finding
information about performing procedures in specific parts of the Skyhigh Security Cloud
product.

Skyhigh Security Cloud Release Notes: https://success.myshn.net/Release_Notes

Skyhigh Security Cloud Product Guide: https://success.myshn.net/

Access to https://success.myshn.net/ requires login from a Dashboard or credentials for Skyhigh

Security Cloud upon opening

11
 Skyhigh Security SNS
The Skyhigh Security Support Notification Service (SNS) is a communication service.
It provides timely information by email to corporate customers, partners, and
employees who subscribe to the service. SNS communications help you maximize
the functionality and protection capabilities of your Skyhigh Security products.
To receive SNS communications, you must subscribe and select your products from
the SNS Subscription Preference page at:
https://www.trellix.com/en-us/contact-us/sns-preferences.html

To receive Alerts or Notifications about Secure Web Gateway, select Skyhigh

Security Secure Web Gateway under Skyhigh Security Subscriptions.

The Skyhigh Security Support Notification Service (SNS) is a communication service. It provides
timely information by email to corporate customers, partners, and employees who subscribe to
the service. SNS communications help you maximize the functionality and protection
capabilities of your Skyhigh Security products.
To receive SNS communications, you must subscribe and select your products from the SNS
Subscription Preference page at:
https://www.trellix.com/en-us/contact-us/sns-preferences.html

To receive Alerts or Notifications about Secure Web Gateway, select Skyhigh Security Secure
Web Gateway under SNS Product option.

12
 Lab Environment

Host Virtual Machines

PDC ATD 4.2 SWG1 SWG2 WRK1 WRK2 EPO

Network 1

Network 2

WRK3
LAB

 Perform all labs using the virtual machines

 Do not change any passwords
 # machines total as part of the student pod
 See the Lab Guide for details

This course uses a virtual environment technology to provide the required resources for your lab.
The table highlights IP addressing, users, and passwords for your virtual machines (VMs). All labs
are to be performed on the virtual machines not the physical host systems. The lab instructions
highlight the required VM systems and lab files.
• WRK1: Use this machine to access the Web Gateway user interface and browse to websites to
test Web Gateway.
• WRK2: This Widows machine will be used in the ATD lab.
• EPO: This is the server that hosts the ePO software. You will use for reporting and to see how
Web Gateway and ePO interact. You will connect to the ePO interface using a browser from
the client machine and will not be required to connect to this machine directly.
• PDC: This machine hosts Domain Control, DNS, e-mail server, and some of the reporting
features. Students should not be required to connect to this machine directly.
• SWG1: This is a Web Gateway virtual appliance. This machine is a clean install of the Web
Gateway software right before initial configuration.
• SWG2: This is a Web Gateway virtual appliance.
• ATD: This is the server that hosts the ATD software. You will log on to the GUI during the ATD
integration lab.

13
Using the Lab Guide
The Lab Guide Provides
 Classroom lab setup
 User credentials
 Lab exercises
 Goals and durations
 Scenario at the beginning of each lab
 Detailed steps to complete the lab
 Access to required systems and files

14
 Lab Exercises
Lab 1: Access the Lab Environment

 Goals:
 Start your virtual machines and verify that your lab environment is
ready to use.

 Duration:
 15 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

15
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

16
Module 2: Solution Overview

1
 Module 2 Objectives

 Describe the Secure Web Gateway for On

Premise Appliances solution and its key
features
 Identify new features and enhancements for
this release.
 Identify the components in a basic
deployment architecture.
 Explain how Secure Web Gateway for On
Premise Appliances works.

• Describe the Secure Web Gateway for On Premise Appliances solution and its key features
• Identify new features and enhancements for this release.
• Identify the components in a basic deployment architecture.
• Explain how Secure Web Gateway for On Premise Appliances works.

2
 Challenges of Effective Web Security
Three Primary Challenges

THREAT INFORMATION PROTECTION

DETECTION SHARING EVERYWHERE
Security teams cannot Point products are not It is expensive and
keep up with highly sharing threat often not possible to
sophisticated malware information between maintain consistent
and targeted attacks internal and external protection wherever
that evade traditional sources, resulting in an employee resides
defenses. an inefficient and and on each of their
expensive security devices.
practice.

When we look at the security landscape, we see three primary challenges our customers face
in the area of web security.

First, security teams simply can’t keep up with the growing quantity and sophistication of
malware that comes through everyday access to the internet. Traditional web security
defenses such as URL filtering and antivirus simply do not detect new threats, resulting in high
remediation costs for compromised endpoints, and often data loss that can be devastating for
an organization.

Second, web security deployments, along with most other security solutions in the past have
not shared information with each other or cannot learn from external sources. This results in an
inefficient security practice that often results in compromise – even when another security
solution may have had the information that could have stopped an attack.

Last, employees today access the internet from an array of devices and locations. Many of
them are accessing the internet from outside the corporate network and do so unprotected.
Extending security to every device and location has proven to be expensive, challenging, if not
impossible for many security teams.

3
 Introducing Skyhigh Web Protection

Deployment
Security Controls Flexibility
 Advanced protection from  Security controls across on-  Flexible deployment options
zero-day and known threats network and off-network web support every network -
 Comprehensive signature- access. physical, virtual, and cloud.
based antivirus protection  Rules-based engine for policy  Available both as on-premise
with real-time lookups flexibility and control. hardware or virtual appliances
 Leverages Global Threat  Pre-built rules library with deployment as well as multi-
Intelligence (GTI) file common policy actions. tenant secure web gateway
reputation and web  Cloud application controls to cloud service with global spread
categorization. manage or restrict access of data centers.
 Patented approach to zero- using business criteria, such as  Central Management for cluster
day malware prevention application risk or user profile. and high availability mode
through behavioral analysis. supported.
 Skyhigh Client Proxy available
for end point traffic redirection
to appliances or the cloud
service.

Skyhigh Web Protection offers Security, Controls and Deployment Flexibility for enterprise
security.

Security
• Skyhigh Web Protection layers numerous threat detection technologies to provide
advanced protection from zero-day and known threats.
• Provides comprehensive signature-based antivirus protection with real-time
lookups.
• Leverages Global Threat Intelligence (GTI) file reputation and web categorization.
• Patented approach to zero-day malware prevention through behavioral analysis.

Controls
• Skyhigh Web Protection extends security controls across on-network and off-network
web access. Rules-based engine for policy flexibility and control.
• Pre-built rules library with common policy actions.
• Cloud application controls to manage or restrict access using business criteria, such
as application risk or user profile.

Deployment Flexibility
• Flexible deployment options support every network - physical, virtual, and cloud.
• Available both as on-premise hardware or virtual appliances deployment as well as
multi-tenant secure web gateway cloud service with global spread of data centers.
• Central Management to synchronize configuration (policy) between two or more
Secure Web Gateway for On Premise Appliances appliances and high availability
mode supported.
• Skyhigh Client Proxy available for end point traffic redirection to appliances or the
cloud service.

4
 Skyhigh Web Protection Solution Features

Increase efficacy and improve

security operations through
integration to sandbox, endpoint,
threat intelligence exchange, Security Content Filter unwanted URLs, categories,
SIEM, and more. Integration Inspection and media types

Rule

eP
Identify all cloud applications Application SSL
Gain visibility into encrypted
including shadow IT, then control Visibility Scanning traffic and prevent hidden
both access and functionality and Control threats
Engine

Control regulated data with Data Anti- Stop both known and zero-day
Protection Malware
pre-built dictionaries and malware before it reaches its
encryption for cloud storage target

Outbound Traffic
Inbound Traffic

Skyhigh Web Protection is a robust web security solution built for the most demanding
enterprise environments. Let’s quickly walk through the key areas of the base solution to show
how it processes web traffic with multiple layers of security.

• First, for the inbound flow of traffic, it runs extensive content inspection, reputation analysis
and site categorization, plus a variety of file filtering techniques to block malicious or
undesired content.
• Next, with more websites and cloud apps using SSL encryption, it is more critical than ever to
have the capability to inspect that traffic. This allows identification of malware and
enforcement of application controls within encrypted traffic that otherwise the organization
would be completely blind to.
• Skyhigh Web Protection has full visibility into all traffic, including SSL, and runs both
signature-based and zero-day malware detection with very high detection rates.
• Skyhigh Web Protection complements your existing DLP practice with built-in dictionaries to
detect PII, PCI, PHI, and more data attempting to leave the organization via web traffic.
• Cloud applications add risk to the protection of corporate data. Skyhigh Web Protection
provides over 1,500 application controls to decide where data can be uploaded, what users
can do on social networks, and more.
• Lastly, web security cannot exist in a silo and is a critical element to a broader security
architecture. Through integration to Skyhigh Endpoint Security, malware sandboxing, SIEM,
and more, Skyhigh Web Protection can increase the efficacy with which threats can be
prevented and improve the efficiency of security operations.

5
 New/Enhanced Features for this Release
Web Gateway 11.2.X

New Features in the 11.2 Release

This release provides the following new features. For resolved issues in this release
and the update releases, see further below.
• New Properties for Web Policy Rules
• GTI Data Included in Feedback File
• TCP Dump Options Enhanced
• More Flexibility for HTTP Proxy Port Configuration
• SSL Tap Configuration Enhanced
• Detection of Excel 4 Macros Added
• IP Spoofing Supported for HTTP(S) in Proxy Configuration
• Skyhigh Rebranding Changes

New Features in the 11.2 Release

This release provides the following new features. For resolved issues in this release and the
update releases, see further below.
NOTE: Secure Web Gateway 11.2 is provided as a main release.
For information about how to install this release, see the Upgrading to a New Version -
Controlled Release. If you are installing the Secure Web Gateway appliance software for the
first time, see Installing Secure Web Gateway for the First Time.
New Properties for Web Policy Rules
When configuring rules for your web policy, you can use these new items:
•A new property to expose encrypted archive directory listings.
•A new property to store the rule and rule set names or IDs that were processed at the end of
the request and response filtering cycles.
GTI Data Included in Feedback File
Data that is collected by the GTI diagnosis script of the operating system is included in the
output feedback file.
TCP Dump Options Enhanced
TCP dump options have been enhanced by adding a packet tracing feature.
More Flexibility for HTTP Proxy Port Configuration
When configuring an HTTP Proxy Port, you can disable the Enable FTP over HTTP option. The
option is enabled by default.
SSL Tap Configuration Enhanced
The following enhancements have been added to SSL Tap configuration:
•The destination port number is not overwritten by default when tapped packets are created.
•The destination MAC address can be customized when tapped packets are broadcast.
•SSL tapping now supports HTTP2 on Secure Web Gateway.
Detection of Excel 4 Macros Added
Excel 4 macros are now detected in media type filtering.
IP Spoofing Supported for HTTP(S) in Proxy Configuration
IP spoofing is supported for HTTP(S) when setting up proxies in Explicit Proxy or L2 Transparent
mode.

6
What's new in update 11.2.5
Enhancements have been introduced as follows in this release.
•Skyhigh Rebranding Changes
•Icons, and logos are rebranded from McAfee to Skyhigh Secure Web Gateway.

6
 Skyhigh Web Protection Components

Web Gateway Cloud Secure Web Gateway Content Security

Skyhigh Client Proxy
Service Appliances Reporter

• Globally available, true • On premise hardware • End user transparent • ePO embedded
multi-tenant secure or virtual appliances and tamper resistant reporting solution for
web gateway cloud • Unmatched flexibility end point client that Internet usage
service for policy redirects traffic to trending and policy
• Ability to filter web configuration to adopt appliances or the enforcement reporting
traffic without enterprise business cloud service
deploying hardware goals and principle • Performs end user
on premise and model these into authentication and
• Allows to connect an Internet access allows fully enforced
branch office directly and security policy scanning of web
using IPsec • Ability to also manage traffic
• Can be managed Web Gateway Cloud • Available on Windows
from the appliances in Service in a hybrid Desktop, Server and
a hybrid deployment deployment scenario macOS

Web Gateway Cloud Service

• Globally available, true multi-tenant secure web gateway cloud service .
• Ability to filter web traffic without deploying hardware on premise.
• Allows to connect branch office directly using IPsec.
• Can be managed from the appliances in a hybrid deployment.

Secure Web Gateway Appliances

• On premise hardware or virtual appliances.
• Unmatched flexibility for policy configuration to adopt enterprise business goals and
model these into an Internet access and security policy.
• Ability to also manage Web Gateway Cloud Service in a hybrid deployment scenario.

Skyhigh Client Proxy

• End user transparent and tamper resistant end point client that redirects traffic to
appliances or the cloud service.
• Performs end user authentication and allows fully enforced scanning of web traffic.
• Available on Windows Desktop, Server and macOS.

Content Security Reporter

• ePO embedded reporting solution for Internet usage trending and policy
enforcement reporting.

7
 Integrations
Management, Monitoring, Reporting and Threat Information Sharing

 Trellix Advanced Threat Defense (ATD)

ATD
 Skyhigh Content Security Reporter
SIEM CSR
 Trellix Data Exchange Layer (DXL)/Threat
Intelligence Exchange (TIE)

 Trellix ePolicy Orchestrator (ePO)

Cloud WG DXL/TIE
 Trellix Global Threat Intelligence (GTI)

 SWG on Cloud
SWG on
Cloud
ePO  Skyhigh Security Cloud

GTI  Trellix Security Information and Event

Management (SIEM)

Trellix Advanced Threat Defense

• Web Gateway integrates with Advanced Threat Defense (ATD) to enable more
effective threat detection, lower total cost of ownership, and improve operational
efficiency.
Skyhigh Content Security Reporter
• Content Security Reporter (CSR) is a reporting software solution that helps you
understand Internet and email usage, and intrusion prevention alert data within your
organization.
Trellix Data Exchange Layer and Trellix Threat Intelligence Exchange
• Data Exchange Layer (DXL) is a messaging technology for real-time information
exchange.
• Threat Intelligence Exchange (TIE) optimizes threat detection and response by
closing the gap from malware encounter to containment from days, weeks, and
months down to milliseconds.
Trellix ePolicy Orchestrator
• Web Gateway supports the ePolicy Orchestrator platform. As the single source for
consolidated information, the Trellix ePO platform helps you quickly identify and
mitigate problems and improve compliance management.

Continued on next page.

8
Trellix Global Threat Intelligence
 Web Gateway leverages the Global Threat Intelligence (GTI) web reputation technology.
SWG offers expanded cloud-based reputation capabilities that now include geo-location,
enabling geographic visibility and policy management based on the web traffic’s
originating country.
Skyhigh Security Cloud
 Web Gateway integrates with Skyhigh Security Cloud for the purposes of Shadow IT.
Trellix Security Information and Event Management
 Enterprise Security Manager (ESM) is a high-performance, powerful security information
and event management solution combines event, threat, and risk data together to provide
strong security intelligence, rapid incident response, seamless log management, and
compliance reporting.

9
 Management Interface
Organized by Pages

 Dashboard: Shows key information on the appliance system and activities.

 Policy: Configure and manage web security policies for your network.

 Configuration: Configure appliance settings and edit system files on an appliance.

 Accounts: Add and manage internal administrative accounts and roles.

 Troubleshooting: Analyze and resolve problems on an appliance

The user interface allows you to work with rules, lists, settings, accounts, and other items for
administering Web Gateway. It provides information on key filtering and system parameters
and enables you to perform troubleshooting measures. The menu bar at the top of the page is
used to access the pages used for initial configuration and ongoing management.

• Dashboard: Shows key information on the appliance system and activities. This lets
you see the system operation, briefly.

• Policy: Used to configure and manage web security policies for your network. The
foundation of this is rules, which control web filtering and authentication. A variety of
rule types are available, which you can implement and modify to let them suit the
needs of your network.

• Configuration: Used to configure appliance settings and edit system files on an

appliance. When configuring the appliance system, you are dealing mainly with
system settings, system files, and database updates. System configuration is in part
performed during the initial setup of an appliance. After this setup, you can complete
further configuration activities for the appliance system.

Continued on next page.

10
 Accounts: Used to add and manage internal administrative accounts and roles. You can
add administrator accounts to the account that is created by the appliance system at the
initial setup. The administrator role settings are used for configuring roles that can be
assigned to administrators. Optionally, you can let administrator accounts be managed on
external authentication servers and map externally stored user groups and individual users
to roles on an appliance.

 Troubleshooting: Web Gateway provides troubleshooting tools and functions, which are
your first level of support. These include packet and rule tracing, the creation of core files to
record memory content after terminated operation, restart tool, the display of anti-malware
scanning threads, and backup and restore.

11
Knowledge Check

12
Check your learning
Multiple choice: Choose the correct answer.

Skyhigh Web Protection is available both as on-premise

hardware or virtual appliances deployment as well as multi-
tenant secure web gateway cloud service.

A. True
B. False

Answer: True. See Introducing Skyhigh Web Protection.

13
Check your learning
Multiple choice: Choose the correct answer.

Which component of Skyhigh Web Protection performs end

user authentication and allows fully enforced scanning of web
traffic?

A. Secure Web Gateway for On Premise Appliances

B. Skyhigh Client Proxy
C. Secure Web Gateway Cloud Service

Answer: B. Skyhigh Client Proxy. See Skyhigh Web Protection Components.

14
 Review

 Skyhigh Web Protection offers Security, Controls and Deployment Flexibility for
enterprise security.
 Offers physical, virtual and cloud deployments.
 Provides inbound and outbound security for web traffic.
 Skyhigh Web Protection has full visibility into all traffic, including SSL, and runs both
signature-based and zero-day malware detection with very high detection rates.
 Web Protection components include Web Gateway, Web Gateway Cloud Service,
Skyhigh Client Proxy and Content Security Reporter.
 Optionally integrates with other Skyhigh products for unified management,
monitoring, reporting, and threat-information sharing.

• Skyhigh Web Protection offers Security, Controls and Deployment Flexibility for enterprise
security.
• Offers physical, virtual and cloud deployments.
• Provides inbound and outbound security for web traffic.
• Skyhigh Web Protection has full visibility into all traffic, including SSL, and runs both
signature-based and zero-day malware detection with very high detection rates.
• Web Protection components include Web Gateway, Web Gateway Cloud Service, Skyhigh
Client Proxy and Content Security Reporter.
• Optionally integrates with other Skyhigh products for unified management, monitoring,
reporting, and threat-information sharing.

15
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

16
Module 3: Planning

1
 Module 3 Objectives

 Define the program strategy and goals.

 Describe deployment modes.
 Describe the key parts of a deployment plan.
 Identify solution requirements.
 Give examples of best practices for
implementing the solution.

• Define the program strategy and goals.

• Describe deployment modes.
• Describe the key parts of a deployment plan.
• Identify solution requirements.
• Give examples of best practices for implementing the solution.

2
 Planning Overview
Checklist
 Business requirements
 Deployment type
 System requirements
 Deployment plan
 Other considerations

This slide highlights key planning considerations.

3
 Business Requirements
Identify Required Policies and Related Features/Applications
• Deployment type
• File load
• Access control
• Data loss prevention Data loss
prevention
• Central Management
• Reporting
• Integration Reporting User roles and controls

Web filtering Malware

protection

First, identify your business requirements or objectives. This includes policies, controls, and
other features.

Also determine if a related product is needed. As an example, if reporting is important, consider

implementing Trellix Content Security Reporter (CSR). The Content Security Reporter collects
data from devices on the network and manages it in a central database. This helps identify any
issues in your organization. Once identified, you can use this information to modify your
Internet, email, and IPS policies to effectively enforce network protection.

If advanced malware protection is desired, implement Trellix Advanced Threat Detection (ATD).
The ATD solution provides static and dynamic malware analysis.

4
 Deployment Types
Flexible Deployment Options

SWG Deployments

AWS or Azure
Physical appliance Virtual appliance Blade Server
platforms

An important consideration is deployment type.

• Physical and virtual machine deployments are supported.

• In addition, you can install Web Gateway software on a Blade Server or on the Cloud using
Microsoft Azure or Amazon Web Services.

• The solution requirements will vary depending on the type and number of Web Gateway
appliances you plan to deploy.

5
 System Requirements
Physical Appliance
Web Gateway runs on a customized Trellix Linux Operating System (TLOS) which is a
proprietary operating system hardened to support Skyhigh products.
The newer hardware models include:
• WBG-4500-D
• WBG-4500-E
• WBG-5000-D
• WBG-5500-D
• WBG-5000-E
• WBG-5500-E
The older models include:
• WBG-4500-C
• WBG-5500-C
• WBG-5500-C

The newer hardware models include:

• WBG-4500-D
• WBG-4500-E
• WBG-5000-D
• WBG-5500-D
• WBG-5000-E
• WBG-5500-E
The older models include:
• WBG-4500-C
• WBG-5500-C
• WBG-5500-C

Note: The older C Appliances are approaching End of Life.

6
 System Requirements
Physical Appliance
D- series
specifications

https://www.trellix.com/enterprise/en-us/assets/technical-specifications/ts-web-gateway-d-
model-appliance-specifications.pdf

7
 System Requirements
Physical Appliance

E- series
specifications

https://success.myshn.net/@api/deki/files/39191/Secure_Web_Gateway_Model_E_Appliance
s_Hardware_Specification_Sheet.pdf?revision=1

8
 System Requirements
Model WBG-4500-D

Name assigned to
Position Interface port on interface

1 Network interface 1 eth0

2 Network interface 2 eth1
3 Network interface 3 eth2
4 Network interface 4 eth3
5 Network interface 5 eth4
6 Network interface 6 eth5
7 RMM
For operating the Remote Management Module (RMM) with Baseboard
Management Controller (BMC)
8 Serial

WBG-4500-D appliance model has six network interfaces, a serial interface, and an RMM
interface on its rear panel.

The network interfaces include two onboard interfaces and four interfaces on a built-in IO
module on the lower right of the panel.

9
 System Requirements
Model WBG-5000-D and
WBG-5500-D

Name assigned to
Position Interface port on interface

1 Network interface 1 eth0

2 Network interface 2 eth1
3 Serial
4 RMM
For operating the Remote Management Module (RMM) with Baseboard
Management Controller (BMC)
5 Network interface 3 eth2
6 Network interface 4 eth3
7 Network interface 5 eth5
8 Network interface 6 eth4

The WBG-5000-D and WBG-5500-D models use the same hardware platform, which has six
network interfaces, a serial interface and an RMM interface on its rear panel.

10
 System Requirements
Model WBG-4500-E

Name assigned to
Position Interface port on interface

1 RMM
For operating the Remote Management Module (RMM) with Baseboard
Management Controller (BMC)
2 Network interface 1 eth2
3 Network interface 2 eth0
4 Network interface 3 eth3
5 Network interface 4 eth1
6 Network interface 5 eth5
7 Network interface 6 eth4

This appliance model has six network interfaces and an RMM interface on its rear panel.

The network interfaces include four onboard interfaces and two on a network interface card
that is preinstalled in a card slot on the upper right.

11
 System Requirements
Model WBG-5000-E and
WBG-5500-E

Name assigned to
Position Interface port on interface

1 Network interface 1 eth0

2 Network interface 2 eth1
3 Serial
4 RMM
For operating the Remote Management Module (RMM) with Baseboard
Management Controller (BMC)
5 Network interface 3 eth3
6 Network interface 4 eth2
7 Network interface 5 eth5
8 Network interface 6 eth4

WBG-5000-E and WBG-5500-E appliance models use the same hardware platform, which has
six network interfaces, a serial interface, and an RMM interface on its rear panel.

The network interfaces include two onboard interfaces, two interfaces on a built-in IO module
on the lower right, and two on a network interface card that is preinstalled in a card slot on the
upper right.

Four more network interfaces can be added on a network interface card that is installed in the
other card slot on the panel. This will increase the number of network interfaces to ten. You
must purchase this card on your own and install it.

12
 System Requirements
Virtual Appliance

ESXi 5.5 ESXi 6.0 ESXi 6.5 ESXi 6.7

update 2 ESXi 6.0 update 2 ESXi 6.5 update 2 update 1 ESXi 7.0
MWG 8.x.x No No Yes Yes Yes Yes* No

MWG 9.x.x No No Yes Yes Yes Yes Yes

SWG 10.x.x No No Yes Yes Yes Yes Yes

SWG 11.x.x No No No Yes Yes Yes Yes

No = Not recommended
Yes = Recommended
Yes* = ESXi 6.7 update 1 is recommended for the MWG 8.0.1 controlled release and later 8.x.x releases.

The table highlights specifications for a virtual Web Gateway appliance.

With this deployment, Web Gateway software is installed on a virtual machine that is hosted by
a system.

For more information, see the Web Gateway installation guide or Technical Article KB85908
Recommended VMware versions for Web Gateway.

13
 System Requirements
Amazon Web Services Environment
Prior to installation on AWS environment, you will need:

 AMI ID
 Region
 AWS account number

AWS instance depends on what you plan to use the Web Gateway instance for, for example, testing or
production, account network performance and the number of NICs that you plan to run with the instance.

Prior to installation on AWS environment, you will need:

• AMI ID
• Region
• AWS account number

AWS instance depends on what you plan to use the Web Gateway instance for, for example,
testing or production, account network performance and the number of NICs that you plan to
run with the instance.

14
 System Requirements
Azure Environment
 Prior to installation on Azure
environment, you will need:
 Azure account
 Windows, Linux, or Mac system
with:
 2 GB of free disk space
(minimum)
 Most recent version of the
Azure command line
interface
 AzCopy
 Azure Web Gateway does not support
Proxy HA, Transparent Bridge and
Transparent Router modes of
deployment.

Prior to installation on Azure environment, you will need:

• Azure account
• Windows, Linux, or Mac system with:
• 2 GB of free disk space (minimum)
• Most recent version of the Azure command line interface
• AzCopy

Azure Web Gateway does not support Proxy HA, Transparent Bridge and Transparent Router
modes of deployment.

15
 System Requirements
Blade Server
A blade server is a modular server that is itself installed in a blade system
enclosure. A blade system enclosure that has blade servers installed is referred to
as a blade server system.

Blade Server Requirements

The following blade server models:
• ProLiant BL460c G8

One of the following enclosure models:

• M3 (c3000)
• M7 (c7000)

To run Web Gateway on a blade server, you must install the blade system enclosure with the
blade servers. A blade system enclosure that has blade servers installed is referred to as a
blade server system.

Hewlett-Packard provides blade servers for Web Gateway. For a detailed description of how to
install a blade server system, refer to the Hewlett-Packard documentation.

16
 Deployment Port Requirements
Ports Required for Communication with External Services

• SWG must access servers outside of the local infrastructure.

• For this reason, certain ports must be open.

• Visit this link to view all port requirements for SWG.

https://success.myshn.net/Skyhigh_CASB/Skyhigh_CASB_Sanctioned_Apps/Skyhi
gh_CASB_for_Salesforce/Configure_Salesforce_Proxy/Deployment_and_Network
_Requirements

Visit this link to view all port requirements for SWG.

https://success.myshn.net/Skyhigh_CASB/Skyhigh_CASB_Sanctioned_Apps/Skyhigh_CASB_f
or_Salesforce/Configure_Salesforce_Proxy/Deployment_and_Network_Requirements

17
 Open Port Requirements
Ports required for communication with External Services
Application
Port Direction Transport Protocol Destination Use Note
Protocol
22 Inbound TCP SSH Local Admin secure shell
161 Inbound TCP/UDP SNMP Local SNMP
1080 Inbound TCP SOCKS Local SOCKS proxy
1344 Inbound TCP ICAP Local ICAP
Passive FTP data From FTP client to
2000–20000 Inbound TCP FTP Local
connection SWG
2121 Inbound TCP FTP Local FTP control port
4005 Inbound TCP IFP Local IFP
4711 Inbound TCP HTTP Local Admin UI Also REST if enabled
4712 Inbound TCP HTTPS Local Admin UI Also REST if enabled
4713 Inbound TCP HTTP Local File server
4714 Inbound TCP HTTPS Local File server
5050 Inbound TCP Yahoo Local Yahoo proxy
5190 Inbound TCP ICQ Local ICQ proxy
5222 Inbound TCP XMPP Local XMPP (Jabber) proxy
9090 Inbound TCP HTTP Local HTTP(S) proxy
Intel Active System
9393 Inbound TCP HTTPS Local
Console
16000–17000 Inbound UDP Local SOCKS UDP relay
Active FTP data From FTP server to
20001–40000 Inbound TCP FTP Local
connection SWG
520 Bidirectional UDP RIP Your RIP routers IP routing

18
 Open Port Requirements (Continued…)
Ports required for communication with External Services
Transport
Port Direction Application Protocol Destination Use Note
Protocol
SWG cluster
12346 Bidirectional TCP Proprietary Your SWG appliances
communication
WCCP and traffic
Your SWG appliances/WCCP
Bidirectional IP Protocol 47 GRE tunneling between
routers
SWG nodes
Bidirectional IP Protocol 89 OSPF Your OSPF routers IP routing
Bidirectional IP Protocol 112 VRRP Your SWG appliances VIP failover
21 Outbound TCP FTP Arbitrary FTP servers File transfer protocol Active and passive
25 Outbound TCP SMTP Your email server Email notifications
Domain name
53 Outbound TCP/UDP DNS Your DNS server
system
appliance1.webwasher.com,
80 Outbound TCP HTTP System update
appliance2.webwasher.com
Other ports
80, 443 Outbound TCP HTTP(S) Arbitrary HTTP(S) servers User HTTP(S) traffic depending on
configuration

80, 443 Outbound TCP HTTP(S) Update Servers Centralized Updater

Your Customer Maintained Subscribed Lists

80, 443 Outbound TCP HTTP(S)
Subscribed Lists Servers Manager
Your Scheduled Job Servers Scheduled Job
80, 443 Outbound TCP HTTP(S)
(Upload, Download) Manager
Your NTP servers, Time
123 Outbound TCP/UDP NTP
ntp.webwasher.com synchronization

19
 Open Port Requirements (Continued…)
Ports required for communication with External Services
Transport Application
Port Direction Destination Use Note
Protocol Protocol
162 Outbound TCP/UDP SNMP Your SNMP trap sink SNMP traps

Directory service/Active
389 Outbound TCP LDAP Your directory servers
Directory
GTI Cloud lookups
tunnel.web.trustedsource.org (Reputation, Categories,
443 Outbound TCP HTTPS
(default; can be configured) Geo Location, File
Reputation)
tunnel.web.trustedsource.org GTI Telemetry (Malicious
443 Outbound TCP HTTPS
(default; can be configured) URL Feedback)
514 Outbound TCP/UDP Syslog Your Syslog servers Syslog
Secure directory/Active
636 Outbound TCP LDAP Your directory servers
Directory
1344 Outbound TCP ICAP Your ICAP servers ICAP
2020 Active FTP data From SWG to FTP
Outbound TCP FTP Local
(Source) connection client
Communication between
8883 Outbound TCP DXL Connection to the DXL broker SWG and DXL broker
installed on ePO
For user traffic and
various internal
Your proxy
Outbound TCP HTTP Your parent proxies HTTP proxy connections (AV
ports
update), configured
individually

20
 Web Security Licenses
Determine Available Features and Functionality
Skyhigh Web Security, Gateway Edition license:
• Category-based filtering, reputation-based web filtering,
and Trellix Anti-Virus software
• SSL scanning, caching, content and authentication • Downloaded from
controls
https://contentsecurity.skyhi
Trellix Web Anti-Malware, Gateway Edition: gh.cloud
• Add-on license for signature-based, anti-virus engine for
known malware • Purchased and
evaluation licenses are
• Intent analysis for blended attacks and unknown traffic
available
with malicious content and deep content inspection
Other licensing arrangements
• See Technical Article
• reverse https proxy KB73701 for FAQ about
licensing
• ICAP
• Pure ATD deployments

Web Gateway protections are enabled through a choice of licensing options. The Skyhigh Web
Security, Gateway Edition license combines the accuracy and breadth of category-based
filtering with reputation-based web filtering and Trellix Anti-Virus software to provide
bidirectional web security. The Skyhigh Web Security license also includes SSL scanning,
caching, content and authentication controls.

The Skyhigh Web Anti-Malware, Gateway Edition add-on software license gives you an
additional signature-based anti-virus engine for known malware along with the in-depth intent
analysis of our proactive security filters to detect blended attacks and unknown traffic with
malicious content. Deep content inspection makes sure that malware is reliably detected even
if hidden deep in compressed or spoofed files.

You download licenses from https://contentsecurity.skyhigh.cloud.

After a purchased license expires, you cannot download updates for the filtering engines, but
you may continue to use the rule engine and filter traffic. In addition, Web Gateway will still
serve requests

After an evaluation license expires, you cannot download updates and filtering no longer works.
In addition, Web Gateway no longer serves requests.

21
 Proxy Design
Considerations

• Explicit or transparent?

• High availability?

• Next hop proxy?

• Reverse HTTPS proxy?

• An explicit proxy is typically recommended.

• Proxy network, protocol settings and configuration are discussed in more detail later in
the course.

If allowed by the filtering rules, the appliance uses its proxy functions to intercept web traffic
and transmit it. Some design considerations include:

• Do you plan to use an explicit or transparent proxy? As a rule, an explicit proxy is

recommended.
• Is high availability required?
• Do you have any special requirements, such as a reverse HTTPS proxy?

22
 Proxy Overview: Explicit vs. Transparent
Methods to Deliver Web Content to Users

Explicit Proxy (Default) Transparent Proxy (Transparent Router

• Connections are proxied through Web and Bridge modes)
Gateway. No direct connect from client to • Browser is unware of presence of Web
website. Gateway or any proxy server.
• Browser is configured to send its traffic to • Direct connection from client (browser)
Web Gateway on specific port (default to destination web server.
9090).
• No trust relationship between browser
• Browser and Web Gateway establish
and Web Gateway.
trust relationship.

As a review, there are two main methods of delivering web content to users: through a
transparent proxy or an explicit proxy. Do you know the difference?

23
 Explicit Proxy
Trust Relationship

Web Gateway

Website

• Client connects to web proxy server.

• Proxy server makes separate connection to destination web server.
• Default configuration.

With an explicit proxy, the client connects to its web proxy server depending on browser proxy
settings and delivers the HTTP GET request with the client’s configured headers.

The proxy server makes a separate connection to the destination web server and sends an
HTTP GET request; this request does not have to be identical to the clients GET request.

The web server sends the website back to the proxy where it is inspected. The proxy then sends
the website back to the client.

24
 Proxy High Availability (HA)
Explicit Proxy with Failover Functions
• Recommended for smaller networks or
locations/offices within a larger
deployment (up to 1000 Web Gateway Secondary
users). Active Director/
Director/
Scanner Scanner (s)
• For larger networks, external load
balancing is recommended. Virtual IP

Websites

When higher priority director fails, secondary assumes virtual IP and continues passing
traffic.
State is not preserved, but Web Gateways can still synchronize authentication, quotas and
other runtime information.

Web Gateway offers a Proxy high availability (HA) network or explicit proxy mode. This mode
allows failover and load balancing without using external load balancers.

With this mode, traffic directed to the virtual IP is accepted by a main director and processed
normally. If the higher priority director fails, a secondary director assumes the virtual IP and
attempts to pass traffic. State is not preserved, but Web Gateways can still synchronize
authentication, quotas, and other runtime information.

This deployment is recommended for smaller networks of up to 1000 Web Gateway users. For
larger networks, external load balancing is recommended.

25
 Transparent
No Trust Relationship

Website
Web Gateway

Routing Table

• Clients are unaware of appliance

• Transparent Router (Layer 3) or Transparent Bridge (Layer2)
• Diagram shows Transparent Router
• Relies on network configuration to traffic to reach proxy

With a transparent or non-aware router, clients are unaware of the Web Gateway appliance.

The appliance is placed as router behind firewall.

A switch optionally connects appliance and clients.

26
 Reverse HTTPS Proxy
Enable External Users to Upload Content to Internal Web Sites

1. Load balancer sends content to Web

Gateway cluster for review.

2. Web Gateway receives files being uploaded

to Web Server.

3. Scans inbound content.

4. Content containing malware is blocked.

5. Clean content is forwarded to Web server

for processing.

Web Gateway can also be setup as a reverse https proxy to enable external users to upload
content to internal web sites.

With a reverse https proxy, an Internet user attempts to upload content to a web site.

A load balancer sends the content to a Web Gateway cluster which examines it.

If the content fails examination, Web Gateway returns a block page to the user. If the content
passes inspection, the load balancer forwards it to the web server for further processing.

We will discuss this in detail in Advanced Management module.

27
 Secure Web Gateway for On Premise Appliances as ICAP Server
Web Gateway functions as ICAP server to perform full range of malware scanning
and analysis
1. User attempts to upload the file directly to
web server (ICAP client)
2. ICAP client transmits the file to Secure
Web Gateway (ICAP Server)
3. If the file does not pass inspection the
ICAP client takes an appropriate
corrective action based on the business
logic of the ICAP application
4. Clean content is forwarded to the Web
Server for processing

You can also utilize the Internet Content Adaptation Protocol (ICAP), to offload processing from
the web server to a Secure Web Gateway for On Premise Appliances.
Here, the users upload content to the web server (ICAP client).
The ICAP client intercepts and forwards content to a Web Gateway (ICAP server) for malware
analysis.
If the file passes inspection, Web Gateway notifies the web server to continue processing it. If
the file fails, Web Gateway takes the appropriate corrective action, such as deleting the file,
based on the business logic of the ICAP application.

We will discuss more on this in Advanced Management module.

28
 Reverse Proxy vs. ICAP Server Configuration

Web Gateway as Reverse HTTP Proxy Web Gateway as ICAP Server

Secure Web Gateway for On Premise The ICAP Client receives the content and
Appliances intercepts the content before forwards it to Secure Web Gateway for
it reaches the web server, processes it On Premise Appliances (ICAP Server) for
and then either blocks or forwards it further analysis before processing it. The
depending on the results of the analysis. web server gains the benefit of having
If the content is blocked it never reaches the ICAP server perform more in-depth
the web server analysis.
Does not require any additional software ICAP mode requires that an ICAP client
development. Only block pages need to be written and installed within the data
be designed to conform to the style of flow of the application
the site.

The major differences between a reverse https proxy and an ICAP server configuration are:
• In reverse https proxy mode, the Web Gateway intercepts the content before it
reaches the web server, processes it, and then either blocks or forwards it, depending
on the results of the analysis. If the content is blocked, it never reaches the web
server.
• In an ICAP configuration, the web server receives the content and forwards it to Web
Gateway for further analysis before processing it. The web server gains the benefit of
having the ICAP server perform in-depth analysis, freeing up resources on the web
server.
• Reverse https proxy mode does not require any additional software development
other than designing and creating block page responses that conform to the style of
the site. ICAP mode requires that an ICAP client be written and installed within the
data flow of the application.
• Reverse https proxy mode does not require any additional software development
other than designing and creating block page responses that conform to the style of
the site. ICAP mode requires that an ICAP client be written and installed within the
data flow of the application.

29
 Deployment Plan
Workflow

Identify if new Identify if there are

Verify requirements
deployment or any compatibility
are met.
upgrade. issues.

Identify how to
monitor and Plan the Enterprise
Plan the pilot.
optimize solution rollout.
post-deployment.

If migrating from an earlier release, review the Web Gateway installation guide
for the hardware and software requirements.

After identifying your requirements, you are ready to move forward with the deployment plan.
An example deployment is:

• Identify the deployment type, as this impacts the requirements.

• Verify solution requirements are met, including application compatibility.
• Plan the pilot, including test systems, hosts, users, and rules.
• Plan the rollout to the Enterprise, including how to measure its success.
• Identify how to monitor the solution, as well as how to optimize it.

30
 Change Control
Recommended Phases

Prepare Manage Reinforce

• Initial • Implementation • Data

Planning Gathering
• Detail
• Strategy • Corrective
• Notifications Action

In addition, define processes to ensure changes proposed to your environment’s information

resources are reviewed, authorized, tested, implemented and released in a controlled manner.
Processes and relevant procedures depend on your company’s requirements; however, some
recommended phases are:

• Preparing for change: Initial planning and development of change management strategy.
• Managing change: Implementing plan and adding any detail identified.
• Reinforcing change: Data gathering and taking any corrective actions.

31
Knowledge Check

32
Check your Learning
Multiple choice: Choose the correct answer.

Which proxy mode is configured by default?

A. Explicit
B. Transparent

Answer: A. Explicit. See Proxy Design.

33
Check your Learning
True - False

External load balancing are recommended for smaller

networks or locations/offices within a larger deployment (up to
1000 Web Gateway users).

 True
 False

Answer: B. False. See Proxy High Availability (HA).

34
Check your Learning
Multiple choice: Choose the correct answer.

Which proxy mode intercepts content directly and processes

content before it reaches internal web servers?

A. Reverse HTTPS proxy

B. ICAP

Answer: A. Reverse HTTPS proxy. See Comparing ICAP and Reverse HTTPS Proxy.

35
Check your Learning
True - False

The client machine used to access the Web Gateway for

administration and management runs on the proprietary Trellix
Linux Operating System (MLOS).

 True
 False

Answer: B. False. See Web Gateway Operating System.

36
 Review

 Identify business requirements.

 Establish priorities and scope.
 Accurately scope and scale, before procuring solution hardware, software, storage,
and so on.
 Pilot before rollout.
 Establish a structure for monitoring.
 Refine and optimize.

• Identify business requirements.

• Establish priorities and scope.
• Accurately scope and scale, before procuring solution hardware, software, storage, and so
on.
• Pilot before rollout.
• Establish a structure for monitoring.
• Refine and optimize.

37
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

38
Module 4: Installation

1
 Module 4 Objectives

 Describe the basic installation workflow for a

physical appliance.
 Install the Web Gateway.
 Log into and navigate the user interface.
 Import a license.
 Activate the product.

• Describe the basic installation workflow for a physical appliance.

• Install the Web Gateway.
• Log into and navigate the user interface.
• Import a license.
• Activate the product.

2
 Installation Workflow
Steps to install a physical appliance

1 Plan the installation and read documentation

2 Download the software for your appliance

3 Connect to appliance with a monitor and

keyboard or with a serial connection

4 Go through the initial configuration wizard

5 Log into the GUI and run through the setup wizard
to license and activate your appliance

See the Secure Web Gateway Product Guide for greater detail on all items.

Download the latest version of the Web Gateway software from the Content and Cloud
Security Portal. The software is available in an ISO format or a USB format.

If you are installing the Web Gateway as a physical appliance, you will need a monitor and
keyboard to access the appliance. If you are installing the Web Gateway as a virtual
appliance, you will need a system to host the virtual appliance.

The Web Gateway can also be installed over a serial console. Once the Web Gateway software
has been installed and configured, you will need an administrative system to access the user
interface. The requirements for this system are displayed in the table.

The final item you will need is a license file. You are required to active the license before you
are allowed access to the user interface.

3
 Downloading Appliance Software
https://contentsecurity.skyhigh.cloud
• Log into Skyhigh Content & Cloud Security Portal. An account is required.
• Download software (typically ISO format).
• Copy software from system file store to installation media (CD/DVD or USB drive) for
installation on appliance.

On a newly purchased hardware platform, the appliance software is pre-installed. Connect

the appliance and turn it on.

If you require a different version of software, download the software from the Skyhigh Content
& Cloud Security Portal. The software is available in ISO or USB format.

Note: You typically select ISO. Optionally, select USB to make a bootable USB stick to install an
appliance.

1. Use a browser to go to the Skyhigh Content & Cloud Security Portal at

https://contentsecurity.skyhigh.cloud. Submit your username and password.
2. Beginning on the home page of the portal, select Software > Secure Web Gateway >
Download.
3. A page with software versions in ISO and USB format appears. Click the icon for the
exact software version you want to download. A download window opens.
4. Select the option for storing a file and click OK. The software is downloaded and
stored within your file system.
5. Copy the downloaded software to a CD/DVD or a USB drive to have it available for
installation.

4
 Connect to the appliance
Client Machine

Component Specification
Monitor  Standard VGA monitor and keyboard or Serial system
console

Administration  Microsoft Windows or Linux operating system, Mac

System  Microsoft Internet Explorer, version 6.0 or later
 Network cables for the administration system

Serial System  Baud rate: 19200

 Data bits: 8
 Parity bits: N (none)
 Stop bits: 1
 Short: 19200/8-N-1
 Flow control: No

The client runs on an off-the-shelf hardware and software platform.

5
 Installing Software on Physical Appliances
Workflow

Access
and work Software is
Insert Select the Select
Turn on with Boot installed
installation installatio installatio
appliance Manage on
media n device n mode
(Varies by appliance
model)

NOTE: On a newly purchased hardware platform, the appliance

software is pre-installed. Connect the appliance and turn it on.

To install downloaded software on a physical appliance, connect the appliance, turn it on, and
work with the Boot Manager:

1. Insert the CD/DVD or the USB drive with the downloaded software and then turn on
the appliance. The installation begins.
2. During the initial phase, select the installation device and access the Boot Manager.
When working with the Boot Manager, the steps vary depending on model:
• Web Gateway new generation of appliances: (WBG) 4500D, 4500E,
5000D and 5500D, 5000E and 5500E.
• Older models include: (WBG) 4500C, 5000C, 5500C
• Model not specified

Work with the configuration wizard to implement the initial configuration settings.

6
 Implementing Custom Settings
Workflow
DHCP = NO
Network Default Host Name
IP Address Mask Gateway
Start Mount
Software

Select Secondary Primary

Installer DNS? Yes/No DNS? Yes/No
Option

DHCP?
Yes/No

Confirm Root Confirm

Host Name Changes? Password Password
DHCP = YES Yes/No

Appliance Permit Root

End Volume via SSH?
Wizard Yes/No

Before beginning the Web Gateway installation, you must be prepared to answer questions
that will be asked in the configuration wizard. After mounting the software media and selecting
an installer option, first identify if DHCP is used.

If you choose No, you will have to manually enter IP Address, network mask, default gateway,
hostname as well as DNS configuration.

If DHCP server is setup, only hostname needs to be configured before you continue with the
rest of the workflow to confirm configuration changes, setup a root password, root SSH
connection and appliance volume configuration.

7
 Installation Steps
Mount software and select Installer option

Select #1 for serial console if

using a serial connection.

Select #2 for video console if

using a monitor and keyboard.
• Both options use the
configuration wizard

Installation Steps

Mount software and select Installer option.

Select #1 for serial console if using a serial connection.

Select #2 for video console if using a monitor and keyboard.

Note: Both options use the configuration wizard.

8
 Installation Steps (continued)
DHCP
Since the SWG appliance will be using a static IP address – select No at the prompt
for using DHCP.

Installation Steps (continued)

DHCP

Since the SWG appliance will be using a static IP address – select No at the prompt for using
DHCP.

9
 Installation Steps (continued)
IP Address, Subnet Mask and Default Gateway

1. Enter the IP Address.

2. Enter the Subnet Mask.
3. Enter the Default Gateway.

These values can be modified in the GUI.

Installation Steps (continued)

IP Address, Subnet Mask and Default Gateway

1. Enter the IP Address

2. Enter the Subnet Mask
3. Enter the Default Gateway

Note: These values can be modified in the GUI.

10
 Installation Steps (continued)
Primary/Secondary DNS and summary confirmation
4. Primary DNS should be configured select
Yes.
5. Enter in a value for the primary DNS.
6. You can also add a secondary DNS but
that is not required.
7. After the DNS is entered you will be
presented with a summary of what is
configured at this point. If everything is
correct select Yes. If not select No to go
back and re-enter the correct
information.

These values can be modified in the GUI.

Installation Steps (continued)

Primary/Secondary DNS and summary confirmation

4. Primary DNS should be configured select Yes.

5. Enter in a value for the primary DNS.
6. You can also add a secondary DNS, but that is not required.
7. After the DNS is entered you will be presented with a summary of what is configured at this
point. If everything is correct select Yes. If not select No to go back and re-enter the
correct information.

11
 Installation Steps (continued)
Enter and confirm a root password as well as allowing root via SSH

8. Enter in a root password

9. Confirm the root password
10. Choose to allow root access via
SSH.

Installation Steps (continued)

Enter and confirm a root password as well as allowing root via SSH.

8. Enter in a root password.

9. Confirm the root password.
10. Choose to allow root access via SSH.

12
 Installation Steps (continued)
Web Cache volume scheme
11. Select your volume scheme for web
cache, you select the default or use
an alternative scheme with limited
cache.
12. Using the default, the volume wizard
will allocate a certain amount of
space based on space available.

NOTE: These values are from a lab

environment and will be different in a
production environment on a physical
appliance.

The appliance will initialize after this step, and you

should be able to log into the UI.

Installation Steps (continued)

Web Cache volume scheme

11. Select your volume scheme for web cache, you select the default or use an alternative
scheme with limited cache.
12. Using the default, the volume wizard will allocate a certain amount of space based on
space available.

Note: These values are from a lab environment and will be different in a production
environment on a physical appliance.

The appliance will initialize after this step, and you should be able to log into the UI.

13
 SWG GUI Login
Three ways
Log on to the interface that is provided for Web Gateway to use the product for
configuring a web security policy. You can do this one of three ways:

 As a Java applet in your browser

 As a Java Web Start application
 As an HTML application in your browser

The logon procedure differs depending on the method you choose. In each case,
the procedure begins with accessing the logon options window for Web Gateway
through a browser.

There are three ways to log into the SWG GUI.

Log on to the interface that is provided for Web Gateway to use the product for configuring a
web security policy. You can do this one of three ways:

• As a Java applet in your browser

• As a Java Web Start application
• As an HTML application in your browser

The logon procedure differs depending on the method you choose. In each case, the
procedure begins with accessing the logon options window for Web Gateway through a
browser.

14
 Logging on to Secure Web Gateway for On Premise Appliances
Login options

SWG UI is accessible over:

https://<IP/hostname>:4712 Java applet in

browser

Default credentials:

admin/webgateway Java Web Start

Application

HTML application
in browser

Some browsers do not support logging on to and running the Web Gateway interface due to
their plug-in architecture. For example, current Google Chrome and Mozilla Firefox versions do
not allow for the use of Java. When working with one of these browsers, you will not be able to
logon to the default UI. Instead, you will need to use one of the other two options.

When Webstart is downloaded, the Web Gateway UI is stored locally, replacing the need for a
browser, and an icon can be added to the desktop for subsequent logins.

From the login screen, you also have the option to logon to the UI in an HTML browser, which
replaces the need to use Java.

15
 Completing the Setup in the UI
Using the setup wizard to license the appliance

When you log into the user interface

for the fist time, the setup wizard will
walk you through basic settings
 Accept the End User License
Agreement
 Accept the Data Usage Statement
 Import a license
 Activate the product

Completing the Setup in the UI

When you log into the user interface for the fist time, the setup wizard will walk you through
basic settings
• Accept the End User License Agreement
• Accept the Data Usage Statement
• Import a license
• Activate the product

16
 Completing the Setup in the UI (Continued)
Use the setup wizard to set the time zone

You can then set your timezone.

Skyhigh recommends leaving this set
to Etc/UTC if you plan on having
gateways in different timezones to
maintain consistency.
Select the appropriate timezone for
your setup.

Completing the Setup in the UI (Continued)

Use the setup wizard to set the time zone.

Skyhigh recommends leaving this set to Etc/UTC if you plan on having gateways in different
timezones to maintain consistency.
Select the appropriate timezone for your setup.

17
 Completing the Setup in the UI (Continued)
Use the setup wizard to change or configure additional network settings
You can change your current information
configured for eth0 as well as enable other
network interfaces and configure those as
well.
 Enable or disable network interfaces and
configure them
 Change the default gateway for IPv4
and/or IPv6
 Configure advanced settings such as
speed and duplex as well as MTU size
 Make changes to DNS adding a
secondary as well as a tertiary server
 You can also configure VLANs and add IP
aliases

Completing the Setup in the UI (Continued)

Use the setup wizard to change or configure additional network settings

You can change your current information configured for eth0 as well as enable other network
interfaces and configure those as well.
• Enable or disable network interfaces and configure them
• Change the default gateway for IPv4 and/or IPv6
• Configure advanced settings such as speed and duplex as well as MTU size
• Make changes to DNS adding a secondary as well as a tertiary server
• You can also configure VLANs and add IP aliases

18
 Completing the Setup in the UI (Continued)
Use the setup wizard to change the password

You can change the password for the

main admin account.
The password needs to conform the
password policy that includes:
 Minimum of 8 characters
 One upper case
 One lower case
 One non-alphanumeric character

Completing the Setup in the UI (Continued)

Use the setup wizard to change the password.

You can change the password for the main admin account.
The password needs to conform the password policy that includes:
• Minimum of 8 characters
• One upper case
• One lower case
• One non-alphanumeric character

19
 Verifying User Interface is Accessible
Dashboard Landing Page
8

The Dashboard appears after a success log in to its interface. This interface is your launching
point for Web Gateway. It displays performance information and statistics about Web
Gateway operation. The Dashboard is discussed in more detail later in the course.

The menu bar, located at the top of the pages, is a primary navigational control. Each page is
represented by an icon. Click the icon for the page you want to access.

The interface also provides icons and other controls; for example, User Preferences, Logout,
Search, and Save Changes.

20
 Navigating Web Gateway Interface
Become Familiar with Menu Bar and Page Controls

Take a moment to familiarize yourself with Web Gateway menu bar options and other page
controls.

Pay special attention to the Save Changes button. If it is red, it indicates your input or settings
have not been saved. The button changes to gray after the changes are saved.

21
Knowledge Check

22
Check your Learning
Multiple choice: Choose the correct answer.

What is the default primary network interface for Web

Gateway?

A. eth0
B. eth1
C. net0
D. net1

Answer: A. eth0. See Initial Configuration Settings.

23
Check your Learning
Multiple choice: Choose the correct answer.

Which of the following configurations can be performed using

the Web Gateway Setup Wizard?

A. Product activation
B. Product licensing
C. Modify default password
D. Proxy HA configuration

Answer: A, B, C. See Completing the Setup.

24
Check your Learning
Multiple choice: Choose the correct answer.

Which items below are the default password requirements for

a Web Gateway appliance? Select all that apply.

A. Minimum of 8 characters
B. One upper case
C. One lower case
D. One non-alphanumeric character

Answer: A, B, C, D

25
 Review

 Verify solution requirements. Varies, depending on scope (new or upgrade) and

appliance type.
 Use configuration wizard for initial configuration. Remember, you can customize
these, as needed.
 At a minimum, you must define root password and remote root logon.
 Import the license and activate the product.
 The Dashboard page opens after a successful logon.
 Use the menu bar to navigate between pages.

• Verify solution requirements. Varies, depending on scope (new or upgrade) and appliance
type.
• Use configuration wizard for initial configuration. Remember, you can customize these, as
needed.
• At a minimum, you must define root password and remote root logon.
• Import the license and activate the product.
• The Dashboard page opens after a successful logon.
• Use the menu bar to navigate between pages.

26
 Lab Exercises
Lab 4: Installation

 Goals:
 View appliance settings
 View UI settings
 Duration:
 20 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

27
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

28
Module 5: System Configuration

1
 Module 5 Objectives

 Communicate about system configuration

basics
 Access and navigate the Configuration page
 Identify initial system configuration settings
 Configure general appliance settings
 Configure network settings
 Configure proxies
 Configure basic Central Management settings
 Configure log file settings
 Configure update settings

• Communicate about system configuration basics

• Access and navigate the Configuration page
• Identify initial system configuration settings
• Configure general appliance settings
• Configure network settings
• Configure proxies
• Configure basic Central Management settings
• Configure log file settings
• Configure update settings

2
 Configuration Overview
After the initial setup you can configure more system
settings and modify the initial settings from the
Configuration Page including license, network interfaces,
proxies and cluster nodes setup.

This slide highlights the key topic discussed in this module.

3
 Configuration Page
Appliances and File Editor Tabs
Use the Appliances tab to manage and configure SWG. It has a toolbar, which you
use to add or delete appliances, update engines (modules), and expand or
collapse the tree in the left pane.
Use the File Editor tab to edit system files. This tab does not have a toolbar.

This is the SWGConfiguration page. You access it by clicking the Configuration icon on the
menu bar.
This page has two tabs: Appliances tab and File Editor.
Use the Appliances tab to manage and configure the Web Gateway. It has a toolbar, which you
use to add or delete appliances, update engines (modules), and expand or collapse the tree in
the left pane. Use the File Editor tab to edit system files. This tab does not have a toolbar.

4
 Appliances Tab
Cluster and Appliances Lists

Specific Web Gateway

appliance

Cluster:
• Manage license
• Configure Mobile Cloud Security
• Configure hybrid settings for syncing policy (Web Hybrid) and Cloud hosted lists (UCE Hybrid).

Appliance: Configure settings for specific appliance.

In the left pane of the Appliances tab, the tree is divided by Cluster and Appliances.

Cluster options include License and Web Hybrid. Within Appliances, you see an icon for each
SWG.

5
 Web Gateway License Administration
Appliances Tab > Cluster List > License
• Import License
• Status
• Creation
• Expiration
• License ID
• Customer
• Customer ID
• Seats
• Evaluation
• Features
• Data usage statement

Use the License Administration page to verify the license status is valid. Complete these steps
from the Configuration page, Appliances tab:
1. Within the Cluster list, select License.
2. In the right pane, verify the status of the license. If it is not valid, read and
accept the end user license agreement.
3. Browse to, select, and open the appropriate license file.
4. Verify the selected license displays in the License file box.
5. Click Save Changes.

After the license is installed, you can view information about it, such as:
• Creation: Shows the date when a license file was created.
• Expiration: Shows the date when a license file expires.
• License ID: Shows the ID of a license.
• Customer: Shows the name of the license owner.
• Customer ID: Shows the ID of the license owner.
• Seats: Shows the number of workplaces in the license owner's organization that the
license is valid for.
• Evaluation: Shows whether the license has been evaluated.
• Features: Lists the features of SWG that are covered by the license.
• I have read and understood the data usage statement: Provides a link to the Data
Usage Statement.

6
 Obtaining Web Gateway Updates
Ensure Engines, Definitions, and Product Files Remain Current

Automatic update: • Antimalware and URL

• From the Internet or from other nodes in Central Filter
Management configuration.
• Dynamic Content
Classification
Manual update:
• Application Control
• From Content Security website,
https://contentsecurity.skyhigh.cloud/update
• Single Sign On (SSO) and
Connector Catalog
As a best practice, allow communications to HTTPS
services (TCP/443) for any destination. Alternatively, • Cloud Encryption Service
use a next-hop proxy that allows contact to
download servers. • Third-party Avira
Antivirus

Web Gateway requires access to several download servers to obtain the required files for
engine, definition, and product updates. The following data is retrieved from the download
servers:
• Gateway Antimalware and URL Filter
• Data Loss Prevention (DLP)
• Dynamic Content Classification
• Application Control
• Single Sign On and SSO Connector Catalog
• Cloud Encryption Service
• Third-party Avira Antivirus

If access is blocked by an outbound firewall, Web Gateway may not be able to retrieve all
necessary data, which can lead to failing updates or missing the latest available security
signatures. As a best practice, allow SWG to communicate to HTTPS services (TCP/443) for any
destination.

Alternatively, it is possible to use a next-hop proxy in your network, which allows SWG to
contact the download servers.

7
 Configuring Automatic Updates
Appliances Tab > Appliances > [appliance] > Central Management

• Enable automatic updates.

• Allow download of updates.

Central • Optionally change update intervals.

Management
Environments • Optionally enable use of update
proxies. This is especially useful in an
air-gapped environment where an
appliance has no direct internet
access

Optional
Automatic update requires an Internet
connection for SWG to access the
update servers.

To configure automatic updates of the database, complete these steps from the Configuration
page, Appliances tab, and Appliances list:
1. Within the list for your Web Gateway appliance, click Central Management.
2. Scroll down to Automatic Engine Updates and make sure these options are selected
(checked/ticked):
• Enable automatic updates.
• Allow to download updates from internet.
• Allow to download updates from other nodes. This applies to Central
Management configurations. When enabled, this allows you to
schedule updates for the modules (also known as engines) on the
nodes as part of configuring settings for this configuration.
3. Optionally change the default update intervals.
4. Optionally enable the use of update proxies.
5. If you modified the default settings, click Save Changes.

8
Using an Update Proxy for Automatic Updates

 If a SWG does not have direct

internet access then a proxy can be
added to connect to the internet for
engine updates.
 With a proxy connection then
automatic updates can function as
normal.

9
 Triggering Automatic Updates Manually
Appliances Tab > Update Engines > Trigger Update

Occurs automatically based on define

update interval but can also be triggered
manually.

When there is an Internet connection and automatic update is configured, updates occur
regularly based on the intervals defined on the Central Management page. Optionally, you can
also trigger the update manually.

10
 Downloading Update Package Manually
In an Air Gapped environment where a proxy connection is also not available
then engine & DAT updates can be performed manually.

Workflow – Step 1 of 4
• Navigate to
https://contentsecurity.skyhigh.cloud/
update
• Accept terms and conditions and click
Next Step.

This slide explains step 1 of 4 for downloading update package manually.

• Navigate to https://contentsecurity.skyhigh.cloud/update
• Accept terms and conditions and click Next Step.

11
 Downloading Update Package Manually
Workflow – Step 2 of 4
• Select Skyhigh Secure Web Gateway from the product drop-down list.
• Click Next Step.

This slide explains step 2 of 4 for downloading update package manually.

• Select Secure Web Gateway from the product drop-down list.
• Click Next Step.

12
 Downloading Update Package Manually
Workflow – Step 3 of 4
• Provide Secure Web Gateway version number and build number.
• Click Next Step.

This slide explains step 3 of 4 for downloading update package manually.

• Provide Secure Web Gateway version number and build number.
• Click Next Step.

13
 Downloading Update Package Manually
Workflow – Step 4 of 4
• Select updates to include in the update package.
• Click Generate Update Package.

This slide explains step 4 of 4 for downloading update package manually.

• Select updates to include in the update package.
• Click Generate Update Package.

14
 Downloading Update Package Manually
• Download the generated
package.
• On SWG UI, navigate to
Configuration > Appliances >
Update engines. Click Upload
update file.

Download the generated package.

To initiate a manual update, complete these steps from the Configuration page, Appliances
tab:
1. From the Update Engines drop-down list, select Upload Update File.
2. Browse to, select, and open the update package.
3. After selecting the package, click Update.
4. Wait while the upload is in progress.
5. After the update is complete, click Close.

15
 Reviewing Update Information on Dashboard
Update Information Displays on Dashboard page, Alerts Tab

After the update is complete, you can review the update information on the Dashboard page,
Alerts tab.

16
 Reviewing Update Logs
Troubleshooting > [appliance] > Log files > update

Optionally review the update logs from Troubleshooting page. The update logs are also
available located in /opt/mwg/log/update/update.log.

17
 Network Settings Overview

 Proxies
 Network Interfaces
 Domain Name Service
 Network Protection
 Static Routes
 Port Forwarding

This slide highlights key networking settings for SWG.

18
 Viewing Proxy Configuration
Appliances Tab > Appliances > [appliance] > Proxies
• Default and recommended
configuration is Proxy (optional
WCCP). WCCP refers to Web Cache
Control Protocol redirection method.

• Optionally change the configuration;

for example, select a different
network mode or configure other
protocols for data transfer.

• Modify the HTTP proxy listener IP to

the interface IP of the SWG appliance.

• In a pure ICAP environment HTTP

Proxy is unlikely to be used.

You can configure the proxy functions of the appliance as is appropriate for your network. From
the Configuration page, Appliances tab, complete these steps:
Review the proxy settings. The following key settings are configured by default:
1. Within the Appliances list for the SWG you are administering, click Proxies.
2. In the right pane, review the current configuration. By default, the network mode is
Proxy (optional WCCP) and Enable HTTP proxy is selected (checked/ticked).
3. Optionally, change the proxy configuration; for example, select a different network
mode or configure other protocols.
4. Save any changes.
5. When prompted, log out of the interface and then log back into the interface.

19
 Supported Network Modes: Review
Identifies How Traffic is Directed to Web Gateway

Name Description
Proxy (optional WCCP) • Explicit proxy mode (default).
• HTTP enabled by default.
• Web Cache Communication Protocol (WCCP)
supported for client redirects.
• Appliance is typically behind firewall.
Proxy HA • Explicit proxy mode with high availability
functions (No external load balancer).
Transparent Router • Clients are unaware of appliance.
• Appliance is placed as router behind firewall.
• Switch optionally connects appliances and
clients.
Transparent Bridge • Clients are unaware of appliance.
• Appliance is usually placed behind firewall and
router as invisible bridge.
Note: ICAP is independent of network mode but in the vast majority of cases the Network Mode chosen when SWG is
configured as an ICAP Server is Proxy (Optional WCCP) with the WCCP disabled.

The appliance uses its proxy functions to intercept web traffic and transmit it if this is allowed
by the filtering rules. You can configure these functions to meet the requirements of your
network.

• Proxy (optional WCCP)

• When Proxy (optional WCCP) is selected, the explicit proxy mode is used, and Web
Cache Communication Protocol (WCCP) services can redirect web traffic to an
appliance. This is typically the default configuration.
• Proxy HA
• When Proxy HA is selected, an explicit proxy mode with High Availability (HA)
functions is used. The idea of this configuration is to introduce failover and load
balancing without the need for external load balancers.
• Transparent Router
• The transparent router mode is one of the two transparent modes you can configure
for the proxy functions of a Web Gateway appliance if you do not want to use an
explicit mode. In transparent router mode, the clients are unaware of the appliance
and need not be configured to direct their web traffic to it.
• Transparent Bridge
• With this mode, the clients are unaware of the appliance and need not be configured
to direct their web traffic to it. The appliance is usually placed between a firewall and
a router, where it serves as an invisible bridge.

20
 Proxy (Optional WCCP)

Network

Websites

SWG

• Explicit proxy mode (default).

Proxy
• HTTP enabled by default.
(optional
• Web Cache Communication Protocol (WCCP) supported for client redirects.
WCCP)
• Appliance is typically behind firewall.

In explicit proxy mode, the clients directly send traffic to the web gateway. This is the default
configuration.

The browsers are configured to accept proxy web connections and establish a trust
relationship with the Web Gateway.

Typically, the SWG is placed behind a firewall and connected to its clients and the firewall by a
router.

Optionally, the web cache communication protocol i.e., WCCP services or Layer 2 transparent
can be configured to redirect the web traffic to the SWG

21
 Proxy (optional WCCP) Configuration
Network Setup and Transparent Proxy

Network mode

Methods for intercepting and

redirecting traffic
transparently

• WCCP: HTTP client requests sent to web servers under IPv4 and IPv6 are intercepted and
redirected to the appliance using Web Cache Communication Protocol (WCCP). For more
information see Request for Comment (RFC) 3040 on www.ietf.org. This RFC discusses the
web replication and caching taxonomy for WCCP.

• Layer 2 Transparent: HTTP client requests sent to web servers under IPv4 and IPv6 are
intercepted and redirected using Layer 2.
Note: Neither of these transparent options are likely to be used with an ICAP server.

• Supported Client Redirection Methods - Web Gateway supports two methods for
intercepting web traffic and redirecting it to an appliance: Web Cache Communication
Protocol (WCCP) and Layer 2 transparent.

• Web Cache Communication Protocol - When WCCP is selected, HTTP client requests sent to
web servers under IPv4 and IPv6 are intercepted by an additional network device and
redirected to the appliance using the Web Cache Communication Protocol (WCCP). The
clients are not aware of the redirection, it remains transparent for them.

• Layer 2 Transparent - When selected, client requests sent to a web server under IPv4 and
IPv6 are intercepted by an additional network device and redirected to the appliance using
the Layer 2 method. Client requests are accepted on the appliance even if their destination
IP addresses are not addresses of the appliance. The redirection is transparent to the
clients.

22
 Proxy HA

Network

Websites

SWG
Scanning Node P89

Scanning Node P88

Active Director
(VIP)
Scanning Node P0

• Explicit proxy mode with high availability functions. No external load

Proxy HA balancer.
• Discussed later.

When Proxy HA network mode is selected, an explicit proxy mode with High Availability (HA)
functions is used.

The idea of this configuration is to introduce failover and load balancing without the need for
external load balancers.

This setup is recommended for smaller deployments or locations/offices within a larger

deployment where an external load balancer is not feasible. This mode is discussed in more
detail later in the course.

23
 Proxy HA Configuration

Scanner IP

Director priority

Virtual IPs

Note: HA features when using SWG as an ICAP server are usually provided by either the ICAP Client or a hardware load
balancer, but Proxy HA can be used if required.

The typical configuration for Proxy HA mode include:

• Director priority:
• Sets the priority (ranging from 0 to 99) that an appliance takes in directing data
packets.
• The highest value prevails. 0 means the appliance never directs data packets, but
only filters them.
• In a High Availability configuration, two appliances are typically configured as
director nodes with a priority higher than zero to direct data packets, providing fail-
over functions for each other.
• The remaining nodes are configured with zero priority (also known as scanning
nodes).
• The priority value is set on a slider scale.
• Directory priority must be set first to enable other Proxy HA configurations.

• Virtual IPs:
• Provides a list of virtual IP address. It is recommended that virtual IP is used to log in
to the user interface after configuring HA proxy mode.
• All members of the HA proxy setup must have the same Virtual IP.

• Scanners:
• Define Peer/Director or scanner IPs for HA setup.
• Typically, a director is configured a Scanner node itself and the backup node is
configured as a peer/director. The other scanning nodes are configured as scanners.

24
 Transparent Router

Network SWG

Websites

• Clients are unaware of the appliance.

Transparent
• Appliance is placed as router behind the firewall.
Router
• Switch optionally connects appliance to clients.

The transparent router mode is one of the two transparent modes you can configure for the
proxy functions of a Web Gateway appliance.

In transparent router mode, the clients are unaware of the appliance and need not be
configured to direct their web traffic to it.

The appliance is placed as a router immediately behind a firewall.

A switch can be used for connecting the appliance to its clients.

A routing table is used to direct the traffic.

25
 Transparent Router Configuration

Director priority

Port
Redirects Virtual IPs

IP Spoofing

Note: ICAP is unlikely to be used with this network mode.

Typical settings for a transparent router mode include port redirects, management IP for Web
Gateway, Virtual IP, Virtual Router ID and IP spoofing configuration.

26
 Transparent Bridge

Network SWG

Websites

Transparent • Clients are unaware of the appliance.

Bridge • Appliance is usually placed between firewall and router as invisible bridge.

The transparent bridge mode is one of the other transparent modes you can configure for the
proxy functions of the gateway appliance.

With this mode, the clients are unaware of the appliance and need not be configured to direct
their web traffic to it.

The appliance is usually placed between a firewall and a router, where it serves as an invisible
bridge.

27
 Transparent Bridge Configuration

Port
Redirects

Management IP

IP Spoofing

Note: ICAP is unlikely to be used with this network mode.

Typical settings for transparent bridge mode include port redirects, Management IP and IP
Spoofing configuration.

28
 Supported Data Transfer Technologies
Determine How Data is Transferred

Name Description
HTTP Proxy Hypertext Transfer Protocol
(Default)
FTP Proxy File Transfer Protocol
ICAP Server Internet Content Adaption Protocol
IFP Proxy Internet Facsimile Protocol
TCP Proxy Transmission Control Protocol
SOCKS Proxy Sockets Protocol

In addition to network mode, you also configure the technologies used to transfer data. By
default, HTTP is enabled. You can configure other data transfer technologies as needed, as
shown in the figure.

29
 ICAP Server Configuration

ICAP Server config

 Define Interface and port used

 ICAPS
 Certificate Used for ICAPS
 Preview Size
 TLS Versions supported for ICAPS

30
 HTTP Proxy Settings
Ports, Anonymous Login for FTP, Add Via HTTP Header

HTTP Port Definition

List

Anonymous login for

FTP over HTTP

Add via HTTP

header

As discussed, HTTP proxy is enabled by default. Other key settings here are:
• HTTP Port Definition list: Provides a list for entering the ports on an appliance that
listen to client requests.
• Anonymous login for FTP over HTTP: Specifies the username for logging on as an
anonymous user when requests are transmitted to an FTP server by an HTTP proxy on
an appliance.
• Password for anonymous login for FTP over HTTP: Sets a password for a username.
• Add Via HTTP header: When selected, a Via HTTP header is added to a request that is
processed on an appliance. This option is selected by default.
• Adjust content-type header for requests to archives (depending on the content
encoding): When selected, a content-type header in a request for access to an
archive file is adjusted if this header does not match the content encoding that was
detected for the archive.
• Host header has priority over original destination address (transparent proxy): When
selected, requests that are sent to the proxy on an appliance in transparent proxy
mode are recognized as traffic in explicit proxy mode and processed accordingly.
This option is only available if the explicit proxy mode is not already configured on an
appliance. If the option is available, it is selected by default.

31
 Configuring Network Interfaces
IPv4 and IPv6

 Host name / Fully qualified domain name

 Default gateway (IPv4)
 Default gateway (IPv6)
 Enable these network interfaces
 IP settings, Subnet mask, maximum
transmission unit (MTU), and IP Aliases
 Add VLAN

The Network Interfaces settings are used for configuring the network interfaces of an
appliance. This page is divided into three tabs: Appliance settings for IPv4, Appliance settings
for IPv6, and Advanced settings.

The options on the IPv4 tab are listed below. The IPv6 tab has similar options:
• Host name/Fully qualified domain name: Specifies the host name of an appliance.
The name must be specified as fully qualified domain name.
• Default gateway (IPv4): Specifies the default gateway for web traffic under IPv4.
• Default gateway (IPv6): Specifies the default gateway for web traffic under IPv6.
• IPv4 and IPv6: Provides options for configuring network interfaces under IPv4 and
IPv6. The options are provided on a separate tab.
• Add Alias: Opens the Input window for adding an alias.
• Add VLAN: Opens a window for adding a network interface for VLAN traffic. You can
use this option to run VLANs under IPv4 or IPv6. To add a network interface, you
specify a number as its ID and click OK. The interface name is composed of two
parts, separated by a dot.

32
 Configuring Network Interfaces (Continued…)
Advanced Settings

 Media (additional media)

 Bridge enabled (transparent bridge)

 Bond enabled (subordinate interface)

Advanced tab options include:

• Media: Lets you select additional media for use with a network interface.
• Automatically detect: Media for use with a network interface
are automatically detected if available in the network
environment of an appliance.
• 1000BaseT-FD, 1000Base-HD, and so on: The selected media
item is used with a network interface.
• Bridge enabled: When selected, web traffic is routed through a network interface in
transparent bridge mode. The Name field specifies the name of the transparent
bridge.
• Bond enabled: When selected, the currently selected network interface (for example,
eth2) is configured as a bonded interface that is subordinated to a bonding
interface. The Name field Specifies the name of the bonding interface.

33
 Configuring Domain Name Service
DNS Server Settings and Conditional Forwarding

IP address of first server

IP address of second
server
IP address of third server

Enable to configure and

use Conditional
Forwarding

For ICAP Servers DNS is used more for internal SWG functions e.g. accessing
update servers, CRLs etc and for GTI lookups.

The Domain Name Service settings are used for configuring Domain Name Service (DNS)
servers, including the use of DNS servers according to particular domains, which is also known
as conditional DNS forwarding. Settings here include:

• Primary domain name server: Specifies the IP address of the first server.
• Secondary domain name server: Specifies the IP address of the second server.
• Tertiary domain name server: Specifies the IP address of the third server.
• Conditional DNS Forwarder: When selected, a DNS server from the Conditional
Forwarder List resolves domain information sent in a request to Web Gateway into an
IP address.

34
 Configuring Domain Name Service (Continued)
Guidelines for Conditional Forwarding

Options Description
Default resolver(s) Specify up to five IP addresses of DNS server or servers
used for resolving domain information.
TTL (Time to Live) for Limit time (in seconds) that positive answers are cached
positive answer for conditional DNS forwarding to the specified value.
TTL for negative answer Limit time (in seconds) that negative answers are cached
for conditional DNS forwarding to the specified value.
Conditional Forwarder List Add entries for domains and IP addresses of DNS servers
involved in conditional forwarding.
Conditional Forwarder Add entries for domains and IP addresses of DNS servers
Reverse Lookup List involved when reverse lookup is performed.

See the Secure Web Gateway Product Guide for

greater detail on all items.

This table lists other settings related to Conditional Forwarding. These options are available
only when Conditional Forwarding is enabled.

35
 Configuring Network Protection
Appliance-specific Rules for Incoming Traffic

Allow use of appliance-specific

rules
Accept or drop incoming traffic
Accept and answer Ping
requests

Define
exceptions
from default
policy

The Network Protection system settings are used for configuring protective rules for traffic
coming into an appliance from your network. Settings for configuring network protection rules
include:
• Enable network protection: When selected, the settings configured in the following for
network protection are enabled.
• Input policy: Lets you select the action taken on incoming traffic. Incoming traffic can
either be dropped or accepted.
• Allow Ping requests: When selected, the appliance accepts and answers Ping
requests.
• Exceptions from default policy: List network devices that send traffic to an appliance.
Traffic from these devices is not handled according to the rules that are currently
implemented. When these rules drop incoming traffic, traffic sent from the devices
listed here is accepted and vice versa.

36
 Configuring Static Routes
Routes that Always Use Same Gateway and Interface

Add list of static routes for

IPv4

Add list of static routes for

IPv6

The Static Routes settings are used for configuring routes that always use the same gateway
and interface on this gateway when web traffic is routed from an appliance to a particular
host.

37
 Configuring Port Forwarding
Forward Web Traffic to Another Port

Add rules to forward traffic

from one port to another

Enable and configure

settings for extended
logging
Configure type of data
logged when forwarding is
successful or fails

The Port Forwarding settings are used for configuring rules that let an appliance forward traffic
sent from a port on a particular host to another port. Key settings include:

• Source host: Specifies the IP address of a host that is the source of web traffic in a
port forwarding rule.
• Bind IP: Specifies the bind IP address.
• Target port: Specifies the port that web traffic from the source host is forwarded to.
• Destination host: Specifies the IP address of the host that is the destination of web
traffic sent from the source host.
• Destination port: Specifies the port on the destination host used for listening to web
traffic coming in from the source host.
• Enable extended connection logging: When selected, all logs for port forwarding are
stored on the appliance system under /var/log/mwg_fwd.log.
• Customize extended logging fields: When selected, the input fields for configuring the
type of data that should be logged become accessible.
• Log on success: Lets you enter the type of data to be logged when web traffic is
successfully forwarded.
• Log on failure: Lets you enter the type of data to be logged when forwarding web
traffic failed.

38
 Configuring Date and Time
Appliances Tab > Appliances List > [appliance] > Date and Time

Use server for time

synchronization. Disable to
set time manually.

Specify NTP Server, IP

address or hostname.

Select timezone.

Set time manually.

If you change NTP synchronization settings, it is recommended

to restart the appliance.

Use this page to modify time and date settings defined initially for a specific appliance. To
review the current date and time settings, complete these steps from the Configuration page,
Appliances tab:

1. Within the Appliances list, expand the list for the Web Gateway you want to manage
and then click Date and Time.
2. In the right pane, the options are:
• Enable time synchronization with NTP servers: When selected, the appliance
uses time servers under the NTP (Network Time Protocol) for time
synchronization.
• NTP server list: Provides a list for entering the servers that are used for time
synchronization under the NTP protocol. The list elements are as follows:
• String: Specifies the name of an NTP server.
• Comment: Provides a plain-text comment on an NTP server.
• Select time zone: Provides a list for selecting a time zone.
3. If you make changes, be sure to click Save Changes.

Alert: It is recommended to restart the appliance after configuring time

synchronization with NTP servers. When the appliance restarts, it sets
system time to the time on the NTP servers.

39
 Log File Manager Overview
Rotation, Deletion, and Pushing of Log Files
• Log File Manager allows
configuration of settings for logs Auto Rotation
Settings for rotating log file automatically based on
maintained by modules of an size and time of day.
appliance. Settings for deleting log files automatically based on
Auto Deletion
size and last time of modification.
Settings for pushing rotated log files automatically to
• System logs are enabled by Auto Pushing
another location.
default.
Settings for
Specific settings for Error Logs.
error logs
• Auto-deletion is enabled by Settings for
Specific settings for Update Log.
default for more than 7 files for Update log
the same log and if a log file is Settings for
unchanged for more than 7 Audit log
Enable specific Audit Log settings.
days.
• Not to be confused with User- Advanced Settings for auto-deletion of core and feedback files.
Defined Logs which are
configured in policy.

The Log File Manager settings are used for configuring the rotation, deletion, and pushing of log
files that are maintained by modules of an appliance. Settings can be configured for log files in
general and for two important types of log files, which are stored in the Update Log and the
Audit Log.

40
 Enabling and Configuring Audit Log Settings
Example

As an example, we have enabled specific log file settings. The default is disabled. When
enabled, you can configure the settings for file size before rotation, scheduling of log file
rotation, interval, and related settings. You may also choose to save the audit log to the syslog.

41
Knowledge Check

42
Check your Learning
Multiple choice: Choose the correct answer.

The network mode of the proxy configuration identifies how

traffic is directed to the Web Gateway. Which mode is the
default?

A. Proxy HA
B. Proxy (optional WCCP)
C. Transparent Router
D. Transparent bridge

Answer: B. Proxy (optional WCCP). See Supported Network Modes.

43
Check your Learning
Multiple choice: Choose the correct answer.

You are configuring Domain Name System (DNS) settings.

What is the maximum number of DNS servers you can specify?

A. 1 (one)
B. 2 (two)
C. 3 (three)
D. 4 (four)

Answer: C. Three. See Domain Name System (DNS) Settings.

44
Check your Learning
True - False

The Audit log is enabled by default.

 True
 False

Answer: A. True. See Enabling and Configuring Audit Log Settings.

45
 Review

 System settings are configured for general functionality, network interfaces, DNS
servers, proxies, Central Management, and so on.
 The Log File Manager lets you configure settings for various log file types.
 Engine update ensures relevant information is made available to the filtering
functions of Web Gateway.

• System settings are configured for general functionality, network interfaces, DNS servers,
proxies, Central Management, and so on.
• The Log File Manager lets you configure settings for various log file types.
• Engine update ensures relevant information is made available to the filtering functions of
Web Gateway.

46
 Lab Exercises
Lab 5: System Configuration

 Goals:
 Configure HTTP listener settings
 Configure alias IP address
 Configure DNS settings
 Configure static route
 Configure log settings
 Duration:
 30 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

47
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

48
Module 6: Policy Overview

1
 Module 6 Objectives

 Recall the HTTP communication protocol

 Explain the purpose of rules and rule sets
 Give examples of rule types
 Identify rule elements
 Explain the purpose of lists
 Give examples of list types
 Access and navigate the Policy page

• Recall the HTTP communication protocol

• Explain the purpose of rules and rule sets
• Give examples of rule types
• Identify rule elements
• Explain the purpose of lists
• Give examples of list types
• Access and navigate the Policy page

2
 Review: Hypertext Transfer Protocol (HTTP)
Key Terms and Concepts

 TCP 3-way Handshake

 Request-Response Sequence

 Request Header

 Response Header

 Encoding

 Embedded Objects

When using ICAP it is still important to understand the underlying HTTP protocol

Before working with policies, you also should be familiar with some basic Hypertext Transfer
Protocol (HTTP) terms and concepts.

3
 TCP 3-way Handshake
Establish TCP Connection

SYN – SYN/ACK - ACK

1 SYN is sent

SYN/ACK is returned 2

3 ACK is sent

Acknowledgement is
received and the TCP socket
connection is established.

Before HTTP communication can occur, a connection must be established between two
computers. This connection occurs through what is called a TCP 3-way handshake.

The 3-way handshake uses a sequence commonly called SYN – SNY/ACK – ACK to establish the
TCP connection.

4
 HTTP Request-Response Sequence
Foundation for Internet Communications

Response
message
includes:
Server returns a • Response
response message headers
to the client. • Response status
code
2 • Response body
1
Client submits an
HTTP request
message to the
Request message server.
includes:
• Request method
• Request headers
• Request body

Once a TCP connection has been established, HTTP communication may occur. HTTP, which
stands for hypertext transfer protocol, is a protocol in the client–server model. HTTP is the
foundation for Internet communications.

Just like the 3-way handshake, HTTP also has a sequence. The HTTP sequence is called the
request – response sequence. The client, such as a web browser, submits a request to the web
server. The web server returns a response to the client.

5
 How It Works: Web Gateway Explicit Proxy Mode
HTTP Request-Response Sequence
Web Gateway
(Proxy Mode)

1 Requests www.apple.com

2 Traffic is scanned and

filtered

3 DNS lookup for

www.apple.com

4 Requests www.apple.com
Proxy Mode:
The client is
aware that the Provides www.apple.com 5
Web Gateway is
in the path Traffic is scanned and
6
filtered

Provides www.apple.com 7 Skyhigh Web

Client Browser Server

We will now look at how the Web Gateway fits into the HTTP request-response sequence.

This example illustrates the request-response sequence when operating in proxy mode. Proxy
mode is when the client is aware that the Web Gateway is in the path to the web server. We will
cover proxy mode in detail in the configuration module.

1. The client browser requests a web site, let’s say www.apple.com.

2. The request is explicitly sent to the to the Web Gateway where it is scanned and filtered.
3. The Web Gateway does a DNS lookup to find the web server for www.apple.com.
4. Request is sent to www.apple.com
5. The web server returns www.apple.com to the Web Gateway
6. Again, the traffic is scanned and filtered.
7. The page is then sent to the client browser.

6
 How It Works: Web Gateway Transparent Mode
HTTP Request-Response Sequence
Web Gateway
(Transparent Mode)
1 Request
www.apple.com

2 DNS lookup www.apple.com

3 Traffic is scanned and

filtered

4 Requests www.apple.com

Transparent
Mode: 5
Provides www.apple.com
The client is
unaware that the Traffic is scanned and
Web Gateway is in 6
filtered
the path

Provides www.apple.com 7 Skyhigh Web

Client Browser Server

This example illustrates the request-response sequence when operating in transparent mode.
Transparent mode is when the client is unaware that the Web Gateway is in the path to the web
server. We will cover transparent mode in detail in the configuration module.

1. The client browser requests a web site, let’s say www.apple.com.

2. A DNS lookup sends the request to the web server with the Web Gateway in the path.
3. The Web Gateway scans and filters the request
4. Then the request is sent to the web server.
5. The web server returns www.apple.com to the Web Gateway
6. The traffic is scanned and filtered.
7. The page is then sent to the client browser.

7
 Example Request Header
GET Request and Additional Parameters

Request This example was captured

using Chrome developer
tools.

Request
Header

Here is an example of a request header.

Notice that it contains the request method…a GET… and then provides additional parameters for
the communication between the client browser and the web server.

This information was gathered using the Chrome developer tools.

8
 Table: Request Methods

Request Method Description

GET Retrieve data from the web server.
HEAD Retrieve only the response headers.
Identical to GET, without response body.
POST Submit data to be processed (e.g., an HTML form).
Data is included either in the body of the request or as a parameter in
the first line.
OPTIONS Retrieve HTTP methods supported by the server.
Checks the functionality of a web server.
CONNECT Convert the request to a transparent TPC/IP tunnel.
TRACE (rarely used) Echoes back the received request.
Used to determine if changes have been made by the server.
PUT Uploads a representation of the specified resource.

The table lists requests methods. The request method identifies what the client is doing. You
can think of it as a command; for example, when the client would like to retrieve data from the
web server, it sends a GET in its request. If the client is submitting data to be processed by the
web server, it sends a POST in its request. Pause the course and Read the description for each
request method.

9
 Table: Request Headers

Request Header Description

Host The fully qualified domain name requested by the web browser.

User-Agent Client-specific information (browser type and version, physical

system, operating system, enhancements).
Accept The content types supported by the client web browser.
Accept-Charset The character sets supported by the client web browser.
Accept-Encoding The encoding (zip, gzip) supported by the client web browser.

Accept-Language The language supported by the client web browser.

Cookie State information sent to a web server to identify a specific client’s

browser.

Along with the request method, the client also send a request header to the web server. The
request header tells the web server what parameters should be used when it responds back to
the client.

For example, ACCEPT-LANGUAGE identifies the language supported by the client browser. The
request header may or may not contain the fields shown in the table. It all depends on the type
of request.

10
 Table: Status Codes

Class Description
1xx Informational
2xx Success
3xx Redirection
4xx Client error
5xx Server error

Status Code Description

200 OK In response to a GET request, response contain the requested
resource.
302 Found Response includes a new URI (uniform resource identifier).
400 Bad Request Request contains bad syntax.
401 Unauthorized Authentication has failed or credentials have not been
provided.
403 Forbidden The request was legal, but the server is refusing to respond.
404 Not Found Requested resource not found. Retries are allowed.
407 Proxy Authentication Required The client must first authenticate with the proxy.

The response header will include a status code. At a minimum, there are five classes of status
code response. 1XX, 2XX, 3XX, 4XX, and 5XX.

• 1XX is an information response. The request has been received and the process is being
continued.
• 2XX means success. The action requested by the client was received, understood, accepted,
and processed successfully.
• 3XX signifies redirection. The client must take additional action to complete the request.
• 4XX is a client error. This status code should include an explanation of the error situation and
if it is a permanent or temporary condition.
• 5XX is a server error. This status code should also include an explanation of the error situation
and if it is a permanent or temporary condition.

The second table lists some common response codes. Working in support, you will most often
encounter the 4XX class of response codes.

11
 Example Response Header
Status Listed in First Line

This example was

Response captured using Chrome
developer tools.

Response Header

Here we have another example, this time we are looking at the response header. Notice that the
status of 200, which we know is success, is listed.

In the sequence we just viewed, the client sent a GET request and a request header identifying
the parameters of communication to the web server. The web server replied with a 200
response status saying OK, and additional parameters for the communication. And as we saw
in the previous example, this detail of information can be viewed using the browser’s developer
tools.

12
 Table: Common Response Headers

Response Header Description

Date The date and time that the response was returned.
Server The name of the web server.

Set-Cookie An HTTP cookie to be saved in the client’s web browser.

Accept-Ranges The type of content accepted by the web server.
Content-Type The type of data that follows the header.
Content-Encoding The encoding used for the data that follows the header.
Expires The TTL (time to live) for the information.

Once the client browser has sent the request header to the web server, the web server will reply
with a response header. This table shows some common response headers.

13
 HTTP Encoding
Process of Compressing Content Sent from Web Server to Client Browser

Request = GET
Accept-Encoding: gzip,
deflate

Response
Content-Encoding-gzip

HTTP encoding is simply the process of compressing content that is sent from a web server to a
client browser. We are all familiar with encoding, and we often zip files before saving them on a
local or network drive or sending them through email. It does no good for a web server to
compress content in a way that cannot be uncompressed by the client. So, within the request
header, there is a parameter called Accept-Encoding. This parameter identifies the
compression methods that the client can support.

In this illustration, the web browser uses the Accept-Encoding parameter to identify that it can
support the gzip and deflate compression methods. When the web server responds with
content for the client, it uses a parameter called Content-Encoding to identify the method it
used to compress the content. In this case of our example, the method used is gzip.

14
 How Encoding Works

Request Header

Response Header

This page shows examples of how the encoding is identified in the request header and in the
response header. The request header identifies that the web browser can accept encoding
types of gzip and deflate. The response header identifies that the web server compressed the
content using gzip.

15
 Embedded Objects
Risks

 Ensures that objects retain original properties.

Embedded  May attempt to gather user information or
Objects compromise the system.

 AJAX allows web pages to be updated

Ajax asynchronously by exchanging data with a web
server behind the scenes.
 Increases the likelihood of malicious code or scripts.

Ajax – Asynchronous JavaScript and XML

Embedded objects are objects that are created with one application and embedded into a
document created by another application. Embedding an object, rather than simply inserting it
or pasting it, ensures that the object retains its original properties.

Embedded objects can be the source of attempts to gather user information or compromise
the system. Risks with embedded objects include XSS attacks, tracking bugs, attack scripts,
worms, and Trojans.

Ajax represents a broad group of web technologies that are used to implement web
applications that communicate with a server in the background. These technologies power and
increase the dynamic information displayed on a web page.

The use of Ajax technologies increases the risk of malicious code and scripts being downloaded
by a browser.

The Web Gateway monitors and filters web content for risks associated with embedded objects
and the use of new technologies.

16
 Policy Overview
Key Terms and Concepts
• Rules define filtering activities.

• Similar rule types are grouped logically into rule sets  Rules
for management.
 Rule Sets

• Rules typically reference lists, which let you define  Lists

common values once for re-use in multiple rules and
 Policy page
helps simplify management.

• Rules, rule sets, lists and related components are

configured on the Policy page.

Before working with SWG, there are some important terms and concepts with which you should
be familiar. They are Rules, Rule Sets, and Lists.

Rules define filtering activities. Similar rule types are grouped into rule sets for common
management. Rules typically reference lists, which let you define common values once for re-
use in multiple rules.

Rules, rule sets, lists, and related components are configured on the Policy page.

On the following pages, we will take a closer look at rules, rule sets, and lists, including what they
are and how they work. In the next module, you will learn how to configure and manage rules,
rule sets, and lists.

17
 Policy Page Overview
Tree, Tabs, and Toolbars

The Policy page is where you configure settings used to manage the traffic that passes through
the SWG. It is organized by these tabs: Rule Sets tab, Lists tab, Settings tab, and Templates tab.
Each of the tabs has its own toolbar. Default and configured objects display in a tree, which you
can expand and collapse. Other navigation controls include the toolbars.
• Rule Sets Tab
• Use the Rule Sets tab to work with rules and rule sets.
• Lists Tab
• Use the Lists tab to work with list.
• Settings Tab
• Use the Settings tab to configure module (engine), action, and system settings for
rules.
• Templates Tab
• Use the Templates tab to work with templates for messages to SWG users. You can
access this tab from the Policy top-level menu. The content of the tab also appears
within the Template Editor. This editor opens when you select an action setting from
the settings tree and click Edit for a template or template collection under Language
and Template Settings.

18
 Policy Page Overview: Rule Sets Tab Views
Four Tab Views for Managing Different Types of Rules and Rule Sets

The Rules Set tab has four-tab views: Rule Sets. Log Handler, Error Handler, and User Defined
Properties.

• Rule Sets Tab View

• Use this tab view to configure rules for filtering and authentication and group them
into rule sets.
• Log Handler Tab View
• Use this tab view to create rules for logging. A logging rule handles the writing of log
file entries into a particular log. Its elements are of the same types as with other rules.
• Error Handler Tab View
• Use this tab view to create rules for error handling. Working with the rules in the Error
Handler rule sets gives you control over what happens when errors occur with
processing web traffic on Web Gateway.
• User Defined Properties Tab View
• Use this tab view to configure properties for use in rule set criteria, rule criteria, and
rule events.

19
 Policy Page Overview: Lists Tab
Define Commonly Used Values for Re-use in Multiple Rules

On the Lists tab, you see there are three list types: Custom, Subscribed, and Systems.

• Custom Lists
• You can modify these lists. They are displayed on the upper branch of the lists tree on
the Lists tab, for example, the list of URLs that are exempted from filtering. Custom lists
can have entries in string, number, category, and other formats.

• Subscribed Lists
• You set up these lists with a name on Web Gateway. They are initially empty and
retrieve content from a subscribed data source. Subscribed lists display in the lists
tree at the end of custom lists.
• There are two subtypes of subscribed lists: Skyhigh-maintained lists and customer-
maintained . The content for Skyhigh-maintained lists is retrieved from a Skyhigh
server. Several lists are available on the Skyhigh server; for example, lists of IP address
ranges or media types. The content for customer-maintained lists is retrieved from a
data source that you specify. Sources that you can specify are files on web servers
running under HTTP, HTTPS, or FTP.

• Systems Lists
• You cannot modify these lists. They include category, media type, and application
name lists, as well as lists of connectors used for cloud single sign-on. They are
updated when an upgrade to a new version of Web Gateway is performed.

20
 Policy Page Overview: Settings Tab
Configure Modules (Engines), Rule Actions, and System Settings

 Implemented with
initial configuration
but support
customization.

 Additional module and

action settings are
implemented when
you import a rule set
from the rule set
library.

Settings are used within SWG for configuring modules (engines), rule actions, and system
functions.

Settings names appear in different places on the user interface, for example, in the criteria,
action, and events of rules or on the Settings and Appliances tabs.

After clicking a settings name, you can access and configure the parameters and values of the
settings.

At the initial setup of the appliance, module and action settings are implemented together with
the rule set system, as well as settings for the appliance system. Additional module and action
settings are implemented when you import a rule set from the rule set library.

You can review and modify the initially implemented or imported settings. You can also
completely delete module and action settings and create module and action settings of your
own.

21
 Policy Page Overview: Templates Tab
Configure Messages Sent to Users when Rule is Triggered
• Implemented with initial configuration but supports customization
• Contain standard text with variables

The Templates tab is used to configure messages for users. Message types include:
• Authenticate message: Informs a user that authentication is required to access a URL.
• Block message: Informs a user that a request was blocked for various reasons, for
example, because a virus was detected in the requested object.
• Redirect message: Informs a user that redirecting to another URL is needed for
accessing the requested object.

Default settings apply for user messages and their templates after the initial setup of the
appliance, which you can review and modify as needed.

Message templates contain standard text with variables. The variables are filled with values as
needed in a given situation.

All variables used in message templates are also properties used by rules. For example, URL is a
variable in a message text and a property when used in a rule to exempt URLs from filtering.

22
 How Rules and Rule Sets Work
A Closer Look

Rule Set Rule Set Rule Set Rule Set

Rules Rules Rules Rules
Rules Rules Rules Rules
Rules Rules Rules
Rules Rules Rules
Rules Rules Rules
Rules
5. Log
End
4. Embedded Object

3. Response

2. Embedded Object Rule Set: Container for one or more rules.

1. Request Rule: Defines how to treat the traffic.

Now that you are familiar with some key terms and concepts, here is closer look at how these
components work to enforce your security requirements.

As review, the purpose of SWG is to filter traffic. It filters traffic by passing each cycle, request,
response, and embedded object through a list of configured rule sets and rules.

A rule set is a container for one or multiple rules. A rule defines how to treat the traffic.

23
 Inside a Rule Set
Basic Parts of a Rule

Top-level container that stores rules. Rule Set

Specific types of filtering activities:

Rule
Media type, URL, virus, malware filtering, etc.

Building blocks to meet the Event

Criteria Action
requirements. (optional)

Let’s look in inside a rule. At the top-level, there are rule sets, which contain one or more rules.
Rules define filtering activities; for example, virus and malware filtering, URL filtering,
authentication, and so on.

Each rule consists of three basic elements: criteria, action, and (optionally) event.

24
 Rule Elements: Criteria
Property, Operator, and Operand

Property (Category)

Anti-malware criteria, Media Type criteria, User Group criteria, Web

Filtering criteria, etc.

Operator (Filter)

All, Contains, Does Not Contain, Equals, Matches, etc.

Operand (Value)

Application name, Boolean, Category, IP, String, Wildcard, etc.

As discussed, each rule has three main elements. The first is criteria. This defines the conditions
that trigger the rule. The criteria consist of Property, Operator, and Operand.

The Property defines the criteria type or category, such as User Group criteria, Web Filtering
criteria, Media Type criteria, and so on.

The Operator and Operand work together to define the expression to apply. The Operator acts
as a filter and links an operand to the property. Some example Operators are All, Contains, Does
not contain, Equals, and Matches.

The Operand represents a specific value. Some examples are Application name, Boolean,
Category, IP, IP range, String, and Wildcard.

25
 Operators
Properties are Directly Affected by the Operators Used

Operator Properties

equals value (number, URL, client IP)

matches wildcard expression

is in range single range

is in range list list of ranges

is in list list (IP, string, IPRange)

at least one in list list (category, MediaType)

contains single element (Category, MediaType)

greater than Number

The properties you can choose are directly affected by the type of operator you use. Most have
the mirrored pair (greater than, less than) so make sure you choose the correct operator for
what you are trying to build with your policy.

Take special care with the at least one in list, all in list, and is in list operators.

One is in list means that one of the properties (usually URL Categories) is in the list you choose
in the properties.

If a site has three categories, only one needs to match the properties for that Rule to be fired. All
in list would mean all three of the Website Categories must matched for the rule be applied.

Is in list is for properties that can be matched exactly (IP address, string) and looks for the exact
match in the list.

26
 Rule Elements: Actions
Response or Behavior

Continue

Block
Remove

Action? Redirect

Stop Cycle
Authenticate

Stop Rule Set

The Action defines the response or behavior to execute when a rule is triggered; for example,
Continue, Block, Redirect, Authenticate, Stop Rule Set, Stop Cycle, and Remove.

The most used actions are Block and Stop.

27
 Rule Elements: Event
Optional. These can typically set areas like headers, user defined properties
logging entries and counters

Events (Optional)
Additional activities that
can be performed if the Statistics. Counter. Increment – Name of the event
rule criteria is met.
“BlockedByURLFilter, 1” – Parameters of the event

<Default> - Settings of the event

Header.ICAP.Response.Add– Name of the event

“URL_Filter”, “Block” – Parameters of the event

Finally, the last rule element is an Event. Events are optional. Events are additional activities that
can be added to a rule. Event activities will be performed if the criteria is met.

28
 Rule Cycles
Choose Cycles Best Suited for Activities
Filter network user requests:
If request or response has an  Allow/Block list
embedded object:  Anti-malware scanning
 Anti-malware scanning  Authentication
 Inspection of request or  Client-sent header
response body  DLP filtering
 Media type filtering  Media type uploads
 URL filtering
 URL category filtering

Filter network user response:

 Anti-malware scanning
 Server-sent header
 Media type downloads

The filtering process on the appliance has three cycles. A rule set can have one or a
combination of cycles
• The request cycle is performed for filtering user requests sent to the web.
• The response cycle is for responses to the user requests.
• The embedded objects cycle is an additional cycle of processing when requests or
responses embedded objects.

Choose cycles best suited for the rule activities. Some guidelines are:
• Request cycle:
• Anti-malware scanning
• Authentication
• Blacklist/whitelist, client-sent header, and URL filtering
• Response cycle:
• Anti-malware scanning
• Media type, server-sent header, and whitelist filtering
• Embedded objects cycle:
• Anti-malware scanning
• Inspection of request or response body
• Media type filtering

29
 Rule Processing
Top-down Hierarchy

 Rules are processed in the order they are

listed

 Processing continues until there is a

match or until all implemented rules have
been processed

 Traffic not specifically denied is allowed

The rule sets themselves are processed in the order of the rule set system, which is shown on
the Rule Sets tab of the user interface.

In each of the three cycles, the implemented rule sets are looked up one after another to see
which must be processed in this cycle. When a rule is processed and found to apply, it triggers
an action. Processing also stops after all implemented rules have been processed.

30
 Nested Rule Sets
Rule Sets with Other Rule Sets within Them
• Each nested rule set has its own criteria.
• Allows you to configure a nested rule to address one cycle and another rule for a
different cycle.

Media Type Filtering Rule

Set:
Requests, responses  Top level rule set for request,
and embedded objects responses and embedded
objects

 Nested Rule Set 1 for requests

Nested Rule Set 2:  Nested Rule Set 2 for responses

Nested Rule Set 1:
Media Type and embedded objects
Media Type Upload
Download

Rule sets can have other rule sets nested within them. A nested rule set has its own criteria.
Regarding cycles, it can only be processed in the cycles of the nesting rule set but need not be
processed in all of them. This way you can configure one nested rule set to address a particular
cycle and configure another nested rule set to address a different cycle.

As an example, a media type filtering rule set might apply to all cycles but include nested rule
sets that are not processed in all of them.

• Top-level rule set: Media Type Filtering for requests, responses, and embedded
objects
• Nested Rule Set: Media Type Upload for requests
• Nested rule set: Media Type Download for responses and embedded objects

31
 How Lists and Rules Interwork
Retrieve Information about Web Objects and Users
• Define common values once and then re-use
them in multiple rules
• For example, rather than embed list of domains
in the rule. Reference a list of domains
• When changes are required, update the list
instead of individual rules

Web security rules on Web Gateway use several types of lists for retrieving information about
web objects and users. The main list types are:
• Custom lists: Can have entries in string, number, category, and other formats.
• System lists (read-only): Display on the lower branch of the lists tree on the Lists tab
and include category, media type, and application name lists, as well as lists of
connectors used for cloud single sign-on. They are updated when an upgrade to a
new version of Web Gateway is performed.
• Inline lists: Editable but they do not appear on the Lists tab. They appear inline as part
of the settings for a configuration item; for example, a list of HTTP ports as part of the
proxy settings.
• Subscribed lists: Define content retrieved from a subscribed data source. Subscribed
lists display in the lists tree at the end of the custom lists. There are two subtypes of
subscribed lists: Skyhigh-maintained and Customer-maintained.
• External lists: Reside on external sources under their own names. They have their
content transferred to Web Gateway, where they provide the value of a property in a
rule.
• Map type lists: Store pairs of keys and values that are mapped to each other. You can
create map type lists and include list entries on Web Gateway or retrieve entries as
subscribed or external lists from other sources.
• Common Catalog lists: Pushed from a Trellix ePO server to Web Gateway. Type of
entries are IP address, domain name, string, and wildcard expression format. They are
maintained on the Trellix ePO server.

32
 Rule Set Permissions
Select the permissions tab

Grant or Restrict Access

 Read and write permission

 Read-only permission

 No permission

As the administrator, you can grant or restrict access to rules, rule sets, and lists. Your options
are Read and write permission, Read-only permission, and No permission.

33
 Best Practices
Grouping, Naming Convention, and Search

Group rule sets by functionality.

• Use a consistent naming schedule; for example, include the filtering type in
the name (Media Type filtering, Antimalware filtering, URL filtering, and so on).
• We can use a search to find rule names, rule contents, list names, list contents
and comments.
• Ensure rules reference the list and include a comment to allow easy search.
• Use the import and export features to simplify management; for example,
reuse and backup.

Group rule sets by functionality. This allows you to define exceptions that can be set for each of
the types of filtering.

Use a consistent naming schedule. A best practice is to name the rule set using its filtering type;
for example: Media Type filtering Antimalware filtering, URL filtering, and so on.

In addition, ensure rules reference the list and include a comment for search purposes.

Finally, use the import and export features to simplify management. Import allows you to an
item import from the library. Export allows to save an item for reuse, as well as serve as a
backup.

34
 Best Practices (Continued)
Use Expensive Properties at End of Filtering Process

Low Medium High

• Client.IP, Proxy.IP, • Media.EnsuredTypes • Antimalware.Infected
Proxy.Port • Authentication • Data Loss Prevention
• Check HTTP header • Composite opener filtering
• System.Hostname • URL.Destination.IP • HTML Opener
• URL, URL.Categories,
URL.Host

Expensive properties are those that require a huge processing effort. Use expensive properties
at the end of the filtering process. Some guidelines are:
• Low:
• Client.IP, Proxy.IP, or Proxy.Port properties
• Properties to check HTTP header information
• System.Hostname property
• URL, URL.Categories, or URL.Host properties
• Medium:
• Media.EnsuredTypes property
• Properties used for authentication
• Properties that use the composite opener
• URL.Destination.IP property
• High:
• Antimalware.Infected property
• Properties used in Data Loss Prevention (DLP) filtering
• Properties that use the HTML Opener

35
Knowledge Check

36
Check your Learning
Multiple choice: Choose the correct answer.

Which of the following is not an action?

A. Allow
B. Block
C. Continue
D. Stop Rule Set

Answer: A. Allow. See Rule Elements: Actions.

37
Check your Learning
Multiple choice: Choose the correct answer.

Rules are processed in the order they are listed in the rule set
list.

A. True
B. False

Answer: A. True. See Rule Cycles.

38
 Review

 Rules are processed in the order they are listed. Processing continues until there is a
match or until all implemented rules have been processed.
 Group rule sets by functionality.
 Access control (limiting administrator privileges) is applied to rule sets not
individual rules.
 Rule sets can have nested rule sets for more granular control.
 Perform filtering activities in best suited cycles.
 Use expensive properties at the end of the filtering process.
 Use lists for commonly used values to improve the efficiency of rule creation and
management.

• Rules are processed in the order they are listed. Processing continues until there is a match
or until all implemented rules have been processed.
• Group rule sets by functionality.
• Access control (limiting administrator privileges) is applied to rule sets not individual rules.
• Rule sets can have nested rule sets for more granular control.
• Perform filtering activities in best suited cycles.
• Use expensive properties at the end of the filtering process.
• Use lists for commonly used values to improve the efficiency of rule creation and
management.

39
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

40
Module 7: Rule, Rule Set, and List
Configuration

1
 Module 8 Objectives

 Create a rule.
 Create a rule set.
 Import a rule set.
 Create a list.
 Add list entries.
 Configure rules and rule sets.

• Create a rule.
• Create a rule set.
• Import a rule set.
• Create a list.
• Add list entries.
• Configure rules and rule sets.

2
 Review: Filtering Traffic

SWG
Request Response

Request and Response and

Client Web Servers
embedded objects embedded objects

The SWG filters web traffic:

• Requests
• Responses
• Embedded objects

As a review, the purpose of the web gateway is to filter web traffic. This includes requests sent
from the client to the web server, responses sent from the web server to the client, and any
embedded objects that were included in the client request or the web server response.

3
 Review: Transactions (Request-Response)

SWG

Makes a request Provides a response

Client Web Servers

Request
Transaction – All of the
cycles that are needed Embedded
Object
to complete a client’s (optional)
request.
Response
Cycles
Embedded
Object
(optional)

Log

When a client makes a request, the request enters the web gateway and becomes a
transaction. The definition of a transaction is all the cycles that are needed to complete a
client’s request.

Cycle types include the client’s request, any embedded objects sent with the request, the
server’s response, any embedded objects sent with the response, and a final log cycle.

4
 Review: Cycles

Cycle Includes
Cycles
Request HTTP, HTTPS, FTP, IM
Request Response HTTP, HTTPS, FTP
Embedded Embedded Java and Visual Basic scripts,
Object
(optional) Objects (if sent ActiveX controls, graphics and
Response with request or compressed files
response)
Embedded
Object
Log Automatically occurs after each
(optional) transaction
Log

The table provides additional information on the transaction cycles.

A request cycle includes HTTP, HTTPS, FTP, and instant messaging requests from a client.
• A response cycle includes HTTP, HTTPS, and FTP responses from a server.
• An embedded object cycle includes Java and Visual Basic scripts, ActiveX controls,
graphics, and compressed files that are sent as part of a client request or part of a server
response.
• The last cycle is a log cycle. A log cycle occurs automatically after each transaction.

5
 Review: How Rules Work

1 Request
No Does this rule apply
response
to the cycle type?
embedded
Yes object
Skip the rules. Go to 2
Always apply this
the next rule set in the
rule set? Yes
list. Go to the rules. Use
No the rules in the rule
3 set to filter the web
Has the predefined object.
criteria been met? Yes
No

When traffic enters the SWG and passes through the rule sets, three configuration options
within a rule set determine if the traffic is filtered by the rule set’s rules or if the rule set is
skipped. These configuration options are shown in this flowchart.

The first configuration option is cycle type. The traffic is first analyzed to determine if its type;
request, response, or embedded object, is enabled in the rule set. If the cycle type is not
enabled, the rule set will be skipped. If the cycle type is enabled, the second configuration
option will be considered.

The second configuration option is to always apply this rule set. If this is enabled, the traffic will
be filtered by the rule set rules without any further analysis. If this option is not enabled, the
third configuration option will be considered.

The third configuration option is predefined criteria. If the traffic meets the predefined criteria,
the traffic will be filtered by the rule set rules. If the traffic does not meet the predefined
criteria, the rule set will be skipped.

6
 Default Rule Sets with Preconfigured Rules
Modify Defaults or Create Your Own

Default Rule Set

You can’t undo the action once a rule is

unlocked and changes are saved.

Web Gateway includes default rule sets with preconfigured rules. By default, the rule set rules
are displayed in a simplified view. The simplified view can be changed to a full view by clicking
Unlock View. A warning alerts warning alert you there is no undo if you unlock the rule.

7
 Enabling and Disabling Rule Sets
You can enable or disable these rule sets for on-premise and for cloud use, move,
copy, and delete them, modify their rules, import rule sets from a built-in or an
online library, and create rule sets of your own.

You can enable or disable these rule sets for on-premise and for cloud use, move, copy, and
delete them, modify their rules, import rule sets from a built-in or an online library, and create
rule sets of your own.

By enabling or disabling a rule set, you enable or disable all rules inside it.

1. Select Policy > Rule Sets.

2. On the rule sets tree, navigate to the rule set you want to enable and select it. A view of the
rule set is shown in the configuration pane.
3. Click Enable and/or Enable in cloud, to make this rule set available.
4. Click Save Changes.

8
 Rule Design Overview
Define Relationships to Visualize Policy Requirements

Blocked IP
Blocked Range:
Client IP 10.10.10.170- Block
Range 10.10.10.175

Allowed IP
Allowed Range:
IP
Client IP 10.10.10.50- Stop Rule Set
Restrictions
Range 10.10.10.220

Block All
All Block
(Catch all)

When designing rules, your first step is to define the relationships between rule sets, rules, and
criteria. This helps you visualize your requirements.

Understand that the order of rules is vital. In this example, we configure Web Gateway to
restrict clients by IP address range.

Blocked IP Range:
10.10.10.170 - 10.10.10.175

Allowed IP Range:
10.10.10.50 – 10.10.10.220

9
 Example Rule Construction
Custom Rule Set and Rule
• Build custom rule set and rules.
• Use meaningful naming conventions to identify purpose and facilitate future
searches.
• Use lists to save configuration and management time.

Custom Rule Set and Rule Settings

Rule Set: IP Applies to: Request Cycle
Restrictions Apply: Always
Rule 1: Blocked Client Criteria: Client.IP is in range list
IP Range Action: Block
Rule 2: Allowed Client Criteria: Client.IP is in range list
IP Range Action: Stop Rule Set
Rule 3: Block All Criteria: Always
Action: Block
Settings: URL Blocked

This example shows one way to build a new rule set. For training purposes, we will first delete
all rules so that all traffic is allowed. You can always re-import the default rules from the rule
set library.
Within this rule set, we will add three rules, one named Blocked Client IP Range, one named
Allowed Client IP Range, and a catch-all group named Block All. These names are for training
purposes. Use a naming scheme that is meaningful to you.
After saving the rules, we will configure the lists next. Remember, lists allow you to define
commonly used parameters once for reuse in multiple rules. This saves configuration and
management time.

10
 Deleting Default Policies
All Traffic Now Allowed

For training purposes, we will first delete all rules so that all traffic is allowed. You can import
the default rules from the rule set library.
From the Web Gateway interface, click the Policy icon on the menu bar to open the Policy
page. In the left page, select (highlight) all items in the tree. Right-click and select Delete.
When prompted, click Yes.
Our next step is to add a rule set.

11
 Adding Top Level Rule Set
IP Restrictions Rule Set

To add a top-level rule set:

1. At the top of the left pane, click Add and select Top Level Rule Set.
2. In the Name box, type IP Restrictions. Make sure Enable is selected (checked/ticked)
and that Enable in Cloud is de-selected (no check/tick).
3. In the Applies to section, make sure Requests (and IM) is selected. Disable (remove
check/tick) by the other options. Restricting the number of cycles, you apply to the
rule set, helps speed up the processing time.
4. In the Apply this rule set section, select Always. This ensures the rule set is applied
to all traffic.
5. Click OK and then click Save Changes.

12
 Adding Blocked Client IP Range Rule: Name and Rule Criteria
Example

6. Add a User/Group criteria.

13
 Adding Blocked Client IP Range Rule: Add Criteria
Selected Property, Selected Operator, and Compare with

Property Operand

Operators that apply to the select property

7. Beginning on the left side of the Add Criteria window:

• In the Selected Property list, select Client.IP.
• In the Selected Operator list, select is in range list.
• At the bottom of the Compare with list, click Add list of IP Range.

Continued on the next page.

14
 Adding Blocked Client IP Range Rule: Add List

8. In the Name box of the Add List window, type Blocked Client IP Range. Make sure the Type is
set to IPRange and then click OK.
9. Select the list and click Edit.
10. Define IP Range as 10.10.10.170-10.10.10.175.

15
 Adding Blocked Client IP Range Rule: Action
Block

11. Next, define the action you want performed when there is a match. In this example, we
want to block IP addresses. Remember, we are defining the list entries later.

You can also modify the Settings to send any number custom block pages to the user. In this
case we could have a custom block page just for the IP range user explaining why they cannot
access the web.

12. We do not need to define any events, so the configuration is complete. Click Finish.

13. Verify the rule displays on the page and then click Save Changes.

16
 Adding Allowed Client IP Range Rule: Name and Rule Criteria
Example

Within the IP Restrictions rule set, we will now add a rule named Allowed Client IP Range.

1. In the left pane, right-click on the IP Restrictions rule set and then select Add > Rule. In the
Name box, type Allowed Client IP Range. Make sure Enable rule is selected and then click
Next.

2. At the top of the Add Rule window, make sure If the following criteria is matched is
selected. Click Add, select User/Group criteria, and then Next.

17
 Adding Allowed Client IP Range Rule: Add Criteria
Selected Property, Selected Operator, and Compare with

3. Beginning on the left side of the Add Criteria window:

• In the Selected Property list, select Client.IP.
• In the Selected Operator list, select is in range list.
• At the bottom of the Compare with list, click Add list of IP Range.

4. In the Name box of the Add List window, type Allowed Client IP Range. Make sure the Type is
set to IPRange and then click OK.

5. The list we added now appears in the far-right pane. Click OK and then Save Changes.

18
 Adding Allowed Client IP Range Rule: Action
Stop Rule Set
• Stop Rule Set (Continue to other rule sets, if configured)
• Settings (optional)
• No events

6. Finally, define the action. For this rule, we want Stop Rule Set. This tells Web Gateway to
ignore any further rules in this rule set and continue to any other configured rule sets.
Because Events are not required, click Finish.

7. Verify the rule displays on the page and then click Save Changes.

19
 Adding Block All Rule: Name and Rule Criteria
Example
• Enable rule
• Always

Our final rule is a catch-all one named Block All.

1. In the left pane, right-click on the IP Restrictions rule set and then select Add > Rule. In the
Name box, type Block All. Make sure Enable rule is selected and then click Next.

2. An important difference from our previous rules is the action. At the top of the Add Rule
window, this time select Always.

20
 Adding Block All Rule: Action
Block
• Block
• Authorized only
• No Events

Like the other rules, you must define the action. For this rule, we want Block and Authorized only
which defines the block page used. The allowed IP addresses will never use this rule because
Web Gateway stops the rule set and bypasses this rule. Events are not required.

3. Verify the rule displays on the page and then click Save Changes.

As a reminder, rules are executed in the order they are listed. To change the order, use the
Move up or Move down options.

21
 Review: Lists
Define Commonly Used Values for Re-use in Multiple Rules
• Custom Lists
• Subscribed Lists
• System Lists

Note: Reuse lists in multiple rules with caution. Editing a list for one rule may have an
unintended impact on another rule.

Here is the Lists tab. Lists are referenced by both rule sets and rules. List categories include
Custom Lists, Subscribed Lists, Hybrid Lists, and System Lists. Custom lists are the only lists you
can modify.

22
 Example: List Management
Blacklist and Whitelist
Blocked Client IP Range
• IP range: 10.10.10.170-10.10.10.175
Allowed Client IP Range
• IP Range: 10.10.10.50-10.10.10.200

 Edit Allowed Client IP Range and Blocked Client IP Range rules to add list
entries. Be sure to save the changes.

 You can also manage lists from the Lists tab.

 Use Show referring objects options to identify policy use.

 You cannot delete a list referenced in a rule or rule set.

We will now define the lists to be used in the rules we just created. We can manage lists from
within the rules or from the Lists tab.

From the Lists tab, you can also identify its policy use.

• Right-click and select Show referring objects.

It is important to remember that you cannot delete a list referenced in a rule or rule set.

23
 Editing Blocked Client IP Range List
Add IP Address Range

The list is currently empty. Click the link to open the window for editing. Click + (plus sign), type
the IP address range in the dialog and then click OK. Review the list content and then click OK
again.

24
 Editing Allowed Client IP Range List
Add IP Address Range

The list is currently empty. Click the link to open the window for editing. Click + (plus sign), type
the IP address range in the dialog and then click OK. Review the list content and then click OK
again.

25
 Importing Rule Set from Rule Set Library
Web Gateway’s Rule Set library has many rule sets available which can be
imported and modified.

Solve conflicts by referring to

existing objects or by copying and
renaming as suggested.

You can also import rule set from

an xml file Secure Web Gateway
for On Premise Appliances specific
format.

The built-in and online libraries provide rule sets for importing into your rule set system.

You can import a rule set, for example, to add a function that is missing in your system or
when the default rule sets do not suit your network.

The built-in rule set library also contains the rule sets that are part of the default rule set
system.

More rule sets are available from an online rule set library. A link to this library is provided in
the window of the standard rule set library.

In the built-in rule set library, rule sets are grouped in categories, for example, authentication
or URL filtering.

26
Knowledge Check

27
Check your Learning
Multiple choice: Choose the correct answer.

Which list type(s) are editable in the Web Gateway user

interface? Select all that apply.

A. Custom Lists
B. Subscribed Lists
C. Skyhigh Maintained Lists

Answer: A. Custom Lists. See Review: Lists.

28
Check your Learning
Multiple choice: Choose the correct answer.

Which element determines rule matching?

A. Action
B. Criteria
C. Events

Answer: B. Criteria. See Review: How Rules Work.

29
 Review

 You can manage lists from within the rule or on the Lists tab.
 By enabling or disabling a rule set, you enable or disable all rules inside it.
 You can import rule sets from the Rule Set Library at any time.
 Optionally restrict access to rule sets, lists, or settings.
 There are multiple ways to create the same rule. Web Gateway supports flexibility to
meet your unique needs.

• You can manage lists from within the rule or on the Lists tab.
• By enabling or disabling a rule set, you enable or disable all rules inside it.
• You can import rule sets from the Rule Set Library at any time.
• Optionally restrict access to rule sets, lists, or settings.
• There are multiple ways to create the same rule. Web Gateway supports flexibility to meet
your unique needs.

30
 Lab Exercises
Lab 7: Rules and Rule Set Configuration

 Goals:
 Configure proxy settings
 Configure a basic rule set

 Duration:
 35 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete
the lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

31
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

32
Module 8: Global Threat Intelligence and URL
Filtering

1
 Module 8 Objectives

 Describe the functionality that Global Threat

Intelligence gives to Web Gateway.
 Identify the URL categories that Web Gateway
uses.
 Create a custom URL category list using
wildcards.
 Configure a web policy using URL categories,
geolocation, and wildcard lists

• Describe the functionality that Global Threat Intelligence gives to Web Gateway.
• Identify the URL categories that Web Gateway uses.
• Create a custom URL category list using wildcards.
• Configure a web policy using URL categories, geolocation, and wildcard lists

2
 URL Filtering Overview
Key Components
• Global Threat Intelligence (GTI)
• Gateway Anti-Malware Engine
• URL Filter Engine
• Rule Construction
• Dynamic Content Classifier

The slide highlights the key topic discussed in this module.

3
 GTI Overview
Real-Time Categorization, Location, and Reputation Services
• Cloud-based database with
information correlated to
produce threat intelligence

• Bidirectional communication
between GTI and participating
Trellix/Skyhigh products

• Trellix/Skyhigh products
integrated with GTI

GTI is best described as three-part framework.

• At the top in the cloud there is the threat data correlated to produce threat
intelligence. The data comes from multiple sources, primarily queries from the millions
of Trellix products acting as sensors that are deployed in real-world settings around
the globe. With each query, the cloud system learns something new about the subject
of the query. This information is combined with data from other threat vectors to
better understand cyber-threats from all angles and to identify threat relationships,
such as malware used in network intrusions, websites embedded in malware code,
websites hosting malware, botnet associations, and more.

• The middle tier represents the bidirectional communications that occurs between
various Trellix & Skyhigh products and GTI. Products query the cloud, and our cloud
renders the latest reputation or categorization intelligence to the products so that
they can act.

4
 GTI Overview (Continued)
Review: Telemetry (Feedback) Settings

The Telemetry settings are used for configuring the collection of feedback data about web
objects that are potentially malicious, as well as about policy configuration. To access the
Telemetry page:

1. Click the Configuration icon on the menu bar to open the Configuration page.

2. At the top of the left pane, make sure the Appliances tab is selected.

3. In the left pane, expand Appliances and click Telemetry. The Telemetry page opens in
the right pane.

5
 Some Ways SWG Uses GTI
Categorization, or category-based URL filtering based on URL
Categorization mapping to defined URL categories, such as Pornography,
Auction, Business, Shopping or Sports

GTI File and Web Reputation technologies provides access to

Reputation an online cloud database containing classification details to
determine if the content is malicious

Behavioral heuristics by combining rule-based and weight-

Heuristic Scanning based methodologies to estimate a program’s behavior or
functionality at runtime.

Geographic visibility and policy management based on the

Geolocation
web traffic’s origination

Point-and-click control for nearly 1,000 web applications and

Application Mapping
granular function control within those applications.

• Categorization
• Categorization, or category-based URL filtering, is a primary way to prevent user
access of dangerous sites. Categorization consist of a few basic components: a
database of URLs, a category scheme for classifying content, and a rules engine for
applying corporate policy to control who can view certain content on the Internet.
• Reputation
• GTI File and Web Reputation provides you with always-on, real-time protection that
safeguards and secures you from emerging threats. GTI File and Web Reputation
technologies provides access to an online cloud database containing classification
details to determine the content is malicious.
• Heuristic Scanning
• The Anti-Malware engine employs behavioral heuristics by combining rule-based and
weight-based methodologies. This enables the engine to estimate a program’s
behavior or functionality at runtime.
• Geolocation
• Geolocation refers to the physical location of hosted web sites. This feature provides
geographic visibility and policy management based on the web traffic’s origination.
• Application Mapping
• Leverage Web Gateway to extend your security policy to web applications. With point-
and-click control for nearly 1,000 web applications and granular function control
within those applications.

6
GTI Categorisation
• You can lookup the category and
reputation of any url at
https://sitelookup.mcafee.com/
• At this site you can also report
possible errors for review
• You can overwrite any category for
your policy in the url filter engine
used at Policy>Settings>URL
Filter><urlfilterused>>Extended List

7
Access to GTI
 GTI is a Cloud Based Databased storing Intelligence
 Only a proportion of this database is synchronised to the on prem SWG
appliance
 You should configure your engines to use the local copy and query the cloud if
local finds no result.
 In an environment where you have no direct internet access then you can
configure a proxy to reach the cloud GTI
 In a pure air gapped environment then you should switch off cloud GTI look ups
as you will experience performance problems otherwise.

8
Access to GTI
 Access to GTI is important in SWG
particularly for Gateway Anti
Malware and URL Filters.
 If the SWG does not have direct
internet access then a proxy for GTI
access can be configured in the URL
filter engine
 A default rule Set URL Filter Settings
to be Used by Other Filters should
be placed at or near the top of your
policy.
 This rule sets GTI setting in particular
for Gateway Antimalware.
 If air-gapped and NO proxy is used
then you should disable GTI access
to prevent performance problems.

9
GTI uses in Gateway Anti-
Malware

10
 Gateway Anti-Malware Engine Overview
Proactive Detection
• Antivirus prescan
• Light-pass on common web files, low risk
files and trustworthy sites
• Global Threat Intelligence (GTI) file
reputation
• Heuristic scanning
• Gateway Antimalware's ability to defend
against zero-day advanced malware is
greatly enhanced with the availability of
online GTI queries.

The Gateway Anti-Malware engine is configured from the Policy page (Policy > Settings >
Engines > Anti-Malware > Gateway Anti-Malware). To ensure a higher level of web security, it
uses proactive methods to detect new viruses and malware, including antivirus prescan, light-
pass on common web files, low risk files and trustworthy sites, GTI file reputation queries and
heuristic scanning.

11
 Configuring Gateway Anti-Malware Engine
Default Settings

Policy > Settings > Engines > Anti-Malware > Gateway Anti-Malware

Note: Only If operating in an air-gapped environment without access to online GTI

queries should you select the Allow local-only lookups in air-gapped environment
option.

Web Gateway is preconfigured for GTI; however, you can adjust the configuration, as necessary.
To view these settings, complete these steps from the Web Gateway interface:
1. Click the Policy icon on the toolbar to open the Policy page.
2. At the top of the left pane, click the Settings tab.
3. In the left pane, expand Engines and Anti-Malware and then click Gateway Anti-
Malware.
4. Scroll to the Advanced Settings section. Two important GTI settings here are listed
below. Both are enabled by default.
• Provide GTI web and file reputation queries to Gateway Anti-malware: Online
GTI web reputation and categorization services need to be enabled for the AV
filter by using rule Common Rules > Set URL Filter Internal Settings > Set URL
Filter Settings to be used by other Filters using a URL filter settings object
where GTI lookups are not disabled. Otherwise, this option will have no effect.
• Enable heuristic scanning: Enabled by default. When enabled, Web Gateway
applies heuristic scanning methods to web objects.

12
URL Filtering

13
 URL Filter Engine Overview
Default and Special Settings for GTI Categorization and Reputation
• Search and rating of embedded URLs
• Forward DNS lookup to rate URLs
• Backward DNS lookup for unrated IP-based URLs
• Settings for default server used for GTI services
• Dynamic Content Classifier
• Advanced settings, such as cloud errors and
invalid URLs

The URL Filter module is also known as the URL Filter engine. It retrieves information on URL
categories and reputation scores from the GTI service. Based on this information, blocking rules
block access to URLs.

Various technologies, such as link crawlers, security forensics, honeypot networks, sophisticated
auto-rating tools, and customer logs are used to gather this information. An international, multi-
lingual team of analysts evaluate the information and enters URLs under particular categories
into a database.

To gather information on the reputation of a URL, its behavior on a worldwide real-time basis is
analyzed, for example, where a URL shows up in the web, its domain behavior, and other details.

You can configure settings for this module, for example, to let it include category information
retrieved from an extended list that you provide or to perform a DNS lookup for URLs and include
the corresponding IP address in the search for category information.

14
 Configuring Default URL Filter Engine

Other important GTI settings are addressed in the URL Filter section. From the Policy page,
Settings tab:
1. In the left pane within the Engines section, expand URL Filter and then click Default.
2. In the right pane, scroll to the Ratings Settings section. Important GTI settings here
are listed below:
• Disable local GTI database: Enabled or disable. This is disabled by
default.
• Use online GTI web reputation and categorization services if local rating
yields no result: Enabled or disable. It is disabled by default. When
enabled, information on URL categories and reputation scores is
retrieved from GTI only if the search in the internal database yielded no
results.
• Use default server for online GTI web reputation and categorization
services: by default. When enabled, you can define a different server.

Another important feature that works with GTI is the Dynamic Content Classifier, which is
discussed later in this module. This feature applies only when the database and online GTI web
categorization lookups yield no result.

15
 Configuring Dynamic Content Classifier (DCC)
When GTI Web Categorization Yields No Result

 Pornography category
selected by default.

 Select other categories to

enable them (optional).

Dynamic classification is used when other methods do not return results for a website.
Pornography is blocked by default. Optionally, you can enable other supported categories.

From the Policy page:

1. Click the Settings tab:
2. In the left pane within Engines > URL Filter, click Default.
3. In the right pane, scroll to the Ratings Settings section.
4. Make sure the Enable the Dynamic Content Classifier if GTI web categorization yields
no result option is enabled.
5. In the Categories that will be dynamically detected table, notice Pornography is
selected by default.
6. To select other categories, click the pencil icon and then expand the Supported
Categories list.
7. Click (check/tick) the box by a category to select it. Remove the check/tick by a
category to de-select it.
8. Click OK.
9. Verify the categories that you want to use are listed on the page.
10. Click Save Changes.

16
 GTI Properties Used for Rule Construction in URL Filters

 URL.Categories

 URL.IsHighRisk

 URL.IsMediumRisk

 URL.IsMinimalRisk

 URL.IsUnverified

 URL.Geolocation

Web Category Criteria options include:

• URL.Categories: Match requests access to a specific category.

• URL.IsHighRisk: Match high risk URLs.
• URL.IsMediumRisk: Match medium risk URLs.
• URL.IsMinimalRisk: Match minimal risk URLs.
• URL.IsUnverified: Match unverified risk URLs.
• URL.Geolocation Returns the Geolocation the site is hosted in

17
 Other Properties Used for Rule Construction in URL filters
URL/Host Criteria (Destination)  URL.Parameters

 URL.Destination.IP

 URL.File.Extension

 URL.Host

 URL.Host.BelongsToDomains(List
of String)

 URL.HostIsIP

 URL.Parameters

 URL.Path

 URL.Port

 URL.Protocol

URL/Host Criteria options are for the host destination. They include:

• URL.Parameters
• URL.Destination.IP
• URL.File.Extension
• URL.FilerName
• URL.Geolocation
• URL.Host
• URL.Host.Belongs
ToDomains(List of String)
• URL.HostIsIP
• URL.Parameters
• URL.Path
• URL.Port
• URL.Protocol

18
 Default URL Filter Rule Sets and Rules
Available in Rule Set Library

URL Filtering by • URL Filtering by Category rules

Category • Web Category Filtering rules

• Special URL Filtering Group rules

URL Filtering
• Default rules

• Bypass (disabled)
Geolocation • Geolocation – Lookup Country Codes
• Geolocation – Blocked Countries

Dynamic • Allow Uncategorized URLs

Content • Block Uncategorized URLs (disabled)
Classification • Block URLs Whose Country is in Category Blacklist

Note URL Filters tend to be very deployment specific. Default rulesets can be used as a starting
point to build custom solutions.

Now that we have reviewed some basics, let’s take a closer look at the basic types of URL
filtering rules. Remember, if you deleted these rule sets, you can always import them from the
Rule Set Library.

19
 Default URL Filtering by Category Rule Set
Whitelist/Blocklist and Category-based Filtering

This rule set includes these default rules:

• Allow URLs that Match in URL WhiteList: If a given URL is on the specified whitelist, rules
processing stops. The blocking rules that follow whitelisting rule are not processed.
• Block URLs that Match in URL BlockList: If a given URL is on the specified blocking list, rules
processing stops. The access request is not passed on to the web server. The rule also uses
an event to count blocking due to virus and malware infections.
• Enable SafeSearchEnforcer: This is an additional module for filtering access to web sites with
adult content. The enabling is done by executing an event.
• Allow Uncategorized URLs: Uses the List.OfCategory.IsEmpty property, which has the
URL.Categories property as a parameter, to check whether the list of categories for
categorizing a URL is empty.
• Block URLs whose category is in URL Category BlockList: Uses the URL.Categories property to
check whether one of the categories a given URL belongs to is on the specified blocking list.
The URL Filter module, which is called to retrieve information on these categories, runs with
the Default settings, as specified with the property.
• Block URLs with Bad Reputation: Uses the URL.IsHighRisk property to find out whether a URL
has a reputation that lets access to it appear as a high risk. If the value for this property is
true, processing of all rules stops and the request for access to the URL is not passed on to
the appropriate web server.

20
 Default Web Category Filtering Rules
Predefined Categories with Block Everything Else Catch-All

The Web Category Filtering group includes rules mapped to predefined categories. Access is
allowed or blocked by category; for example: Allow URLS Whose Category is in List Social
Networks, Instant Messaging Categories, General Use Categories, Personal Use Categories, and
so on. At the end, there is a catch-all Block Everything Else rule.

21
 Default Geolocation Rule Set
ISO 3166 2 Alphanumeric Country Codes

See www.iso.org/iso/english_country_names_and_code_elements

The Geolocation rule set includes these rules:

• Bypass (disabled): Uses List.OfCategory.IsEmpty property.

• Geolocation: Performs lookup using URL.Geolocation<Default> property.
• Geolocation: Blocked Countries: Uses arbitrary list of blocked countries entered in ISO
3166 notation format. For more information, see
www.iso.org/iso/english_country_names_and_code_elements.

22
 Default Dynamic Content Classification (DCC) Rules
Based on DCC Analysis

Detects URL categories when other methods yield no results

The Dynamic Content Classification rule set contains these rules:

• Allow Uncategorized URLs

• Block Uncategorized URLs
• Block URLs Whose Category is in Category Blocklist

Remember, the Dynamic Content Classifier detects URL categories when other methods of
detection yield no results.

23
 Use Cases
 Block access to sites categorized as having Pornography/Nudity and
Mature/Violent content
 Deny all users except those in specific IP range (IT machines) from sites
categorized as Risk/Fraud/Crime
 Deny access to specific sites and subdomains: npr.org, cnn.com, or
foxnews.com

How would you implement these policies?

What are some other use cases?

As we bring it all together, let us look at some use cases. How would you implement these
policies? Remember, there are different ways to implement the same policy.

24
 Use Case 1
Block access to sites categorized as having Pornography/Nudity and
Mature/Violent content.
• Add a rule to block the listed URL categories.

In the first use case, we block access to sites categorized with pornography or violent content.

25
 Use Case 2
Deny all users except those in
specific IP range (IT machines)
from sites categorized as
Risk/Fraud/Crime
• Add a rule to block access to
listed URL Categories and if
Client IP is not in the range of
allowed IPs.

In the second use case, we want to deny all users except for a specific IP range, to be allows to
access risk/fraud/crime related sites.

26
 Use Case 3
Deny access to specific sites and subdomains: npr.org, cnn.com, or foxnews.com.
• Add a rule to block the URLs listed.

In the third use case, we can deny access to specific sites and subdomains.

27
Knowledge Check

28
Check your Learning
Multiple choice: Choose the correct answer.

Which Global Threat Intelligence feature does Web Gateway

leverage for a cloud-based lookup of the origination of web
traffic?

A. Categorization Service
B. Dynamic Content Classifier
C. Geolocation Lookup
D. Reputation Matching

Answer: C. Geolocation. See Some Ways Web Gateway Uses GTI.

29
Check your Learning
Multiple choice: Choose the correct answer.

When a connection matches the default Block URLs that match

in URL BlockList rule, which action is applied?

A. Bypass is applied and processing continues

B. Processing stops and access is blocked.
C. URL Filter module retrieves GTI Reputation score.

Set.
Answer: B. Processing stops and access is blocked. See Default URL Filtering by Category Rule

30
 Review

 The GTI Gateway Engine and URL Filter Engine are preconfigured by default;
however, you can modify the defaults, as necessary.
 GTI relies on online queries. A proxy can be configured in the URL Filter Engine.
 Dynamic classification is used when other methods do not return results for a
website. Pornography is blocked by default. Optionally, you can enable other
supported categories.
 Some ways Web Gateway uses GTI are Categorization, Reputation, Application
Mapping, Heuristic Scanning, and Geolocation.
 Web Gateway provides default rule sets and rules that you can use as a starting
point; however, you can also create your own.

The GTI Gateway Engine and URL Filter Engine are preconfigured by default; however, you can
modify the defaults, as necessary.
Dynamic classification is used when other methods do not return results for a website.
Pornography is blocked by default. Optionally, you can enable other supported categories.
Some ways Web Gateway uses GTI are Categorization, Reputation, Application Mapping,
Heuristic Scanning, and Geolocation.
Web Gateway provides default rule sets and rules that you can use as a starting point; however,
you can also create your own.

31
 Lab Exercises
Lab 8: GTI and URL Filtering

 Goals:
 Filter by URL
 Filter by subscribe list

 Duration:
 30 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

32
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

33
Module 9: Media Type Filtering and Data Loss
Prevention

1
 Module 9 Objectives

 Configure Media Type Filtering

 Explain the basic Web Gateway features for
document inspection and archive handling.
 Identify Dictionaries and Classifications
supported in SWG
 Create DLP rules using built in Web Gateway
dictionaries

 Configure Media Type Filtering

 Explain the basic Web Gateway features for document inspection and archive handling.
 Identify Dictionaries and Classifications supported in SWG
 Create DLP rules using built in Web Gateway dictionaries

2
Media Type Filtering

3
 Media Type Filtering Overview
Block Upload/ Download Based on Media Type
• Specific Types
• Undetected
• Unsupported
• Multimedia
• Streaming

Filters 700+ online media types, including

video, PDFs and Torrent files

This slide highlights one of the key topics discussed in this module.

4
 Media Type Filtering Overview (Continued)
Example Media Types
• Organized logically such as Documents
• Further divided by subtypes

The figures shows some types of media files for Documents. Notice there are subtypes within
the list. You can also use media types to prevent users from uploading content to websites; for
example: archived or encrypted files, corporate documents, or Other sensitive document types

5
 Some Ways Web Gateway Controls Media Access

Upload media Blocks upload of media based on defined media type criteria.
type rule Processed in request cycle.

Download media Blocks download of media based on defined media type criteria.
type rule Processed in response cycle.

Media type and Included in rules for matching. Includes Custom Lists, String or
other lists Wildcards, and System Lists.

Inspects and extracts web content that can be opened.

Enable opener rule Processed in separate embedded cycle. Always initiated unless
cycle stops before its reached.

The media type filtering process includes several elements, which contribute to it in different
ways.

• Upload media type rule: This nested rule set blocks the upload of media belonging to
particular media types. It is processed in request cycles when users request to upload media
to the web, as well as in embedded object cycles when objects are embedded in media.

• Download media type rule: This nested rule set blocks the download of media belonging to
particular media types. It is processed in response cycles when web servers send media in
response to user requests for downloading them, as well as in embedded object cycles when
objects are embedded in media.

• List types: Rules use different list types for matching. These include System lists, String or
Wildcard Lists, and System lists.

• Enable Opener rule: When enabled it inspects web content for data that can be opened. If
data is found it extracts the data and run a separate embedded cycle for the data. Without
this event, no archived or embedded data will ever be examined. This rule type is included in
the Common Rules set. It is enabled by default.

6
 Rule Construction
Key Elements
Media Type Criteria:
• Ensured
• Not ensured
• Composite
Media Type Lists:
• Custom Lists (editable)
• String or Wildcards
• System Lists (read-only)

Basic key elements for rules are Media Types properties and blocking lists. A blocking list is used
by a rule to block access to media that belong to particular types. Commonly used blocking list
types includes:

• Custom Lists (editable)

• String or Wildcards
• System Lists (read-only)

7
 Rule Construction: Media Type Criteria
Policy > Rule Sets > Rule Set Tab View (New Media Type Rule Set/Rule)

High probability of detection (>50%)

Archive or Microsoft Office file

Low probability of detection (<50%)

Commonly used media type criteria are:

• MediaType.EnsuredTypes: Media with a high probability of detection (greater than 50%). This
level of probability is assumed if a media type signature from an internal list on the appliance
can be found in the object code of the media.
• MediaType.Is.CompositeObject: Property of media type that is archive or Microsoft Office file.
• MediaType.NotEnsuredTypes: Media with a low probability of detection (less than 50%).

Other criteria types include:

• MediaType.FromFileExtension: Property of media for which types are assumed based on the
extensions of the media type file names. Extensions and the media types associated with
them are looked up in an internal catalog on the appliance. There are, however, extensions
that are used by more than one media type.
• MediaType.FromHeader: Property of media for which types are assumed according to the
content type field of the headers sent with the media. Headers are read and evaluated in a
standardized format. To filter headers in their original formats, you can use the Header.Get
property.
• List.OfMediaType.IsEmpty: Property of media with types that are not on an internal list.
• User Defined Property: Custom property and list content.

8
 Rule Construction: Media Type Lists
Custom, Wildcard Expression, and System

System Lists

The figure shows the types of lists used in rules. Remember, Custom Lists are editable, but
System Lists are read-only. You manage lists from the Lists tab on the Policy page or by clicking
a links in the rule.

9
 Default Enable Opener Rule
Opens Jobs for Examination

Import
Import rulerule
set
set
from from
library.
library

The Enable Opener rule set is the default rule set for handling file opening on Web Gateway.

The key elements of the Enable Opener rule set include settings for file opening and several
block options.

Key elements of the Enable Opener rule:

• Composite Opener settings
• Clicking Edit makes the Composite Opener settings available for editing.
• Block encrypted media types
• When selected, a rule is enabled that blocks encrypted media types.
• Block multipart media types
• When selected, a rule is enabled that blocks multipart media types.
• Block corrupted media types
• When selected, a rule is enabled that blocks corrupted media types.

10
 Default Media Type Filtering Rule Set
Block Upload Rules

Media type filtering ensures that the users of your network can only access media belonging to
types that are allowed under your web security policy. For example, access to streaming media
might not be allowed because it consumes too many resources.

The default Media Type Filtering rule set includes upload and download rules.

11
 Default Media Type Filtering Rule Set
Block Download Rules

There can be a blocking list for media that should not be uploaded from within your network to
the web, as well as one for media that should not be downloaded from the web to your network.

12
Data Loss Prevention

13
 Data Loss Prevention (DLP) Overview
Engines Included with Web Gateway
• Data loss prevention rules control the process.

• Default classifications and dictionary entries

identify sensitive content.

• Also used to prevent inappropriate content

from entering network; however, this can Select, add, and
impact performance. define
parameters.

DLP ensures that sensitive content is not allowed to leave your network. The prevention process
detects this content and blocks traffic going out to the web accordingly.

The following elements are involved in this process:

• Data loss prevention rules that control the process.
• Default classifications and a dictionary that you fill with entries for data loss
prevention.
• Data loss prevention modules, which are called by the rules that are processed to find
out about sensitive content.

You can also use data loss prevention rules to keep inappropriate content from entering your
network; however, this can have an impact on performance.

The data loss prevention process can be applied to text contained in the body that is sent with a
request or response or to any other text that is contained in requests or responses, for example,
URL parameters or headers.

When you are running the appliance together with a DLP solution that uses an ICAP server for
the filtering process, you can implement a rule set to ensure the smooth flow of data between
the appliance and the ICAP server.

Note: Basic Data Loss Prevention (DLP) functionality is included with the base Web Gateway
license.

14
 Adding DLP Classifications
Policy > Settings > Engines > Data Loss Prevention (Classifications)

Select classification, such as acceptable

use, country-based policies, industry and
government regulatory compliance, etc.

Classification parameters include:

• Tracking Policy: Controls if the DLP filter will keep looking through the file after the first
match. Minimum means the DLP will stop inspecting the document after the first
match. Maximum will continue searching through the file. Maximum WILL cause a
performance hit but will give you an accurate count of total DLP matches.

• DLP Classifications: Allows you to select the classifications you wish to look for from the
pre-generated groups. You can select individual classification (like HIPAA Compliance
– Credit Cards) or a larger group (HIPAA).

• Reported Context Width: How much data around the matched term is included in the
logging. By default, the matched term is surrounded by brackets [ ]. The default is 30
characters.

• Context List Size: Maximum number of entries that are stored in the *.MatchedTerms
properties for use in logging or other reporting.

15
 Adding DLP Dictionary Entries
Policy > Settings > Engines > Data Loss Prevention (Dictionaries)

Text Entry Regex Wildcard Entry

Dictionary entries are a created list of text or wildcard expressions. It is recommended that you
use regular expression (regex) statements when using wildcards for quicker processing. It is
quicker and more efficient to perform a regular expression search than a wildcard match.

16
 Default DLP Rule Sets and Rules
Available in Rule Set Library

• Imported from
Rule Set Library

• Full view

Import the Data Loss Prevention rule set from the library. Review its rules and modify them as
needed; for example:

• Configure settings for data loss prevention using default classifications.

• Configure settings for data loss prevention using dictionary entries.
• Modify other settings parameters.
• Create rules of your own.

Make sure the Composite Opener is enabled so the body text sent with requests and responses
is inspected. In the default rule set system, this rule is contained in the Enable Opener rule set,
which is nested in the Common Rules rule set.

If you want to run data loss prevention with the Internet Content Adaptation Protocol (ICAP), you
can import another rule set from the library and modify its rules as needed.

After completing the configuration, be sure to save your changes.

17
 Use Cases

 Block download of executables (.exe) from all sites except mcafee.com.

 Block upload of files with payment card industry (PCI) information.

 Block upload of files with Sarbanes-Oxley (SOX) information.

How would you implement these policies?

What are some other use cases?

As we bring it all together, let us look at some use cases. How would you implement these
policies? Remember, there are different ways to implement the same policy.

18
 Use Case 1
Block download of executables (.exe) from all sites except mcafee.com.

In this first use case, we are looking to block the download of executables from all sites except
certain ones.

19
 Use Case 2
Block upload of files with payment card industry (PCI) information.

The second use case involves blocking the upload of files with PCI information.

20
 Use Case 3
Block upload of files with Sarbanes-Oxley (SOX) information.

Our third use case blocks uploading files that contain SOX information.

21
Knowledge Check

22
Check your Learning
True - False

You can use wildcards for matching.

A. True
B. False

Answer: A. True. See Rule Construction: Media Type Criteria.

23
Check your Learning
Multiple choice: Choose the correct answer.

Which criteria is used to match a list of MIME types detected by

signatures with a high probability of detection (more than
50%)?

A. MediaType.EnsuredTypes
B. MediaType.FromFileExtension
C. MediaType.NotEnsuredTypes

Answer: A. MediaType.EnsuredTypes. See Rule Construction: Media Type Criteria.

24
Check Your Learning
Multiple choice: Choose the correct answer.

FILL IN THE BLANK: The job of the

____________________________ is to detect sensitive
or inappropriate content in the body text of requests and
responses and in any other text that is sent with requests and
responses.

A. data loss prevention modules

B. DLP Web Prevent engines
C. classification dictionaries

Answer: A. data loss prevention modules. See Data Loss Prevention in the Product Guide.

25
 Review

 Media Type filtering rules block upload/download of content based on media type.
 Blocked lists types are Custom Lists, String or Wildcards, and System Lists (read-
only).
 Make sure the composite opener is enabled and placed before media type or
malware filtering rules.
 Enforce on appropriate cycles; for example: Upload = Requests/Embedded Objects,
Downloads = Responses/Embedded Objects.
 SWG – DLP; Data loss prevention (DLP) ensures that sensitive content is not allowed
to leave your network.

• Media Type filtering rules block upload/download of content based on media type.
• Blocked lists types are Custom Lists, String or Wildcards, and System Lists (read-only).
• Make sure the composite opener is enabled and placed before media type or malware
filtering rules.
• Enforce on appropriate cycles; for example: Upload = Requests/Embedded Objects,
Downloads = Responses/Embedded Objects.
• SWG – DLP; Data loss prevention (DLP) ensures that sensitive content is not allowed to leave
your network.

26
 Lab Exercises
Lab 9: Media Type Filtering

 Goals:
 Filter download by media type

 Duration:
 30 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

27
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

28
Module 10: Malware Scanning

1
 Module 10 Objectives

 Recall the purpose and functionality of the

anti-malware engines.
 Configure a rule to apply virus scanning to
specific web page content.
 Configure anti-malware engine settings.

• Recall the purpose and functionality of the anti-malware engines.

• Configure a rule to apply virus scanning to specific web page content.
• Configure anti-malware engine settings.

2
 Malware Filtering Overview
Block Infected/Malicious Sites

Engine Settings

Rule Construction

Media Stream Scanning

Anti-malware Queue

The slide highlights the key components discussed in this module.

3
 Anti-Malware Scanning Engines and Behavior
Policy > Settings > Engines > Anti-Malware > Gateway Anti-Malware

Full
coverage

Advanced
Threat Layered
Defense coverage
only
Scanning
Engines

Duplicate
Avira only
coverage

Web Gateway supports the following anti-malware engine configurations:

• Full coverage: The recommended high-performance configuration. When selected, the
Gateway Anti-Malware engine and the Trellix Anti-Malware engine are active. The scanning
mode is then Proactive methods + virus signatures. This module combination is enabled by
default.
• Layered coverage: Full coverage plus specific Avira engine features (minor performance
impact). When selected, the Gateway Anti-Malware engine, the Trellix Anti-Malware engine,
and, for some web objects, also the third-party Avira engine are active. The scanning mode is
then Proactive methods + virus signatures + third-party module functions for some web
objects. For more information about Avira, go to www.avira.com.
• Duplicate coverage: Full coverage and Avira engine. This configuration provides less
performance and more false positives. When selected, the Gateway Anti-Malware engine,
the Trellix Anti-Malware engine, and the third-party Avira engine are active. The scanning
mode is then Proactive methods + virus signatures + third-party module functions.
• Avira only: Only uses Avira engine. This configuration is not recommended. When selected,
only the Avira engine is active. The scanning mode is then Third-party module functions.
• Advanced Threat Defense only: Send files to ATD appliance for deep analysis through
sandboxing. Requires ATD add-on license. ATD installed and deployed separately.

4
 Configuring Mobile Code Behavior
Policy > Settings > Engines > Anti Malware > Gateway Anti-Malware

• Classification Threshold from 60 to 100.

• Low = Higher proactivity but potentially more false positives.
• High = Better accuracy but potentially more false negatives.

The Mobile Code Behavior settings define the risk level in classifying mobile code. The risk level
can take values from 60 to 100.

A low value means the risk in proactively scanning the behavior of mobile code and not
detecting that it is malware is low because the scanning methods are applied very strictly.
Mobile code will then be classified as malware even if only a few criteria of being potentially
malicious have been detected. This can lead to classifying mobile code as malware that is not
malicious (false positives). While more proactive security is achieved with a stricter setting,
accuracy in determining which mobile code is malicious will suffer. Consequently, the appliance
might block web objects that you want to get through to your users.

A high value means the risk in not detecting malicious mobile code is high (more false
negatives), but more accuracy is achieved in classifying mobile code correctly as malicious or
not (fewer false positives).

5
 Configuring Advanced Settings
Policy > Settings > Engines > Anti Malware > Gateway Anti-Malware

 Enable Antivirus prescan (Recommended)

 Increase Web Gateway performance by making light-
weight pass. (Default is Common Web files and other low-
risk files)
 Enable GTI file reputation queries. (Enabled. Discussed
earlier.)
 Enable heuristic scanning. (Enabled. Discussed earlier.)
 Custom AV scan timeout settings.

Advanced Settings include:

• Enable Antivirus prescan. When selected, performance of the submodules is improved

by reducing the load sent to them for scanning. Enabled by default and
recommended.
• Increase Web Gateway performance by making light pass on. Common Web files and
other low-risk files selected by default. You can select one of them to configure the
range of file types that light-weight malware scanning should be applied to.
• Provide GTI web and file reputation queries to Gateway Anti-Malware. Enable GTI file
reputation queries (discussed earlier). Enabled by default. When selected, information
on the reputation of files retrieved from the Global Threat Intelligence (GTI) system is
included in the scanning result.
• Enable heuristic scanning (discussed earlier). Enabled by default. When selected,
heuristic scanning methods are applied to web objects.

6
 Configuring Gateway Anti-Malware Settings
Policy > Settings > Engines > Anti Malware > Gateway Anti-Malware

 Enable detection for potentially unwanted programs. (Disabled)

 Enable mobile code scanning. (Enabled)
 Enable removal of disinfected content detected in HTML documents by mobile
code filter. (Disabled)

Advanced Settings for Gateway Anti-Malware options are shown in the figure.
• Enable detection for potentially unwanted programs. When selected, web objects are
also scanned for potentially unwanted programs.
• Enable mobile code scanning. When selected, mobile code is scanned in general.
Individual settings can be configured under Scan the following mobile code types.
• Enable removal of disinfected content detected in HTML documents by mobile code
filter.

Continued on the next page.

7
 Configuring Advanced Settings for Avira
Policy > Settings > Engines > Anti Malware > Gateway Anti-Malware

 Limits size (in MB) of member in archive that

Avira engine scans for infections.
 When threshold is exceeded, member is not
scanned, and archive blocked.
 Default 1024 MB.

The Advanced Settings for Avira section is used to limits the size (in MB) of a member in an
archive that the Avira engine scans for infections. If an archive member exceeds this size, it is
not scanned, and the archive is blocked. The default size limit is 1024 MB.

8
 Configuring Custom Anti-Malware Engine
Specific Traffic Types, Authentication, and GTI Lookups

Policy > Settings > Engines > Anti-

Malware > Gateway Anti-Malware

Optionally, you can create a custom new Anti-Malware engine with different settings, such as
layered coverage and a lower classification threshold. This gives you the flexibility to use a
different engine for specific traffic type, as well as for authentication and Global Threat
Intelligence (GTI) Lookups.

9
 Rule Construction Overview
Key Elements

Blocklists and Whitelists:

• User Agent, URL Host, and so on

Scanning Options:
• Remove partial content for HTTP requests (scan complete HTTP/HTTPs files)
• Block partial content for FTP requests
• Use the Media Stream Scanner

Gateway Anti-Malware Settings:

• Enable Anti-Malware scanning

Quarantine Settings:
• Enable to quarantine virus into file based on IP ranges
• IP ranges to include

Blocklists and Whitelists

Control access using lists, such as User Agent, URL Host, and so on.
Scanning Options
• Remove partial content for HTTP requests: When selected, a rule is enabled that
removes the specification in an HTTP or HTTPS request for accessing only a part of the
content of a web object and lets the request ask for the complete content. If a web
object, for example, a file, is delivered completely by the web server in question, it can
also be scanned completely on Web Gateway. A complete scan can detect infections
that might not be noticed if only a part of the web object was scanned.
• Block partial content for FTP requests: When selected, a rule is enabled that blocks FTP
requests for access to only a part of the content of a web object. Under the FTP
protocol, it is not possible to remove a specification in a request for access to only a
part of the content of a web object. For this reason, it might be advisable to block such
requests.
• Use the Media Stream Scanner: When selected, the Media Stream Scanner scans and
delivers web objects that are streaming media chunk-by-chunk to speed up the
process. The proactive functions of the Gateway Anti-Malware engine are used for the
scanning. The other engines that are available for this purpose on Web Gateway are
not involved.
Continued on the next page.

10
Gateway Anti-Malware Scanning
 Enable Anti-Malware scanning: When selected, a rule is enabled that calls the Anti-
Malware Module, which scans web objects for infections by viruses and other malware.
Quarantine Settings
 Enable to quarantine virus into file based on IP ranges.
 IP ranges to include.

11
 Rule Construction (Continued)
Anti-Malware Criteria

 Antimalware.Infected (commonly used to

detect malware)
 ATD (Requires add-on license. ATD
acquired/ deployed separately.)

 Avira (Avira acquired/deployed

separately.)

 User Defined

Main property for activating the

Malware engines.

A commonly used property is Antimalware.Infected. This is a simple true/false property. If web

traffic is infected with malware, then block.

Scanning traffic for malware is expensive in terms of processor and memory usage. It is
recommended to try to minimize the amount of traffic the Antimalware.Infected property
checks.

There is a special Virus Found block page that contains the name of the virus, where the virus
was found, and the filename was that contained the file. This, like all block pages is editable and
can have different administrative contact information.

Other base Anti-Malware Criteria options:

• Antimalware.Infected
• Antimalware.Proactive.Probability
• Antimalware.VersionString
• Antimalware.VirusNames

Continued on the next page.

12
Advanced Threat Defense (ATD) options are:
• Antimalware.MATD.GETReport
• Antimalware.MATD.InitBackgroundScan(Number)
• Antimalware.MATD.IsBackgroundScan
• Antimalware.MATD.Hash
• Antimalware.MATD.Probability
• Antimalware.MATD.Report
• Antimalware.MATD.Server
• Antimalware.MATD.TaskID
• Antimalware.MATD.VersionString

An Avira option is Antimalware.Avira.VersionString. In addition, User Defined Properties are also

supported.

13
 Rule Construction (Continued)
Operators and Comparison Values

 Equals/Does not equal

 True/False
 Value

Simple true/false property.

Notice this is a simple true/false property.

14
 Default URL Filter Rule Sets and Rules
Gateway Anti-Malware • Allow if User Agent Matches User
Agent Whitelist
• Allow URL Host that Match Anti-
Malware Whitelist
• Remove Partial Content for HTTP(s)
Requests
• Block Partial Content for FTP
Gateway Anti-Malware Requests

• Start Media Stream Scanner on

Streaming Media and Skip Anti-
Malware Scanning
• Bypass Based on Size (200MB)
• Anti-Malware: Quarantine IPRange
• Block if Virus was Found

Now that we have reviewed some basics, let’s take a closer look at the malware filtering rules.
Remember, if you deleted these rule sets, you could always import them from the Rule Set
Library. The first rule set type is Gateway Anti-Malware, which is available with the standard Web
Gateway license.

15
 Default URL Filter Rule Sets and Rules (Continued)
Advanced Threat Defense (ATD)

 Upload File to MATD and Wait for Scanning Result

MATD – Handle Offline  Offline Scanning with Immediate File Availability
Scan
 Stop cycle

 Re-use Existing Report, if Possible

MATD – Initial Offline
Scan  Only Send Media types with High Probability
 Offline Scanning with Immediate File Availability

 Enable Progress Page

Advanced Threat
Defense  Only Send Media Types with High Probability
 Upload File to MATD and Wait for Scanning Result

Other rule sets include MATD – Handle Offline Scan, MATD – Initial Offline Scan, and Advanced
Threat Defense. Although these rule sets are present in the Rule Set Library, they do not work
without ATD. ATD is purchased and deployed separately. In addition, the add-on license for Web
Gateway is required.

16
 Default Gateway Anti-Malware Rules
Allow/Block and Scan to Detect Viruses and Other Malware

This rule set has the following rules:

• Allow if User Agent Matches User Agent Whitelist: Uses Header.Request.Get property.
• Allow URL Hosts That Matches in List Anti-Malware URL Host Whitelist: Uses URL.Host
property.
• Remove Partial Content for HTTP(s) Requests: Uses Cycle.Top.Name and
Connection.Protocol properties.
• Block Partial Content for FTP Requests: Uses Cycle.Top.Name and Connection.Protocol
properties.
• Start Media Stream Scanner on Streaming Media and Skip Anti-Malware Scanning:
Uses Cycle.Name and StreamDetector.IsMedia properties.
• Bypass Based on Size (200MB): Uses StringToNumber, Cycle.Name, and Body.Size
properties.
• Anti-Malware: Quarantine IPRange: Uses Client.IP and Antimalware.Infected properties.
• Block if Virus was Found: Uses Antimalware.Infected property.

17
 Use Cases
1. Use custom Anti-Malware Engine:
• Name: Antimalware-80 w/Avira
• Coverage: Layered
• Classification threshold: 80
2. Bypass scanning for youtube.com, hulu.com. and netflix.com.
3. Bypass scanning for media in Anti-Malware Category Whitelist including
Streaming Media, Internet Radio, Web Phone and General news or 10.10.10.0/24
subnet.

How would you implement these policies?

What are some other use cases?

As we bring it all together, let us look at some use cases. How would you implement these
policies? Remember, there are different ways to implement the same policy.

18
 Use Case 1
Use custom Anti-Malware Engine
• Name: Antimalware-80 w/Avira
• Coverage: Layered
• Classification threshold: 80

In the first use case, we will create our own instance of the settings for the Anti-Malware module
and use them in anti-malware filtering rules.

19
 Use Case 2
Bypass scanning for youtube.com, hulu.com and Netflix.com

In the second use case, we will create a whitelist to exclude web objects from further anti-
malware filtering.

When administering the anti-malware filtering process, we can create URL lists of hosts and use
this list to exclude requests with particular URLs from further anti-malware filtering.

Note: The list is empty by default and will need to be filled in with your chosen entries.

20
 Use Case 3
Bypass scanning for media in Anti-Malware Category Whitelist including
Streaming Media, Internet Radio, Web Phone and General news or 10.10.10.0/24
subnet.

In the third use case, we will create a whitelist to bypass scanning for Internet Radio / TV,
Streaming Media, General News and Web Phones.

You can maintain lists of media types, which are used by the rules in the rule set for allowing
and blocking access to particular media types.

21
Knowledge Check

22
Check your Learning
Multiple choice: Choose the correct answer.

Which Gateway Anti-Malware scanning engine is typically

enabled by default?

A. Full coverage
B. Layered coverage (Full coverage plus specific Avira
features)
C. Duplicate coverage Full coverage plus all Avira engine)
D. Avira only

Answer: A. Full coverage. See Anti-Malware Scanning Engines and Behavior.

23
Check your Learning
True - False

When configuring mobile code behavior, the lower the setting

the higher proactivity; however, there are potentially more false
positives.

A. True
B. False

Answer: A. True. See Configuring Mobile Code Behavior.

24
Check your Learning
Multiple choice: Choose the correct answer.

Which property checks for malware?

A. URL.Infected
B. Website.Bad
C. Antimalware.Infected
D. Antimalware.Check

Answer: C. Antimalware.Infected. See Rule Construction.

25
 Review

 Filtering rules control the process.

 Whitelists are used to let some web objects skip virus and malware filtering.
 The Anti-Malware engine, which is called by a particular rule, scans web objects for
infections by viruses and other malware. Bypass Scanning is also supported.
 Web Gateway supports various anti-malware engine configurations, including Full
coverage, Layered, Duplicate, Avira only, Advanced Threat Defense only, and
custom. Full coverage is the default.
 Web Gateway includes default rule sets and rules but supports custom ones.
 A commonly used property in rules is Antimalware.Infected. It is a simple true/false
property.

• Filtering rules control the process.

• Whitelists are used to let some web objects skip virus and malware filtering.
• The Anti-Malware engine, which is called by a particular rule, scans web objects for infections
by viruses and other malware. Bypass Scanning is also supported.
• Web Gateway supports various anti-malware engine configurations, including Full coverage,
Layered, Duplicate, Avira only, Advanced Threat Defense only, and custom. Full coverage is
the default.
• Web Gateway includes default rule sets and rules but supports custom ones.
• A commonly used property in rules is Antimalware.Infected. It is a simple true/false property.

26
 Lab Exercises
Lab 10: Malware Scanning

 Goals:
 Block the downloading of material that contains malware

 Duration:
 30 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

27
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

28
Module 11: Authentication and Account
Management

1
 Module 11 Objectives

 Explain how authentication is injected into

rules.
 Define the authentication cycle.
 List authentication protocols Web Gateway
supports.
 Configure authentication rules to meet
customer requirements.
 Identify default administrator roles.
 Add and assign roles.
 Add an administrator account.
 Manage external accounts.

• Explain how authentication is injected into rules.

• Define the authentication cycle.
• List authentication protocols Web Gateway supports.
• Configure authentication rules to meet customer requirements.
• Identify default administrator roles.
• Add and assign roles.
• Add an administrator account.
• Manage external accounts.

2
 Authentication Overview

Authentication
Deny Failure
Authenticated=No
Client Request Deny connection
Browser

Authentication
Success

Authenticated=Yes
Allow Connection
Web Gateway
Request
Authentication
Rule Set | Rules
Engines | Methods Web
Server

The Web Gateway can be configured to authenticate requests before users are allowed to
access specific web sites.

Authentication is configured by creating an authentication rule set and authentication rules. An

authentication engine is used to specify the authentication method.

If the authentication fails, the user is denied access to the site. If the authentication passes, the
user is allowed access to the site.

3
 Configuration Overview
Workflow

Step Description
Configure Authentication engine. (Method Web
1 Gateway authenticates a session)
• Policy > Settings > Engines
Configure authentication rule set
2 • Apply to Requests (and IM)
• Configure criteria

Configure authentication rules

3
• Select authentication method in criteria
• Configure action

Here are the high-level steps to configure the Web Gateway for authentication.
1. The first step is to configure the method that will be used to authenticate the user.
Authentication methods are configured from the Settings tab of the Policy page
under Engines.
2. Next, create a rule set that applies only to requests. Configure the rule set with the
criteria that has been recommended for authentication.
3. Finally, create rules for authentication. Authentication methods are selected when
configuring the rule criteria.

4
 Authentication Engine Overview
Policy > Settings > Engines >Authentication

Authentication methods are configured from the Settings tab of the Policy page, under the
Authentication engine.

After an installation, User database is the only authentication method that is configured by
default under the Authentication engine.

The additional authentication methods that can be configured include NTLM, NTLM-Agent, LDAP,
Novell eDirectory, Radius, Kerberos, SSL Client Certificate, Authentication server, One Time
Password, and SWPS. See the next page for an explanation of each method.

Note: You can use multiple authentication methods; for example, use different methods based
on properties (client IP, hostname, URLs).

5
 Authentication Engine Overview
Methods

Method Authenticates Using…

Default. There is only one User Database list. You cannot add
User Database
any additional Local User Lists.
NTLM Database on a Windows domain controller (NT LAN Manager).
NTLM-Agent External agent on a Window-based system.
Database on Lightweight Directory Access Protocol (LDAP)
server.
LDAP Note: A hash value is calculated for the shared secret and
additional parameters on the client and transmitted to Web
Gateway. To configure Secure LDAP (LDAPS), use LDAP version 3.
Novell eDirectory Directory on a server taking the role of an LDAP server.

The table explains the authentication methods available from the authentication drop-down
menu.

Note: There is only one User Database list on the Web Gateway. You cannot add any additional
Local User Lists. The list contains usernames, passwords and group memberships.

Continued on the next page.

6
 Authentication Engine Overview (Continued)
Some authentication methods require configuration of settings for the appliance system;
Additional Methods for example, NTLM and Kerberos.

Method Authenticates Using…

Database on Remote Authentication Dial-In User Service
Radius
(RADIUS) server.
Kerberos Database on a Kerberos server.
SSL client Certificate sent by client in Secure Socket Layer (SSL)-secured
certificate communication.
Uses an external Authentication Server in combination with
Authentication other authentication mechanisms. This is typically used for
server Transparent Proxies or for SAML Authentication with an
external Identity Provider.
One Time
One Time Password server. (EOL)
Password

SWPS Client Proxy Authentication

Using System Settings to Configure Authentication

For some authentication methods, you must configure settings that are not settings of the
Authentication module, but of the appliance system.

This applies when you are implementing NTLM as the authentication method. In this case, you
need to join the appliance to a Windows domain and configure the Windows Domain
Membership settings, which are system settings. It applies also for the Kerberos authentication
method, which is implemented using the Kerberos Administration system settings.

7
 Configuring Authentication Method
Address Common and Specific Settings

There is more than one way to add a new authentication method. You can either click Add from
the Settings tab, or as shown on this page, right-click on Authentication and select Add.

Type a name and select an authentication method from the drop-down menu. After selecting a
method, configuration settings for your selection appear. Modify the default settings, as
necessary. Click OK and Save Changes.

8
Configuring Kerberos

9
 Kerberos Configuration Workflow - I
Setup on Active Directory
1. Create Kerberos user with the following properties:
• The user cannot change the password
• The password never expires
• On the user account, you will want to enable the options for support of AES128 or AES256
for Kerberos Authentication

2. Create SPNs with the following syntax command:

• setspn -a HTTP/proxy.techlearn.edu svc-kerberos

3. Generate keytab file with the following syntax command:

• ktpass -princ HTTP/[email protected] -mapuser svc-kerberos –
pass ***** -ptype KRB5_NT_PRINCIPAL -out proxy.techlearn.edu.keytab

You can perform all of these steps using the Three Headed Dog tool.

1. Create Kerberos user with the following properties:

• The user cannot change the password.
• The password never expires.
• On the user account, you will want to enable the options for support of AES128
or AES256 for Kerberos Authentication.

2. Create SPNs with the following syntax command:

• setspn -a HTTP/proxy.mcafee.edu svc-kerberos

3. Generate keytab file with the following syntax command:

• ktpass -princ HTTP/[email protected] -mapuser svc-
kerberos –pass ***** -ptype KRB5_NT_PRINCIPAL -out
proxy.techlearn.edu.keytab

You can perform all of these steps using the Three Headed Dog tool.

10
 Kerberos Setup Tool
Three Headed Dog
• Setting up Kerberos can be tough from an
organizational standpoint as well as a
technical standpoint.
• The Three Headed Dog (THD) is here to simplify
the process by taking the guess work out of the
syntax.
• THD will use smart defaults and validate the
inputs to make sure you're on the right track.

A Kerberos setup tool has been created to make the setup process much easier -- it will provide
you with the commands to give to your Active Directory team.

11
 Kerberos Configuration Workflow – II
Setup on SWG GUI
1. Integrate SWG to Windows Domain.
• (Configuration > Appliances > [Appliance] > Windows Domain
Membership)

2. Upload Keytab file to all SWG appliances.

• (Configuration > Appliances > [Appliance] > Kerberos Administration)

3. Set up Kerberos authentication with NTLM fallback ruleset on Web Gateway on a

test environment.

4. Set up Kerberos SID to Group Name Mapping ruleset.

1. Integrate SWG to Windows Domain

• (Configuration > Appliances > [Appliance] > Windows Domain Membership)
2. Upload Keytab file to all SWG appliances
• (Configuration > Appliances > [Appliance] > Kerberos Administration)
3. Set up Kerberos authentication with NTLM fallback ruleset on Web Gateway on a test
environment
4. Set up Kerberos SID to Group Name Mapping ruleset

12
 Kerberos Configuration Workflow – III
SID to Group Name Mapping

• Groups Export is a feature intended for deployments where the Web Gateway does not have
a connection to directory resources.
• With Kerberos, the ticket presented by the workstation includes the Group IDs (not Group
Names), so a directory connection is required to map or lookup the actual Group Names.
• With the Groups Export feature in THD, it can export a "Map" list of Group IDs to Group Names.
• This Map list can be used in the Web Gateway to substitute for a directory connection.

13
 Joining Appliance to Windows Domain
NT LAN Manager (NTLM) Authentication
• Required for NTLM authentication method.
• An appliance can be a member of multiple
domains.

Configuration > Appliance > Windows Domain

Membership

When using the NTLM authentication method, you need to join an appliance to a Windows
domain to let the authentication module retrieve user information stored on the domain server.
An appliance can be joined to more than one domain.

Select Configuration > Appliances. On the appliances tree, select the appliance you want to join
and click Windows Domain Membership. A list of domains appears on the settings pane. It is
initially empty.

Note: You may need to use FQDN for the domain controllers since it's more likely to properly
resolve (forward DNS > Hostname to IP) than the IP address (Reverse DNS -> IP to hostname) of
the Active Directory servers.

14
 Rule Construction: Rule Set
Framework for Authentication Rules

Because authentication occurs

on the initial connection, the rule
set typically applies only to the
request cycle. De-select the
other options to improve
processing efficiency.

Policy > Rule Sets > Rule Sets tab

view

Here we look at the framework to create an authentication rule set. This rule set will be the
container for the authentication rules.

To configure the authentication rule set:

1. Type a name.
2. In the Applies to section, make sure Requests (and IM) is selected and the other
options are de-selected. Because authentication occurs on the initial connection, the
rule set typically applies only to the request cycle. De-select the other options to
improve processing efficiency.
3. In Apply this rule set section, select If the following criteria is matched.
4. Last, click + (Add icon) and select User/Group criteria.

15
 Rule Construction: Criteria
Properties, Operators, and Operands

Operators vary, depending on

property; for example:
Authenticate.UserName versus
Authenticate. Authenticate.

Includes settings for the Authentication

engine, which specifies use of the
authentication method.

The rule criteria includes settings for the Authentication engine, which specify use of the
authentication method. This means information for authenticating users is retrieved from an
internal database on the appliance.

The Operator list varies, depending on selected property; for example, the
Authenticate.UserName property has more operator options than the Authenticate.Authenticate
property.

16
 Rule Construction: Multiple Authenticators
Authenticate with Kerberos with NTLM Fallback

Here we see a rule for multiple authenticators:

1. The 1st rule tests authentication with NTLM.

2. The 2nd rule tests authentication with Kerberos.
3. The 3rd rule will force the Web Gateway to reject any Negotiate request which
contains NTLM related tokens (TlRM). Internet Explorer specifically will attempt to use
Negotiate with NTLM tokens instead of NTLM with NTLM tokens (which results in
prompts). The event removes Kerberos as an authentication methods so the next
authentication attempt will not include Negotiate TIRM
4. The final authentication rule fires the Authenticate action which sends a 407
response to start the authentication process.

Note: The HTTPS URL can be blocked in HTTP-CONNECT method itself considering no Stop
Cycle for the HTTP-Connect request.

17
 Authentication Process
1st Unauthenticated Request

The 1st request is unauthenticated (no Proxy-Authorization header), which is normal.

Proxy sends a 407 response to client requiring user to authenticate himself.

3 headers are present in this example telling the client which authentication methods are
supported on this SWG.
• Negotiate (Kerberos)
• NTLM
• Basic (login / password sent in base64)

SWG adds those headers based on engines defined in rules.

18
 Authentication Overview
Kerberos Authentication
Client

KDC Web Server

SWG

Kerberos HTTP HTTP/S

AS
Traffic TGS Traffic Traffic
Browser
Client logs to machine (AS-
REQ)
1
AS sends TGT
2
Client sends HTTP request without authentication
information
3 Proxy sends a 407 requiring client to
authenticate
4
Client asks for a service
ticket for proxy service (TGS-
REQ)
5 TGS sends proxy
service ticket
6
Client sends HTTP request with Kerberos service ticket to User is authenticated, request
proxy is sent to server
7 Proxy forward response to Server sends requested
server page
8

Kerberos Authentication
1. Prior to accessing the proxy, the user logs into Windows and contacts the Authentication
Service (AS) for a Ticket Generating Ticket (TGT).
2. The AS sends back a TGT hashed with the client's secret key.
3. The user attempts to access a URL that requires authentication.
4. Client receives the HTTP response code 407 (proxy authentication) from the Web Gateway .
5. Client contacts the Ticket Generating Service (TGS) with his TGT and requests service ticket
for Web Gateway service.
6. The TGS verifies ticket is valid and issues a new Service Ticket with the client information
encrypted with the Web Gateway’s key.
7. The Client sends the Service Ticket to the Web Gateway for authentication. The Web
Gateway can decrypt it, verify the ticket, and see client identity. Request is sent to server.
8. Server sends response to client through proxy.

19
 Authentication Overview
NTLM Authentication
Client

AD Web Server
SWG

SMB HTTP/S
HTTP
Traffic Traffic
Browser Traffic

Client logs to his machine

1 Client sends HTTP request
without authentication
information
2
Proxy sends a 407 requiring
client to authenticate
3
Client sends HTTP request Proxy forwards
with NTLM_NEGOTIATE NTLM_NEGOTIATE
4
Proxy forwards NTLM_CHALLENGE AD sends NTLM_CHALLENGE
5
Client sends NTLM_AUTH as
response to challenge Proxy forwards NTLM_AUTH
6 AD confirms successful
authentication
7
User is authenticated, request is sent to server
Proxy forwards response to 8 Server sends requested
server page
9

NTLM Authentication
1. Prior to accessing the proxy, the user logs into the local domain.
2. The user attempts to access a URL that requires authentication.
3. The proxy sends a 407-challenging user for authentication.
4. The user sends a NTLM_NEGOTIATE message containing its Windows domain and username.
Proxy forwards information to AD.
5. The DC sends NTLM Challenge data to client through proxy.
6. The client sends NTLM response to AD through proxy.
7. AD confirms successful authentication to proxy, we now have a verified authenticated proxy
session.
8. Proxy sends requests to server.
9. Server sends response to client through proxy

20
 Transparent Authentication with Cookies

1. Client requests webpage.

2. Is Routed through Web Gateway.

4. HTTP Error Code: Redirect to Authentication 3. Checks for

4. HTTP Error Code: Redirect to
Server. session cookie.
AuthenticationServer.

5. Authentication – client stores a cookie.

6. Client redirected back to Web Gateway with

modified URL. 7. Checks session
cookie, sets
cookie for
8. Client makes original request again, with requested host,
and redirects to
proper cookies, and is allowed.
original page.

The figure shows an example of transparent authentication with cookies.

1. The client connects out to a website on port 80.
2. The connection is directed through the Web Gateway using WCCP, routed through a SWG in
transparent router mode or passes through a SWG in transparent bridge mode.
3. SWG checks to see if the connection has an authentication cookie set for that host, if it does
it will bypass the cookie authentication Rules and continue to the destination web server.
4. If it does not have a cookie, the SWG redirects the connection to the Authentication Server on
port 9090 with a special redirect URL.
5. At the authentication server, the client is authenticated with a 401 HTTP Response and a
session ID stored in a cookie.
6. Client is redirected back from the Authentication Server back to the original web page with
the additional information in the path.
7. Web Gateway sets a cookie for the specific host and after verifying the remaining rules
redirects the client to the original URL.
8. A normal connection takes 4 separate client connections to successfully connect to the
destination web site..

21
Web Gateway Account Management

22
 Account Management Overview
Accounts Page
Add/modify internal administrator accounts and roles.
Enable/configure external management of administrator accounts.
Default administrator account settings:
• Name: admin
• Password: webgateway
• Role: Super Administrator

Accounts Roles

The accounts page is used to add or modify internal administrator accounts and roles and
enable and configure external management of administrator accounts. Internal administrator
accounts are used to authorize access to the user interface. Multiple administrators can be
logged on to the Web Gateway simultaneously, provided each administrator is using a unique
account.

This page shows the internal administrator accounts and roles that are created by default
during installation.

23
 Default Administrator Roles
Assign Permissions to Internal Administrators

Super ePO Common Catalog

Administrator Administrator

Roles are used to assign permissions to internal administrators. Roles allow or deny access to
the top-level pages Dashboard, Policy, Configuration, Accounts, and Troubleshooting. The
figures show the settings of the default roles.

24
 Adding a Role
Internal Administrator Accounts Pane or Roles Pane

You may add a role from the internal administrator accounts pane or the roles pane. After
saving your changes you may be prompted to log out and then log back in again.

25
 Adding a Role (Continued)
Configuring Access

Enable
specific
policy
permissions

Enable REST
interface

Here we will see how roles allow or deny an administrator account access the top-level pages
of the user interface.

Access to the Dashboard, Configuration, Accounts, and Troubleshooting pages is either allowed
or denied by checking or not checking the box next to the page name.

Access to Policy page is more granular. An administrator account can be allowed or denied
access to the rules, lists, and settings. Additionally, the administrator account can be allowed or
denied the ability to create and move rules, create lists, and create settings.

26
 Adding an Administrator Account
Accounts Page

To add an administrator account, complete these steps from the Accounts page:
1. Click Add. An Add Administrator window opens.
2. Type the username.
3. Type and confirm the password.
4. Use the drop-down to select an existing role. Optionally, edit or add a role here.
5. Optionally, type a name.
6. Click OK.
7. Click Save Changes.

Once you have added an internal administrator account, you may test using the Test with
current settings pane on the right side of the page. Type in the administrator credentials;
username and password and then click the Test button. The results appear in the
authentication test results window.

27
 Configuring External Account Management
Authentication by External Server

We will now talk about external account management.

It is possible to have administrators authenticated by an external server.

To configure this feature, first enable administrator accounts are managed externally (LDAP,
NTLM, or Radius) or via SSL client certificates. Then configure the authentication server details.

To configure the authentication server details, first select the authentication method from the
drop-down list. The area will then populate with parameters specific to the authentication
method.

You may use role mapping to assign Web Gateway roles to groups or users authenticated by an
external server.

28
 Use Cases
1. Create a Log file Reviewer role.

2. Create a role to execute policy creation/retrieval requests to Web Gateway

over the REST interface.

3. Create a Management role.

How would you meet the requirements?

What are some other use cases?

As we bring it all together, let us look at some use cases. How would you implement these
policies? Remember, there are different ways to implement the same policy.

29
 Use Case 1
Create a Log file Reviewer role

In the first user case, we create a log file reviewer role. This is typically enabled to allow access
to the Troubleshooting tab to carry out troubleshooting measures.

30
 Use Case 2
Create a role to execute policy creation/retrieval requests to SWG over the REST
interface

In the second use case, we create a role that allows access to the REST Interface. This is
typically applied to roles that use of the REST interface for completing administration activities
on an appliance.

31
 Use Case 3
Create a User Role

In the third use case, creating a Manager role is often used when needing to allow access to
the Dashboard tab on the user interface.

32
Knowledge Check

33
Check your Learning
Multiple choice: Choose the correct answer.

Which of the following is the default authentication method?

A. User Database
B. NTLM
C. Kerberos
D. SSL Client Certificate

Answer: A. User Database. See Authentication Engine Overview.

34
Check your Learning
Multiple choice: Choose the correct answer.

Which of the following are the default roles available in Web

Gateway? (Choose two)

A. Super Administrator
B. ePO Common Catalog Administrator
C. Help Desk

Answer: A,B. See Account Management Overview.

35
 Review

 The User database authentication method is configured by default.

 You can use multiple authentication methods; for example, use different methods
based on properties (client IP, hostname, URLs).
 Some authentication methods require configuration of settings for the appliance
system; for example, NTLM and Kerberos.
 Roles allow or deny access to the top-level pages Dashboard, Policy, Configuration,
Accounts, and Troubleshooting.
 Two default roles are included: ePO Common Catalog Administrator and Super
Administrator.
 You can add new accounts and roles.
 It is possible to have administrators authenticated by an external server.

• The User database authentication method is configured by default.

• You can use multiple authentication methods; for example, use different methods based on
properties (client IP, hostname, URLs).
• Some authentication methods require configuration of settings for the appliance system; for
example, NTLM and Kerberos.
• Roles allow or deny access to the top-level pages Dashboard, Policy, Configuration,
Accounts, and Troubleshooting.
• Two default roles are included: ePO Common Catalog Administrator and Super Administrator.
• You can add new accounts and roles.
• It is possible to have administrators authenticated by an external server.

36
 Lab Exercises
Lab 11: Authentication and Account Mangement

 Goals:
 Enable Windows Domain Authentication (NTLM)
 Use windows domain groups to determine which sites users can
access
 Authenticate users using Kerberos
 Create a new administrator role

 Duration:
 45 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

37
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

38
Module 12: HTTPS Scanning

1
 Module 12 Objectives

 Explain the purpose of HTTPS scanning.

 Give examples of HTTPS scanning rules.
 Access and navigate through the HTTPS
scanning modules.
 Identify the purpose of the root certificate
authority.
 Describe ways to replace the root certificate
authority.
 Configure HTTPS scanning settings.
 Configure an HTTPS scanning rule.

• Explain the purpose of HTTPS scanning.

• Give examples of HTTPS scanning rules.
• Access and navigate through the HTTPS scanning modules.
• Identify the purpose of the root certificate authority.
• Describe ways to replace the root certificate authority.
• Configure HTTPS scanning settings.
• Configure an HTTPS scanning rule.

2
 HTTPS Overview
Key Components
• HTTPS Scanning Engines
• Certificate Authority (CA)
• HTTPS Scanning Rules
• Whitelist and Other Lists

The slide highlights the key components discussed in this module.

3
 HTTPS Scanning Overview: How It Works

Client

1. Encrypted using a certificate signed using

the Web Gateway.

2. Decrypt and inspect traffic.

https://gmail.com
3. Encrypted connection signed using Gmail
certificate.

You can configure the Web Gateway to present its own certificate when clients request a HTTPS
connection. This allows the Web Gateway to decrypt client traffic sent to itself, inspect it for
malware, keywords, Media Types and any other normal policy restriction and then re-encrypt
the traffic before sending it to the destination server. For this you need:

• A Certificate Authority must be configured or imported on the Web Gateway.

• The event “Enable SSL Client Context with CA” must be called.
• The event should be placed above all your existing rules in your policy.

This is technically a type of Man-in-the-middle attack where the Web Gateway is decrypting
the SSL stream, inspecting the traffic, then re-encrypting on the far side for the server. This
requires the client to trust the Web Gateway as a root CA, as it will be signing certificates for all
SSL connections it will be decrypting.

Note: You can bypass scanning of any type of traffic you want to remain encrypted; for example:
SSL VPN tunnels, connections to banking/financial sites, connections to partners and resellers.

4
 HTTPS Overview
HTTPS Through a Proxy

To better understand the HTTPS Scanner rule set, let’s look at what happens when internal client
makes HTTPS request to external web server.
In this example, no filters are in place and SWG will only be facilitating the connection.

1. First, the client establishes a connection to the proxy.

2. Once the connection is established, the client sends the ‘Client Hello’ message.
3. The Web Gateway passes that ‘Client Hello’ on to the external host, on behalf of the
client. The external host responds with a ‘Server Hello’, which the SWG forwards on to the
client.
4. As a part of the ‘Server Hello’ process, the external Web Server’s certificate is sent to the
client, along with a ‘Server Hello Done’ message.
5. The client sends along a client key, as well as Cipher Spec information.
6. The external server sends back its own Cipher Spec info to meet client’s requirements, the
tunnel is established.
7. Traffic can now be sent along to the external host inside of the encrypted tunnel.

5
 HTTPS Overview
SSL Inspection (Traffic allowed by policy)
1. The client sends encrypted traffic. The gateway intercepts the encrypted traffic and
decrypts it. It inspects the content based on its rule policy (Antivirus, Web Filtering, etc.)
2. If the gateway rule policy determines the traffic is allowed, it encrypts the content and
sends it to this destination.
3. The destination receives the encrypted content, decrypts it, encrypts a response and
sends it to the gateway.
4. The gateway receives the content, and the process starts all over throughout the
interaction between the client and the web server.

Here the SSL inspection is on the Web Gateway:

1. The gateway intercepts the encrypted traffic and decrypts it. The gateway inspects the
content based on its rule policy (Antivirus, Web Filtering, etc.)
2. If the gateway rule policy determines the traffic is allowed, it encrypts the content and sends
it to this destination.
3. The destination receives the encrypted content, decrypts it, encrypts a response and sends
it to the gateway.
4. The gateway receives the content and the prosses starts all over throughout the interaction
between the client and the web server.

6
 HTTPS Scanning Engines
Rules Call Engines for HTTPS Scanning Processes

• Default root CA that signs incoming Hypertext Transfer

SSL Client Context Protocol – Secure (HTTPS) client connections.
with CA • It is recommended to use your own.

• Default Certificate Verification settings: Certificate

verification (default) or SSL inspection.
SSL Scanner
• Enable Content Inspection: Certificate verification or SSL
inspection (default).

• List of known client certificates Web Gateway can send

SSL Client
web servers in SSL-secured communication. None listed
Certificate Handling
by default.

SSL Client Context • Settings to send certificates with no information about CA

without CA to clients.

HTTPS scanning rules call the following engines to perform HTTPS scanning process:

• SSL Client Context with CA: The SSL Client Context with CA (certificate authority) engine
settings defines how Web Gateway sends certificate information to clients. By default, a root
certificate authority included with Web Gateway; however, it is recommended that you
generate and use your own CA.

• SSL Scanner: This engine has two sub-engines: Default Certification Verification and Enable
Content Inspection. On the Default Certificate Verification page, Certificate verification is
enabled and configured by default. On the Enable Content Inspection page, SSL inspection is
enabled and configured by default.

• SSL Client Certificate Handling: Used to add a list of known client certificates that Web
Gateway can send web servers in SSL-secured communication.

• SSL Client Context without CA: The SSL Client Context without CA settings are used to
configure settings to send certificates with no information about the CA to the clients of a
Web Gateway appliance.

7
 Viewing Default Certificate Authority
Provided with Web Gateway

• Same certificate included with all

Web Gateways.

• Recommended to use your own.

CA details

Manage CA

Default

Policy > Settings > SSL Client Context with CA > Default CA

The Default CA page (Policy > Settings > SSL Client Context with CA > Default CA) displays
information about the current CA and is used to manage the CA, as well as enable or disable
the Send Certificate option, which is enabled by default.

It is recommended to replace the default root CA for signing certificates that the appliance
sends to its clients with your own. You can create a CA yourself and import from your file system.

Web Gateway provides a default root CA. This CA signs incoming HTTPS connections from
clients if the SSL scanner is enabled. Clients should not recognize this as a valid root certificate
authority by default and will present warning pages about the site being untrusted. To remove
these messages, it is recommended to create a new root certificate on the Web Gateway and
import it. Then clients will trust the Web Gateway as a certificate authority and no longer display
popup untrusted messages when making HTTPS connections.

You can push and add the Web Gateway as a trusted CA using Microsoft Group Policy.

You CANNOT purchase a server certificate from a certificate authority that allows the Web
Gateway to sign certificates as if it was a CA.

8
 Generating Certificate
Policy > Settings > SSL Client Context with CA > Default CA

Replace default
text.

To generate a new CA, complete these steps from the Policy page > Settings tab:
1. In the left pane, expand Engines and SSL Client Context with CA and then select
Default CA. The default CA opens in the right pane.
2. By Certificate Authority, click Generate. The Generate Certificate Authority window
opens.
3. Replace the default text with valued appropriate for environment and click OK.
4. Verify the new settings display on the Default CA page.
5. Click Save Changes.

Your next step is to export the CA into clients, so Web Gateway is authorized to sign HTTPS
connections. See the next page for details.

9
 Exporting Certificate
Policy > Settings > SSL Client Context with CA > Default CA

Export the certificate and

copy it to location
accessible to client.

Your next step is to export the certificate and copy it to location accessible to client.

Import the CA into clients so Web Gateway is authorized to sign HTTS connections. See the next
page for details.

10
 Importing Certificate: Internet Options
Follow Certificate Import Wizard Instructions and Prompts

Your final step is to import the certification into the browsers you use. For training purposes, we
will begin with Internet Explorer.
1. Open Internet Options. Internet Options > Content and then click Certificates. A
Certificates page opens.
2. Select Trusted Root Certification Authorities and then click Import. This launches
Certificate Import Wizard.
3. Follow the instructions and prompts to complete the import process.

11
 Importing Certificate: Firefox
Use Certificate Manager

The import process for Firefox is similar to that of Internet Options.

1. Open Firefox. Select Settings > Privacy & Security > Certificates and click View
Certificates. A Certificates Manager page opens.
2. Click Import and follow the instructions and prompts to complete the import process.

12
 HTTPS Scanner Rule Set Overview
Description
This is the HTTPS Scanner rule set that can be
imported from the library. It is recommended
to place it as high in the rule policy as
possible.

The HTTPS Scanner rule has 3 main functions:

• Handles SSL handshakes
• Performs certification verification
• Performs content inspection

HTTPS scanning ensures that SSL-secured web traffic can be processed and made available to
other filtering functions. This scanning mode is also known as SSL scanning.

The HTTPS or SSL scanning process includes several elements, which contribute to this it in
different ways.

After the initial setup, the following configuration items are available on Web Gateway for
running and controlling an HTTPS scanning process:

HTTPS Scanning rule set — Default rule set for HTTPS scanning.
• This rule set is part of the default rule set system, but it is not enabled by default. You can
enable this rule set and also modify it to meet the requirements of network.
• You can also extend the HTTPS scanning process or create your own process.

13
 HTTPS Scanning Rule Set Overview
HTTPS Scanning
 Non-HTTP traffic encrypted in SSL tunnel can’t be inspected. It will cause connection
failures.

 Examples:

• Webex

• Citrix

• VPNSSL

Here you see the default configuration for the HTTPS Scanning Rule Set. Notice this applies only
to Requests (and IM).

14
 HTTPS Scanner Rule Set Overview
Handle CONNECT Call
 Handle CONNECT Call rule set enables the SWG to
facilitate a connection between client and external SSL
server.

 Most admins want this feature enabled, even if HTTPS

connections will not be decrypted, as it allows SWG to
interact with HTTPS session with things like block pages
and redirects.

 Ruleset Criteria is set to Command.Name equals

“CONNECT”, and is the initial connect request from client.
This is beginning of HTTPS session.

This nested rule set is within the HTTPS rule set. It contains the following rules:
1. Set Client Context: Enable the use of a server certificate that is sent to a client. The
event settings specify the Web Gateway root certificate authority (CA), which is
implemented on the appliance after the initial setup, as the default issuer of this
certificate. The Continue action lets processing continue with the next rule.
2. Tunneled Hosts: Use the URL.Host property to match hosts with a URL that is on the
specified whitelist skip SSL scanning.
3. Tunneled Pinned Certificate Hosts for IPSec Mobiles: Use the URL.Host property to
match hosts with sites using pinned certificates when filtering IPSec traffic from
mobile devices.
4. Enable Certificate Verification: Enables certificate verification. Its rule criteria is set to
Always.

15
 SSL Client Context with CA Engine
Within rule, 1st event is Set Client Context with CA on SWG.

If Content Inspection is enabled, or a block or redirect is called

on CONNECT, this establishes SSL settings SWG uses to
communicate with client.

The CA that is specified in this event, is used to sign server

certificates for resources the client is trying to reach.

This event does not trigger communication with server side of

the transaction, it only sets client context between SWG and the
client.

SSL Client Context with CA: The SSL Client Context with CA (certificate authority) engine settings
defines how Web Gateway sends certificate information to clients. By default, a root certificate
authority included with Web Gateway; however, it is recommended that you generate and use
your own CA.

16
 SSL Client Context with CA Engine
HTTPS URL Blocked

If the client makes an HTTPS request for a site the Web Gateway’s policy determines should be
blocked, the Web Gateway will issue a block page.
For that block page to be presented to the client, the Web Gateway must interact with that SSL
Connection to be able to present the block page inside an SSL tunnel.
To do so, the Web Gateway issues a web server certificate (with common name matching the
request from the browser and signed by a certificate authority loaded on the box). It uses this
web server certificate to establish the SSL connection with the client, in order to present the
block page.

17
 SSL Scanner Engine
Certificate Verification
 The final rule in the Handle CONNECT Call
ruleset is Enable Certificate Verification, this
enables the Certificate Verification Engine in
an event which is required for the Certificate
Verification ruleset that follows.

 It is important to recognize without event

enabled, the CERTVERIFY command will not be
issued through rule engine and following two
rule sets will NOT be applied.

 This means no Content Inspection will be

performed.

The SSL Scanner Engine has two sub-engines: Default Certification Verification and Enable
Content Inspection. On the Default Certificate Verification page, Certificate verification is
enabled and configured by default. On the Enable Content Inspection page, SSL inspection is
enabled and configured by default.

18
 SSL Scanner Engine
Certificate Verification

Enable Certificate Verification event allows certificate verification with the “Certificate, Server
Hello Done” packet. It also :
• Controls the SSL/TLS versions used on the server side
• Proposes acceptable Cipher suites to Web Server

This is done in the “Client Hello” packet between Web Gateway and HTTPS Web Server.

19
 Configuring certificate verification rule set
Scan traffic without verifying certification

This rule set contains the following rules:

• Skip Verification for Certificates Found in Certificate Whitelist: Let whitelisted
certificates skip verification.
• Block Self Signed Certificates: Blocks requests with self-signed certificates. The action
settings specify a message to the requesting user.
• Block Expired Server (7 Day Tolerance) and Expired CA Certificates: Block requests
with expired server and CA certificates. The action settings specify a message to the
requesting user
• Block Too Long Certificate Chains: Block a certificate chain if it exceeds the path
length.
• Block Revoked Certificates: Block a certificate chain if one of the included certificates
has been revoked.
• Paranoid Certificate Chain Verification: Use SSL.Server.CertificateChain property to
match known members of the chain the certificate revocation list (CRL) queried or
have a valid Online Certificate Status Protocol (OSCP) response.
• Block Unknown Certificate Authorities: Block a certificate chain if none of the
certificate authorities (CAs) issuing the included certificates is a known CA
• Block Untrusted Certificate Authorities: Block a certificate chain if the first known CA
that was found is not trusted.
• Block Weak Key Exchange: Block connect if there is less than 80-bit security.

20
 HTTPS Scanner Rule Set Overview
Verify Signature Algorithms

The default SSL Scanner policy has a Verify Signature Algorithms rule set with two rules:
• Verify Safe Signature Algorithms
• Block unsafe Signature Algorithms

These rules block traffic if signature methods are unsafe.

21
 HTTPS Scanner Rule Set Overview
Verify Common Name (Proxy Setup)

This rule set blocks access to site if the Host entered in the browser does not match Common
Name or Alternative CN of the certificate.
This rule set is for Explicit Proxy mode.

22
 HTTPS Scanner Rule Set Overview
Content Inspection
Content Inspection rule set gives SWG ability to inspect and filter all traffic through
within HTTPS connection.

Rule that must apply for decryption of HTTPS traffic through proxy is “Enable Content Inspection”
rule.
Event “Enable SSL Scanner<Enable Content Inspection>” triggers full man-in-the-middle
transaction where SWG establishes two separate SSL tunnels on either side.
Decrypted HTTP content inside HTTPS tunnel is then passed through rule engine and is visible to
policy as normal HTTP traffic.
Notice this rule set applied on the CERTVERIFY command.

23
 HTTPS Scanner Engine
SSL Inspection
Event “Enable SSL Scanner<Enable Content
Inspection>” enables content inspection. It also:
• Controls which SSL/TLS version is used on the
server side
• Proposes acceptable cipher suites to the Web
Server

This is done in the “Client Hello” between Web Gateway and HTTPS Web Server only if Event
“Enable SSL Scanner<Certificate Verification>” is not triggered.

24
 HTTPS Scanner Rule Set Overview
Verify Common Name (Transparent Setup)

This rule set block access to site if the Host entered in the URL bar does not match Common
Name of the certificate or Alternative CN.
This rule set is for Transparent Setup.
Any idea why two similar rule sets are available for proxy and transparent setup (hint
Command.Name)?

25
 Use Cases
1. Can I enable the Handle CONNECT Call step, but not do Certificate Verification?
2. Can I enable Certificate Verification, but NOT Content inspection?
3. Can I enable Content Inspection without Certificate Verification?

How would you implement these policies?

What are some other use cases?

Let’s now look at a few use cases.

26
 Use Case 1
Can I enable the Handle CONNECT Call step, but not do Certificate Verification?
• Under Handle CONNECT Call rule set, disable Enable Certification Verification rule.

USE CASE 1: Can I enable the Handle CONNECT Call step, but not do Certificate Verification or
Content Inspection?

Yes, under Certification Verification rule set, disable Enable Certification Verification rule.

27
 Use Case 2
Can I enable Certificate Verification, but NOT Content inspection?
• Under HTTPS Scanning, disable Content Inspection ruleset.

USE CASE 2: Can I enable Certificate Verification, but NOT Content Inspection? Yes.

28
 Use Case 3
Can I enable Content Inspection without Certificate Verification?
• Yes, but not recommended. Under HTTPS Scanning, you can disable Certificate
Verification rule set.

USE CASE 3: Can I enable Content Inspection without Certificate Verification? Yes, but not
recommended.

29
 Hardware Security Module
The following solutions can be implemented to provide the functions of a Hardware
Security Module on Web Gateway:
 Using a Hardware Security Module
 Key handling with a Hardware Security Module
 Work with a Hardware Security Module
 Using private keys from an Azure Key Vault

Use of a Hardware Security Module (HSM) enhances security when dealing with private keys for
the certificates that are exchanged between clients and servers in SSL-secured
communication.

Keys for SSL-certificates can be public or private. If you are using private keys and do not want
to expose them, you can store them on a Hardware Security Module.

When a key is required for enabling the use of a certificate, the key is referenced by its ID (also
known as key name) while remaining protected on the module.

This method of key handling provides greater security than storing private keys in a file within
your file system.

This file might be read or copied after unauthorized access to a Web Gateway appliance. The
private keys on the Hardware Security Module, however, would remain protected.

30
 Using a Hardware Security Module
Several components are involved when a Hardware Security Module is used on
Web Gateway. These include the HSM Agent and other components that differ
depending on the particular solution that is implemented.
 HSM Agent
 Module card
 Appliance
 Remote server
 Emulation
 Client-server model for multiple appliances
 Web Gateway as client of a remote server (Thales)

HSM Agent - The HSM Agent runs as a daemon within the Web Gateway appliance system. This
agent enables the handling of the Hardware Security Module. Depending on the solution that is
implemented, the agent addresses the component that provides the module functions, for
example, a module card or a remote server.

The agent provides a command line interface for performing activities on the module, such as
generating,
storing, or unlocking keys.

Module Card - A module card can be installed as a hardware component on a Web Gateway
appliance to provide the functions of a Hardware Security Module. The module card that is
available for use with Web Gateway is the nShield Solo HSM card. It is provided by a Trellix
partner (Entrust). When the module card is installed, you can access it by logging on to the
appliance from a system console.

Appliance - The functions of a Hardware Security Module can be provided on a Web Gateway
appliance using an additional appliance. The appliance that is used within this solution is the
nShield Connect appliance. It is provided by a Trellix partner (Entrust).

Remote server - The functions of a Hardware Security Module can be provided on a Web
Gateway appliance using a remote server. The remote server that is used within this solution is
the Luna Network HSM server. It is provided by a Trellix partner (Thales).

When the remote server has been set up and connected to the appliance, you can access the
module by logging on to the appliance from a system console.

Continued on the next page.

31
Emulation - An emulation can be run on Web Gateway, which provides the functions of a
Hardware Security Module using OpenSSL.

As this solution does not include a module card, additional appliance, or remote server for
storing private keys, you must store these keys manually in a directory of the Web Gateway
appliance system.

This solution is not considered as secure as the module card solution. When implemented on
a standalone Web Gateway appliance, however, it compares to the remote server solution
with regard to security. An emulation is preferably used for demos, tests, and training.

Client-server model for multiple appliances - When multiple Web Gateway appliances are
part of an HSM solution, they can be configured to follow the client-server model.

This means, for example, that you need not install a module card on every Web Gateway
appliance in your network to use the functions of a Hardware Security Module. Appliances
that have no HSM solution of their own implemented can connect to an appliance with this
solution to use its functions.

The appliance that has an HSM solution implemented then takes the server role towards the
other appliances, which connect to it as clients.

Web Gateway as client of a remote server (Thales) - When the HSM solution on a Web
Gateway appliance uses the remote server that is provided by a Trellix partner (Thales), the
client-server model also applies. The Web Gateway appliance then connects as client to the
remote server.

When a Web Gateway appliance has the HSM solution implemented that uses a remote
server (Thales) and other appliances connect to it to use the functions of this solution, this
Web Gateway appliance takes both the roles of a client and a server.

The appliance then acts as a client towards the remote server (Thales) and as a server
towards the other
appliances.

32
Knowledge Check

33
Check your Learning
True - False

The same root certificate is included with all Web Gateways.

A. True
B. False

Answer: A. True. See Viewing Default Certificate Authority.

34
Check your Learning
Multiple choice: Choose the correct answer.

You want to bypass all HTTPS Scanner features, including

Certificate Verification and Decryption. In which list would you
place the host?

A. Default CA Verification list

B. SSL Inspection Whitelist
C. SSL Host Tunnel list

Answer: C. SSL Host Tunnel list. See Configuring Content Inspection Rule Set.

35
Check your Learning
True - False

You can bypass scanning of traffic you want to remain

encrypted.

A. True
B. False

Answer: A. True. See SSL Scanning Engines and Viewing Default Certificate Authority.

36
Check your Learning
True - False

It is a best practice to keep the default Web Gateway

certificate authority.

A. True
B. False

Answer: B. False. See SSL Scanning Engines and Viewing Default Certificate Authority.

37
 Review

 HTTPS scanning rules call the following engines to perform SSL scanning process:
 SSL Client Context with CA
 SSL Scanner
 SSL Client Certificate Handling
 SSL Client Context without CA
 A default root CA is included but it is recommended to generate your own.
 Default HTTPS Scanner rule sets include:
 HTTPS Scanner
 Handle CONNECT Call (nested)
 Certificate Verification
 Content Inspection (nested)
 Verify Common Name (Transparent Setup)
 Whitelists let web objects bypass parts of the process.

• HTTPS scanning rules call the following engines to perform SSL scanning process:
• SSL Client Context with CA
• SSL Scanner
• SSL Client Certificate Handling
• SSL Client Context without CA
• A default root CA is included but it is recommended to generate your own.
• Default HTTPS Scanner rule sets include:
• HTTPS Scanner
• Handle CONNECT Call (nested)
• Certificate Verification
• Content Inspection (nested)
• Verify Common Name (Transparent Setup)
• Whitelists let web objects bypass parts of the process.

38
 Lab Exercises
Lab 12: HTTPS Scanning

 Goals:
 Implement HTTPS Scanning

 Duration:
 30 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

39
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

40
Module 13: Quota Management and
Coaching

1
 Module 13 Objectives

 Explain the purpose of quota management.

 Give examples of ways to restrict web usage.
 Explain how Coaching works.
 Configure a rule to restrict web usage.

• Explain the purpose of quota management.

• Give examples of ways to restrict web usage.
• Explain how Coaching works.
• Configure a rule to restrict web usage.

2
 Quota Management Overview
Imposing Quotas and Restrictions on Web Usage

Coaching
• Educate users on Time Quotas Volume Quotas
usage. • Limit download
• Limit usage time.
• Warn, allow volume (GB/MB).
access, and • Based on by URL
categories, IP • Based on URL
blocks after categories, IP
defined duration. addresses, or
usernames. addresses, media
type, or
usernames.

The basic elements for quota management are: Coaching Quotas, Time Quotas, and Volume
Quotas. Web Gateway provides default rules but supports custom ones.

Coaching
By configuring coaching quotas, you can limit the time that users of your network are allowed to
spend for web usage but allow them to continue if they choose to do so.

Time Quotas
By configuring time quotas, you can limit the time that users of your network are allowed to
spend for web usage. Time quotas can be related to different parameters:
• URL categories
• IP addresses
• Usernames
Users are identified by the usernames they submitted for authentication. If no username is sent
with a request, web usage is recorded and blocked or allowed for the IP address of the client
system that the request was sent from.

Continued on the next page.

3
Volume Quotas
By configuring volume quotas, you can limit the volume of web objects (measured in GB and
MB) that the users of your network are allowed to download from the web. Volume quotas can
be related to several parameters:
• URL categories
• IP addresses
• Media types

Information on the volume that users download from the web is stored on the appliance. When
the configured volume quota has been exceeded for a user, a request that this user sends is
blocked. A message is displayed to the user stating why the request was blocked.

4
 Coaching Overview

 Configure coaching
session with a particular
length of time.

 Allows access but

displays warning.

Coaching allows users to access sites that may be considered work-inappropriate. The Web
Gateway calls up a modified block page when a user attempts to browse to a coached site. This
page warns the user that they are attempting to access a site and what the category of site is.
Coaching can be enabled by:
• URL the user attempts to visit
• Client IP address
• Authenticated Username

Coaching goes off a timer, once a user is prompted for coaching, they will not be coached
again for two minutes by default.

5
 Coaching Overview (Continued)
Basic Order of Coached Connection

1. Client requests webpage.

2. Checks Policy, no valid

3. Denied, Display Coaching session found.
Block Page

5. Session starts. Redirect

4. Yes. I want to continue the
request to original URL.
session.
requested.

6. Connection allowed for

duration of coaching
timeout period.

This is the basic order of a coached connection:

1. User makes a connection to a website.
2. The session bypasses the redirect rule because it is not a redirected from the quota
or coaching block page.
3. Session hits the Block page rule and matches the URL criteria, and because it is not
an approved session the Rule fires and sends the user a coaching block page. This
stops the Cycle.
4. User clicks Yes, I want to continue the session. This triggers a brand-new Request
Cycle.
5. Session hits the redirect rule in the Coaching rule set and is redirected back to it’s
original URL, which triggers a third Request Cycle
6. This time the session bypasses both the redirect and block action Rule because it is
an authorized coaching session. If it was a Quota session the session would be
checked each time to confirm it has not exceeded the Quota limit.

6
 Configuring Quota System Settings
Configuration > Appliances > Coaching

General settings
for time intervals.

Quota system settings are configured within the Appliances section off the Configuration page
> Appliances tab.

Quota system settings are general settings for time intervals related to quota management. If
an appliance is a node in a Central Management configuration, you can configure time
intervals for data synchronization with other nodes.

7
 Configuring Coaching Engine Settings
Policy > Settings > Engines > Coaching

Hours and Minutes of Session Time

Coaching engine settings are configured within the Engines section off the Policy page >
Settings tab.

8
 Configuring Time Quota Engine Settings
Policy > Settings > Engines > Time Quota

Quota per day, week, month, or session

time.

Time Quota engine settings are configured within the Engines section off the Policy page >
Settings tab.

9
 Configuring Volume Quota Engine Settings
Policy > Settings > Engines > Volume Quota

Quota per day, week, month, or session

time

Volume engine settings are configured within the Engines section off Policy page > Settings tab.

10
 Configuring Authorized Override Engine Settings
Policy > Settings > Engines > Authorized Override

Authorized Override engine settings are configured within the Engines section off the Policy
page > Settings tab.

11
 Configuring Blocking Session Engine Settings
Policy > Settings > Engines > Block Session

Hours and Minutes of Session Time

Block Session engine settings are configured within the Engines section off the Policy page >
Settings tab.

12
 Rule Construction

Key Elements

Blocking Sessions:
Quota:
• Session Time
• URL Categories
• Category List for Blocking Session
• Quota per Day and Session Time
• URL Category Blocklists • Welcome:
• URL Categories
Authorized Overrides:
• Session Time
• Maximum Adjustable Session Time
• URL Category Blocklist

The slide highlights some key elements of quota management rules.

13
 Importing Coaching Rule Sets
Rule Sets Library

• If you already have

coaching/quota rule sets, you can
modify them directly.
• It is not necessary to import
coaching/quota rule sets more
than once.

Like other rule sets, you can import coaching and quota rule sets from the Rule Set Library.

Tip: To save time, click Auto-Solve Conflicts and then Solve by referring to existing objects.

14
 Default Coaching/Quota Rule Sets

•Coaching with URL Configuration (only one enabled by default)

•Coaching with IP Configuration
Coaching
•Coaching with Authenticated User Configuration
•Coaching with IFP (Internet Facsimile Protocol)

•Time Quota with URL Configuration (only one enabled by default)

•Time Quota with IP Configuration
Time
•Time Quota with Authenticated User Configuration
•Time Quota with IFP (Internet Facsimile Protocol)

•Volume Quota with URL Configuration (only one enabled by default)

•Volume Quota with IP Configuration
Volume
•Volume Quota with Authenticated User Configuration
•Volume Quota with IFP (Internet Facsimile Protocol)

Web Gateway provides the following coaching/quota rule sets. Commonly use rule sets
enabled by default.

• Coaching:
• Coaching with URL Configuration (enabled)
• Coaching with IP Configuration
• Coaching with Authenticated User Configuration
• Coaching with IFP (Internet Facsimile Protocol)

• Time:
• Time Quota with IP Configuration
• Time Quota with Authenticated User Configuration
• Time Quota with IFP (Internet Facsimile Protocol)

• Volume:
• Volume Quota with URL Configuration (enabled)
• Volume Quota with IP Configuration
• Volume Quota with Authenticated User Configuration
• Volume Quota with IFP (Internet Facsimile Protocol)

15
 Other Default Rule Sets

•Authorized Override
•Authorized Override with IFP
Authorized •Authorized Override with OTP (One Time Password)
Override
•Authorized Override with OTP and Pledge
•Authorized Override with SSL (Secure Socket Layer)

Blocking •Blocking Sessions

Sessions

•Welcome Page
Welcome Page
•Welcome Page with IFP

Default Authorized Override and Blocking Sessions rule sets include:

• Authorized Override:
• Authorized Override (enabled)
• Authorized Override with IFP
• Authorized Override with OTP (One Time Password)
• Authorized Override with OTP and Pledge
• Authorized Override with SSL (Secure Socket Layer)

• Blocking Sessions: (enabled)

• Welcome Page:
• Welcome Page
• Welcome Page with IFP

16
 Configuring Coaching Rule Set
Redirect and Blocking Rules

• URL.Categories (default)

• URL Category Blocklist for Coaching (empty)

• URL Category Configuration (session time)

This nested coaching rule set is used to impose restrictions on web usage while allowing users
to pass by if they choose to do so. It is enabled by default and applies only to the Requests (and
IM). It includes these rules:

• Redirecting After Starting New Coaching Session: Uses the

Quota.Coaching.IsActivatationRequest property to redirects a request to let a user
again access a web object after session time is exceeded and the user has chosen to
continue with a new session. The action settings specify a message to the requesting
user.

• Check If Coaching Session Has Been Exceeded: Uses the

Quota.Coaching.SessionExceeded property to check whether the configured session
time has been exceeded for a user. If it has, the user’s request for web access is
blocked. The URL Category Configuration settings, which are specified with the
property, are the settings of the module that handles coaching. The action settings
specify a message to the requesting user.

17
 Configuring Coaching Rule Set (Continued)
Edit URL Category Blocklist for Coaching List

Because the blocklist is empty, your first step is to edit the list to add entries.
1. From the rule set, click the URL Category Blocklist for Coaching link.
2. Click the pencil icon.
3. Select one or more categories or subcategories and then click OK.
4. Click Save Changes.

18
 Configuring Coaching Rule Set (Continued)
Edit Settings
• User session time
• Days, Hours, and
Minutes

Optionally edit the session time settings.

1. From the rule set, click the URL Category Configuration link.
2. The hours and minutes of session time are configured in Days, Hours, and Minutes. If
you change the settings, click OK and then Save Changes; otherwise click Cancel.

19
 Defining Coaching Criteria: Redirection
Redirecting After Starting New Coaching Session Rule

Property Equals
True

The figure shows the criteria for the Redirecting After Starting New Coaching Session. As
discussed earlier, this rule uses the Quota.Coaching.IsActivatationRequest property.

20
 Defining Coaching Criteria: Block
Check If Coaching Session Has Been Exceeded

URL Category
Configuration

Property Equals False

The figure shows the criteria for the Redirecting After Starting New Coaching Session. As
discussed earlier, this rule uses the Quota.Coaching.SessionExceeded property.

21
 Adding URLs to Coaching Rule Set
Restrict and Coach Specific Websites

Any URL host matching

*.hulu.com

As needed, you can add specific URLs to coach to the coaching rule set. By default, coaching
rules use rule set criteria for this; for example, a client IP or a wildcard. In the example, a wildcard
is configured for any URL host matching *.hulu.com.

Pay special attention to the Boolean criteria combination. Make sure if it matches the URL
Category list OR the new criteria.

22
 Configuring Time Quota Rule Set
Similar Configuration as Coaching

• Redirect rule action redirects if session time is exceeded.

• First block rule denies connection if time is exceeded.
• Second block rule denies connection if quota is exceeded.

The figures show the default Time Quota rule set. This rule set has a similar configuration as the
Coaching rule set; however, it includes a Time Quota blocking list. It includes the following rules:
1. Redirecting After Starting New Time Session: Redirects a request to let a user again access a
web object after session time has been exceeded and the user has chosen to continue with
a new session. The action settings specify a message to the requesting user.
2. Check If Time Session Has Been Exceeded: Uses the Quota.Time.SessionExceeded property to
check whether the configured session time has been exceeded for a user. If it has, the user’s
request for web access is blocked. The URL Category Configuration settings, which are
specified with the property, are the settings of the module that handles time quotas. The
action settings specify a message to the requesting user.
3. Check If Time Quota Has Been Exceeded: Uses the Quota.Time.Exceeded property to check
whether the configured time quota has been exceeded for a user. If it has, the user’s request
for web access is blocked. The URL Category Configuration settings, which are specified with
the property, are the settings of the module that handles time quotas. The action settings
specify a message to the requesting user.

23
 Configuring Volume Quota Rule Set
Similar Configuration as Coaching

• Redirect action rule redirects connections back to the original URL if the user has a
valid session.
• First block rule blocks connection to any website in URL Category list and session
time is exceeded (default 2 minutes - same as coaching).
• Second block rule denies connections if user has downloaded defined quota in the
<URL Category Configuration> setting (default 5 GB per day).

The figures show the default Time Quota rule set. This rule set has a similar configuration as the
Coaching rule set; however, it includes a Volume Quota blocking list. It includes the following
rules:
• Redirecting After Starting New Volume Session: Redirects a request to let a user again access
a web object after session time has been exceeded and the user has chosen to continue with
a new session. The URL Category Configuration settings, which are specified with the
property, are the settings of the module that handles volume quotas. The action settings
specify a message to the requesting user.

• Check If Volume Session Has Been Exceeded: Uses the Quota.Volume.SessionExceeded

property to check whether the configured session time has been exceeded for a user. If it has,
the user’s request for web access is blocked. The URL Category Configuration settings, which
are specified with the property, are the settings of the module that handles time quotas. The
action settings specify a message to the requesting user.

• Check If Volume Quota Has Been Exceeded: Uses the Quota.Volume.Exceeded property to
check whether the configured time quota has been exceeded for a user. If it has, the user’s
request for web access is blocked. The URL Category Configuration settings, which are
specified with the property, are the settings of the module that handles time quotas. The
action settings specify a message to the requesting user.

24
 Other Rule Set Types
Authorized Override and Blocking Sessions

We will now look at other types of rule sets: Authorized Override, Blocking Sessions, and Welcome
Page.

25
 Authorized Override Rule Set
Authorized Override Rule With URL Configuration

• URL.Categories (default)

• URL Category Blocklist for Authorized Override (empty)

• URL Category Configuration (session time)

The nested Authorized Override Rule With URL Configuration rule set is used to configure
authorized overriding to restrict the web usage of your users but allow the configured time limit
to be passed by through the action of an authorized user. It contains these rules:

• Redirect After Authenticating For Authorized Override: Redirects a request to let a user again
access a web object after session time has been exceeded and the credentials the user
submitted to continue with a new session have been validated. The action settings specify a
message to the requesting user.

• Check If Authorized Override Session Has Been Exceeded: Uses the

Quota.AuthorizedOverride.SessionExceeded property to check whether the configured
session time has been exceeded for a user. If it has, the user’s request for web access is
blocked. The URL Category Configuration settings, which are specified with the property, are
the settings of the module that handles authorized overriding. The action settings specify a
message to the requesting user.

26
 Blocking Sessions Rule Set
Block Web Sessions When Access is Not Allowed

• Blocking configuration

• Category Blocklist for Blocking Session

The nested Blocking Sessions rule set is used to blocking web sessions after an attempt to
access a web object that is not allowed. It is enabled by default and applies to all three cycles. It
contains these rules:

• Block User If Blocking Session Is Active: Uses the BlockingSession.IsBlocked property to check
whether a blocking session has been activated for a user who sends a request. If it has, the
request is blocked. The action settings specify a message to the requesting user.

• Activate blocking session if user is in list Category List for Blocking Sessions: Uses the
URL.Categories property to check whether a URL that a user requests access to falls into a
category on the blocking list maintained especially for blocking sessions. If it falls into a
category on the list, a blocking session is activated for the user. The BlockingSession.Activate
event is used to activate the blocking session. The event settings are specified with the event.

27
 Welcome Page Rule Sets
 URL.Categories (default)

 URL Category Configuration for Welcome Page (empty)

It is enabled by default and applies only to Requests (and IM). It contains these default rules:

• Redirecting After Starting New Welcome Page Session: Uses

Quota.Coaching.IsActivationRequest property. It returns True if the request is an internal
activation request coaching session.

• Check If Welcome Page Session Has Been Exceeded: Uses

Quota.Coaching.IsActivationExceeded property.

28
 Use Cases

1. Allow access to cloud lab environment for duration of the class. Deny access at
course conclusion.

2. Allow access to potentially undesirable sites for legitimate work purposes.

3. Allow access to safe entertainment sites after work hours.

How would you implement these policies?

What are some other use cases?

As we bring it all together, let us look at some use cases. How would you implement these
policies? Remember, there are different ways to implement the same policy.

29
 Use Case 1
Allow access to cloud lab environment for duration of the class. Deny access at
course conclusion.

In the first use case, we created a Time Quota for class at 8 hours per day, 50 per week and 200
monthly.

30
 Use Case 2
Allow access to potentially undesirable sites for legitimate work purposes.

In the second use case, we created a list of categories for coaching.

31
 Use Case 3
Allow access to safe entertainment sites after work hours.

In the third use case, we create a Time Quota allowing access to certain sites for after work
hours (09:00:00 – 17:00:00).

32
Knowledge Check

33
Check your Learning
Multiple choice: Choose the correct answer.

Time Quota with IP Configuration is enabled by default.

A. True
B. False

Answer: B. False. See Default Coaching/Quota Rule Sets.

34
Check your Learning
True - False

Importing coaching and quota rule sets immediately impact

network traffic.

A. True
B. False

Answer: B. False. See Configuring Coaching Rule Set.

35
Check your Learning
Multiple choice: Choose the correct answer.

How many request cycles does an initial coaching session take

to display the destination web page?

A. 1 (one)
B. 2 (two)
C. 3 (three)

Answer: C. Three. See Authentication Engine Overview.

36
Check your Learning
True - False

The URL Category Blocklist for Coaching list is a Skyhigh-

maintained list and is read-only.

A. True
B. False

Answer: B. False. See Configuring Coaching Rule Set.

37
 Review

 Coaching and quota rules allow you to restrict how often and how much
information users can retrieve through the Web Gateway.
 By default, these rules do not affect your policy because the blocking lists are
empty.
 Volume Quota rules are like coaching quota rules; however, in addition to having a
session timeout, Web Gateway also tracks how much information is sent and
received to sites in the Quota configuration.
 Authorized overrides rules restrict the web usage of your users but allow the
configured time limit to be passed by through the action of an authorized user; for
example, in a classroom setting.
 Blocking Sessions rules block web sessions after an attempt to access a web object
that is not allowed.

• Coaching and quota rules allow you to restrict how often and how much information users
can retrieve through the Web Gateway.
• By default, these rules do not affect your policy because the blocking lists are empty.
• Volume Quota rules are like coaching quota rules; however, in addition to having a session
timeout, Web Gateway also tracks how much information is sent and received to sites in the
Quota configuration.
• Authorized overrides rules restrict the web usage of your users but allow the configured time
limit to be passed by through the action of an authorized user; for example, in a classroom
setting.
• Blocking Sessions rules block web sessions after an attempt to access a web object that is
not allowed.

38
 Lab Exercises
Lab 13: Coaching and Quotas

 Goals:
 Implement coaching by category
 Implement volume coaching

 Duration:
 30 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

39
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

40
Module 14: Web Caching, Next Hop Proxies,
Progress Pages, and Block Pages

1
 Module 14 Objectives

 Explain how web caching works.

 Give example of the types of web sites
appropriate for web caching.
 Configure web caching for a specific group of
web sites.
 Explain how and why you would want to
configure a next hop proxy on the Web
Gateway.
 Explain the purpose of and how to configure
Progress page settings.
 Recall how to modify and configure custom
block pages.

• Explain how web caching works.

• Give example of the types of web sites appropriate for web caching.
• Configure web caching for a specific group of web sites.
• Explain how and why you would want to configure a next hop proxy on the Web Gateway.
• Explain the purpose of and how to configure Progress page settings.
• Recall how to modify and configure custom block pages.

2
Web Caching

3
 Web Caching Overview
Before
1. Client 1 requests www.nasa.gov
Client 1
2. Web Gateway checks cache.
3. Site not cached, so Web Gateway
retrieves site data.
Site Not
Cached 4. Web Gateway saves copy and
forwards data to Client 1.

www.nasa.gov

This figure shows how web caching works. Because the site is not cached, Web Gateway
accesses the site and saves a copy of the data.

4
 Web Caching Overview (Continued)
After
1. Client 2 requests www.nasa.gov

2. Web Gateway checks cache.

Client 2
3. Site cached, so Web Gateway
forwards copy to Client 2.

Site
Cached

www.nasa.gov

Because the site is now cached for future requests, Web Gateway accommodates the request
with the cached copy.

5
 Enabling Cache Option
Configuration > Appliances > [Appliance] > Proxies > Web Cache

Make sure Web Cache is enabled.

Web Cache is enabled on the appliance on the Configuration page (Configuration > Appliances
> [Appliance] > Proxies >Web Cache).

In addition to enabling the web cache, you must implement a rule set to control reading from
and writing to the cache.

6
 Enabling Cache Option
Policy > Lists | Policy > Rule Sets

Web Cache URL Bypass List:

• List of URLs (Wildcard Expression)
• Empty by default

Web Cache Media Bypass List:

• List of media types

Default Web Cache Rule Set:

• Read from Cache and Write to Cache Rule Sets (Common Rules section of the
Rule Set Library)

The slide highlights key elements for this rule type. The bypass list is empty by default. Add
entries using a wildcard expression. Default Web Cache rule sets are in the Common Rules
section of the Rule Set Library. There are two nested rule sets: Read from Cache and Write to
Cache.

7
 Configuring Read from Cache Rule Set
Policy > Rule Sets

The Web Cache URL Bypass List is empty

by default.

The default Read from Cache rule set is enabled by default and applies only to the Requests
cycle. It includes these rules:

1. Skip Caching URLs That Are in Web Cache URL Bypass List: Uses URL property to match
Web Cache URL Bypass List.
2. Enable Web Cache: Last rule in the list. It has a Continue action. It is enabled by an
Event and is applied automatically (always) if the other rules do not apply.

8
 Default Write to Cache Rule Set

8MB

1. This rule skips caching if URL matches Web Cache URL Bypass List
2. This rule allows to skip caching of objects are greater than a default of 8 MB
3. This rule skips caching is media type matches Web Cache Media Type Bypass
List
4. This rule enables web cache if no other rule above applied.

The default Write to Cache rule set is enabled by default and applies only to the Responses
cycle. It includes these rules:

• Skip Caching URLs That Are in Web Cache URL Bypass List: Uses URL property to match
Web Cache URL Bypass List.
• Skip Caching Objects That Are Larger Than X Bytes: Uses String.ToNumber(String) and
greater than operator to match a number value. The default is 8388608
(approximately 8MB). You can modify this setting for larger or smaller objects,
depending on cache performance
• Skip Caching Objects That Are in Web Cache Media Type Bypass List: Uses
MediaType.FromHeader property to match Web Cache Media Type Bypass List. By
default, the list is empty.
• Enable Web Cache: Last rule in the list. It is enabled by an Event. It has a Continue
action and is applied automatically (Always) if the other rules do not apply.

9
Next Hop Proxies

10
 Next Hop Proxies Overview
Additional Means of Forwarding Web Requests to Destinations

Client 1 requests DNS Direct connect to

www.nasa.gov Lookup www.nasa.gov
(port 80)

Client 2 Upstream
requests Forwards proxy server
www.nasa.gov request (port 9090)

Allows Web Gateway to forward outgoing client requests to

upstream proxy server.

Next hop proxies provide additional means of forwarding requests received from the clients of
an appliance to their destinations.

When next hop proxies are implemented, a rule in a corresponding rule set uses a module (also
known as engine) to call next hop proxies that have been entered into a list for forwarding
requests.

For example, you can forward requests that have internal destinations using internal next hop
proxies. IP addresses of destinations that are internal are then entered into a list, which the
forwarding rule relies on. In addition to this, there is a list of internal next hop proxies for use by
the rule.

A rule set with a rule for using next hop proxies is not implemented on the appliance after the
initial setup. You can import a rule set from the library and modify it according to your needs or
create a rule set of your own.

When you import the next hop proxy rule set, a list of servers that can be used as next hop
proxies is also imported. The list is initially empty and must be filled by you. You can also create
more than one list and use these lists for routing in different situations.

Settings for the next hop proxy module are imported with the library rule set. You can configure
these settings to let the module use a particular next hop proxy list and to determine the mode
of calling the next hop proxies (round-robin or failover).

11
 Next Hop Proxy
Rule Construction

• Next Hop Proxy IP Range List

• Next Hop Proxy IP List

• Settings for internal next hop proxy

• List of next hop proxies

• Round robin, fail over, or Sticky

• Proxy style requests (enabled)

The slide highlights key elements for a Next Hop Proxy rule.

When multiple servers are available as next hop proxies for routing requests, the next hop proxy
module can use several modes to call them: Round-robin, failover, and stickiness.

When routing a request in round-robin mode, the next hop proxy module calls the next-hop
proxy that is next on the list to the one that was called last time. For the next request, this is
handled in the same way, so all servers on the list are eventually used as next hop proxies.

12
 Default Next Hop Proxy Rule Set
Rule Set Library
• Next Hop Proxy IP Range List
• Next Hop Proxy IP List
• Settings for internal next hop proxy

The Next Hop Proxy Rule Set contains a single rule. It only applies to the Request cycle.

The first hop matches the type of traffic you want to forward to the next hop proxy. This usually is
a set of Destination IPs but supports other applicable Criteria, such as usernames, URLs, or
media types.

The next hop matches the Enable Next Hop Proxy event. This allows you to choose the group of
proxy servers where you are directing traffic. Traffic sent round robin (one request/server) or in
failover mode. With failover mode, traffic is sent to the first server. When the first server is
unavailable, traffic is sent to server 2, and so on.

13
Progress Pages

14
 Progress Indication Overview
Customizable Progress Message Configured within Rules

When the Antimalware is

enabled, Web Gateway must
download the complete file to
scan it successfully. You can
configure Web Gateway to
display a progress page
during this process.

When the Antimalware feature is enabled, Web Gateway must download the complete file to
scan it successfully. You can configure the Web Gateway to display a progress page to show
the user the status. These templates are combined with download and upload rules.

15
 Default Progress Indication Rule Sets
Policy > Rule Sets > Common Rules
Two nested rule sets:

 Downloads: Enable Progress

Page
 Enable Data Trickling: FTP
Uploads and FTP Upload Timeout
Prevention

Shows users the download progress for web objects.

Apply to Requests (and IM) and Responses.

Web Gateway provides the following nested Progress Indication rule sets in the Rules Set Library:

• Downloads:
• Enable Progress Page: Enables an event that lets a page be shown to indicate the
progress made when a web object is downloaded to a client.
• Enable Data Trickling: Enables data trickling for all browsers that are not Mozilla. The
event settings specify the chunk and block sizes used for the trickling.

• FTP Uploads:
• FTP Upload Timeout Prevention: Enables the FTP Upload Progress Indication function if
a file has been sent from a client for uploading to the web under the FTP protocol.
Messages indicating upload progress are then sent to the client during the upload to
prevent a timeout that could occur on the client if the upload takes more time. This
could be due, for example, to scanning the file that is to be uploaded for infections by
viruses and other malware.

16
 Default Enable Progress Page Rule
Language, Schema, Template Names, Timeouts

Click the Enable Progress Page <Default> link to define these parameters for Templates:

• Language: Select Auto (Browser), Force to, or Value of ‘Message.Language’ property.

• Collection: Select Default Schema, SAML Request Schema, or Single Sign On Schema.
• Template name for progress bar page: Select name to display; for example, Progress,
Progress Cancelled, Progress Done, and so on. See the Web Gateway Product Guide
for the complete list.
• Template name for downloaded finished page: Name to display; for example,
Progress, Progress Cancelled, Progress Done, and so on. See the Web Gateway
Product Guide for the complete list.
• Timeouts: Select Delay for redirects progression page (seconds), File availability time
before download, File availability time after download.

17
 Default Enable Data Trickling Rule
Size and Forwarding Rate

Click the Enable Data Trickling <Default> link to define these parameters:

• Specify Size of first forwarded chunk (bytes).

• Specify Forwarding rate during down or upload (per thousand).

18
 Review

 Web Caching
• Web Caching allows the Web Gateway to save web content for distribution to
clients.
• If clients are always requesting the same URLs, Web Caching can drastically
increase performance and reduce resource impact.
 Next Hop Proxy
• The Next Hop Proxy feature allows Web Gateway to forward outgoing client requests
to upstream proxy server.
 Progress Pages
• When Antimalware is enabled, the Web Gateway must download the complete file
to scan it successfully.
• You can configure the Web Gateway to display a progress page to show the user
the status.

• Web Caching
• Web Caching allows the Web Gateway to save web content for distribution to clients.
• If clients are always requesting the same URLs, Web Caching can drastically increase
performance and reduce resource impact.
• Next Hop Proxy
• The Next Hop Proxy feature allows Web Gateway to forward outgoing client requests to
upstream proxy server.
• Progress Pages
• When Antimalware is enabled, the Web Gateway must download the complete file to
scan it successfully.
• You can configure the Web Gateway to display a progress page to show the user the
status.

19
Block Pages

20
 Block Pages Overview
Default and Customizable Block Pages
• 80-plus block pages

• Fully editable to include

custom text and graphics

Web Gateway includes configured block pages for almost every filter available. Unlike Progress
message, block pages have no associated rules. Instead, they consist of template collections
and templates.

21
 Basic Components
Template Settings
• Schema (common structure) • Foundation/base for block pages
• Block page-specific templates • Language, schema and template
• File System (files, images, style sheets) used, and reason for reports

Schema

Page-specific Groups of
templates templates

File System

Policy > Templates Policy > Settings > Actions >

Block

The block pages consist of two components: Collections and Templates.

Collections are the main pages that define the foundation and baseline for a block page. All
logos, information, disclaimers, and so on belong to a collection main page. To configure
collections, go to the Policy page, Settings, and expand the Block group.

The second component are the templates. Templates complement collections. They contain
schema and file system contents. The File System section shows the existing templates, as well
as image and other files that are related to templates, in a tree structure. To configure
collections, go to Policy page, Templates tab.

22
 Basic Components (Continued)
Schema and Template

Schema

Template

Schema

Update the Acceptable Use Policy to include contact information for the
administrator.

Block pages are composed of the Schema and the Template.

The Schema by default displays on all block pages.

It is best practice to update the Acceptable Use Policy to include contact information for the
administrator.

The Template contains information that explains why the page was blocked. You can add other
text, as necessary; for example, troubleshooting information.

A best practice would be to hide the web gateway information somewhere on the block page
(seen here in the lower right-hand corner of the page). You could hide the text by making it the
same color as the background. Customers won’t know it’s there until you ask them to highlight
it and tell you what it says.

23
 Creating a Custom Block Page
Policy > Templates
Policy > Templates > [template] > Add Clone
(Recommended)

Policy > Templates > Default Schema >

Add Template

There are two ways to create a custom template. From the Policy page, Templates tab:

• Right-click on Default Schema and select Add Template. You can specify a specific name or
allow the Web Gateway to automatically generate one. After creating the template, add new
content.
• Right-click on a message template (for example URL Blocked) and select Clone. Again,
specify a specific name or allow automatic assignment. After cloning the template, modify
the existing content to meet your needs.

It is not recommended to edit the default block pages. A best practice is to clone an existing
one and keep the default page as a reference.

24
 Modifying Custom Block Page
HTML Editor

Add properties
and variables.

Preview your
block page.

Using the HTML Editor, modify the custom template to meet your needs; for example, links,
images, text, and variables. Click Preview to view your page. After you are satisfied with the
changes, click Save Changes.

Note: Use properties that are relevant for the user and troubleshooting.

25
 Modifying Custom Block Page (Continued)
Add Custom Properties

At the top of the HTML Editor page, select Add and then Property. Some common properties used
in block pages:

• Client.IP: Client IP address.

• URL: URL trying to be accessed.
• Authentication.Username: Username used to authenticate.
• URL.Destination.IP: IP address of the destination web server.
• Rules.CurrentRule.Name: Name of the current rule used to generate the block page.
This is useful for troubleshooting.
• Proxy.IP: IP address of the proxy server this connection was connecting too. This is
useful if you are using load balancers and want to know the exact IP address through
which the connection flowed.

Important: You must reference variables as criteria or use variables included in another rule for
proper display.

26
 Creating Block Action
Policy > Settings > Actions > Block

To create a new block action, complete these steps from the Policy page, Settings tab:

1. Right-click on Block and select Add. An Add Settings page opens in the right pane.
2. Type a name and customize the other settings, as necessary. See the following
pages for additional information about each setting.
3. After completing the configuration, click Save Changes.

27
 Block Action: Language
Auto (Browser)

 Auto (Browser) – browser

language

 Force to – chosen language

 Value of ‘Message.Language’
property – value set by user

Policy > Settings > Block > (Default)

Each Block Page Template can be written in as many languages as needed and the Web
Gateway can automatically forward the appropriate language page to each client based on
several different factors. The options here are:

• Auto (Browser): When selected, the message is in the language of the browser from
which the blocked request was sent.
• Force to: When selected, the message is in the language chosen from the list that is
provided here.
• Value of Message.Language property: When selected, the message is in the language
that is the value of the Message.Language property. You can use this property to
create a rule.

28
 Block Action: Schema (Structure)
Default Schema

• Default: Templates for user

message templates

• SAML: Templates for application

Launchpad and logon pages

• Single Sign On: Templates for

SAML authentication requests
and responses

SAML = Security Assertion Markup Language

The Default Schema is selected. Other options are SAML (Security Assertion Markup Language),
or Single Sign On Schema.

The Default Schema provides user message templates that you can customize. The SAML
Request Schema provides templates for customizing the application Launchpad and logon
pages. The Single Sign On Schema provides templates for SAML authentication requests
(SAMLRequest.html) and responses (SAMLRedirectToAuth.html) sent to and received from an
external Identity provider, respectively.

29
 Block Action: Template Name
Custom Template

On the Template Name drop-down list, select the custom template you created.

30
 Block Action: Reason
Block Reason ID 2/ Default Error Template Reason Example Block Reason IDs
• 0 – Allowed
• 1 - Error

• 2 - Default message template

being used for action
Reason for
• 3 - Internal URL filter error
Web Reporter
or Content • 10 - Blocked due to entry in URL
Reporting filter database
System
• 14 - Blocked according to URL
filtering by expression

• 15 - Blocked by Real-Time
See Web Gateway Product Guide for complete Classifier
list of reason IDs.

These sections apply to the Web Reporter or Content Reporting System applications.

The Web Reporter Block Reason ID field is a numerical value that identifies a block reason; for
example:
• 0 - Allowed,
• 1 - Internal error,
• 2 - Default message template being used for an action,
• 3 - Internal URL filter error,
• 10 - Blocked due to an entry in the URL filter database,
• 14 - Blocked according to URL filtering by expression.

See the Web Gateway Product Guide for the complete list of reason IDs.

31
 Block Action: Reason (Continued)
CSR Report with Mapped Reason Data

Translates reason to
meaningful content in
Protection area.

The CSR parses the reason ID code from block pages and translates it to a meaningful block
motive in reports called the Protection area, as shown in the figure. The CSR is discussed in more
detail later in the module.

32
 Configure Action in Rule
Policy > Rule Set > [Rule Set] > [Rule]

The final step is to select your custom block action in a rule, as shown in the figure.

33
 Block Page Example
Additional fields added to a custom URL Blocked Page include:
• Media type
• Rule Name
• Client IP
• Username
• User Method

Additional tokens (fields) can be used in the block page to reflect information about the web
requests that trigger the blocking action and the block message.

34
 Exporting Templates to Archive
Policy > Templates > Export

 Export all or
selected templates.

 Archive is saved in
zip format.

To export all or selected templates, complete these steps from the Policy page, Templates tab:

1. Right-click on Export.
2. Select the files to export.
3. Click Browse, select the destination, and then click Save.
4. Click Export to complete the process.
5. Click OK to close the success message popup.

Note: When exporting a rule set, the block page is not exported.

35
 Importing Template Archive
Policy > Templates

Import previously exported

archive.

To import a previously exported archive, complete these steps from the Policy page, Templates
tab:

1. Right-click on Import.
2. Click Browse, select the archive, and then click Open.
3. Click Import to complete the process.
4. Follow the onscreen instructions to complete the process.

36
WebSocket

37
 What is WebSocket ?

Communication Protocol providing full-duplex communication channels over a

single TCP connection

Standardized by the IETF as RFC 6455

More specifically, it allows:

• notification to the client of a change in server state,
• sending data in "push" mode (Push method) from the server to
• the client, without the latter having to make a request.
 What is WebSocket ?

To establish a WebSocket connection, the client sends a WebSocket handshake

request, for which the server returns a WebSocket handshake response, as shown
in the example below.

• Client Request

• Server Response
 Proxy vs WebSocket

• This behaviour can cause problems

with the SSL Scanner rule set.

• With an explicit proxy, a

client WebSocket request on port 80
contains an Upgrade:
websocket header. If the SSL Scanner
rule set is enabled, a 500 handshake
failed error response is returned.

• Example client WebSocket connect

request and SWG response:
 Proxy vs WebSocket

Solution:
• SWG supports WebSocket connections and a rule set is contained in the library.
This support allows specific destinations to allow or establish
a WebSocket connection.

• SWG allows the establishment of a tunnel so communication between the

client, SWG, and the webserver is established. But, SWG does not scan the traffic
or responses received from the web server.

• CAUTION: Be careful when you allow a WebSockets connection through SWG.

You do not want to open a security hole inside your setup. We recommend that
you do not allow WebSockets in general. Allow only the destinations that you
really want to use WebSockets.
 WebSocket Rule Set

To import the rule set:

 Log on to SWG.
 Select Policy, Rule Sets, Common Rules.
 Click Add and select Rule Set from Library.
 In the Overview section, expand Common Rules.
 Select WebSocket Handling and click OK.
 Place this rule set into your Common Rules set.
 WebSocket Rule Set (Continued)

WebSocket Handling includes the following four rules:

• Enable WebSocket handling: This rule allows SWG to establish
the WebSocket connection or tunnel in the event. The event applies only to
the WebSocket and is achieved by checking the connection for the specific
header defining the WebSocket.
IMPORTANT: This rule is not a general bypass or tunnel; other traffic or
protocols are not affected.
• Enable WebSockets for Special Sites (client initiated):
This rule allows traffic to and from the specific destination of the client
initiating the WebSocket connection.
• Enable WebSockets for Special Sites (server initiated):
This rule allows traffic to and from the specific destination of the server
initiating the WebSocket connection.
• Block WebSockets:
This rule blocks any other connection that the preceding two rules do not
explicitly allow.
Knowledge Check

44
Check your Learning
Multiple choice: Choose the correct answer.

What is a next-hop proxy?

A. Client machine that sends requests to the Web Gateway

B. Proxy server to which Web Gateway forwards web requests
C. Proxy server Web Gateway uses to perform Antimalware scanning
D. Router to which Web Gateway sends outbound traffic

Overview.
Answer: B. Proxy server to which Web Gateway forwards web requests. See Next-hop Proxies

45
Check your Learning
True - False

The Web Cache URL Bypass List is Skyhigh-maintained and

read-only.

A. True
B. False

Answer: B. False. See Web Cache Rule Construction.

46
Check your Learning
Multiple choice: Choose the correct answer.

Which tool is typically used to edit custom block pages?

A. CLI (Schema)
B. HTML Editor
C. Notepad
D. Wordpad

Answer: B. HTML Editor. See Default Progress Indication Rule Sets.

47
Check your Learning
True - False

The Progress Indication rule set is included in the Common

Rules set.

A. True
B. False

Answer: A. True. See Default Progress Indication Rule Sets.

48
 Review

 Do not edit the default block pages. A best practice is to clone an existing one and
keep the default page as a reference.
 Take advantage of block page by requesting a print screen of the page when the
blocked user needs to open a support ticket. This alerts you to which rule is likely
blocking the request. Have the gateway information hidden in the lower right corner
on your block page and ask them to highlight it before taking the screen shot.
 Use properties relevant for the user and troubleshooting.
 Avoid loading image files. Images increase the block page’s load time.
 When exporting a rule set, the block page is not exported.
 Do not remove the sw.js from the Collection. Web Gateway uses it to display specific
block pages, such as used for quota management.
 Simplify block pages. Their primary objective is to inform a user about a blocked
web request. Complex web elements, such as menus and javascripts are not
required.

• Do not edit the default block pages. A best practice is to clone an existing one and keep the
default page as a reference.
• Take advantage of block page by requesting a print screen of the page when the blocked
user needs to open a support ticket. This alerts you to which rule is likely blocking the request.
Have the gateway information hidden in the lower right corner on your block page and ask
them to highlight it before taking the screen shot.
• Use properties relevant for the user and troubleshooting.
• Avoid loading image files. Images increase the block page’s load time.
• When exporting a rule set, the block page is not exported.
• Do not remove the sw.js from the Collection. Web Gateway uses it to display specific block
pages, such as used for quota management.
• Simplify block pages. Their primary objective is to inform a user about a blocked web request.
Complex web elements, such as menus and javascripts are not required.

49
 Lab Exercises
Lab 14: Web Caching, Next Hop Proxies, Progress Pages, and Block Pages

 Goals:
 Create a block page

 Duration:
 20 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

50
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

51
Module 15: Logging

1
 Module 15 Objectives

 Identify the elements involved with logging.

 Identify how to administer the logging
functions of an appliance to monitor how it
performs filtering and other activities.

• Identify the elements involved with logging.

• Identify how to administer the logging functions of an appliance to monitor how it performs
filtering and other activities.

2
 Logging Overview
• System Log Files
• User-defined Log Files
• Log File Settings
• Rule-based logging
• File Editor

The slide highlights the key topics discussed in this module.

3
 System Log Files
Troubleshooting > [appliance] > Files

• Maintained by Web
Gateway

• Fixed

• Useful for troubleshooting

• Viewed using Web Gateway

interface or command line

Do not push system logs to reporting applications.

The applications cannot parse the data and discard it.

Web Gateway maintains the following fixed (non-editable) logs, which are useful for
troubleshooting :changes.
• Debug: Contains debugging information.
• Migration: Contains migration activities.
• Mobile-device-certificates: Contains certificates for remote devices.
• MWG-errors: Contains module errors.
• Scheduled-jobs: Contains scheduled jobs information.
• System: Contains operating system activity.
• Update: Contains information on module and file updates.

Important: Do not push system log files are not pushed to a reporting application, such as the
Skyhigh Content Reporting System (CSR). Because these applications do not parse system logs,
the log information is not reportable, and the information is discarded.

4
 Viewing System Log Files
Troubleshooting > [appliance] > Files
View now or download for future analysis.

View audit log now.

Navigate through the log types to become

familiar with their contents.
Command line use is discussed in Basic
Troubleshooting module.

To view system log files from the Web Gateway interface, complete these steps from the
Troubleshooting page of a selected appliance.

1. Click Log files.

2. Open a log file collection (for example, audit) and select a file.
3. Click View to review the file now or Download to save the file for future analysis.

Note: You can view log files from the command line. This is discussed in the Basic
Troubleshooting module

5
 User-defined Log Files
Troubleshooting > [appliance] > Files

 Defined by logging rules

 Do not modify access.log!

User-defined log files are generated by logging rules and are customizable; however, do not
modify the access.log. This prevents the proper recording of access data and results in a loss of
data, which is not recoverable.

6
 Log File Settings

System-maintained Logs User-defined Logs

Configuration > Appliances

> [appliance] Policy > Settings > Engines

Two key configuration components for logging are the Log file System and File System Logging.

Use the Log File Manager to configure settings for module-maintained log files. Go to
Configuration > Appliances > [appliance] > Log File Manager.

Use File System Logging to configure settings for rule-maintained log files. Go to Policy > Settings
> Engines> File System Logging.

7
 Log File Manager Settings: System Log Files
General and Log-specific Settings

Option Description
Controls general settings for rotation, deletion, and push.
Global Log Settings Many settings are enabled and preconfigured by default.
Important: By default, log files are deleted after 7 days.
Enable and configure specific rotation, deletion, and push
Settings for Error Logs settings for error logs. Disabled by default. When disabled,
global log settings will apply.
Enable and configure specific rotation, deletion, and push
Settings for the Update
settings for the update log. Disabled by default. When
Log
disabled, global log settings will apply.
Enable and configure specific rotation, deletion, and push
Settings for the Audit
settings for the update log. Disabled by default. When
Log
disabled, global log settings will apply.
Controls settings for core files, feedback files, and
Advanced eventBody.ToFile. Many settings are enabled and
preconfigured by default.

The table highlights the settings for the Log File Manager. The page is divided into general and
log-specific settings.

8
 File System Logging Settings: User-defined Log Files
General and Log-specific Settings

Option Description
Name of the log Specifies the name of a log.
When selected, the log is buffered. The buffer interval is 30
Enable log buffering
seconds.
When selected, you are able to define a header for all log files
Enable header writing
which may be used by a reporting tool or SIEM.
Log header Provides box to type header for all log files.
Encrypt the log file When selected, log files are stored encrypted.
First password, Repeat
Sets a password for access to encrypted log files.
password
[Optional] Second
password, Repeat Sets a second password for access to encrypted log files.
password

The table highlights the settings for File System Logging. Some options are already enabled and
preconfigured by default.

9
 Rule-based Logging Overview

Client
Browser Makes Provides
request a
response
Web
Transaction
Server

Request

Embedded
Object
(optional)

Response

Embedded
Object
(optional)

Last cycle of every Log

transaction

As we discussed earlier, the log cycle is the last cycle of every transaction. The log cycle is run
after the request, response, and embedded object cycles are complete.

10
 Rule Construction
Key Elements

Logging Rule Set Contains one or more logging rules.

Logging Rule Defines criteria to write a log.

Custom parameters configured for use in rule set criteria,

User-Defined
rule criteria, and rule events; for example, Web Gateway
Properties
properties and custom text.

File System Writes user-defined properties to a log file and defines

Logging Engine log settings, such as rotation, push, and deletion.

Key element for logging rules are logging a logging rule set, one or more logging rules, user-
defined properties, and the file system logging engine.

11
 Logging Rule Sets
Define Criteria to Enable Rules

Access
Denied Log
rule set

Found
Viruses Log
rule set

Like other rule set types, a logging rule set includes one or more rules. As an example, the Found
Viruses Log rule set has one rule, while the IM Log rule set has three rules. They also define the
criteria to enable the rules.

12
 Logging Rule Sets (Continued)
Policy > Rule Sets > Log Handler > Default

 Imported from Rule Set Library.

 You can create a new one, but it will
have no preconfigured rules.

To add a logging rule set, complete these steps from the Policy > Rule Sets tab:

1. Click Log Handler.

2. Select the Default log handler rule set.
3. Click Add and select Rule Set to create a new rule set or Rule Set from Library to import
an existing one.
• If importing a rule set, you must select a Logging option (for example, Access
Log or Found Viruses Log) and resolve the differences.
• In the Name field, type a suitable name for the new log rule set, for example,
Troubleshooting Log. Click OK. The window closes and the new log rule set
appears on the log handler tree.

13
 Logging Rule
Name: Write access.log

Policy > Rule Sets > Log Handler > Default > Access Log

Your next step is to configure a logging rule. For training purposes, we are working with the
Access Log rule set. It has one rule named Write access.log.

Continued on the next page.

14
 Logging Rule
Rule Criteria: Always

It is applied Always.

Continued on the next page.

15
 Logging Rule
Action: Continue

The configured action is Continue.

Continued on the next page.

16
 Elements of Logging Rule: Events
What to Write and Which Log to Write

What to
write in log

Which log
to write

Finally, the rule has configured Events. The Set parameter defines what to write to the log. The last
parameter defines which log to file.

17
 Configuring File System Logging Settings
Policy > Settings > Engines > [Setting]

 Use existing setting as

template, such as
Access Log
Configuration.

 Add setting.

 Specify setting name

and log file name.

 Configure other options,

as necessary.

You can create a log that can be used by a logging rule to write entries into its log files. When you
create a log, you do not create it separately, but as a part of creating new settings for the File
System Settings module. Complete these steps:

1. Select Policy > Settings.

2. Expand File System Logging and select an existing settings, for example, Access Log
Configuration. This serves as a starting point for creating new settings, including the
creation of a new log.
3. At the top of the left pane, click Add. The Add Settings window opens.
4. In the Name box, type a name for the setting.
5. Optionally in the Comment field, type a plain-text comment on the settings.
6. Optionally, click the Permission tab and configure who is allowed to access the
settings.
7. Under Name of the log, type the name of the new log.
8. Configure other settings items, such as rotation or deletion, as needed.
9. Click OK. The Add Settings window closes, and the new settings appear under File
System Logging on the settings tree.
10. Click Save Changes.

18
 Adding Custom Log Handler (Optional)
Policy > Rule Sets > Log Handler

 Optionally, add a custom log handler

for your rule.

 You can also use the default log

handler.

Required

When you create new logging rules, you can insert them into existing logging rule sets or create
new rule sets for them. These must be nested themselves in top-level rule sets known as log
handlers. You can also use the Default log handler for inserting new logging rule sets.

Complete these steps from the Policy > Rule Sets tab:
1. Click Log Handler.
2. At the top of the log handler tree, click Add and from the drop-down list, select Log
Handler. The Add New Log Handler window opens.
3. Configure the window, as follows and then click OK and Save Changes:
• In the Name field, type a name for the log handler.
• Make sure Enable is selected.
• Optionally in the Comment field, type a plain-text comment on the log handler.
• Optionally, click the Permissions tab and configure who is allowed to access the
log handler.

19
 Defining User Defined Properties
Policy > Rule Sets > User Defined Properties

Store user or group attribute in separate User

Defined Property.

Another helpful tool for creating logging rules use the User Defined Property features. It allows
you to store a user or group attribute in a separate User Defined Property for logging and other
purposes.

20
 Syslog Configuration
Configuration > File Editor>rsyslog.conf

Modify syntax of system file.

Sometimes it is necessary to modify system files. When this is necessary, use the File Editor
(Configuration > File Editor). As shown in the figure, you can use the File Editor to change a
specific line in the file.

21
 Use Cases

1. Log all requests sent from a particular client that are invalid or blocked.

2. Apply logging rule when a requested web object is found to be infected.

3. Add log file entry for destination IP address of client request received on Web
Gateway.

How would you implement these policies?

What are some other use cases?

As we bring it all together, let us look at some use cases. How would you implement these
policies? Remember, there are different ways to implement the same policy.

22
 Use Case 1

Log all requests sent from a particular client that are invalid or blocked.

In the first use case, we will log all requests sent from a particular client with invalid or blocked
responses.

23
 Use Case 2

Apply logging rule when a requested web object is found to be infected.

In the second use case, we will apply a logging rule when a requested web object is scanned
and determined to be infected.

24
 Use Case 3

Add log file entry for destination IP address of client request received on Web
Gateway.

In the third use case, we will log the file entry for destination IP addresses of client requests
received on the Web Gateway.

25
Knowledge Check

26
Check your Learning
Multiple choice: Choose the correct answer.

Which log is system-generated?

A. audit.log
B. access_denied.log
C. foundViruses.log
D. licenceIncident.log

Answer: A. audit.log. See System Log Files.

27
Check your Learning
True - False

A best practice is to edit the access.log to facilitate content

export to a supported reporting application.

A. True
B. False

Answer: B. False. See User-defined Log Files.

28
Check your Learning
Multiple choice: Choose the correct answer.

By default, system log files are deleted after:

A. 7 (seven) days
B. 10 (ten) days
C. 30 (thirty) days
D. 60 (sixty) days

Answer: A. 7 (seven) days. See Log File Manager Settings: System Log Files.

29
 Review

 Web Gateway maintains system Log files. They are useful for troubleshooting.
 You can view system log files using Web Gateway interface or command line.
 System log files are not pushed to a reporting application because these
applications do not parse system logs. The log information is discarded.
 User-defined log files are defined by logging rules.

• Web Gateway maintains system Log files. They are useful for troubleshooting.
• You can view system log files using Web Gateway interface or command line.
• System log files are not pushed to a reporting application because these applications do not
parse system logs. The log information is discarded.
• User-defined log files are defined by logging rules.

30
 Lab Exercises
Lab 15: Logging

 Goals:
 Create custom log file
 Create a rule that separates log information from specific user
 Export logs via syslog
 Duration:
 45 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals, required
systems, and any files needed to complete the lab; for example, text files or executables. At the
top of each lab, there is a scenario. The scenario often contains the information needed to
complete the lab. Beneath each scenario, there are detailed steps. The steps are supplied as a
resource, in the event you need additional information to complete the lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

31
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

32
Module 16: Dashboards and Reports

1
 Module 16 Objectives

 Access, navigate, and interpret the Web

Gateway dashboard.

 Use the different methods to filter alerts on the

dashboard.

• Access, navigate, and interpret the Web Gateway dashboard.

• Use the different methods to filter alerts on the dashboard.

2
 Web Gateway Dashboard: Overview – Standalone
Monitor Web Gateway Operation and Performance in brief

Standalone Configuration:
 Status and alerts for a single system

When you log into Web Gateway, the first page you see is the Dashboard. This page lets you
monitor Web Gateway traffic and operations, briefly. If the appliance part of a Central
Management configuration, you also see information for the other appliances (nodes).

3
 Web Gateway Dashboard: Overview – Central Management
Monitor Web Gateway Operation and Performance in brief

Central Management Configuration:

 Status and alerts for managed systems
 Alerts are consolidated for all appliances

When you log into Web Gateway, the first page you see is the Dashboard. This page lets you
monitor Web Gateway traffic and operations, briefly. If the appliance part of a Central
Management configuration, you also see information for the other appliances (nodes).

4
 Alerts Tab: Appliance Status
Standalone Configuration

 Appliance Name
 Performance Metrics
 Anti-Malware Versions
 URL Filter

The Dashboard is divided into two tabs. We will first look at the Alerts tab. At the top of this tab,
you see a horizontal bar called Appliance Status, which has columns.

The first column is Appliance Name. The Web Gateway shown has a standalone configuration,
so only one appliance are listed.

The next column is Performance. This shows alert peaks from the last seven days and the
requests per second.

Next is Trellix Anti-Malware Versions. Update and version information for engines and DATs is
displayed.

Last is URL Filter, which displays update and version information.

5
 Alerts Tab: Alerts
Filtering Options for Alerts

 Appliance Filter
 Date Filter
 Message Filter (Error, Warning, Information)
 Keyword Search

The next horizontal bar is called Alerts. There are many filtering options for alerts.

Use the Reset Filters button to reset all settings back to their default values.

6
 Alerts Tab: Alerts (Continued)
Filtering by Appliance

Use the Appliance Filter to select the appliances you wish to

filter on. You can:
 Select each SWG or All or None or Invert your current
selection
 You can also type in the name to find the appliance

The first filter on the left is called Appliance Filter. Clicking the drop-down allows the
administrator to filter by appliance.

Use the Reset Filters button to reset all settings back to their default values.

7
 Alerts Tab: Alerts (Continued)
Filtering by Date

Use the Date Filter to select the date or date range

to filter the alerts shown on the Dashboard.
 Select All, Today, Yesterday or Last Week
 You can select Other and pick the starting and
ending date

The next filter is called Date Filter. Clicking the drop-down allows the administrator to filter by a
date; all, today, yesterday, last week, or custom. The time can also be entered for more granular
filtering.

Use the Reset Filters button to reset all settings back to their default values.

8
 Alerts Tab: Alerts (Continued)
Filtering by Message Type

Use the Message Filter to

show the different types of
messages on the Dashboard
by severity.
 The default has all three
Message types enabled
 You can deselect one or a
combination to get the
desired information

Next are the Message Filters. The first set allow filtering by message type; Error, Warning, and
Information. The next one allows filtering by a term that is typed into the “Type to filter alerts”
field.

Use the Reset Filters button to reset all settings back to their default values.

9
 Alerts Tab: Alerts (Continued)
Filtering by Search Terms

You can use the Search field to filter the alerts shown on the
Dashboard.
You can type any term and the Dashboard will filter the view.
There is a Reset Filters button to clear out any filtering previously
used.

You can use the Search field to filter the alerts shown on the Dashboard, you can type any term
and the Dashboard will filter the view.

Use the Reset Filters button to reset all settings back to their default values.

10
 Charts and Tables Tab: Default Reports
20+ Different Reports

Use the Charts and Tables tab to view reports for multiple Web Gateway items.

In a central management configuration, use the drop-down to select an appliance.

11
 Charts and Tables Tab: Executive Summary Report

Executive Summary Report

URL Executive Summary - Shows how numbers of requests evolved during the selected interval
and sorts them into allowed (“good”) requests and requests blocked by filtering rules for viruses
and other malware, URLs, and media types.

Categories by Hits - Shows the URL categories that were requested most often within the
interval selected for the summary.

Malwares by Hits - Shows the virus and malware types that were requested most often within
the interval selected for the summary.

12
 Charts and Tables Tab: System Summary Report

System Summary Report

Network Utilization - Shows how numbers of requests sent and received evolved during the
selected interval.

System Utilization - Shows how usage of hard disk, CPU, physical memory of the appliance
system, and the physical memories of the core and coordinator modules evolved during the
selected interval.

13
 Charts and Tables Tab: System Summary Report (Continued)

System Summary Report (Continued)

Update Status - Shows the versions of several modules and filter information files that are
implemented on the appliances, for example, of the Gateway Antimalware engine or of the anti-
malware signature files.

Last Update - Shows when several modules of the appliance were last updated, for example,
the URL Filter module.

Open Ports - Lists the ports on the appliance that are currently listening to requests.

WCCP Services - Shows status of WCCP services used to redirect traffic to the appliance.

Note: System Summary > Number of Active Proxy Connections shows Active Client/Proxy
Connections.

14
 Charts and Tables Tab: Traffic Volume Report

Traffic Volume Report

Top-Level Domains by Bytes Transferred - Lists the domains that were requested most
according to the amount of bytes transferred from them.

Top-Level Domains by Number of Requests - Lists the domains that were requested most
according to the number of requests for them.

Destinations by Bytes Transferred - Lists the destinations that were requested most according
to the number of bytes transferred from them.

Destinations by Number of Requests - Lists the domains that were requested most according to
the number of requests for them.

15
 Charts and Tables Tab: Malware Statistics Report

Malware Statistics Report

Malware URLs by Hits - Lists the URLs infected by viruses and other malware that were most
requested.

Malware by Hits - Lists the malware types that most requests were made for.

16
 Charts and Tables Tab: URL Filtering Statistics Report

URL Filtering Statistics Report

Category - Shows how numbers of requested URL categories evolved during the selected
interval.

Reputation - Shows how numbers of requests evolved during the selected interval and sorts
them according to the reputation of the requested URLs.

17
 Charts and Tables Tab: URL Filtering Statistics Report
(Continued)

URL Filtering Statistics Report (Continued)

Categories by Hits - Lists the URL categories that were most requested.

Sites not categorized by Hits - Lists among the sites that are not categorized those that were
most requested.

Malicious Sites by Hits - Lists among the sites that were found to be infected those that were
most requested.

Top Blocked URLs – List the top sites that were blocked by URL filtering.

18
 Charts and Tables Tab: System Details Report

System Details Report

Network Utilization - Shows how numbers of requests sent and received evolved during the
selected interval.

CPU Utilization - Shows how CPU usage evolved during the selected interval.

Memory Usage - Shows how usage of memory evolved during the selected interval.

Swap Space (Virtual Memory) Usage - Shows how usage of virtual memory evolved during the
selected interval.

File System Utilization - Shows how usage of the file system evolved during the selected interval.

File System Utilization - Shows usage of the file system per partition.

Open TCP Ports - Shows how numbers of open TCP ports evolved during the selected interval.

19
 Charts and Tables Tab: Performance Information Report

Performance Information Report

You can view performance information about several appliance functions on the dashboard.

20
 Charts and Tables Tab: Custom Reports
Unique Options Based on Report Type

Each individual report on the charts and tables tab will have customization options unique to
that report.

The options to customize this report include the reporting time period format and the view.
Additionally, each section allows an administrator to enable or disable the performance items
that are reported up.

For general performance, these are DNS lookup, connect to server, and used by rule engine.
Detailed HTTP performance also has items that can be enabled or disabled.

While not a customization option, it is important to know that every report and report section
has a refresh button.

21
Knowledge Check

22
Check your Learning
True - False

What are the four main ways of filter Alerts on the Dashboard?
(Choose all that apply)

A. Date
B. Appliance
C. Message Type
D. Keywords
E. All of the above

Answer: E. All of the above. See Alerts Tab: Alerts

23
Check your Learning
Multiple choice: Choose the correct answer.

The alerts on the Dashboard are consolidated in a Central

Management cluster with multiple appliances.

A. True
B. False

Answer A. See Alerts: Central Management

24
 Review

 Web Gateway provides dashboards for monitoring and analysis.

• Web Gateway provides dashboards for monitoring and analysis.

25
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

26
Module 17: Content Security Reporter

1
 Module 17 Objectives

 Recall deployment requirements for Content

Security Reporter.
 Generate and interpret reports using the
Content Security Reporter.

• Recall deployment requirements for Content Security Reporter.

• Generate and interpret reports using the Content Security Reporter.

2
 Content Security Reporter Overview
Identify and Analyze Network Activity

Bandwidth

CSR
Security
Liability

Productivity

CSR identifies and analyzes network activity. It collects and manages the data from your
integrated alert, authentication, email, and web devices. This data helps you identify these
potential issues:

• Bandwidth consumption (overload)

• Liability exposure or risk
• Productivity
• Security threats

Once identified, you can use this information to modify your policies and effectively enhance
network protection.

3
 Content Security Reporter Overview
How it works

Content Security Reporter

(CSR) ePO

Log Source Logs Report Server Console

Collects alert, Dashboards
authentication, Organizes your data in a
and web data customized view to
provide detailed
information for analysis.

Database
Query Filter
Central data Reports
storage Retrieves Limits the data set
data from the Combines queries, filters,
component to specific and other elements into
database usernames,
and defines PDF documents to provide
websites, and detailed information for
how it is reputations
displayed analysis

On managed systems, an alert or event occurs. Depending on your configuration, the alert or
event is logged to the Content Security Reporter database.

The Content Security Reporter database saves the alert, authentication, email, and web data.

Web Gateway captures and logs the web event. It sends the logs to the Content Security
Reporter database.

Advanced Threat Defense captures and logs the event. It sends the logs to the Content Security
Reporter database.

A Content Security Reporter query retrieves data from its database and defines how it is
displayed.

A Content Security Reporter filter limits the data to specific users, websites, and threat
reputations. The data is displayed in the Trellix ePO.

Dashboard — Organizes your data in a customized view to provide detailed information for
analysis.

Report — Combines queries, filters, and other elements into a PDF to provide detailed
information for analysis.

4
 Planning
Platform, Database and ePO Server requirements

Client Customer
Requirements Hardware Requirements
Platform Category
• Hardware: x86_64 Intel/AMD 64-bit Small • Processor: 2.30 GHz (4 Core)
• Supported Microsoft Windows operating • Memory (RAM): 8 GB
system: •
Medium Processor: 2.30 GHz (8 Core)
64-bit – Windows Server 2019 • Memory (RAM): 24 GB
– Windows Server 2016 •
Large Processor: 2.30 GHz (16 Core)
– Windows Server 2012 • Memory (RAM): 32 GB
– Windows Server 2012 R2

Supported Supported
Database Requirements ePO Version
Databases ePO Servers
Microsoft SQL Server 2017
Microsoft SQL Server 2019
Trellix 5.10.x
MySQL 5.5
MySQL 5.6
MySQL 5.7

Prior to deployment, verify a supported Microsoft Windows operating system is installed on the
client you plan to use to generate reports.
For more information, see Technical Article KB83557 - Supported Platforms, Environments, and
Operating Systems for Content Security Reporter 2.x.
Another consideration is a supported version of Microsoft SQL Server software. It provides the
database to store the data for your environment.
The minimum supported ePO version(s) are listed on the table.
Go to: https://www.mcafee.com/enterprise/en-us/support/product-eol.html, to verify EOL of
Trellix products.

5
 Deployment Overview
Workflow

•No charge with Web Gateway grant

Download number.
CSR Software
•Available on Product Download site.

Install •Run installation wizard.

CSR Software •When prompted, enter a passkey.

Set up •Download CSR extension for ePO.

ePO Server •Register Report Server. (Only one).

Set up Report •Configure log source, database, and

Server performance settings.

This shows the high-level workflow for deploying Content Security Reporter (CSR).

6
 Before You Begin
Installation Considerations

 Sizing determines the hardware and database requirements.

 There is no limitation to install CSR and ePO on the same server; however, it is
only recommended if the ePO server is dedicated to CSR.

 An external database is preferable.

The slide highlights installation considerations before deploying CSR.

7
 Downloading CSR Software
Download Software for Your Supported Operating System

The CSR product is free to all Web Gateway customers with a valid grant number and is
available for download from the Downloads page. Be sure to download the software
appropriate for your supported operating system.

8
 Installing CSR Software
Launch and Follow Setup Wizard
• Log on to the operating system as an administrator.
• Run the installation executable file you downloaded, then follow the on-screen
prompts.

After downloading the appropriate executable, launch the setup wizard. Proceed as instructed
on the screen to advance through the installation.

9
 Installing CSR Extension in ePO
Menu Page > Software > Extensions

 Obtained from Product Download site.

 Install .zip file. Do not extract first.

 Enables CSR functionality within ePO.

Once the CSR software installation is complete, install the Content Security Reporter extension
.zip file so it is available in ePO. The extension is available on the Product Download site.

1. From the ePO console, select the Menu page > Software > Extensions.
2. Click Install Extension.
3. Browse and select the extension and then click Open.
4. In the Install Extension window, verify the correct extension name displays in the box
and then click OK.
5. Wait while the extension is uploaded to the ePO server.
6. Verify the extension details and then click OK. Wait while the extension is installed.
7. After the installation is complete, you are returned to the Software Extensions page.
Review the details for the extension.

10
 Registering Report Server in ePO
Menu Page > Configuration > Registered Servers

 New Server
 Server Type = Report Server
 Name
 Notes (optional)
 Server Name or IP Address (CSR
host)
 Server Port (CSR host)
 Passkey

There is only one registered report server per CSR deployment.

After the registration, the database server is added to the Registered
Servers page automatically. Do not change its default settings.

After installing the extension, register the Report Server with ePO. To register the reporting server
with at ePO:
1. From the ePO console, select the Menu page > Configuration > Registered Servers.
2. Click New Server.
3. Type a name and click Next.
4. From the Server type drop-down list, select Report Server.
5. In the Name box, type a meaningful name. Optionally type a comment in the Notes
box. Click Next to continue.
6. In the Server Name or IP Address box, type the name or IP address of the machine on
which the Content Security Reporter software is installed.
7. In the Server Port box, type the port number of the machine on which the Content
Security Reporter software is installed.
8. In the Passkey box, type the passkey defined previously.
9. Click Test Settings. A Test login successful message appears.
10. Click Save. The report and database servers are added to the list of registered
servers.

Note: There is only one registered report server per CSR deployment. After the registration, the
database server is added to the Registered Servers page automatically. Do not change its
default settings.

11
 Adding Log Source in ePO
Menu > Configuration > Report Server Settings Page > Log Sources

Specify log type (Name, Mode, Log format) and Logon

account to accept log files.
See next page for additional information.

Configure Web Gateway as a log sources for data used in dashboards and reports.

1. From the ePO console, select the Menu page > Configuration > Report Server Settings.
2. From the Setting Categories menu, select Log Sources.
3. From the Actions menu, select New. A New Log Source page opens.
4. Make sure Enable log source is selected (checked/ticked).
5. In the Name box, type a meaningful name and then type and confirm the password.
The credentials must match the Web Gateway push settings.
6. Optionally, change the defaults for Modes and Log format.
7. On the Sources tab below, create a logon account to accept log files from the
network device.
8. Click OK.

Log Sources Modes

Log sources modes depend on the ability of your network filtering device to send log data to
CSR. You can configure a log source by importing a single log file, or by using these options:

• Accept incoming log files: CSR accepts log data from network filtering devices.
• Collect log files from: CSR collects log data from network filtering devices or log data
storage devices.

Log Formats
Log formats determine how CSR processes (also called parsing) data from log files, and how
the data is stored in the database. CSR recognizes the structure of auto-discover and fixed-field
log formats.

12
 Configuring Log Settings in Web Gateway
Policy > Settings > Engines > File System Logging > Logging: Access Log

Enable specific
settings for user
defined log

After configuring the log source, your next step is to collect log information. You will do this from
the Web Gateway Interface.
1. Select Policy > Settings > Engines > File System Logging and click Access Log
Configuration.
2. The Name of the log and Log header values are prepopulated. Do not change them.
3. Make sure Enable log buffering and Enable header writing are selected
(checked/ticked).
4. Expand Settings for Rotation, Pushing and Deletion.
5. Click (check/tick) Enable specific settings for user defined log. Additional fields are
now visible.

Continued on the next page.

13
 Configuring Log Settings in Web Gateway (Continued)
Policy > Settings > Engines > File System Logging > Logging: Access Log

 Enable auto pushing

 Destination
 Username
 Password
 Enable pushing log file
directly after rotation

Click Change to open the password dialog to define or update the

password.

6. Scroll down to the Auto Pushing section and click (check/tick) Enable auto pushing.
7. Type the Destination using the appropriate format.
8. For Username, type something meaningful. Use “%h” as a best practice when using
pushing to more than one appliance (Central Management).
9. By Password, click Set. This opens a New Password dialog.
10. For the Password, enter a password (lower-case) and click OK.
11. Beneath the Password box, click (check/tick) Enable pushing log files directly after
rotation.
12. Click Save Changes.

Continued on the next page.

14
 Rotating and Pushing Log in Web Gateway
Configuration > Appliances > [appliance]

After completing the Access Log Configuration, manually push the log data. From the Web
Gateway Interface:
1. Select Configuration > Appliances > [appliance]; for example, mwg76.
2. At the top of the right pane, click Rotate and push logs.
3. After the rotate and push is complete, click OK.

15
 Verifying Log Push in ePO
Menu > Configuration > Report Server Settings > Log Sources

 View jobs
 Delete jobs
 Customize view with Preset
menu
 Search with Quick Find

As a final step, verify the data pushed successfully to ePO. From the ePO console:
1. Select the Menu page > Configuration > Report Server Settings.
2. In the left pane, expand Log Sources and then click Job Queue.
3. Note the successful jobs by the Web Gateway log source.

Other actions you can take are:

• Delete completed jobs.
• Customize your view with Preset menu; for example, filter by Waiting, Running,
Successful, Failed, Failed – Couldn’t Initialize, Completed – No files available,
Cancelled, and Database Unavailable.
• Search for a specific log with the Quick Find feature.

16
 Post Installation Activities
Performed in ePO

• CSR Dashboards
• CSR Queries & Reports
• CSR Permission Sets
• CSR Maintenance

Post Installation Activities:

• CSR Dashboards
• CSR Queries & Reports
• CSR Permission Sets
• CSR Maintenance

17
 Working with CSR Dashboards in ePO
Menu > Reporting > Dashboards

Default CSR
Dashboards

Dashboards allow you to watch and monitor the data collected within
your organization.
Use the default CSR dashboards and monitors or create custom ones.

After deployment, default CSR dashboards are available in ePO; however, you can create
custom ones:

• CSR: Domain/Site Analysis

• CSR: Email Activity
• CSR: Email Security Overview
• CSR: IP Address Analysis
• CSR: IPS Security Overview
• CSR: OTP Authentication Overview
• CSR: Productivity
• CSR: Web Activity
• CSR: Web Hybrid Activity
• CSR: Web Policy Enforcement
• CSR: Web Security Overview

18
 Example Dashboard
Custom Dashboard with Specific Monitors

The figure shows a custom dashboard. This dashboard was created to show specific monitors.

19
 Working with CSR Queries & Reports in ePO
Menu > Queries & Reports

CSR allows you to create and run queries and reports that provide Internet and email usage,
and IPS alert data in the form of charts and tables. The data for these queries and reports is
pulled from log data and is stored in the registered internal or external database. Use any of the
default queries and reports, or duplicate and modify existing queries and reports to create your
own for a customized view of your organization's data.

After deployment, these queries are available in ePO; however, you can create custom ones.

20
 Example Queries & Reports
Create Custom Queries and Run Reports Now or on Scheduled Basis

Bar Chart

Pie Chart

The figure shows two types of queries. The figure on the left shows a bar chart. The figure on the
right shows data in pie slices.

After creating queries, you can run reports immediately or schedule them to run automatically.

21
 Managing CSR Permission Sets
Menu Page > User Management > Permission Sets > [permission set]

No permissions by default

Optionally, create custom permission sets to control

access and usage for CSR features.

To configure permission sets for CSR, go to the Permission Sets page and edit an existing one or
create and configure a new one (Menu > User Management > Permission Sets > [permission
set]).

22
 Maintaining CSR
Menu Page > Configuration > Report Server Settings

 Server Status (time, version, updates)

 Log Sources (sources, jobs, processing,
and other settings)
 Database (process log database)
 Database Maintenance
 System Maintenance
 Performance Options (memory/cache)
 System Backup (manual backup)
Use this page to manage and
configure options that define  Support (feedback file)
log data used in reports and
CSR operation.

Use the Report Server Settings to manage and configure the options that define the log data
used in reports and how Content Security Reporter performs. The options are:

• Server Status: View server status and available updates.

• Log Sources: Manage log sources to collect the data displayed in dashboards and reports.
• Job Queue
• Custom Columns
• Custom Rule Sets
• Browse Time
• Database: Manage database used to process log data.
• Database Maintenance: Run database maintenance jobs.
• System Maintenance: Run system maintenance jobs.
• Performance Options: View and configure log processing and log processing summary
cache.
• System Backup: Run manual system backup.
• Support: Collect system information for troubleshooting.

23
Knowledge Check

24
Check your Learning
True - False

It is recommended that the Content System Reporter (CSR)

has its own database (does not share a database with ePO).

A. True
B. False

Answer: A. True. See Before You Begin

25
Check your Learning
Multiple choice: Choose the correct answer.

What is the maximum number of report servers you can

register with ePO?

A. 1
B. 2
C. 3
D. 4

Answer: A. 1 (one). See Deployment Overview.

26
Check your Learning
True - False

CSR reports are generated from the Web Gateway.

A. True
B. False

Answer: B. False. See Before You Begin.

27
 Review

 CSR deployment is not the same as Web Gateway and ePO integration.
 CSR uses ePO interface as a front-end to generate reports. The CSR database is
independent of ePO database.
 Reports are generated from CSR and sent to the ePO server.
 Database maintenance, backup and other administrative tasks are managed
separately.
 You can only register one report server per ePO server.

• CSR deployment is not the same as Web Gateway and ePO integration.
• CSR uses ePO interface as a front-end to generate reports. The CSR database is independent
of ePO database.
• Reports are generated from CSR and sent to the ePO server.
• Database maintenance, backup and other administrative tasks are managed separately.
• You can only register one report server per ePO server.

28
 Lab Exercises
Lab 17: Content Security Reporter

 Goals:
 Configure Content Security Reporter
 Experiment with reporting options

 Duration:
 25 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

29
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

30
Module 18: Reverse Proxy and Internet
Content Adaptation Protocol (ICAP)

1
 Module 18 Objectives

 Recall how Web Gateway works in Reverse

Proxy configuration.
 Recall how Web Gateway works in Internet
Content Adaptation Protocol (ICAP).

• Recall how Web Gateway works in Reverse Proxy configuration.

• Recall how Web Gateway works in Internet Content Adaptation Protocol (ICAP).

2
Reverse Proxy Configuration

3
 Reverse Proxy
Many organizations also have internal websites, which they make available to
internal (employees) or external users (contractors, partners, clients, and others)
who need to upload content to the site. These sites need to be protected against
attempts to upload infected content.

For this use case, administrators deploy Secure Web Gateway in reverse proxy
mode to scan and analyze content before allowing it to be uploaded to the target
site.

A reverse HTTPS proxy configuration can prevent clients from uploading unwanted data, such as
malware or particular media types, to web servers under the HTTPS protocol.

In this configuration, HTTPS traffic is redirected to an appliance that a proxy is run on. It is
inspected and eventually forwarded or blocked, according to the rules implemented on the
appliance.

Note: While it is technically feasible, it is not advised to run Forward & Reverse proxies on the
same appliance on a production environment.

4
 Reverse HTTPS Proxy
Enable External Users to Upload Content to Internal Web Sites

1. Load balancer sends content to Web

Gateway cluster for review.

2. Web Gateway receives files being

uploaded to Web Server.

3. Scans inbound content.

4. Content containing malware is blocked.

5. Clean content is forwarded to Web server

for processing.

Web Gateway can also be setup as a reverse https proxy to enable external users to upload
content to internal web sites.

With a reverse https proxy, an Internet user attempts to upload content to a web site.

A load balancer sends the content to a Web Gateway cluster which examines it. If the content
fails examination, Web Gateway returns a block page to the user. If the content passes
inspection, the load balancer forwards it to the web server for further processing.

Reverse https proxy mode does not require any additional software development other than
designing and creating block page responses that conform to the style of the site.

ICAP mode requires that an ICAP client be written and installed within the data flow of the
application.

5
 Setting up Reverse Proxy
 Enable the Web Gateway to listen to incoming HTTP/HTTPS requests in order to intercept
web traffic.
 Create a server certificate to encrypt all traffic between the proxy and the client.
 Reverse Proxy rule set should have a top-level criteria, so it applies to only the reverse
proxy traffic.
For example, criteria based on reverse proxy ports or URL.Host property matching the
backend web server hostname.
Reverse Proxy rule set may contain the following rules:
 Traffic redirection to HTTPS to secure Web Gateway – Client communication.
 Set client context and content inspection rule set for SSL traffic.
 Common rules and filters to inspect traffic like Anti-malware, media type filtering,
caching, progress indication etc.
 Rule set to restrict open access to the reverse proxy for example, by using a criteria such
as URL.Host.Belongs.To.Domain.
 Rule set to redirect traffic to the actual backend web server.
 Finally, re-write the HTML response to contain external server names.

Let us look at the typical Reverse Proxy configuration steps:

1. The first step is to enable the Web Gateway to listen to incoming HTTP/HTTPS requests in
order to intercept web traffic, typically port 80 and 443.
2. Next, you need to create a server certificate to encrypt all traffic between the proxy and the
client.
3. The Reverse Proxy rule set should ideally have a top-level criteria so that the rule set applies
to only the reverse proxy traffic.
4. A redirect HTTP to HTTPS rule set that allows the client to always talk securely with the Web
Gateway using an SSL tunnel so the traffic cannot be intercepted.
5. A Set SSL Client Context rule set that will allow the Web Gateway to terminate the SSL
Connection and issue the web server's certificate to the client. Also, a rule for SSL content
inspection.
6. Common Rules and Filters are some sample rule sets you can configure to inspect traffic,
similar to what you would have for forward proxy, such as Malware scanning, media type
filtering, caching, progress indication and many more.
7. It is very important to restrict access to your reverse proxy to prevent any internet user from
using it as an open forward proxy. We can do this with a simple rule that checks to see if the
request is for a resource that needs to be reverse proxied and if not then block that request.
8. The next rule set will redirect the requests received from the client to the backend web
server. There are many ways to do this.
9. Finally, the last rule set, allows re-writing the HTML response so the response would contain
the external server information instead of the internal web server.

6
 Setting up Reverse Proxy
Web Gateway HTTP/HTTPS Listen Ports
Enable the Web Gateway to listen to incoming HTTP/HTTPS requests in order to
intercept web traffic.

The first step is to enable the Web Gateway to listen to incoming HTTP/HTTPS requests in order to
intercept web traffic, typically port 80 and 443. It is important that an asterisk be entered for
'Ports treated as SSL' for the port 443 configuration as we want all traffic that comes in on port
443 to be treated as SSL encrypted traffic. You can configure this setting from Configuration >
Appliances > mwg1 > Proxies (HTTP(S), FTP, SOCKS, ICAP…).

7
 Setting up Reverse Proxy
Server Certificate

Create a server certificate to encrypt all traffic

between the proxy and the client.

Next, you need to create a server certificate to encrypt all traffic between the proxy and the
client. The certificate can be created under Policy > Settings > SSL Client Context without CA.

Ensure you enable the option "SSL-Scanner functionality applies only to client connection“.
Enabling this setting allows the Web Gateway to immediately perform the ssl handshake with
the client.

You can import the certificate from a trusted CA as well. Often is the case that most companies
will be using a Public certificate so that it is trusted by clients. Our method shown in this slide is
the exception, not the rule.

8
 Setting up Reverse Proxy
Top-Level Criteria
Configure top-level criteria
for the Reverse Proxy rule set.
Only traffic matching the
criteria will be inspected
through the reverse proxy
rules.

• In the lab example, Web

Gateway is configured to
reverse proxy traffic on
port 80,443 for
hfs.mcafee.edu
(10.10.10.52) web server.

The Reverse Proxy rule set should ideally have a top-level criteria so that the rule set applies to
only the reverse proxy traffic. For example, the criteria are based on a Reverse Proxy Ports list
with 80, 443 ports defined in it and on the URL.Host matching to the web server hostname.

9
 Setting up Reverse Proxy
Rule Sets
Traffic redirection to HTTPS to secure Web Gateway – Client communication.

A Redirect HTTP to HTTPS rule set that allows the client to always talk securely with the Web
Gateway using an SSL tunnel so the traffic cannot be intercepted.

10
 Setting up Reverse Proxy
Rule Sets
Set client context and content inspection rule set for SSL traffic.

A Set SSL Client Context rule set is available to allow the Web Gateway to terminate the SSL
Connection and issue the web server's certificate to the client.

11
 Setting up Reverse Proxy
Rule Sets
Common rules and filters to inspect traffic like Anti-malware, media type filtering,
caching, progress indication etc.

Common Rules and Filters are some sample rule sets you can configure to inspect traffic,
similar to what you would have for forward proxy, such as Malware scanning, media type
filtering, caching, progress indication and many more. These settings are customizable to your
requirements.

12
 Setting up Reverse Proxy
Rule Sets
Rule set to restrict open access to the reverse proxy for example.

It is very important to restrict access to your reverse proxy to prevent any internet user from
using it as an open forward proxy. We can do this with a simple rule that checks to see if the
request is for a resource that needs to be reverse proxied and if not then block that request. In
this example the property URL.Host.BelongsToDomain has been used.

13
 Setting up Reverse Proxy
Rule Sets
Rule set to redirect traffic to the actual backend web server.

The next rule set will redirect the requests received from the client to the backend web server.
There are many ways to do this. It can be HTTP or HTTPS communication with the backend
server. If the internal server is used to host more than one domain or site, the host header can
also be re-written at this rule set.

You can also configure Next Hop proxy considering the client cannot be redirected to an internal
server not accessible publicly. Configure Next hop proxy allows the reverse proxy to retrieve
resources from a destination that was not the original destination send over by the client and
sent it back to the client as if it was. Using the next hop proxy method also adds the benefit of
load balancing and failover for the web servers if you add more than one next hop proxy
definition HTTPS.

14
 Setting up Reverse Proxy
Rule Sets
Re-write the HTML response to contain external server names.

Finally, the last rule set, allows re-writing the HTML response so the response would contain the
external server information instead of the internal web server.

15
Internet Content Adaptation Protocol (ICAP) Server
Configuration

16
 Internet Content Adaptation Protocol (ICAP)
ICAP provides a standard lightweight mechanism for a web server (the ICAP client)
to send content to an ICAP server for some further, specialized action.

Web Gateway, acting as an ICAP server, can perform a full range of malware
analysis and scanning. Files infected with malware can be prevented from
contaminating the web server, while files free of malware can be processed.

You can let Web Gateway appliances take the roles of servers and clients with web traffic going
on between them under ICAP.

Under this protocol, an ICAP server modifies requests and responses when communicating with
ICAP clients. Traffic can, therefore, go on in what is known as the REQMOD and the RESPMOD
mode.

17
 Web Gateway as ICAP Server
Web Gateway functions as ICAP server to perform full range of malware scanning
and analysis
1. User attempts to upload the file directly
to web server (ICAP client).
2. ICAP client transmits the file to Web
Gateway (ICAP Server).
3. If the file does not pass inspection the
ICAP client takes an appropriate
corrective action based on the business
logic of the ICAP application.
4. Clean content is forwarded to the Web
Server for processing.

You can also utilize the Internet Content Adaptation Protocol (ICAP), to offload processing from
the web server to a Web Gateway.

Here, the users upload content to the web server (ICAP client). The ICAP client intercepts and
forwards content to a Web Gateway (ICAP server) for malware analysis. If the file passes
inspection, Web Gateway notifies the web server to continue processing it. If the file fails, Web
Gateway takes the appropriate corrective action, such as deleting the file, based on the
business logic of the ICAP application.

18
 Setting up ICAP Server

Enable ICAP server configuration for Web Gateway.

Create an ICAP top level rule set with a criteria to inspect only ICAP traffic.

Create rules to inspect ICAP traffic with appropriate responses configured under
events for ICAP client:

• Content type filtering

• Malware filtering etc.

On a Web Gateway appliance that you want to act as an ICAP client, implement the ICAP
Client rule set.

Configure servers that communicate with the clients in REQMOD mode.

Configure servers that communicate with the clients in RESPMOD mode.

19
 ICAP Server Setup
Web Gateway Configuration
Enable ICAP server configuration for Web Gateway.

Enable Web Gateway as an ICAP server under Configuration > Appliances > mwg1 > Proxies
(HTTP(s), FTP, SOCKS, ICAP…) > ICAP Server. The default listen address is 0.0.0.0:1344 but can be
modified as per requirement.

20
 ICAP Server Setup
Top-level Criteria

Create an ICAP top level rule set with a

criteria to inspect only ICAP traffic.

Create a top-level rule set for ICAP rules and configure a criteria to only inspect ICAP traffic
through the ICAP rules. To do this you can create a criteria such as Connection.Protocol equals
“ICAP”.

21
 ICAP Server Setup
Rule Set
Create rules to inspect ICAP traffic such as content type filtering, malware filtering
etc.

Create ICAP rules as per your requirement. In the current example, media type filtering and anti-
malware filtering has been configured.

22
 ICAP Server Setup
Rule Set – Events
Configure events to send appropriate responses to the ICAP client.

Add Block Reason

and Block ID to the
ICAP response.

Add
Antimalware.VirusNa
mes to the ICAP
response.

You must configure rule events to return appropriate responses to the ICAP client. You can
configure to return Block.Reason, Block.ID, Antimalware.VirusNames etc. as a part of the ICAP
response header.

23
 Reverse Proxy vs. ICAP Server Configuration (Review)

Web Gateway as Reverse HTTP Proxy Web Gateway as ICAP Server

Web Gateway intercepts the content before it The Web server receives the content and
reaches the web server, processes it and then forwards it to Web Gateway for further
either blocks or forwards it depending on the analysis before processing it. The web server
results of the analysis. If the content is gains the benefit of having the ICAP server
blocked it never reaches the web server. perform more in-depth analysis, freeing up
resources on the web server.
Does not require any additional software ICAP mode requires that an ICAP client be
development. Only block pages need to be written and installed within the data flow of
designed to conform to the style of the site. the application.

The major differences between a reverse https proxy and an ICAP server configuration are:

• In reverse https proxy mode, the Web Gateway intercepts the content before it
reaches the web server, processes it, and then either blocks or forwards it, depending
on the results of the analysis. If the content is blocked, it never reaches the web server.
• In an ICAP configuration, the web server receives the content and forwards it to Web
Gateway for further analysis before processing it. The web server gains the benefit of
having the ICAP server perform in-depth analysis, freeing up resources on the web
server.

24
 Advantages of Reverse Proxy/ICAP Deployment Modes
• Enhances network security by isolating internal sites from direct contact by
external users.
• Protects internal websites against malware infection by contaminated content.
• Other security measures, such as data loss prevention (DLP) scanning or strong
authentication, can be applied in reverse proxy mode.
• Provides administrators with multiple deployment options, giving them the
flexibility to choose the most appropriate configuration.

The slide lists the key benefits of Reverse proxy/ICAP deployment modes.

25
Knowledge Check

26
Check your Learning
Multiple choice: Choose the correct answer.

Which Web Gateway proxy mode intercepts the content before

it reaches the web server?

A. Reverse Proxy mode

B. Internet Content Adaptation Protocol (ICAP)
C. Management mode

more details.
Answer: A. Reverse Proxy mode. See Reverse Proxy vs. ICAP Server Configuration (Review) for

27
 Review

 A secure web gateway configured in reverse proxy mode applies malware

detection rules to content being uploaded to, rather than downloaded from, a
website.
 Internet Content Adaptation Protocol (ICAP) enables administrators to off-load
malware scanning to a dedicated server to improve security and
overall performance.

• A secure web gateway configured in reverse proxy mode applies malware detection rules to
content being uploaded to, rather than downloaded from, a website.
• Internet Content Adaptation Protocol (ICAP) enables administrators to off-load malware
scanning to a dedicated server to improve security and overall performance.

28
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

29
Module 19: Advanced Management

1
 Module 19 Objectives

 Explain the purpose of the Central

Management feature and how it works.
 Explain the purpose of the Proxy HA.
 Explain the purpose of the REST interface and
how it works.

• Explain the purpose of the Central Management feature and how it works.
• Explain the purpose of the Proxy HA.
• Explain the purpose of the REST interface and how it works.

2
Central Management

3
 Central Management
What is it?
 Synchronizes policy between two or more Web
Gateway appliances.
 Everything under the Policy tab, along with the
admin accounts, is synced automatically.
 Each time a change is made, and “Save
Changes” is invoked, the change is propagated
to all cluster members automatically.
 This ensures filtering policy is same on all
appliances of the cluster.
 Settings under the Configuration tab are
unique for each cluster node, hence separate
networking configurations can be assigned on
each appliance.

Central Management is used to synchronize the configuration (policy) between two or more
Secure Web Gateway appliances. This is useful as it solves the problem of making duplicate
changes on each appliance. Everything under the “policy” tab, along with the admin accounts,
is synced automatically when creating the cluster. Each time a change is made, and “Save
Changes” is invoked the change will be propagated to all cluster members automatically. This
allows the administrator to ensure that filtering policy is the same no matter which appliance is
handling a given request.

Settings under the Configuration tab are unique for each cluster node. This allows the
administrator to assign separate networking configuration (IPs, routes, etc.) on each appliance.

Central management will also automatically sync a full configuration from every node to every
other node in the cluster. This means that it is only necessary to take a backup on one
appliance as that backup file will contain the full configuration for every cluster member.

4
 Central Management Overview
Key Components

• Central Management: allows for management of multiple appliances through

the use of nodes, node groups and scheduled jobs.

• Nodes: Secondary appliances joined for central management.

• Node groups: Logical grouping of nodes. Control how data is shared between
nodes.

• Scheduled jobs: Tasks configured to run at specified date and time.

A Central Management configuration is sometimes referred to as a cluster.

Central Management allows you to administer multiple appliances that you have set up within
your network as nodes in a common configuration. When administering a Central Management
configuration, you are dealing mainly with:

• Nodes: An appliance can be set up as a node that is connected to other nodes and
can send and receive data to and from them to perform updates, backups,
downloads and other activities.
• Node groups: Nodes are assigned to different types of node groups that allow data
transfer in different ways.
• Scheduled jobs: Data is transferred based on defined schedules.

A Central Management configuration is sometimes referred to as a cluster; however, it is a

cluster in the sense of a High Availability cluster with fail-over functions only if you configure the
Proxy HA (High Availability) mode for the proxy functions of the appliances that are involved.

5
 How It Works

Central Management
Cluster

 In a Central Management cluster, multiple Web Gateway appliances run as nodes.

 Each node is connected to the client systems in the network that direct their web traffic to
it for filtering purposes.

 Nodes are assigned to node groups for common administrative activities for cluster
members.

 Communication between notes is SSL-secured. Certificates and certificate authorities

(CAs) with private keys are implemented to enable this communication.

Central Management allows you to administer multiple appliances that you have set up within
your network as nodes in a common configuration. With this configuration, only one machine in
cluster accepts Web Gateway user interface connections.

Central Management communications is encrypted using a client certificate.

6
 Using Different Node Groups
Network group

 Member nodes of a network group exchange all Central Management communication (policy configuration and
“Save Changes” invocations) immediately with each other.

 Recommended to configure a unique network group for each physical location.

 One node from each network group of the cluster can then be made part of a common “Transit” network group.
All nodes in one location communicate through the Transit node with the rest of the cluster.

Runtime group

 Member nodes in a runtime group share runtime data including coaching, quota, authorized override and
pdstorage values.
 Recommended to have one Runtime group for each physical location considering users browse though multiple
proxies.

Update group

 Member nodes share engine updates (URL Filter, AV DATs and more).
 Recommended to have one Update group for each geographical location so only nodes of the same location with
fast connections and LAN links access engine updates. Different locations typically have slower connections, WAN
links and you do not want to utilize bandwidth on the large update files.

A node can belong to multiple Network groups but only one Runtime or Update group.

There are three different groups that are used to control the central management cluster:

• Network group: Allows node members to immediately connect to other node

members.
• Runtime group: Allow node group members to share runtime data with other node
members.
• Update group: Allows node members to share updates with other node members.

You can assign nodes to multiple Network groups but only one Runtime or Update group.
It is important to limit the amount of data being sent between nodes, especially in situation
involving international communications, load balancers, and high availability configurations.

7
 Node Groups Configuration Examples
Small-scale deployment

Tokyo New York

Transit
1 2 3 4

Node 1: Node 2: Node 3: Node 4:

Runtime Group: Tokyo Runtime Group: Tokyo Runtime Group: New York Runtime Group: New York
Update Group: Tokyo Update Group: Tokyo Update Group: New York Update Group: New York
Network Group: Tokyo Network Group: Tokyo, Network Group: New York, Network Group: New York
Transit Transit

In the reference configuration on the slide note the following:

• Nodes 1 and 2 are a part of the Tokyo Network group, exchanging all policy configuration with
each other.
• Nodes 1 and 2 are a part of Tokyo Runtime group, exchanging all runtime data with each
other.
• Nodes 1 and 2 are a part of Tokyo Update group, exchanging all engine updates with each
other.
• Nodes 3 and 4 are a part of the New York Network group, exchanging all policy configuration
with each other.
• Nodes 3 and 4 are a part of New York Runtime group, exchanging all runtime data with each
other.
• Nodes 3 and 4 are a part of New York Update group, exchanging all engine updates with
each other.
• Nodes 2 and 3 are a part of Transit Network Group. All policy configuration changes made in
any node of the cluster are exchanged across Tokyo and New York sites through the Transit
group nodes only.

8
 Node Groups Configuration Examples
Large-scale deployment

Tokyo New York

1 3

5 6

Toknet1 Transit Nynet1

7 8

2 4
Toknet2 Nynet2

Node Set 1: Node Set 2: Node Set 3: Node Set 4: Nodes 5,6,7,8:
Runtime Group: Tokyo Runtime Group: Tokyo Runtime Group: New York Runtime Group: New York Network Group:
Update Group: Tokyo Update Group: Tokyo Update Group: New York Update Group: New York Transit
Network Group: Network Group: Network Group: Nynet1 Network Group: Nynet4
Toknet1 Toknet2

As a best practice, we recommend only putting up to 10 nodes behind a single transit node. If
you have more than 10 nodes in a location, you should have more than one transit node and
create smaller network groups that are tied to the transit node.

Here’s an example with a larger cluster with nodes in Tokyo and New York. For the smaller
locations with one transit node, the Runtime and network groups use the same name.

Please note the following:

• Node Set 1 is a part of the Toknet1 Network group for exchanging all policy configuration
between them, Tokyo Runtime group for exchanging all runtime data and Tokyo Update
group for exchanging all engine updates.
• Node Set 2 is a part of the Toknet2 Network group exchanging all policy configuration
between them, Tokyo Runtime group for exchanging all runtime data and Tokyo Update
group for exchanging all engine updates.
• Node Set 3 is a part of the Nynet1 Network group exchanging all policy configuration between
them, New York Runtime group for exchanging all runtime data and New York Update group
for exchanging all engine updates.
• Node Set 4 is a part of the Nynet2 Network group exchanging all policy configuration between
them, New York Runtime group for exchanging all runtime data and New York Update group
for exchanging all engine updates.
• Nodes 5,6,7,8 are a part of the Transit Network group. All policy configuration changes made
in any node of the cluster are exchanged across Toknet1, Toknet2, Nynet1 and Nynet2 sites
through the Transit group nodes only.

9
 Configuring Central Management
Workflow

Log into Web Gateway interface.

Generate Cluster CA

Add appliance for Central Management.

Configure Central Management settings.

Verify synchronization of nodes.

The figure shows a high-level workflow for configuring Central Management.

10
 Central Management Settings
IP Address, Port, and Timeout (Seconds)

Must match
appliance

Synchronization
settings

The IP address for central management communication must match the IP of the appliance. If
you change the IP address of the appliance after initial installation this may be incorrect

You can change the port, but it must be same across all appliances in the cluster.

Timeout and attempt settings determine how often the node will attempt to push changes to
other devices in the cluster. The default timeout for connection is 120 seconds.

When working with Advanced Management Settings, some guidelines are:

• Node priority: This determines which node’s policy takes precedence if there are conflicting
policies. As a rule, the lower the number, the higher the priority.
• Allow a GUI server to attach to this node is enabled: If disabled, you will be unable to connect
directly to this appliance with a web browser to attempt to manage the cluster. If you only
want management to be performed on one Web Gateway, disable this setting on all other
appliances
• Allow to attach a GUI server from non-local host: Do not activate without consulting
Customer Support. This feature is used for troubleshooting only.

11
 Generating a Cluster CA
Configuration > Appliances

The first to step to create a Central Management cluster is to

generate a cluster CA and its private key to ensure secure
communication between Web Gateway appliance nodes.
1. On the UI of a Web Gateway appliance, navigate to
Configuration > Appliances.
2. Click Cluster CA.
3. Click Generate CA.
4. Generate new CA by providing Common Name and
Private key password.
5. Import CA for cluster certificates and private key to all
Web Gateway nodes of the cluster.

The first to step to create a Central Management cluster is to generate a cluster CA and its
private key to ensure secure communication between Web Gateway appliance nodes.
1. On the UI of a Web Gateway appliance, navigate to Configuration > Appliances.
2. Click Cluster CA.
3. Click Generate CA.
4. Generate new CA by providing Common Name and Private key password.
5. Import CA for cluster certificates and private key to all Web Gateway nodes of the cluster.

12
 Adding Appliance
Configuration > Appliances

By default, all nodes are a member

of the Network group all. They can all
talk to each other, and there is no
central manager node.

You can add an appliance as a node to a Central Management configuration and assign it to a
network group. Complete these steps from the Configuration page, Appliances tab:

1. On the Appliances toolbar, click Add. The Add/Join Appliance window opens.
2. In the Host name or IP field, type the host name or the IP address of another
appliance within your network.
3. From the Network group list, select a network group for the appliance.
4. Click OK. The window closes.

13
 Adding Appliance (Continued)

Blue arrow indicates which

appliance is connected to the
user interface.

Separate Dashboard for

each appliance.

After the node is added, it appears on the appliances tree. Its policies are overwritten by the
Web Gateway it is joining. After the initial join, all policies remain the same.

14
 Working with Policies
Synchronizes Entire Policy – No Exclusions!
If local policies are required, use rule set.

Identify processing machines with properties:

• Proxy.IP
• System.HostName
• System.UUID

Because all policies are synchronized between nodes, you must specify criteria to create local
rules specific to a Web Gateway. The easiest way is to use the Proxy.IP criteria. In the case
presented in the figure, the Rule Set US Proxy Rules is only be triggered if the Proxy.IP is in the list
US Proxy Servers. That list contains the IP address of all the US Web Gateway appliances. You
can also use the specific System.HostName or System.UUID.

If you only have minor differences in the regional policies (for example just different servers for
authentication), it is easy enough to keep one global policy and make the changes in just the
important rules

15
 Configuring Updates
Options
Central Update Server:
 Downloads updates from Internet.
 Distributes updates to other nodes.

Distributed Node:
 Does not contact Internet for updates.
 Waits for updates from the node
downloading updates.

Stand Alone Updates:

 Each node downloads updates
separately.
 No central distribution.
 No node accepts updates from others
 Same settings across all cluster
members.

The slide highlights update options.

16
Proxy High Availability

17
 Proxy High Availability Overview
Explicit Proxy with High Availability (HA) Functions

• Provides failover and load balancing without external load balancers.

• Recommended for smaller deployments or locations/offices within larger

deployment where external load balancer is not feasible.

• Key settings are Proxy HA, Director priority, and Virtual IPs.

The idea of a Proxy High Availability (HA) configuration is to introduce failover and load
balancing without the need for external load balancers. This setup is recommended for smaller
deployments or locations/offices within a larger deployment where an external load balancer is
not feasible.

18
 Configuring Proxy HA
Workflow

Join appliances in Central Management configuration.

See previous section.

Configure first appliance for Proxy HA.

Configure next appliance for Proxy HA.

Verify configuration.

The figure shows the high-level workflow for configuring Web Gateway for high availability.

19
 Configuring Proxy HA: Guidelines
Field Description
Network Setup Proxy HA
Numerical value for priority in taking director role.
 Director node: Highest priority (example 99).
Director priority
 Backup node: Lower priority than director (example 89).
 Scanning node only: 0 (zero).
 Director node itself configured as Scanner.
Scanners Table  Peer director node configured as Peer/Director
 Scanning only nodes configured as Scanner.
Shared IP address for HA cluster. Owned by active director and must be the same on all nodes.
Virtual IPs
Users select this address in their browsers.
For the director node, configure a TCP port as relay port. This is a port that the scanning nodes in
Relay port
the cluster will use to forward web traffic to external destinations
For the director node, set this interval as the time (in milliseconds) to elapse before the director
Probe Interval node sends the next probe packet to this node. Probe packets are sent to verify that a scanning
node is still alive. If you specify 0, no probe packets are sent.
Virtual router ID Used for the VRRP health checks. Default 51.

VRRP interface Interface used by VRRP for health checks. Default eth0.

Director nodes bind to their own IP address and port 9090 (default).
HTTP Listener address
Scanning only nodes listen unbound i.e., 0.0.0.0:9090

The table lists the properties to be configured for Proxy HA.

Configure the appliances in this cluster one after another. Configure one of them as the director
node and the others as backup nodes or as scanning nodes only. Select different values for the
various settings options depending on the particular role.

20
 Example Proxy HA Configuration
Active Director Node

Proxy HA
network setup

Scanners Table

Director priority

Virtual IPs

The figure shows key settings for the appliance to function as an active director node. The
network setup is set to Proxy HA mode.
• The director priority needs to be set first to enable other settings.
• The director priority for an active director is set to the highest say 99.
• The scanners table should be populated with the node itself as a scanner and the remaining
backup director nodes as peer/directors. Any scanning only nodes must be configured as
scanners. In the example on the screen:
• 10.10.10.41 is an active director, configured as a scanner node itself.
• 10.10.10.42 is a backup or secondary director node.
• 10.10.10.43 is a scanning only node.
• Virtual IP is set the same for all participating cluster members.

21
 Example Proxy HA Configuration
Secondary Director Node

Proxy HA
network setup

Scanners Table

Director priority
(lower than
active director)

Virtual IPs

The figure shows key settings for the appliance to function as a secondary director node.

The network setup is set to Proxy HA network setup.

The director priority is set to anything higher than 0, but less than the active director’s priority.

The scanners table should be populated with the node itself as a scanner and the remaining
backup director nodes as peer/directors. Any scanning only nodes must be configured as
scanners. In the example on the screen:
• 10.10.10.42 is a secondary director, configured as a scanner node itself.
• 10.10.10.41 is a peer director node.
• 10.10.10.43 is a scanning only node.

Virtual IP is set the same for all participating cluster members.

22
 Example Proxy HA Configuration
Scanning Nodes

Proxy HA
network setup

Director priority
set to 0

The figure shows key settings for the appliance to function as a scanning node.
• The network setup is set to Proxy HA mode.
• The director priority is set to 0 for a scanning node.
• No other configuration is available for a scanning node.

23
 Resolving Issues with a Proxy HA Configuration
The following measures can be taken when trying to resolve issues with a Proxy HA
configuration:
• Look up VRRP health check messages
• Find out which node blocked a request
• Test a node
• Identify the active director
• Turn a director node into a scanning node
• Inspect failure to distribute web traffic

Messages about the VRRP health checks are logged on an appliance system under:
/var/log/messages. These messages also inform you about whether an appliance is in director
or backup node status.

To find out which of the nodes in a High Availability cluster blocked a request, edit the user
message template for Block actions. Insert the System.HostName property.

To test the behavior of a particular node, enter only its IP address in the table of scanning nodes,
leaving out all other addresses, before operating the High Availability cluster.

To identify the active director node that owns the virtual IP address of the High Availability
cluster, set up an SSH session with each node. Then run the ip addr show command on each of
them.

When an issue occurred with a director node, you can change its role and turn it into a scanning
node that performs no other functions besides scanning. First, set the director priority for this
node to 0. Be sure to save what you configured here. Then, change the settings that you
configured on this node for the HTTP and FTP proxies with ports that listen to requests coming in
from the clients. These settings include the network interface IP address. Set this address to
0.0.0.0.

If all web traffic is processed on the director node or another single node instead of being
distributed to other nodes, it could have these reasons:
• The director node does not know about any other nodes because no IP addresses of other
scanning nodes have been entered in the scanner table.
• All traffic is coming from the same source IP address because there is a downstream proxy or
a NAT device in place. Then the usual behavior for load balancing is to direct this traffic to the
same node again and again.

24
REST Interface

25
 REST API Interface Overview # !bin/bash
# Set URL variable for access to REST
Representational State Transfer Interface interface

Used to send commands and make REST="http://localhost:4711/Konfigurator

changes with scripts, instead of Web /REST"
Gateway interface. ## Log on and authenticate
curl -c cookies.txt -H "Authorization:
Useful for automated routines and Basic YWRtaW46d2ViZ2F0ZXdheQ==" -X
interaction with third party devices. POST
"$REST/login"
## Create backup file
curl -b cookies.txt -X POST
"$REST/backup" -o filename.backup
## Log off again
curl -b cookies.txt -X POST
"$REST/logout"

Sample script to send request written using Bash

shell environment and CURL program. For more
information, see www.gnu.org/software/bash
and https://curl.haxx.se.

The REST interface on the Web Gateway allows a script to perform common Web Gateway
operations without logging into the Web Gateway user interface. This is useful for automated
routines and interaction with third party devices.

Important: A script file contains a list of commands to execute. Writing scripts requires
knowledge and experience in using a supported scripting syntax. For more information, see
www.gnu.org/software/bash and https://curl.haxx.se.

26
 Types of Scripts
Commonly Used Scripts are Reviewed in Lab

Login and logout Restart and shutdown

Commit changes Log file rotate and push

Backup and restore Licensing

Request version List management

System Configuration Engine Update

The slide highlights some actions you can perform with scripts. You will explore sample scripts
during the lab.

27
 Preparing Use of REST API over the Interface
Workflow

Enable use of the interface (Configuration >

Appliances > [appliance] > User Interface)

Add permission to access REST interface (Accounts >

Administrator Accounts)
Tip: Create a new administrator account and custom
role, instead of enabling REST access for all users.

The figure shows a high-level workflow for preparing the use of the REST interface.

28
 Enabling Use of REST Interface
Configuration > Appliances > [appliance] > User Interface

• Enable REST-Interface
over HTTP

• Enable REST-Interface
over HTTPS

REST interface connections are disabled by default.

Before any REST interface connections can be initiated, the listening port must be enabled to
accept REST commands. This can be done for HTTP or HTTPS and uses the same port as the
standard User Interface. By default, no REST connections are allowed to the Web Gateway.

29
 Adding Custom Role for REST Access
Accounts > Administrator Accounts > Roles

You must add permission to access the REST interface to an administrator role for those users
who work with the interface. Instead of adding access permission to an existing role, consider
creating a new role with this permission and name it, for example, REST Admin.

1. Select Accounts > Administrator Accounts.

2. In the Roles section, click Add.
3. Enable REST interface accessible.
4. Enable other management functions, as necessary; for example: Policy – Lists
accessible, Troubleshooting accessible, and List creation
5. Click OK and then Save Changes.

30
 Adding Custom Account for REST Access
Accounts > Administrator Accounts > Internal Administrator Accounts

You must add permission to access the REST interface to an administrator role for those users
who work with the interface. Instead of adding access permission to an existing role, consider
creating a new role with this permission and name it, for example, REST Admin.

1. Select Accounts > Administrator Accounts.

2. In the Internal Administrator Accounts section, click Add.
3. Type and confirm a password for the account.
4. Select the custom role created for REST access.
5. Click OK and then Save Changes.

31
Knowledge Check

32
Check your Learning
Multiple choice: Choose the correct answer.

What is the maximum number of Update groups to which a

Central Management node can belong?

A. One
B. Two
C. Three
D. Four

Answer: A. 1 (one). See Using Different Central Management Groups.

33
Check your Learning
True - False

The Proxy HA configuration provides failover and load

balancing without external load balancers.

A. True
B. False

Answer: A. True. See Proxy High Availability Overview.

34
Check your Learning
True - False

REST interface connections are enabled by default.

A. True
B. False

Answer: B. False. See Enabling Use of REST Interface.

35
 Review

 Central Management allows you to administer multiple appliances that you have
set up within your network as nodes in a common configuration.
 The Proxy HA configuration provides failover and load balancing without external
load balancers. It is recommended for smaller deployments or locations/offices
within larger deployment where external load balancer is not feasible.
 The REST interface lets you make changes to Web Gateway using scripts without
logging into the Web Gateway interface. It is useful for automated routines and
interaction with third party devices.

• Central Management allows you to administer multiple appliances that you have set up
within your network as nodes in a common configuration.
• The Proxy HA configuration provides failover and load balancing without external load
balancers. It is recommended for smaller deployments or locations/offices within larger
deployment where external load balancer is not feasible.
• The REST interface lets you make changes to Web Gateway using scripts without logging into
the Web Gateway interface. It is useful for automated routines and interaction with third party
devices.

36
 Lab Exercises
Lab 19: Advanced Management

 Goals:
 Configure Web Gateways for Central Management.
 Configure a High availability cluster.
 Configure REST interface.

 Duration:
 45 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

37
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

38
Module 20: Basic Troubleshooting

1
 Module 20 Objectives

 Recall possible problem areas.

 Identify and use troubleshooting tools and
resources.
 Perform a backup and restore.

• Recall possible problem areas.

• Identify and use troubleshooting tools and resources.
• Perform a backup and restore.

2
Connection Errors

3
 Common Connection Issues

Network ? Rule Sets or

Rules

Issue Network Rules

Cannot connect to a website. X
Timeout when connecting to a website. X
Blocked/not blocked when connecting to a X
website.
Delay when connecting to a website. X X

As an administrator responsible for managing the Web Gateway, you will learn that the most
common problem areas are network issues and rule set/rule issues.

As a rule, if you have connection issues or a timeout when trying to connect to websites, this is a
network problem.

If you experience a blocking issue, which should be allowed, examine your rules.

Both network problems and rule set/rule issues can cause delays when connecting to a
website. For these types of issues, it will be very important for you to gather relevant information
so you can determine a troubleshooting strategy.

4
 Connection Errors – Understanding HTTP 502's
The 502 message is used by the Secure Web Gateway to alert a client that a
connection to the destination could not be established or that the destination
provided an invalid response
 [08/Mar/2021:18:25:57 -0600] "" 10.10.67.4 502 "GET http://example.local/
HTTP/1.1" "" "-" "" 3126 "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2;
Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET
CLR 3.5.30729; .NET4.0C; .NET4.0E)" "" "0"

This will usually result in the client getting a block page from the Web Gateway and
this document will focus on three of the more common block messages that are
seen:
 Host Not Resolvable
 Bad Response
 Cannot Connect

The HyperText Transfer Protocol (HTTP) 502 Bad Gateway server error response code indicates
that the server, while acting as a gateway or proxy, received an invalid response from the
upstream server.

5
 Connection Errors – Host Not Resolvable
This message will be displayed if Web Gateway is unable to contact the DNS server
or if the DNS server returns a “No Such Name” response as seen in the example
below.

The filter used to display this was “(ip.addr==10.10.67.4 &&

(http.response.code==502||http.request)) || dns”

This message will be displayed if Web Gateway is unable to contact the DNS server or if the DNS
server returns a “No Such Name” response

To fix this issue the DNS would need to be configured with an “A” record for the reported URL. A
workaround could also be put in place on the Web Gateway’s hosts file.

6
 Connection Errors – Bad Response
This message is displayed in two common scenarios; If the Web Gateway receives
a response from the destination but the response is not a valid HTTP response or if
it does not receive a response at all within the default two-minute timeout.

The filter used to display the behavior below was “(ip.addr==10.10.67.4 ||

ip.addr==10.10.67.124) && (http.request|| http.response)”

Bad response error is generally displayed in scenarios; If the Web Gateway receives a response
from the destination but the response is not a valid HTTP response or if it does not receive a
response at all within the default two minute timeout or connection to destination is failed.

7
 Connection Errors – Cannot Connect
Each connection the Web Gateway makes to a destination begins with a TCP
three-way handshake. This handshake must occur before the Gateway can send
the HTTP request and if it fails then it will result in the “Cannot Connect” message.

The filter used to display this was “(ip.addr==10.10.67.4 &&

(http.response.code==502 || http.request)) ||(ip.addr==10.10.67.124 &&
tcp.port==80)”

The 502 message is used by the Secure Web Gateway to alert a client that a connection to the
destination could not be established or that the destination provided an invalid response. This
will usually result in the client getting a block page from the Web Gateway.

Each connection the Web Gateway makes to a destination begins with a TCP three-way
handshake. This handshake must occur before the Gateway can send the HTTP request and if it
fails then it will result in the “Cannot Connect” message.

The most common cause for the messages is presence of a firewall between the Web Gateway
and destination that is either configured to actively deny connections from Web Gateway to the
destination or to simply drop the packets. The destination could also be configured to actively
block or passively ignore these connections.

8
 Connection Errors – Next Hop Proxy Issues
Slowness experienced due to the next
hop proxy being marked as down
 To troubleshoot a slowness problem,
we recommend setting the Number
of retries to '3' and the After final
failure wait to '0', to ensure that Web
Gateway does not introduce extra
delay even if it detects that the NHP is
down.

Slowness is not a concern, but the

dashboard still indicates the Next Hop
Proxy is getting marked as down
 One reason SWG could mark the NHP
as down is if the SWG made an HTTPS
request (CONNECT) to the NHP but
received a response code back that
SWG associates with an unhealthy
Next Hop proxy.

If you've configured Web Gateway to use a Next Hop Proxy (NHP) to handle some of your web
traffic, you might have seen some dashboard alert warnings indicating that the NHP is down or
connection to it has failed. In many cases, when these alerts are triggered, the NHP you have
configured is not actually down.

9
Web Gateway Troubleshooting Tools

10
 Troubleshooting Tools
Web Gateway and Command Line
• Web Gateway Interface:
 Backup/Restore
 Log files
 Rule tracing
 Feedback
 tcpdump
 ping/nslookup/traceroute

• Command line:
 tcpdump
 netstat
 Manual review of log files in /opt/mwg/log/

The Troubleshooting page provides features for basic troubleshooting, as well as log files you
can generate to send to technical support for assistance. These features are:
Web Gateway Interface:
• Log files
• Rule tracing
• Feedback
• tcpdump
• ping/nslookup/traceroute
• Backup/Restore
Command line:
• tcpdump
• netstat
• Manual review of log files in /opt/mwg/log/

11
 Performing a Backup
Troubleshooting > [appliance] > Backup/Restore
Best practice before making configuration changes.

• Back up to file.

• Navigate to backup
location.

• Optionally, type
encryption password.

• Complete backup.

Performing a backup may not specifically be a troubleshooting tool, but it is a best practice
before making any changes to the configuration. Having a backup allows you to restore the
web gateway to its original configuration. The steps to perform a backup are very
straightforward. From the Troubleshooting page:

• In the left pane within the appropriate appliance group, select Backup/Restore.
• In the right pane, click Backup to file.
• Navigate to the backup location and click Save.
• Type an optional password if the backup should be encrypted and click OK.
• At the Backup successful window, click OK.

Notes:
When backing up the appliance configuration, you have the option of including the Single Sign
On (SSO) credentials in the credential store in the backup file. Likewise, when restoring, you have
the option of restoring the SSO credentials from the backup file to the credential store.

Make sure the UTF-8 character format is used on your administration system for Web Gateway
if you want to insert special characters, for example, German umlaut (ä, ö, ü), in passwords
required for encrypting and decrypting a backup.

12
 Restoring a Backup
Troubleshooting > [appliance] > Backup/Restore

• Restore from file.

• Continue with restore.
• Navigate to backup and
open file.
• Type password
(if applicable).
• Complete restore.
• Log back into interface.

Here are the steps to restore from a backup. From the Troubleshooting page:

1. In the left pane within the appropriate appliance group, select Backup/Restore.
2. Click Restore from File.
3. Follow the onscreen instructions and prompts to complete the restore.
4. Because restore automatically logged you out of the Web Gateway, you will need to
log back in once the restore is complete.

13
 Feedback Files Overview
Generate before Contacting Technical Support

Compilation of major configuration elements:

 Log files
 Packet tracing tcpdump
 Rule and connection traces
 Other configuration and diagnostic
details
Stored in /opt/mwg/log/ debug/feedbacks/
directory.

The feedback file is a compilation of major configuration elements, such as log files, rule and
connection traces, tcpdumps, and other configuration and diagnostic details. If you open a
ticket with technical support, you are often instructed to provide a feedback file. As a best
practice, create the file before contacting support.

When creating the file, be aware of the following:

• The file is stored in the /opt/mwg/log/debug/feedbacks/ directory.
• The process takes several minutes to complete.
• Because the file is typically large in size, only five files are kept at one time. As you
generate a new file, the oldest one is deleted.

14
 Creating a Feedback File
Troubleshooting > [appliance] > Feedback
Only five stored at a time. Oldest is deleted when sixth one is added.

Stops traffic while Web Gateway

creates the file and gathers more
accurate information.

View, Delete, Download, Copy Link

You can also create a feedback file from the command line by
typing: /opt/mwg/bin/feedback.sh.

The feedback script is used to collect large amounts of information from the Web Gateway. The
output of a feedback script is the best way to gather pertinent information about the customer’s
web gateway.

In the left pane of the Troubleshooting page for your appliance, click Feedback and then
complete these steps:

1. Make sure Pause running Skyhigh Secure Web Gateway to create a backtrace
(recommended) is selected.
2. Click Create Feedback File.
3. A feedback file is created and appears with its name, size, and date in the list under
Feedback file.
4. View the file now or download and save it for future analysis. Other actions are Delete
and Copy Link.

Note: You can also create a feedback file from the command line by typing
/opt/mwg/bin/feedback.sh.

15
 Log Files Overview
Useful Information for Configuration Changes and Troubleshooting

Log Folder Description

audit* Contains configuration changes.
debug* Contains debugging information.
migration Contains migration activities.
Mobile-device- Contains certificates for remote devices.
certificates
mwg-errors* Contains module errors.
scheduled-jobs Contains scheduled jobs information.
system Contains operating system activity.
update Contains information on module and file
updates.
* Commonly used troubleshooting log files

Although of the log folders contain information that is helpful, when troubleshooting you will
most likely be viewing the log files in the debug, mwg-errors, and user-defined-logs folders.
Additionally, to view log files on configuration changes, you would go to the audit folder.

16
 Reviewing Log Files
Troubleshooting > [appliance] > Log Files

View now or download for

future analysis.

You can also view log files

from the command line.

To view system log files from the Web Gateway interface, complete the below steps from the
Troubleshooting page of a selected appliance. You can also view log files from the command
line.

1. Click Log files.

2. Open a log file collection (for example, audit) and select a file.
3. Click View to review the file now or Download to save the file for future analysis.

17
 Packet Tracing Overview
Record Network Activities (tcpdump)

Monitor and display TCP

and other packets.

Analyze network
behavior, performance,
and applications.

Analyze network
infrastructure.

A useful tool for troubleshooting web gateway network problems is tcpdump. You can use it to:

• Monitor and display TCP and other packets.

• Analyze network behavior, performance, and applications.
• Analyze network infrastructure, including routing.

You can run a tcpdump from the user interface or from the command line.

Note: This tool is not unique to the Web Gateway. It is a command available on most UNIX/LINUX
operating systems.

18
 Commonly Used Switches
Specified at User Interface or Command Line
Switch Description
-i <interface> To filter by interface, type:
tcpdump –i <interfacename>
-s <snaplen> The number of bytes captured per packet.
To capture all bytes, regardless of size, type:
tcpdump -s 0
-w <filename> To write the output to a file using a raw data format that can be read by
Wireshark, type:
tcpdump –w <filename>
<expression> To filter by IP address, type:
tcpdump host <hostname or IP>
<expression> To filter by protocol, type:
tcpdump ip
tcpdump tcp
tcpdump icmp
<expression> To filter by port, type:
tcpdump port <portnumber>

The table highlights some commonly used switches for a tcpdump. You can specify these
switches when running a tcpdump from the user interface, as well as from the command line.

19
 Running a Packet Tracing
Troubleshooting > [appliance] > Packet Tracing

View now in
Wireshark.

You can also run a

tcpdump from the
command line.

In the left pane of the Troubleshooting page for your appliance, click Packet tracing and then
complete these steps:

1. In the Command line parameters field, type parameters for the packet tracing, as
needed.
2. Click tcpdump start. A feedback file is created.
3. To stop the ongoing generation of a packet tracing file, click tcpdump stop.
4. Using the items on the toolbar of the list, you can perform several file-related
activities, such as view or download a file.

Note: You can also run a tcpdump from the command line.

20
 Rule Tracing Central Overview
Troubleshooting > Rule Tracing Central

Rules pane:
View
processed
rules.

Traces pane:
Create and Details pane:
manage rule View details
traces. about rule
criteria.

Another helpful tool is Rule tracing central. This page provides a central location to create,
review, and manage rule traces. The page is organized by these panes:

• Traces pane: Create and manage rule traces.

• Rules pane: View processed rules.
• Details pane: View details about rule criteria.

21
 Using Rule Tracing Central: Traces Pane
Manage Rule Traces

The traces pane provides the following options:

• Appliance names list: Select a Web Gateway appliance within your network that you
want to import rule traces from or create, review, and manage rule traces on.
• Import: Import rule traces from the appliance directory or the local directory.
• Client IP address field: Enter the IP address of the client that is the source of the
requests rule processing is traced for.
• Go / Stop icon (cross): Start or stop the creation of rule traces.
• Go: Starts the creation of rule traces. After clicking Go, the button
shows the stop icon.
• Stop icon: Stops the creation of rule traces.
• Source: Select the source of rule traces that entries should be shown for on the traces
pane. Clicking the button displays a list of the zipped rule tracing files that you have
imported. After selecting a file, entries for the rule traces contained in the file appear
on the traces pane. The button then shows the name of the selected file. If you do not
select a file, entries for the rule traces that were created in the latest tracing are
shown.
• Action icons bar: View menu of actions for rule execution; for example, Block, Redirect,
Remove, Authenticate, Stop Cycle, Stop Rule Set, and Continue.
• Export: Export selected or visible traces.
• Clear: Clear traces.

22
 Using Rule Tracing Central: Cycle Pane
View Processed Rules

The rules pane provides the following options:

• Cycle: Select a cycle to display information recorded in a trace about the rule processing
that was performed in this cycle. If you select All, summarized information is displayed about
the processing in all cycles that were recorded in a trace.
• Search: Type a search term for information provided on rule sets and rules.
• Cycle column: Shows the cycle in which a rule set, or rule was processed. Request and
response cycles are represented by arrows in different colors. The meanings of these arrows
are as follows:
• Right arrow: Request cycle
• Left arrow: Response cycle
• No arrow pointing to the right (left): No processing in the request (response)
cycle.
• Hollow arrow: Rule set or rule processed, but no action executed (criteria did
not match).
• Gray arrow: Action executed, but not as the most impacting action in the trace.
• Green arrow: Stop Rule Set, Stop Cycle, or Continue executed as the most
impacting action in the trace.
• Yellow arrow: Remove executed as the most impacting action in the trace.
• Blue arrow: Authenticate executed as the most impacting action in the trace.
• Dark green arrow: Redirect executed as the most impacting action in the trace.
• Red arrow: Block executed as the most impacting action in the trace.
• Name column: Displays the name of a rule set or rule. If a rule set or rule uses a list in its
criteria, the criteria is shown below the name. A link to the list is then provided in the details
pane.

23
 Interpreting the Cycle Pane
Most Impactful Rules Have Solid Color
Arrow pointing right: Request Cycle (If hollow, triggered but
not processed).
Arrow pointing left: Response cycle (If hollow, triggered but
not processed).
Gray Arrow: Rule triggered but was not most critical action in
cycle.
Green Arrow: Rule triggered and was most impacting action in
cycle (Redirect, Stop Rule Set, Stop Cycle, or Continue Action).
Yellow Arrow: Remove action.

Blue Arrow – Authenticate Action.

Red Arrow – Block Action.

2 Red Arrow – Second Embedded Response Cycle Block Action.

Depending on the cycle and action taken by a rule, the arrow next to the rule or rule set in the
cycles pane is different color or direction. The most impactful rules have a solid color; for
example, Block, Authenticate, Stop Rule Set.

24
 Using Rule Tracing Central: Rules Pane
View Details about Rule Criteria

List content is never included in a rule trace.

The details pane provides the following options:

• Top Properties tab: Shows the criteria of the rule set or rule that is currently selected in
the rules pane.
• Details tab: Shows the criteria of the rule set or rule that is currently selected in the
rules pane.

Note: List content is never included in a rule trace.

25
 Rule Tracing Comparison
Rule Tracing Central and Rule Tracing Files

Rule Tracing Central:

• IP-based
• Initiated from the user interface
• Traces all rule activity for a single IP
• Analyzed from the Rule Tracing Central window

Rule Tracing Files:

• Rule-based
• Initiated by adding an event to a rule
• Traces all IP activity through that rule
• Analyzed from the Rule Tracing Central window

The two rule tracing options have similarities, but also important differences. Before we move on
to the next tool, here is a quick comparison:

• Rule tracing central is IP-based and initiated from the user interface by specifying a
single IP address. All rule activity for that IP address will be traced and displayed in the
Rule Tracing Central window.
• Rule tracing files is rule-based and initiated by adding an Enable RuleEngine Tracing
event to a rule. All activity through that rule is traced. The trace files display on the
Troubleshooting > Rule Tracing Files page. Selecting a trace file and clicking Analyze
transfers the trace data to the Rule Tracing Central window.

26
 Connection Tracing Overview
Configuration > Appliances [appliance] > Troubleshooting

 Only enable when needed.

 ALWAYS specify a specific IP to trace.
 Optionally, limit the size of connection tracing file.
 Data tracing can very quickly fill log file space. Turn off
when complete.

Connection Tracing record activities on connections between an appliance and other network
components. Before you begin, enable connection tracing (Configuration > Appliances >
[appliance] > Troubleshooting).

When working with this feature, remember the following:

• Only enable Connection Tracing when needed.

• ALWAYS specify a specific IP to trace.
• Optionally, limit the size of connection tracing file.
• Data tracing can very quickly fill log file space. Turn off tracing when data collection
complete.

27
 Working with Connection Traces Files
Troubleshooting > [appliance] > Connection Tracing

Client (C) or server (S) connection

Incrementing number
Protocol

Each time a rule is accessed a new file is created. Files are logged as .xml files.

Connection tracing is usually broken into client side (C) and the server side (S) connections. The
names of the connection traces consist of three parts:

• Protocol (HTTP, FTP, and so on)

• Incrementing number
• Connection type:
• C: Connection to the client
• S: Connection to the server
• CC: FTP control connection to the client
• CD: FTP data connection with the client
• SC: FTP control connection to the server
• SD: FTP data connection with the server

Supported actions from this page are View, Delete, Download, or Copy Link.

28
 Example of a Connection Trace

Here is an example of a typical Connection trace.

29
 Working with Core Files
Record Memory Content after Failure

Configuration > Appliances [appliance] > Troubleshooting

Core files record memory content after failure has caused appliance to terminate operation.
This feature is disabled by default. Before you begin, enable this feature (Configuration >
Appliances > [appliance] > Troubleshooting).

30
 System and Network Tools Overview
Troubleshoot Problems on Appliance

System Tools:
• service restart
• AV threads

Network Tools:
• ping and ping6
• nslookup
• traceroute and traceroute6
• ip neigh
• ntp

You can work with several system and network tools to troubleshoot problems on an appliance.
System Tools are service restart and AV threads. Network Tools are ping and ping6, nslookup,
traceroute and traceroute6, ip neigh, and ntp.

31
 Using System Tools
Troubleshooting > [appliance] > System Tools

The figure shows an example of the results for AV Threads.

32
 Display Running AV Threads
1. Select the Troubleshooting top-level menu.
2. On the troubleshooting tree, select System Tools, then click AV threads.

A list of the AV threads appears under Results.

For each thread, an ID number is shown, the time when the thread was started,
its current status, and other information.

Note: To export the thread list to a location within your file system, click Export and
specify the location in the window that opens.

You can display the threads that are currently running to perform anti-malware scanning
activities. Seeing many threads lets you know that scanning a particular request or response is
consuming a high amount of resources.

The list of threads that is shown includes the threads that perform scanning activities, as well as
the threads that deliver requests and responses to the scanning modules. Both kinds of threads
are referred to as anti-malware working threads or simply as AV threads.

33
 Using Network Tools
Troubleshooting > [appliance] > Network Tools

You can also initiate network commands from the

command line.

The figure shows an example of the results for ip neigh, which manipulates neighbor objects
that establish bindings between protocol addresses and link layer addresses for hosts sharing
the same link.

34
 Command Line Interface (CLI)
Useful Commands

• dig <host> • netstat –nr

• dmesg • netstat –sn Iface eth0
• dmidecode | grep UUID • nslookup
• ifconfig • ping and ping6
• ipneigh • ssh
• lsof –nPi | grep <port number> • tcpdump
• mwg status • traceroute and traceroute6

Other than troubleshooting, only use the command line at the request of technical
support. Make sure you have the Web Gateway software and a new configuration
backup before using the command line.

Some useful commands are:

• dig <host>: Perform DNS lookup on specified host.

• dmesg: Display kernel messages.
• dmidecode | grep UUID: View Gateway UUID.
• ifconfig: Display interface information.
• Ipneigh: Display the neighbor table.
• lsof –nPi | grep <port number>: See if appliance is listening on specified port.
• mwg status: See running processes and identify PIDs.
• netstat –nr: Show routing table.
• netstat –sn Iface eth0: Display statistics.
• nslookup: Query the DNS for resource records.
• ntp:
• ping and ping6: Send echo test to verify a connection.
• ssh: Allow remote administration.
• tcpdump: Display packet information.
• traceroute and traceroute6: Track route packets take.
• traceroute6: Track packet routes

Important: Other than troubleshooting, only use the command line at the request of technical
support. You can permanently damage the Web Gateway by running normal UNIX commands.
Always make sure you have the Web Gateway software and a new configuration backup before
using the command line.

35
Things to look out for when using in ICAP
ICAP is the same as using SWG in any other mode but has some additional areas
that can be viewed/looked for, using the same tools.
 Ensure you have access to the ICAP server from the ICAP client on port 1344
(telnet <serverip> 1344)
 Ensure that preview size is identical on client and server
 For policy issues use Rule Tracing
 If using ICAPS ensure both sides trust the CA used to sign the certificate used.
 For networking issues take a packet trace on port 1344 and the relevant IP
addresses and view in Wireshark

36
Knowledge Check

37
Check your Learning
Multiple choice: Choose the correct answer.

By default, how many Feedback Files are stored at a time?

A. 2 (two)
B. 3 (three)
C. 4 (four)
D. 5 (five)

Answer: D. 5 (five). See Creating a Feedback File.

38
Check your Learning
True - False

List content is not included in a rule trace.

A. True
B. False

Answer: A. True. See Using Rule Tracing Central: Rules Pane.

39
Check your Learning
True - False

It is recommended to keep connection tracing enabled at all

times.

A. True
B. False

Answer: B. False. See Connection Tracing Overview.

40
 Review

 Common problem areas are network issues and rule set/rule issues.
 Commonly used Web Gateway troubleshooting tools are Feedback, Log Files,
Packet tracing (tcpdump), Rule Tracing Central, and Rule Tracing Files.
 Other Web Gateway tools you may sometimes use are Core Files, Connection
Tracing, System Tools, and Network Tools.
 Enable Connection Tracing only when needed.
 ALWAYS specify a specific IP to trace.
 Optionally, limit the size of connection tracing file.
 Data tracing can very quickly fill log file space. Turn off when complete.
 Other than troubleshooting, only use the command line at the request of technical
support.
 Make sure you have the Web Gateway software and a new configuration backup
before using the command line.

• Common problem areas are network issues and rule set/rule issues.
• Commonly used Web Gateway troubleshooting tools are Feedback, Log Files, Packet tracing
(tcpdump), Rule Tracing Central, and Rule Tracing Files.
• Other Web Gateway tools you may sometimes use are Core Files, Connection Tracing,
System Tools, and Network Tools.
• Enable Connection Tracing only when needed.
• ALWAYS specify a specific IP to trace.
• Optionally, limit the size of connection tracing file.
• Data tracing can very quickly fill log file space. Turn off when complete.
• Other than troubleshooting, only use the command line at the request of technical support.
• Make sure you have the Web Gateway software and a new configuration backup before
using the command line.

41
 Lab Exercises
Lab 20: Basic Troubleshooting

 Goals:
 Use Web Gateway troubleshooting tools.
 Perform a rule trace.
 Duration:
 20 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

42
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

43
Module 21: Advanced Threat Defense
Overview and Integration

1
 Module 21 Objectives

 Recall the Advanced Threat Defense solution

and its key features.
 Identify the components in a basic ATD
deployment architecture.
 Identify the products with which ATD
integrates.
 Explain how ATD integrates with Web Gateway
(Web Gateway or SWG).

• Recall the Advanced Threat Defense solution and its key features.
• Identify the components in a basic ATD deployment architecture.
• Identify the products with which ATD integrates.
• Explain how ATD integrates with Web Gateway (Web Gateway or SWG).

2
 Challenge: Signature-less detection
Zero-day/targeted attacks for which signatures not readily available

Criminal
in nature – not Theft
just nuisance Sabotage Espionage
Evade
Stealthy legacy-
Targeted
Unknown based
Data loss
defenses Discovered
Costly clean-up
after the Fact
Long-term
damage

Key Challenges
 Existing blocking and prevention capabilities are insufficient to protect
against motivated, advanced attackers.
 Some attacks are not advanced; they are simply designed to bypass
traditional signature-based mechanisms.

Advanced malware refers to zero-day or targeted malware for which antivirus signatures are
not readily available. These attacks include Advanced Persistent Threats (APT), bots, Worms,
Trojans, and Viruses. Because there are usually no signatures advanced malware, these threats
are hard to detect. Your organization is likely receiving the first and only attack from the
malware.

Advanced malware is likely criminal in nature instead of a nuisance, and you probably only find
out about it after the attack has succeeded. Because traditional defenses are unlikely to block
these new threats, additional protection is needed.

3
 Solution: Advanced Threat Defense
Advanced detection for zero-day malware
• Advanced malware analysis appliance
deployed in existing network to detect
and protect against advanced stealthy
and targeted attacks.
• Centrally managed to streamline
workflows and expedite response and
remediation.

• Integrates with other security solutions

for threat information sharing across the
network, enhancing protection and
investigation.

Addresses three key requirements for advanced malware protection: Find malware, Stop
further attacks, and initiates actions across endpoints by providing intelligence to other
security products to Fix the problem.

ATD identifies and facilitates the detection and prevention of sophisticated, hard-to-detect
threats. It addresses the three key requirements to solve today’s advanced malware problem:
• Find: Files are sent from your existing security products (from network to endpoint) to
ATD for in-depth analysis, which identifies or FINDs malware.
• Stop: After analysis, ATD generates and makes available a hash and other meta data
for integrated security solutions to consume, instantly enable protection, and
effectively STOP further attacks.
• Fix: Initiates actions across endpoints by providing intelligence to other security
products.

4
 Key features
Multilayered defense mechanism against malware
Static Analysis (code unpacking): Static Analysis
Components
• Whitelist/Blacklist
• Embedded Gateway Anti-Malware Whitelist/Blacklist
Engine (GAM) for signature-less
emulation capability GAM Engine GTI
• Embedded Anti-Malware Engine for Anti-Malware
signature-based detection Engine
• Integration with Global Threat
Intelligence (GTI) for cloud-based look- Dynamic Analysis
ups Components
Predefined Android
Dynamic Analysis (sandboxing): VM
• Secure virtual machine (VM) to monitor
User-defined VMs
behavior for malicious activities

See Planning module for supported file type for analysis.

ATD native capabilities provide a multilayered defense mechanism against malware:

• It offers static code analysis that exposes original executable, enabling
analysis/accurate classification and deeper analyst-grade data.
• It includes a whitelist and blacklist. The whitelist is processed first.
• It integrates with Global Threat Intelligence (GTI) for cloud-lookups to detect malware
that has already been identified by organizations throughout the globe for both files
and URLs.
• It includes an embedded Gateway Anti-Malware Engine for emulation capability.
• It includes and embedded Anti-Malware Engine for signature-based detection.
• It dynamically analyzes files by executing them in a virtual sandbox environment.
Based on how the file behaves, ATD determines its malicious nature.

5
 Static analysis (code unpacking)
Removes obfuscation

Packing or protecting changes the composition of the code or obfuscates it to evade and
reverse engineering. Most products cannot properly unpack, but it is the only way to reveal the
original (source) executable code for analysis. Another reason to unpack a file is to evade
standard AV engines.

ATD includes extensive unpacking capabilities that remove obfuscation, exposing the original
executable code. It enables static code analysis to look beyond high-level file attributes for
anomalies and to reverse engineer the code, analyzing all the attributes and instruction sets to
determine the intended behavior.

6
 Local whitelist and blacklist
MD5 hash values

Whitelist Blacklist

 Trusted files (not scanned).  Known malware.

 Based on Application Control  Automatically added to file
database, with over 230,000,000 when malware level is
entries. determined to be 3 or higher.

Local Whitelist
This is the list of MD5 hash values of trusted files, which need not be analyzed. This whitelist is
based on the Application Control database that is used by other solutions in the suite. This has
over 230,000,000 entries. The whitelist feature is enabled by default. The static Application
Control database cannot be modified; however, you can add or delete entries based on file
hash. You can also query the white

The default whitelist entries are not periodically updated; however, they might be updated when
you upgrade the ATD software. When you upgrade the ATD software to build 3.4.8.190 and
above, MD5 added into the whitelist will be merged into Global Whitelist.

Local Blacklist
This is the list of MD5 hash values of known malware stored in the ATD database. When ATD
detects a malware through its heuristic Gateway Anti-Malware engine or through dynamic
analysis, it updates the local blacklist with the file's MD5 hash value. A file is added to this list
automatically only when its malware severity as determined by ATD is medium, high, or very
high. The blacklist is not pre-populated. You manage the blacklist using the command line
interface (CLS).

7
 Embedded anti-malware engines
Engine updates downloaded every 90 minutes

Anti-Malware Engine Gateway Anti-Malware Engine (GAM)

 Analysis of potentially malicious code

to detect and block Trojans, viruses,  Real-time analysis of web site behavior,
worms, adware, spyware, and other web site code, and downloaded Web 2.0
threats content
 Identification of intended behaviors  Preemptive detection and blocking
that might not surface immediately  Signatureless detection to protect against
through analysis of instructions and blended attacks, including viruses, worms,
properties adware, spyware, riskware, and other
 Detailed malware classification crimeware
information

ATD includes two embedded engines for malware detection: Gateway Anti-Malware Engine
(GAM) and Anti-Malware Engine.
By default, ATD downloads the updates for Gateway Anti-Malware Engine and Anti-Malware
Engine every 90 minutes. Manual update of DAT is not allowed. Multiple URLs are needed for the
updates to function properly.

Anti-Malware Engine
Using patented technology, the Anti-Malware Engine analyzes potentially malicious code to
detect and block Trojans, viruses, worms, adware, spyware, and other threats. This includes
analyzing all the instructions and properties to identify the intended behaviors, which might not
surface immediately. In addition, the engine provides detailed malware classification
information, widens the security cover, and identifies associated malware that leverages code
re-use.

Gateway Anti-Malware Engine

The Gateway Anti-Malware Engine analyzes the behavior of web sites, web site code, and
downloaded Web 2.0 content in real time to preemptively detect and block malicious web
attacks. In addition, it protects against modern blended attacks, including viruses, worms,
adware, spyware, riskware, and other crimeware threats, without relying on virus signatures.

8
 GTI Integration
File and Web Reputation

File Reputation:
• Compresses threat protection time period from days to milliseconds.
• Increases malware and zero-day detection rates.
• Reduces downtime and remediation costs associated with malware attacks.

Web Reputation:
• Protects against Web 2.0 threats, social engineering, and malware downloads.
• Increases awareness of online dangers.
• Blocks threats at the network edge.

GTI is a global threat correlation engine and intelligence base of global messaging and
communication behavior, which enables the protection of the customers against both known
and emerging electronic threats across all threat areas. The communication behavior includes
the reputation, volume, and network traffic patterns. ATD uses the File and Web Reputation
features of GTI.

Notes:
• A domain name system (DNS) must be configured for GTI to run.
• For File Reputation queries to succeed, make sure ATD is able to communicate with
tunnel.message.trustedsource.org over HTTPS (TCP/443). Advanced Threat Defense
retrieves the URL updates from List.smartfilter.com over HTTP (TCP/80).

9
 Dynamic analysis (sandboxing)
Executes suspicious file in secure virtual analyzers and monitors behavior for
malicious activities

For dynamic analysis, ATD executes a suspicious file in a secure virtual machine (VM) and
monitors its behavior for malicious activities. This VM is referred to as an analyzer VM.

When you create a VM profile, ATD creates an analyzer VM from the image file you selected in
the VM profile record. Simultaneously, it prints the logs, which you can view in the Advanced
Threat Defense web application. Through these log entries, you can view what is happening as
the analyzer VM is being created. You can use this information for troubleshooting purposes.

10
 Integration Overview
ATD and SWG

GTI & third-party feeds NSP SWG

Block
NSP SWG
Block
MAR
ATD Initiate
TIE ATD/CTD
Deep investigation
analysis MAR

Data Exchange Layer

SIA

ePO ESM Endpoint

Endpoi Servers
Server
Tag for Investigation/ Block/allow/
nt Block/allow/
s
investigation/ backtrace quarantine/ quarantine/
block additional additional
scanning scanning

Provides additional engine for malware protection.

In the following sections, we take a closer look at how ATD integrates directly with Web Gateway.
With this deployment type, ATD provides an additional engine for malware protection and
enables Web Gateway to automatically send suspicious files to ATD for further analysis.

11
 Integration Overview (Continued)
How It Works

1. Network user downloads file.

2. Web Gateway scans file and determines a malware score.
3. Based on score and file type, Web Gateway sends copy of file to ATD for deeper
inspection and dynamic analysis.
4. Based on reported severity level, Web Gateway determines if file is allowed or
blocked.
5. Malware details are available in log file.

When your network user downloads a file, the native Gateway Anti-malware Engine on Web
Gateway scans the file and determines a malware score.
Based on this score and the file type, Web Gateway sends a copy of the file to ATD for deeper
inspection and dynamic analysis.
A progress page informs the user the requested file is being analyzed for malware.
Based on the malware severity level that ATD reports, Web Gateway allows or blocks the
download.
If the download is blocked, Web Gateway displays a block page that provides the reason.
Malware details are available in the log file.

12
 Before you begin
Checklist

SWG is installed and operational.

 7.6.2 or later

You know:

 ATD IP address
 Password and user profile for SWG configured on ATD appliance

Before you begin, ensure the solution requirements are met. Note that solid knowledge of SWG is
required, as well as prior experience with policy and rule configuration.

13
 Integration workflow
ATD and Web Gateway

Log into Web Configure

Log into ATD Configure SWG
Gateway forwarding rule
interface account
Interface set for ATD

Configure
Configure log Configure error scanning
handler rule set handler rule set engine ATD
settings

Before beginning the integration, review the high-level workflow. Notice there is setup within ATD
and Web Gateway.

14
 Configuring SWG User Account in ATD
ATD Web Application > Manage > ATD Configuration > ATD Users

 Username
 Password
 User Type

 First and Last Name

 Default Analyzer Profile

 Restful Access
 Web Access (useful)

First verify the Web Gateway user account from within the ATD interface. Although many of
these settings are preconfigured, it is important to confirm they are correct.

1. Log into the ATD interface.

2. On the menu bar, click Manage. The Manage page opens in the right pane.
3. In the right pane, select McAfee Web Gateway and then click Edit.
4. In the User Credentials section, verify the Username is SWG, the Password is admin,
and User Type is SWG.
5. In the User Details section, type name if the First and Last Name box; for example,
McAfee Web Gateway. Make sure the Default Analyzer Profile is SWG. The other fields
are optional.
6. In the Roles section, make sure Restful Access is selected (checked/ticked). Although
Web Access is optional, it may be useful to test the account access. The other roles
are optional.
7. If you made changes, click Save; otherwise, click Cancel.

15
 Import Forwarding Rule Set
Two Options

Offline scanning
Wait for result

Next, import the primary rule set you want to use for forwarding traffic to ATD. As discussed
earlier, you have two options: MATD – Offline Scanning with Immediate File Availability or
MacAfee Advanced Threat Defense. The main difference is that the first rule set provides online
scanning, while the later waits for the result. Remember, like other rule sets imported from the
library, you must resolve the conflicts.

16
 Gateway Anti-Malware Rule Sets Overview
Two Options for Primary Forwarding Rule Set and Rules

•Enable Progress Page

Advanced Threat Defense •Only Send Media Types with High Probability and Wait for Scanning
– (Wait for Result) Results
•Upload File to ATD and Wait for Scanning Result

• MATD – Init Offline Scan Nested Rule Set:

–Upload File to MATD and Wait for Scanning Result
–Offline Scanning with Immediate File Availability
MATD – Offline Scanning –Stop Cycle
with Immediate File
Availability - (Online
Scanning) • MATD - Handle Offline Scan Nested Rule Set:
–Reuse existing report if possible
–Only Send Media Types with High Probability
–Offline Scanning with Immediate File Availability

Before configuring the rule sets, take a moment to review the rules includes in each rule set.
Notice the MATD – Offline Scanning with Immediate File Availability rule set is further divided
down into two nested rule sets, each with different rules.

17
 Configuring Advanced Threat Defense Rule Set
Workflow

Select Gateway Anti-

Add Top Level Rule Set > Auto-Solve Conflicts.
Malware > McAfee
Import rule set from Rule Solve by referring to
Advanced Threat
Set Library. existing objects.
Defense.

IMPORTANT:

Save Changes. Move new rule set

directly after Gateway
Anti-Malware rule set.

Here is the workflow for configuring the Advanced Threat Defense rule set. Remember, use this
rule set if you want to wait for the results.

Like other rule sets, correct placement in the rule set list is important. Be sure to move it directly
after the Gateway Anti-Malware rule set.

18
 Advanced Threat Defense Rule Set
Default Configuration

Enable, Responses and

Embedded Objects only

At least one in list

AND Size < 30000000
AND probability > 60

To see the Advanced Threat Defense Supported Types, select Policy > Lists >
Subscribed Lists > MediaType.

The figure shows the default configuration of the Advanced Threat Defense Rule Set. Key
settings here are:

• Enable: Put the rule set into service.

• Applies to: Responses and Embedded Objects only.
• MediaType.EnsuredTypes: This property determines if the object being processed belongs to
a media type in a specific list. The default is the Skyhigh-maintained list named Advanced
Threat Defense Supported Types. To take a closer look at this list, select Policy > Lists >
Subscribed Lists > MediaType > McAfee Advanced Threat Defense Supported Types.
• Body.Size: This property determine the file size limit.
• Antimalware.Proactive.Probability: This property determines the probability an object is
malicious remains below a specific value. This value can be modified to tweaked to control
how many files are sent to the ATD for processing.

19
 Advanced Threat Defense Supported Types
Skyhigh-maintained List (Read-only)

Policy > Lists > Subscribed Lists > MediaType > McAfee Advanced Threat Defense
Supported Types

To see the Trellix Advanced Threat Defense Supported Types, select Policy > Lists > Subscribed
Lists > MediaType > McAfee Advanced Threat Defense Supported Types. This is a maintained list
and is read-only.

20
 Advanced Threat Defense Rule Set

 Move the rule set directly after the Gateway Anti-Malware rule set.
 Gateway Anti-Malware scanning options (engine) are also defined at Policy >
Settings > Engines > Anti-Malware > Gateway Anti-Malware.

The figure shows the rules within the Advanced Threat Defense Rule Set.

1. Enable progress page: Enables an event that displays a page to users to indicate the
progress made when a web object is downloaded to a client.
2. Only send media types with high probability to MATD: Includes two criteria parts for
the range of web objects passed to ATD for additional scanning. If both parts of the
criteria match, further processing is stopped. The object is not passed on to ATD.
• MediaType.EnsuredTypes: Determines if the object being processed belongs
to a media type in a specific list. The default is the Skyhigh-maintained list
named McAfee Advanced Threat Defense Supported Types. Optionally, you
can use a custom list.
• Antimalware.Proactive.Probability: Determines the probability an object is
malicious remains below a specific value.
3. Upload file to ATD and wait for scanning result: Uses Antimalware.Infected property to
determine if a web object is infected. If the object is found to be infected, the
forwarding is blocked, and a block message is shown to the user who requested the
object. The statistics counter records the block action.

21
 Configuring Settings for ATD
Policy > Settings > Engines > Anti-Malware > Gateway Anti-Malware

Other scanning options not

needed

Same credentials configured

for SWG in ATD

IP address of ATD appliance

(optional enter second for
round robin connections)

The remaining setup is from within Web Gateway. For demonstration purposes, we begin the
required scanning engine settings and other settings for the ATD appliance.
From the Web Gateway interface:

1. Select Policy > Settings.

2. In the left pane within Engines > Gateway Anti-Malware, select Gateway Anti-
Malware. You can also access this page from within the rule set.
3. In the right pane in the Select Scanning Engines and Behavior section, select McAfee
Advanced Threat Defense only. This send files to ATD appliance for deep analysis
through sandboxing.
4. In the ATD setup section, type the Web Gateway credentials configured in ATD. These
settings must match.
5. In the Server list section, add an entry for ATD and type the IP address the appliance,
types in string format. Optionally, add another entry for round robin connections
between ATD appliances.

Continued on the next page.

22
Configuring Settings for ATD (Continued)

Recommended

6. Scroll down and verify Reuse Previous Detection, McAfee Web Gateway will retrieve
the latest report from MATD based on the hash of the file is selected
(checked/ticked). This allows Web Gateway to use existing results for the same file
based on file’s hash. This speeds the scanning process and also prevents infection of
other end users from the same file.
7. Click Save Changes.

23
 Example Progress Page
Displays When User Begins Download

This figure shows an example progress page that displays when a users begins a download.

24
 Example Malware Detected Page
Displays When Infected File Detected

This figure shows an example progress page that displays when an infected file is detected.

25
 Configuring Offline Scanning Rule Sets
Workflow

Select Gateway Anti-

Add Top Level Rule Set > Malware > MATD - Auto-Solve Conflicts.
Import rule set from Rule Offline Scanning with Solve by referring to
Set Library. immediate file existing objects.
availability.

IMPORTANT:
IMPORTANT:
Move MATD - Init Offline
Save Changes. Move ATD - Handle
Scan rule set directly
Offline Scan rule set to
after Gateway Anti-
top of list (first rule set).
Malware rule set.

Optionally, import the MATD – Offline Scanning with Immediate File Availability rule set. The
workflow is similar to the one for the MacAfee Advanced Threat Defense except for rule set
placement.

• Move the MATD - Init Offline Scan rule set directly after the Gateway Anti-Malware rule
set.
• Move the MATD - Handle Offline Scan to the top of the rule set list (first rule set in the
list). It is important your policy tree. It is important this rule set is before any
authentication or whitelisting/blacklisting rules.

26
 MATD - Offline Scanning Rule Set
After importing the MATD - Offline Scanning with Immediate File Availability rule set, two
rule sets are implemented and appear on the rule sets tree: MATD - Init Offline Scan and
MATD - Handle Offline Scan.

MATD - Init
This ruleset should be Offline Scan
placed immediately
after the Gateway
Ant- Malware rule set.

MATD - Handle
Offline Scan

This rule set should be

the very first ruleset in
your policy.

MATD - Init Offline Scan - MATD - Init Offline Scan rule set contains the following rules.
1. Reuse existing report if possible: Enables an event that lets a page be shown to indicate the
progress made when a web object is downloaded to a client. If there is a match, processing
is blocked, and a block page and a block page displays.
2. Only send media types with high probability to MATD: Includes two criteria parts for the
range of web objects passed to ATD for additional scanning. If both parts of the criteria
match, further processing is stopped. The object is not passed on to ATD.
• MediaType.EnsuredTypes: Determines if the object being processed belongs to a
media type in a specific Skyhigh-maintained list.
• Antimalware.Proactive.Probability: Determines the probability an object is malicious
remains below a specific value.
3. Offline Scanning With Immediate File Availability: Uses Antimalware.MATD.GetReport and
Antimalware.MATD.InitBackgroundScan(Number) properties for matching. If there is a
match, processing is blocked, and a block page and a block page displays.
MATD - Handle Offline Scan - MATD - Handle Offline Scan include the following rules:
4. Upload file to ATD and wait for scanning result: Uses Antimalware.Infected property to
determine if a web object is infected. If the object is found to be infected, the forwarding is
blocked, and a block message is shown to the user who requested the object. The statistics
counter records the block action.
5. Offline Scanning With Immediate File Availability: When the rule is processed, it is checked
whether the value of the Antimalware.Infected property is true. If it is, it means the scanning
that was performed by Advanced Threat Defense has found a web object to be infected by
a virus or other malware. A warning message is then created and sent to the administrator
for the network of the user who sent the request to access the web object. The message
contains information on the request that was recorded by the rule of the preceding rule set.
6. Stop Cycle: This rule stops the processing cycle. It is always executed after the preceding
rules have been processed.

Note: Do not modify the criteria in "MATD - Handle Offline Scan" Rule-set.

27
 Block on ATD Errors Rule Set
Policy > Error Handler > Add from Rule Set Library > Error Handling

The figures shows the default configuration of the Block on ATD Errors rule set. Only some rules
are needed and are enabled.

You can add the rule set from Policy > Error Handler> Add from Rule Set Library > Error Handling.

28
 MATD Scanning Log Rule Set
Policy > Log Handler > Default > Add > Rule Set from Library > Logging > MATD
Scanning Log

You can add the MATD logging rule set under Log Handler.
1. Navigate to Policy > Log Handler > Default. Click Add > Rule Set from Library > Logging > MATD
Scanning Log.
2. Auto-Solve Conflicts and add the rule set.

29
 MATD Scanning Log Rule Set (Continued)
Policy > Log Handler > Default > Add > Rule Set from Library > Logging > MATD
Scanning Log

MATD log file

Log file header

The MATD Scanning Log rule set writes to atdscan.log. Additional headers can be added under
Log header.

Note that it is possible to import a rule set to generate log files that can be processed by
Content Security Reporter that includes information about traffic scanned by ATD. Navigate to
Policy > Log Handler > Default > Add Rule Set from Library > Logging > MATD Scanning Log for
Content Security Reporter.

30
Knowledge Check

31
Check your Learning
Multiple choice: Choose the correct answer.

What two rules are configured by default in the MATD – Init

Offline Scan rule set? (Choose two)

A. Reuse exiting report if possible

B. Offline Scanning with Immediate File Availability
C. Upload file to ATD and Wait for Scanning Result

Correct Answer(s):A, B. See section MATD – Offline Scanning Rule Set

32
Check your Learning
True - False

ATD – SWG integration provides an additional engine for

malware protection and enables Web Gateway to
automatically send suspicious files to ATD for further analysis.

A. True
B. False

Correct Answer: A. True. See section Integration Overview for more details.

33
 Review

 Configure the Web Gateway user account in the ATD interface.

 For Advanced Threat Defense only the scanning engine is needed.
 There are three rule sets to configure: one for forwarding to ATD, one for error
handing, and one for log handling.
 Correct rule set placement is essential.
 If using Advanced Threat Defense rule set (wait for result), move the rule set directly
after the Gateway Anti-Malware rule set.

• Configure the Web Gateway user account in the ATD interface.

• For Advanced Threat Defense only the scanning engine is needed.
• There are three rule sets to configure: one for forwarding to ATD, one for error handing, and
one for log handling.
• Correct rule set placement is essential.
• If using Advanced Threat Defense rule set (wait for result), move the rule set directly after the
Gateway Anti-Malware rule set.

34
 Lab Exercises
Lab 21: ATD Integration

 Goals:
 Integrate SWG and ATD

 Duration:
 35 minutes*

* May vary depending on lab environment

The labs for this course are included in a separate lab guide. Each lab lists the lab goals,
required systems, and any files needed to complete the lab; for example, text files or
executables. At the top of each lab, there is a scenario. The scenario often contains the
information needed to complete the lab. Beneath each scenario, there are detailed steps. The
steps are supplied as a resource, in the event you need additional information to complete the
lab.
Note: The steps will vary depending on if your lab environment is local- or cloud-based.

35
Skyhigh Security is a registered trademark of Musarubra US LLC. Other names and brands are the property
of these companies or may be claimed as the property of others. Copyright © 2022. March 2022

36