Student Guide (.pdf) - CWDotson.com

Websense WSGA 7.5 Certification Training

Websense WSGA 7.5 5 Day Certification Training

Introduction

WSGA-201TPI-V7.5 V5000/V7.5 Features - 1

Introduction

© 2010 Websense, Inc. All rights reserved.


Websense WSGA 7.5 Course Timeline DAY 1 - Monday Module 1 - Architecture and Deployment – Lab 1 Introduction and Access Module 2 – Initial Configuration and Installation of Off Box Components – Lab 2 Initial Configuration of Off Box Module 3 – Explicit and Transparent Proxy – Lab 3 Explicit and Transparent Proxy Configuration DAY 2 - Tuesday Module 4 - Identification and Authentication – Lab 4 Identification and Authentication Module 5 - Troubleshooting – Lab 5 Troubleshooting

Course Timeline – Day 1 and 2


Websense WSGA 7.5 Course Timeline DAY 3 - Wednesday Module 6 –Installation and Upgrading – Lab 6 Install and Upgrade Module 7 – Configuring Advanced Scanning Features – Lab 7 Advanced Scanning Features Module 8 – Advanced Identification and Authentication – Lab 8 Identification and Authentication

Course Timeline – Day 3


Websense WSGA 7.5 Course Timeline DAY 4 - Thursday Module 9 - Deploying WSG in the Network – Lab 9 Deploying WSG Module 10 - Strategies for Handling SSL Content Inspection – Lab 10 SSL Category Bypass Module 11 - High Availability and Load Balancing – Lab 11 Load Balancing Module 13 – Overview of Web DLP – Lab 13 Web DLP (optional) DAY 5 - Friday Module 12 – TruHybrid Lab 12 TruHybrid

Course Timeline – Day 4 and 5


Module 1 Architecture and Deployment

V5000/V7.5 Features - 5

Module 1 – Architecture and Deployment

© 2010 Websense, Inc. All rights reserved.


Architecture and Services

Architecture and Services


TRITON Architecture Web

Data

Email

Security

Security

Security

TRITON unified content security

SaaS

Appliance

Software

ThreatSe eker Network Mix & match “on premise” and “in the cloud” deployment

TRITON unified security center

TRITON Architecture The TRITON architecture delivers Websense technologies for web security, email security, and data-loss prevention as a unified solution, modular in design so that you can start out with one of the technologies and build on that as your organization sees the need. That unified solution is delivered within a unified platform that offers you the flexibility to choose how and what you deploy where. So for example, you can deploy leveraging the Websense SaaS-based infrastructure, with cloud-based security services. You can deploy on a consolidated appliance that reduces down the physical requirements, leveraging today’s computing power, virtualization, to run multiple security services from Websense on a single appliance platform. You also have the flexibility to deploy as software. The Websense TRITON console provides for aggregated, unified management of Websense web, data, and email security technologies across your entire distributed infrastructure, regardless of how you’ve got them deployed—i.e., if they’re used in one region as SaaS and in another region as appliance, you have one place to set policy, one place to report and manage your entire infrastructure for content security, whether that’s for web security or data-loss prevention and soon email security.


Deployment Options SaaS

Appliance

Software

No On-Premise Equipment or Upgrades

Simplified Deployment

Granular Control

Scalable, Enterprise Performance

Performance Scalability

Security Effectiveness

Easy-to-Use Management

Leverage Investments in Virtual Computing

Full Policy Management & Reporting Control Web & Email Integration

Standard Hardware

Extensible Security Platform Leading PricePerformance

Carrier Grade Datacenter Availability & Security

Security as a Service – Benefits No OnPremise Equipment or Upgrades SaaS eliminates the distribution, deployment, and ongoing upgrade of on-premise equipment. Websense takes those operational tasks off your hands, eliminating not only operational costs but also dramatically shrinking deployment time. This is especially true for distributed organizations where remote IT support resources may be limited or nonexistent.

Security Effectiveness SaaS customers automatically and continuously receive real-time threat updates from the Websense ThreatSeeker® Network. No action is required by the customer to stay ahead of the latest threats. Additionally, the scale and elasticity of cloud computing resources delivers multilayered threat protection without any performance impact. As a result, Websense customers achieve industry-leading protection against dynamic, zeroday threats without the overhead associated with on-premise security updates or capacity monitoring.

Full Policy Management and Reporting Control The SaaS platform delivers highly available, centralized policy management and reporting across globally distributed locations without the need for deployment of redundant on-premise management servers. Policies can even be extended to include role and user-specific controls via integration with on-premise directory services. Websense customers retain full control of their policies, without the cost and complexity of on-premise management servers.


Web and Email Integration Websense SaaS Web and email security are integrated at every level. A single user interface configures both, and both leverage shared management services including user directory synchronization, delegated administration, reporting, account management, and more. This integrated approach eliminates repetitive tasks, consolidates vendor support, and lowers administrative training costs.

Carrier Grade Datacenter Availability and Security

Software Deployments Benefits Websense Software Granular Control Websense industry‐leading Web, email, and data security can be deployed on premise as a software‐ based solution. The software model enables granular control over a range of deployment variables for customers who need maximum flexibility.

Performance Scalability Websense software allows customers to select on‐premise server hardware to meet customized performance requirements that scale across any range of environments, from small 25‐user offices to large headquarters offices.

Standard Hardware Software deployment provides a strong choice for organizations that prefer to standardize on specific server hardware/OS platforms rather than support preconfigured appliances.

Leverage Investments in Virtual Computing Many organizations invest heavily in virtual computing platforms not only to cut costs, but to reduce their corporate carbon footprint. Websense software solutions can be deployed in such virtual environments to deliver a better return on investments and support green computing initiatives.


Websense Web Security Gateway The Three Modules WSG comprises three modules Websense Web Security – Provides category and security filtering – Provides reporting of web activity Network Agent – Identifies non-web protocols to support filtering Websense Content Gateway – Integrates with Websense Web Security – Provides proxy and real time security functions – Provides HTTPS content inspection

The Three Modules Websense Web Security provides the policies which determine a client’s access to web sites and protocols. It uses these to filter based on category, security risks and protocols. It also provides reporting of web activity. Network Agent monitors the network to identify non-web protocol traffic. Once identified this may be filtered by Websense Web Security. Websense Content Gateway is a proxy through which clients connect to Web content. Websense Content Gateway integrates with Websense Web Security to further increase the level of security for the Web. The Websense Content Gateway provides visibility into SSL encrypted Web traffic, to ensure that malicious content cannot enter the network. It also enables real-time categorization of dynamic Web 2.0 content, as well as identifying previously unvisited sites that might only exist for a very short period of time such as those used for phishing attacks and proxy avoidance Web sites. Before the release of Websense Web Security Gateway the Web Security product integrated with proxies produced by other vendors (for example Microsoft’s ISA Server). These integrations are still supported but Websense recommend the use of their full product suite as other proxies do not provide the real-time scanning offered by the Websense Content Gateway.


System Architecture Directory Services

DC Agent

Logon Agent

eDirectory

RADIUS

User Service Policy & Global Configuration Logging

Policy Database (PostgreSQL)

Log Server MS SQL Server/MSDE

Request Broker

Filtering

Filtering Service

Policy Broker

Policy Server config.xml

Usage

Management

TRITON – Web Security

Usage Monitor

(Apache/Tomcat)

Traffic Capture/Analysis

Integrations

Network Agent

WCG

System Architecture

The diagram shows an overview of the Websense Web Security Gateway architecture. It does not illustrate all possible components but shows the key elements and their relationship to the others. During the follow pages these will be described in more detail.


Storage of Policy and Global Configuration Policy & Global Configuration

Policy Database (PostgreSQL) Policy Broker

Storage of Policy and Global Configuration Policy Database The database is a PostgresSQL transactional database and it stores global configuration settings and policy data including: 

Clients



Filters



Filter Components



Filter Settings



Global configuration settings specified in Websense Manager



The Audit Log – audit information is held for 60 days

The transactional PostGres database allows for multiple concurrent logins and centralizes all data for role-based administration. As previously mentioned only one administrator per role can make policy changes simultaneously.

Policy Broker The Policy Broker is the gatekeeper to Policy Database. Like the database there is a single Policy Broker per logical install. Other services requiring policy or configuration information (such as the Log Server, User Service & Filtering Service) pull the latest updates from the Policy Database every 30 seconds. There may be a short delay between when changes are saved and when the changes are implemented by the applicable service. This lag of approximately 30 seconds results from the polling interval used by the service.


v7 introduced the option of Websense User accounts – this simplifies the creation of Websense administrators in an environment that does not use a directory service or has multiple directory services. Authentication for these accounts is managed by the Policy Broker service. If the Policy Broker goes down then the other services, especially the Filter Service, will keep running for up to 14 days using current data. The Filter Service stores the data in non-persistent memory, consequently, if the Filtering Service is stopped it cannot start again without receiving the policy from the Policy Broker/Database.

Backup and Restore Capabilities System Backup of Websense filtering policy and configuration Websense software includes a command-line backup utility (i.e. wsbackup) which provides an straightforward mechanism to to backup your Websense software settings and policy data, or revert to a previous configuration. The Websense Backup Utility covers:   

Global configuration information, including client and policy data, stored in the Policy Database. Local configuration information (e.g. Filtering Service and Log Server settings) stored by each Policy Server. Websense component initialization and configuration files.

Example syntax and additional details are covered in the Tools section of the next module.

System Backup of Policy Database Only PgSetup located in the \Program Files\Websense\bin folder can be used to do a complete backup of the Policy Database (i.e. PostgreSQL database) Example syntax: PgSetup –save archive. Creates a backup of Postgres DB called archive. It is good practice to schedule a Policy Database backup daily.


Policy Server Object Request Broker

Policy Server config.xml

Policy Server The main task performed by this component is to identify and track the location and status of other Websense components. In addition it also performs other tasks including: 

Logs event messages for Websense components



Stores configuration information specific to a single Policy Server instance



Communicates configuration data to Filtering Service for use in filtering Internet requests

The Policy Server is typically installed on the same server as the Policy Broker and Policy Database but large distributed environments may use multiple policy servers (typically distributed by site) with a dedicated Filtering service to improve filtering performance. If the Filtering Service losses communication with the Policy Server then it will stop working fairly quickly (i.e. within a few hours). Although it is possible to deploy multiple Filtering Services below a single Policy Server, this architecture provides no resilience. The Policy Server is a low overhead component and consequently it is common to deploy Policy Server and Filtering Service together to provide additional resilience. All Policy Servers will be linked to the same Policy Broker service. It is also necessary to deploy multiple Policy Servers in networks that include multiple types of user directory (e.g. Active Directory and eDirectory). A separate Policy Server and User Service must be deployed to support each directory type. TRITON – Web Security connects to a specific Policy Server. For some configuration it may be necessary to change to another server (e.g. when managing settings for


Filtering Services linked to a different Policy Server or when managing users from multiple directories). Global settings are held in the Policy Database but settings for a specific Policy Server are held in config.xml. These settings include: 

Directory service settings



Network agent settings



Filtering service settings



The subscription key (this is part of the local installation)


Filtering Framework

Filtering Service This service works in conjunction with Network Agent or an integration product to provide Internet filtering. When a user requests a site, it is the responsibility of the Filtering Service to receive the request and determine the applicable policy. The Filtering Service must be running for Internet requests to be filtered and logged. The Filtering Service performs or initiates four major functions: 

URL filtering based on defined policies – policy settings are retrieved by connecting to the Policy Broker and loaded into memory. The Filtering Service receives category lookup requests from Integrations (such as the Websense Content Gateway or Network Agent) and responds with dispositions determined by the policy currently in force



Identifying requestors – the Filtering Service will try to resolve the IP address of the requestor to their user identity



Block page display - If the disposition calls for a block page, the browser is redirected to a block page web server embedded in the Filtering Service, which returns a block page with suitable content



Websense Master Database Download – each Filtering Service must contact the Websense Download Service and load a copy of the Master Database into memory


The image shows the interaction between the Filtering Service and other Websense components: 1. The integration captures a request for web access 2. The Policy Server / Policy Database holds Filter and Policy settings – these are cached by the Filtering Service and updated if any settings amended and committed (using the Save All button) 3. The Filtering Service provides information to the Log Server Service 4. The Filtering Service communicates with the User Service to determine (and cache) group memberships 5. The Transparent Identification Agent (if used) provides the user to IP address mapping – allowing user and group-based policies to be applied. The Filtering Service is typically installed on the same machine as Policy Server, however, in large or distributed environments there may be multiple Filtering Service instances (up to a maximum of 10 per Policy Server).


Integrations Proxies, Firewalls and Network Agent Filtering Service receives Internet requests from an integrated proxy server or firewall. Examples include: – Websense Content Gateway – Microsoft ISA Server – Check Point Firewall WSGA provides maximum protection by integrating with Websense Content Gateway Network Agent gives protection for non-web protocols When ‘stand alone’ environment Network Agent can capture web traffic and rest connections

Integrations The Filtering Service typically receives a request for the policy disposition relating to a client request from a proxy or an integrated firewall. Until the release of Websense Web Security Gateway a third party integration (such as Microsoft ISA Server or Check Point Firewall) provided this function. Now the Websense Content Gateway is the recommended integration for HTTP and HTTPS traffic. Network Agent can be deployed to detect non-web protocols and request policy dispositions from the Filtering Service. In a ‘stand alone’ environment (i.e. one that does not use an integrated proxy or firewall) Network Agent can be used to capture and filter all traffic. As well as receiving information regarding the client request, the integration may also supply the client’s identity. The Websense Content Gateway can provide NTLM or LDAP authentication for users and then pass this information to the Filtering Service.


Network Agent Deploying Network Agent Requires bi-directional visibility into traffic Runs on a dedicated – Linux version – Windows version Multiple instances of NA for large networks – Each Network Agent monitors a specific IP address range or network segment.

Network Agent (NA) Network agent acts as a packet sniffer – using promiscuous mode to capture and analyse packets. Although it is not a mandatory component it offers considerably enhanced security. The following are considerations relating to Network Agent deployment: 

Must be deployed where it can see all internal Internet traffic from the machines that it is required to monitor.



Can be installed on a dedicated machine to increase overall throughput.



Must have bidirectional visibility into Internet traffic to allow the blocking of requests

Multiple instances of Network Agent may be required in larger or distributed networks. Each Network Agent should be allocated to a specific IP address range or network segment. The use of multiple Network Agents allows all network traffic to be readily monitored and spreads the load over multiple hosts. Using multiple Network Agents ensures that all network traffic is monitored, and prevents server overload. The required number of Network Agents depends on network size and Internet request volume. Network Agent can typically monitor 50 Mbits of traffic per second, or about 800 requests per second. The number of users that Network Agent can monitor depends on the volume of Internet requests from each user, the configuration of the network, and the location of Network Agent in relation to the computers it is assigned to monitor. Network Agent functions best when it is close to those computers.


Up to 4 Network Agents can be deployed per Filtering Service. One Filtering Service may be able to handle more than 4 Network Agents, depending on the number of Internet requests. In Integrated mode – its function is to cover non-HTTP protocols and tunnelled protocols (e.g. malicious protocols utilising the DNS port). Network Agent extends analysis to protocols which cannot be proxied. Network Agent is able to view and analyse the content of the protocol so it is not just reacting to the port used like a firewall. Network Agent is also required to provide the information for bandwidth and quota management. Note: Network Agent can be deployed with the filtering components or on a separate machine. Network Agent should not be deployed on the same machine as responsecritical components.


Network Agent Deployment

Network Agent Deployment The Network Agent machine may be connected to a switch or router. It must be installed on the internal side of the corporate firewall, in a location where it can see all Internet requests for the machines it is assigned to monitor. Network Agent only monitors and manages traffic that passes through the network device (switch, hub, or gateway) to which it is attached. The device must provide a mirror or span port to which Network Agent can be connected, allowing it to see Internet requests from all monitored machines. (On most switches, you can change a port mode to spanning, mirroring, or monitoring mode). Websense, Inc., strongly recommends using a switch that supports bidirectional spanning. This allows Network Agent to use a single network card (NIC) to both monitor traffic and send block pages.

Network Agent Functionality 1. Network agent is deployed with a connection to the core switch providing full visibility of all network traffic originating from the corporate LAN 2. Network Agent captures protocol (and web traffic in standalone mode) and determines policy disposition by contacting the filtering service 3. If the communication is not permitted, Network Agent uses a TCP reset (RST) to terminate the session.


User Service User and Group Resolution Retrieves user and group information from the configured Directory Service Explicit Identification – Active Directory (Native Mode) – Windows NT / Active Director (Mixed Mode) – LDAP Transparent Identification – Requires DC Agent – Windows Directory (AD/NT) only

Websense User Service

The Websense User Service communicates with the organization’s directory service to convey user-related information to the Policy Server and Filtering Service, for use in applying filtering policies. This user information includes user-to-group and user-todomain relationships. The example below shows the interaction between the Filtering Service and the User Service to handle a request from the user NIS1\jbausewein on a Microsoft Active Directory network. 

The Filtering Service asks the User Service for the qualified username for NIS1\jbausewein.



The User Service will then search the global catalog servers for the domain NIS1.



Once NIS1 is found, it will search that domain for the jbausewein.



The OS will return the qualified name “LDAP://nis101.websense.com dc=websense, dc=com/Jason Bausewein” to the FS.



The Filtering Service will now have to build a policy for “LDAP://nis101.websense.com dc=websense, dc=com/Jason Bausewein”.



The Filtering Service caches the username locally for 3 hours.



To build the policy, the Filtering Service asks the US for the user’s groups.



The User Service will then search nis101.websense.com for the group membership.



The User Service will then search for each group for group membership. This membership is cached since most users have similar groups.




The User Service then returns the groups to Filtering Service.

The caching of user and group information means that updates to a user’s group memberships will not immediately affect the Policy they receive. As well as providing information for the Filtering Service the User Service also provides the list of objects residing in your directory service to Websense Manager, for use in configuring filtering policies. There must be one instance of the User Service for each Policy Server in your network. There must also be an instance of the User Service for each directory type (e.g. two would be required for an organization using both Active Directory and eDirectory).

Supported Directory Services 

Microsoft Active Directory 2000, 2003, or 2008 (specific permissions need to be



granted to Websense Logon Agent to run with 2008)



Novell eDirectory 8.51 or later o NMAS authentication is supported. o Recommend Novell Client v4.83 or v4.9 (v4.81 and later are supported)



Other LDAP-based directory services



Most standard RADIUS servers



The following RADIUS servers have been tested: o Livingston (Lucent) 2.x o

Cistron RADIUS server

o Merit AAA o Microsoft IAS


XID Agents

Transparent Identification (XID) Agents XID agents transparently identify users without prompting to manually authenticate. This information can be used by the Filtering Service to map a user name to the IP address in the request.

Supported XID Agents Websense DC Agent transparently identifies users in a Windows-based directory service, without prompting users to manually authenticate. DC Agent communicates with User Service to provide up-to-date user logon session information to Websense software for use in filtering. DC Agent provides this information by polling Domain Controllers and Computers to verify which users are logged in. This information can be used by the Filtering Service to map a user name to the IP address in the request. Websense Logon Agent may be a better option for transparent user identification when users frequently change computers and the changes could be missed by DC Agent. The associated logon application on client machines ensures that individual user logon sessions are captured and processed directly by Websense software. Logon Agent does not rely on a directory service or other intermediary component when capturing user logon sessions. It detects user logon (and logoff) events as they occur. This maximizes accuracy in identifying users as they log on to the network. Websense RADIUS Agent lets you integrate filtering policies with authentication provided by a RADIUS server. The Websense RADIUS Agent enables Websense software to transparently identify users who access your network using a dial-up, Virtual Private Network (VPN), Digital Subscriber Line (DSL), or other remote connection


(depending on your configuration). Assign particular filtering policies to users or groups of users who access your network remotely. Websense eDirectory Agent works together with Novell eDirectory to transparently identify users so Websense software can filter them according to particular policies assigned to users or groups. eDirectory Agent uses Lightweight Directory Access Protocol (LDAP) to gather user logon session information from Novell eDirectory, which authenticates users logging on to the network. The Websense eDirectory Agent associates each authenticated user with an IP address. With the help of the Websense User Service, eDirectory Agent supplies this information to the Websense Filtering Service. Further details of XID agents are included in Modules 4 and 8.


Usage Monitor Alerts for Internet Usage Enables alerting based on Internet usage. Usage Monitor tracks URL category and protocol access Generates alert messages according to the alerting behavior configured.

Usage Monitor The Usage Monitor service is used to provide alerting based on Internet usage. It tracks URL category and protocol access and can generates alert messages according to the alerting behavior configured.

Configuring category usage alerts Websense software can notify you when Internet activity for particular URL categories reaches a defined threshold. You can define alerts for permitted requests or for blocked requests to the category. For example, you might want to be alerted each time 50 requests for sites in the Shopping category have been permitted to help decide whether to place restrictions on that category. Or, you might want to receive an alert each time 100 requests for sites in the Entertainment category have been blocked, to see whether users are adapting to a new Internet use policy. On the Settings tab, use the Alerts and Notifications > Category Usage page to view the alerts that have already been established, and to add or delete usage alert categories.


TRITON – Web Security Management and Reporting Services May be deployed on the Appliance or Off Box Web-based interface using Apache / Tomcat Includes services for reporting and interaction with other components If deployed Off Box, Apache / Tomcat services are installed

Triton Web Security In version v7.5 it is possible to deploy the WSGA Management and Reporting components on-box. The following new components are available on the appliance:

Investigative reports scheduler has been renamed from Websense Explorer Report Scheduler



Reports information service has been renamed from Websense Information Service for Explorer



Manager Web Server / Reporting Web Server – replace ApacheTomcatWebsense and Apache2Websense

Important Note: Running TRITON – Web Security (formerly called Websense Manager and Reporting) on the appliance will not be the norm, except for very small companies, evaluations and demonstrations. Running reports can affect performance and is not typically combined on the same server with the analytics.

Multiple TRITON Web Security instances There can be only one instance of TRITON - Web Security that generates and schedules reports. Typically, only one instance is needed in a deployment. It is possible to install additional instances of TRITON - Web Security in a deployment. However, these must be used as configuration- and administration-only instances (referred to as administration-only instances). They cannot be used to generate reports. Each administration-only instance of TRITON - Web Security must be associated with a separate Policy Server instance that is not associated with a Log Server. Because the administration-only instances are not associated with a Log Server, they will not display


Today and History charts. Also, reporting options will not be available. Only configuration and administration functions will be available.


Reporting Management and Reporting Services Uses the Log Server Service to send Internet activity to the Log Database – Windows only component Requires a MS SQL / MSDE database to hold reporting data The database and the Log Server Service may be located on a Windows 2003 / 2008 server

Reporting – Management and Reporting Services Websense Reporting comprises a single instance of the Log Server Service and a SQL database to hold reporting data.

The Log Server Service The Log Server Service is a Windows-only component that is required to enable the reporting features of TRITON - Web Security (including charts, presentation reports, and investigative reports). Before this component can be installed, Microsoft SQL Server or Microsoft SQL Server Desktop Edition (MSDE) must be installed. The Log Server Service sends records of Internet activity to the Log Database. It also sends category names, protocol names, and risk class names from the Master Database to the Log Database.

The Reporting Database The Websense Log Database can be created and maintained by any of the following database engines: 

Microsoft SQL Server 2008



Microsoft SQL Server 2005



Microsoft Database Engine (MSDE) 2000


Log Server logs Internet activity information to only one Log Database at a time.

Microsoft SQL Server Microsoft SQL Server works best for larger networks, or networks with a high volume of Internet activity, because of its capacity for storing large amounts of data over longer periods of time (several weeks or months). Under high load, Microsoft SQL Server operations are resource intensive, and can be a performance bottleneck for Websense software reporting. You can tune the database to improve performance, and maximize the hardware on which the database runs: 

If Log Server is installed on the database-engine machine, alleviate resource conflicts between Log Server and Microsoft SQL Server by increasing the CPU speed and/or the number of CPUs.



Provide adequate disk space to accommodate the growth of the Log Database. Microsoft SQL Client Tools can be used to check database size.



Use a disk array controller with multiple drives to increase I/O bandwidth.



Increase the RAM on the Microsoft SQL Server machine to reduce timeconsuming disk I/O operations.

MSDE Microsoft Database Engine (MSDE) is a free database engine best-suited to smaller networks, organizations with a low volume of Internet activity, or organizations planning to generate reports on only short periods of time (for example, daily or weekly archived reports, rather than historical reports over longer time periods). MSDE cannot be optimized. With MSDE, the maximum size of the Log Database is approximately 1.5 GB. When the existing database reaches this limit, it is saved (rolled over), and a new Log Database is created. Use the ODBC Data Source Administrator (accessed via Windows Control Panel) to see information about databases that have been saved. If the Log Database is rolling over frequently, consider upgrading to Microsoft SQL Server.


Services New to v7.5 V7.5 has seen the introduction of a number of new services TruHybrid uses:– The Sync Service – The Directory Agent Service The new installer works with:– The Control Service Further details of these services will be included in later modules.

Services New to v7.5


Websense Web Security Services Service Control When deployed on the appliance an entirer module may be stopped / started For a software deployments of Web Filtering the service start order is important – Policy Broker relies on Policy Database – Policy Server relies on Policy Broker • Starting Services (stop in reverse order) – Policy Database – Policy Broker – Policy Server – User Service – Filtering Service – Network Agent

Service Control Sometimes services may be slow to start and cause other dependent services to fail. The problem may be remedied by amending the service recovery settings in the Windows Services application – as in the illustration below. It should only be amended for the first and second failure.


Deployment Deployment Limitations Per deployment – 1 Policy Broker – 1 Sync Service per deployment Per Policy Broker – One TRITON - Web Security (only one instance for reporting, other administration-only instances may be deployed Other best practice component limitations

Deployment Limitations Websense deployments should meet the criteria for services:

Per entire deployment 

One Policy Broker



One Sync Service (Websense Web Security Gateway Anywhere deployments)

Per Policy Broker One TRITON - Web Security (only one instance for reporting, other administration-only instances may be deployed. NOTE: Even when the number of dependent components is not limited to one, there are best practice component-to dependent-component ratios.

Per Policy Server 

One Log Server



One User Service



One Usage Monitor



One Directory Agent (for TruHybrid)

Per Filtering Service 

One primary Remote Filtering Server




No more than 4 instances of Network Agent


VM Deployments Virtual Machine Server Environments Websense supports running TRITON – Web Security and Data Security Management server on the same server using separate VMs Supported platforms VMWare ESX Server – VMware ESX 3.5i update 2 – VMware ESX 4i update 1

Virtual Machine (VM) Deployments With Websense Web Security Gateway Anywhere, you can install the Data Security Management Server and TRITON - Web Security on the same Windows server, on separate virtual machines (VMs). The Data Security Management Server includes TRITON - Data Security and the Oracle database. On the TRITON - Web Security VM the following Websense components should be included: Log Service, XID Agents, Linking Service, and Sync Service. The following VM platforms are supported. You can obtain them from the VMware site: www.vmware.com. 

VMware ESX 3.5i update 2



VMware ESX 4i update 1

VMware Server Requirements 

CPU - At least 4 cores 2.5 GHz (for example, 1 QuadXeon 2.5 GHz)



Disk - 300 GB, 15 K RPM, RAID 10



Memory - 8 GB



NICs - 2*1000


Module Requirements for VM installation Data Security Management Server 

Windows Server 2003 Standard SP2



4 GB RAM



150 GB Disk



15K RPM



RAID 1+0



2 CPU 2.4 GHz (dedicated)

TRITON - Web Security machine 

Windows Server 2003 Standard SP2



2 GB RAM



10 GB disk



1 NIC (bridged)



2 CPU cores (dedicated)


Appliance Overview

Appliance Overview


Appliance Deployment

Appliance Deployment The V10000 is an all in one appliance based solution, comprising of the Websense Content Gateway, Websense Web Security and Network Agent on a single appliance. The appliance is based on OEM hardware running a secured Linux environment. This environment uses Xen virtualization technology to manage multiple virtualized OS environments. This enables the use of separate “domains”, which provide separate hardware resources for each domain. An appliance deployment requires some components to be deployed off box. Details of these and deployment recommendations are included later in the course.


Appliance Overview Virtualization Xen Virtualization – Separate virtualized domains for WCG/WWS/NA – Each domain has its own virtualized hardware resources (CPU, memory, file systems etc) and OS – Better reliability • Critical failure in one domain will not affect other domains

– Better isolation • System configuration specific to one application will not conflict with another

Appliance – Virtualization Virtualization of Websense Content Gateway, Websense Web Security and Network Agent domains is used to achieve better reliability and better isolation. Each domain has its own resources allocated to it which achieves better reliability for that particular domain, and failure of one particular domain will not have an impact on other domains running on the appliance. Each domain uses CentOS 5.1 for its base operating system, including the management domain, or Dom0 which will be looked at later in this module.


Appliance Overview What is Xen? Open source industry standard for virtualization Powerful, efficient and secure feature set for virtualization of a variety of CPU architectures It supports a wide range of guest operating systems including – Windows – Linux – Solaris and various versions of the BSD operating systems

What is Xen? The underlying V10000 architecture utilizes, Xen, which offers a powerful, efficient, and secure feature set for the virtualization of x86, x86_64, IA64, PowerPC, and other CPU architectures. It supports a wide range of guest operating systems including Windows, Linux, Solaris and provides the virtualization technology used in the V10000 architecture.


Appliance Hardware V10000 G2 Hardware Configuration Dual Quad-Core processors 24 GB RAM 2 x 300 GB and 2 x 146 GB hard drives – Configured as RAID 1 Failure-resistant, hot-swappable drive configuration 270 W energy efficient and redundant power supply 6 x 10/100/1000 Base-T network interfaces

V10000 G2 Hardware Configuration Currently the V10000 hardware uses 4 drives, forming two RAID 1s, which provides fault tolerance from disk errors and failure. All system and software files are located on one RAID 1, and the second RAID 1 is used solely for WCG caching.


Appliance Hardware Access to the Appliance CLI The Appliance Command Line Interface (CLI) may be accessed using a VGA Console/keyboard – No console authentication required, physical access to the device considered enough Remote serial access to the CLI is available with 3rd party devices

Access to the Appliance Command Line Interface (CLI) For Appliance CLI access, physical access to the Appliance is considered to be authentication of a user. Because of this, physical access to the appliance must be restricted – generally speaking such appliances would irrespectively be located in a server room as are other organisation servers, to which only required administrators have access. The reasoning behind having no CLI authentication is that if a password was used and forgotten, the appliance would need to be returned to Websense for reset. Remote access to the CLI is possible via the serial port utilizing devices such as Cyclades Serial Console Server (and CLI access via SSH is available to technical support) so there is no requirement to access the physical box.


Appliance Hardware V10000 Connector Overview

V10000 G1 2 add on NICs

2 add on NICs

2 onboard NICS

DRAC5 Enterprise

Dual Power Supply


(iDRAC6 Express via C Interface)

4 onboard NICS

Dual Power Supply

V10000 Connector Overview The images identify the ports available on the V10000 G1 and G2 appliances. From the top-left, ports P1 & P2 (or Proxy 1 and Proxy 2) ports are used for the Websense Content Gateway (WCG) module. The WCG Manager GUI can be accessed via P1 on port 8081 by default, however can also be accessed via the console interface, or ‘C’ interface on the same port. P2 is an optional port - One common WCG configuration is to use P1 for traffic into and out of the proxy module. Other deployments include using P1 for inbound traffic and P2 for outbound traffic. (To enable this configuration, an appropriate routing rule needs to be set for P1 and P2 on the Configuration > Routing page in the V10000 GUI – more on this in later modules). P2 can be used as a communication channel for multiple WCG proxy servers in a cluster. In this scenario, P2 can still be used for outbound traffic. More information on clusters can be found in the Websense Content Gateway Administrator’s Guide. Ports E1 and E2 are currently unused and allow for future expansion of the V10000. On the G1 version the DRAC (Dell Remote Access Controller) port is used for remote management allowing you access to the remote CLI console, alerting configurations, hardware monitoring and power management etc. Some of these facilies are included in the iDRAC functionality of the G2 Appliance. Serial, video and USB ports are also available on the appliance for direct connection to the appliance.


The C port, or ‘Console’ port, is used for connecting to the V10000 GUI residing in the management domain, and accessing the WWS domain via the backend virtualized network. It also handles WWS database downloads. Ensure that interfaces C and P1 are able to access the download servers at download.websense.com. (As an alternative, some sites configure the P1 proxy interface to download the Websense Master Database as well as other security updates. In that situation, interface C does not require Internet access.) As with any WWS/WCG implementation, ensure that the download servers are permitted by all firewalls, proxy servers, routers or host files that control the URLs C and P1 interfaces can access. The N port is used by the Network Agent module, and can also be used to send RST and 302 responses if connected to bi-directional SPAN port. If N is not configured to send RST packets, the C interface does this by default.


Installation Installation Process The Appliance comes pre-installed Off-box components require installation for WWS features In the case of persistent system failure, a recovery DVD can be used to restore the appliance to the manufacture state – All previous configurations are lost and the customer needs to accept EULA and re-configure the appliance from beginning

Installation Process When the V10000 arrives on a customer site, all components have been pre-installed. Initial requirements are to physically plug the appliance into the network and to configure the C interface to allow access to the V10000 GUI. Once done, further configurations can be made within the V10000 GUI and further module interfaces can be setup. The appliance package also includes a recovery DVD which reformats the appliance and rebuilds the domains/modules bringing it up to the state the appliance would be on arriving at a customer site. This will be covered later. The firstboot process is performed once the V10000 is plugged into a customer network for the first time. The firstboot process configures the hostname of the appliance, C interface details and V10000 GUI password. Upon completion of the firstboot process which takes approximately 5 minutes, administrators to get into the V10000 GUI and finalize configurations.


Installation Off-Box Component Install Use standard WWS installer – Follow WWS deployment recommendations – Install Components: • • • •

Web Security Manager if running Off Box Log Server Optionally any XID Agents TruHybrid Sync Service

– Log server database • Log Database (SQL Server or MSDE) • May be local or remote

OffBox Component Install To recap, the off box components required are the Websense Manager, and reporting and XID components if needed and these can be installed separately using the custom installation option. Note WWS Manager reporting functionality is only available when WWS Manager is installed on Windows. When installing, the Websense Manager needs to point to the policy server located on the appliance designated as hosting the policy configuration, the primary policy source appliance. This connection to the policy server during installation is made to the C interface so the interface needs to be pre-configured and reachable before attempting the installation.


V5000

The V5000 Appliance


V5000 Appliance Overview Target audience, delivery and competitive objective Solution for targeting – Mid Market SMB – Enterprise branch office Lower cost alternative to V10K – More competitive in appliance marketplace Delivered as a appliance software v7.5.1: – V5000 specific documentation/deployment guides

V5000 Appliance Overview Engineering’s solution for the SMB market segment Characterized as: 

500-2000 users



The customer has small IT budget and staff and low Internet bandwidth



Most likely, the appliance will be an addition into existing routable network infrastructure and it will be deployed without clustering or redundancy.

Targeted as a branch office solution for Enterprise customers V10000 is an expensive method of providing filtering to small remote/satellite offices with lower user counts. V5000 provides an affordable and competitive solution.

Concurrent component restrictions 

V5000 will support WSG or ESG modules, not both concurrently. Will support DLP concurrently



NIC Teaming non-supported


Appliance Hardware V5000 G2 Hardware Configuration Similar price and performance as mid-market platforms Cisco, Blue Coat and McAfee Single Quad-Core processor 8 GB RAM 2 x 250 GB hard drives Single power supply 4 x 10/100/1000 Base-T network interfaces Solution for: – Mid Market SMB – Enterprise branch office

V5000 G2 Hardware Configuration


V5000/V10000 Comparison Physical Comparison V5000 G2 2 add on NICs

2 onboard NICS

Single Power Supply


2 add on NICs

2 onboard NICS

DRAC5 Enterprise

Dual Power Supply


(iDRAC6 Express via C Interface)

4 onboard NICS

Dual Power Supply

V10000 / V5000 Physical Comparison


Appliance Architecture

Appliance Architecture


Xen / Hardware Architecture

Appliance – Xen / Hardware Architecture In the diagram the bottom layer shown is the hardware layer. Domain 0 (DOM0) has to be available – it’s the management domain and handles all hardware management, therefore the entire V10000 system relies on it. As a management domain, DOM0 allows stopping, starting and restarting of other available domains. A domain is the equivalent in the Linux world to virtualized domain or OS. Aside from the console C Ethernet cards used by Dom0 and shared with the WWS DomU all other physical interfaces are mapped to guest domains (DomU’s) e.g. WCG, NA. WCG has 2 available NIC interfaces, P1 and P2. P2 is switched off by default. The Network Agent DomU is allocated one NIC for monitoring, port N. Websense Web Security is not allocated any physical device – it connects to the internet via Dom0 interface C.


Xen Domains Domain Architecture Dom 0 (Control Domain) is for appliance management – Cannot be turned off without shutting down the whole appliance Other Domains can be turned off, on or restarted via appliance management WebGUI (or Serial CLI) All hardware resources, except for NIC P1, P2, and N, are allocated to Domain 0 – Port C is allocated to domain 0 – P1 and P2 are directly allocated to WCG domain – Port N is directly allocated to NA domain

Xen Domains The Xen Domains are similar in concept to Virtual Machines and turning off a domain is like turning off a VM. The Appliance architecture essentially runs a small virtualized LAN in background, virtualized WWS, WCG, NA and management (DOM0). DomUs are preconfigured on the appliance before delivery. NOTE: Currently you cannot add DomUs. All configuration commands set on the management interface are sent via Dom0. The appliance web UI is tomcat based, hosted via Dom0, but WCG still has its own management UI located in the WCG DomU. This is accessible directly via P1 or P2 rather than via C in DomU.

Domain Management The control (management) domain, Dom0 provides the ability to manage each of the other modules and shows the status of each module and the components held within. Application domains are started up in the control domain (Dom0) and can be turned off from control domain. There is no way to directly access application domains. Configuration commands are sent via the Control Domain to application domains and the Appliance GUI is hosted in the control domain Dom0.


Networking

Networking Internally the appliance uses the 169.254.254.0/24 network. This is an IANA reserved network, thus no real life networks should be using it reducing the risk of IP address conflict. The 169 network is virtual and does not go through any physical NIC. The means speed is only limited by CPU resources. If there is a lot of traffic going through the backend, there will be a lot of memory swapping as CPUs switch to different domains, potentially affecting performance. WWS DomU has no direct connection to the internet (required for database downloads/updates). All traffic related to WWS goes via the backend 169 network out through the C interface. Configuration traffic between application domains and outside must go through NIC C and NATed with external IP address assigned to C In the functional relationship between WCG and WWS DomUs, a lot of WISP requests pass between the domains - As these requests are sent via a virtual NIC there is a speed advantage reducing latency. Both interface C and P1 (or P2, one of) need to access the internet. This is for WCG to download analytic databases via P1 or P2 and WWS downloads the URL database through C. Note: In the low probability event of a company using 169.254 IP address range in network, an alternate solution must be provided.


Networking Security Configuration An iptables firewall is installed on DOM0 to minimize ports exposed to outside: – Only selected ports are allowed from outside to inside – Server ports in application domains that need to be access from outside are port-mapped at NIC C – ACL does not limit access from inside to outside

Security Configuration Network Address Translation (NAT) is used between internal network and client network and IPTables is used to ensure only the required for ports in the DOMs are accessible from the external network. IPTables is used to prevent telnet to DOM0 or the WCG DOM.


Knowledge Check Module 1 Architecture and Deployment 1. Which appliance network interfaces are designed for use by the Content Gateway module?

2. What is the main limitation of the V5000? 3. When must you deploy more than one Policy Server and User Service? 4. What components may be installed on VMWare ESXi? 5. What network configuration is required to support Network Agent? 6. What file is used to hold settings that are specific to a policy server?

Knowledge Check