Installation guide

ManualsBrandsRed Hat ManualsComputer equipmentDIRECTORY SERVER 2.0 - GATEWAY

Deploying with Websense

Content Gateway

Websense® Content Gateway is a high-performance Web proxy that provides real-

time content scanning and Web site classification to protect network computers from

malicious Web content while controlling employee access to dynamic, user-generated

Web 2.0 content. Web content has evolved from a static information source to a

sophisticated platform for 2-way communications, which can be a valuable

productivity tool when adequately secured.

The dilemma for administrators is how much access to allow. Web 2.0 sites rely

primarily on HTTP/HTTPS protocols, which cannot be blocked without halting all

Internet traffic. Malicious content can use this means of entry into a company

network.

The Websense Content Gateway module offers:

 Automatic categorization of dynamic Web 2.0 sites

 Automatic categorization of new, unclassified sites

 HTTPS content inspection

 Enterprise proxy caching capabilities

Websense Content Gateway is deployed as an add-on module with Websense Web

Security or Websense Web Filter. Websense Content Gateway can also be an

important piece of the following Websense deployments:

 Web Security Gateway for on premises deployments. On premises deployments

may be implemented on Websense V-Series appliances or as software running on

general purpose servers.

 Hosted Web Security Gateway for software as a service (SaaS) deployments

 Web Security Gateway Anywhere for distributed enterprises with one or more

branch offices and multiple remote users

Deploying Websense Content Gateway can improve network efficiency and

performance by caching frequently accessed information at the edge of the network.

However, the increasing availability of Web dynamic content that cannot be cached

can limit the effectiveness of this feature.

This paper includes the following topics:

Websense Content Gateway system requirements

Proxy deployment options

Summary of content (22 pages)

PAGE 1
Deploying with Websense Content Gateway Websense® Content Gateway is a high-performance Web proxy that provides realtime content scanning and Web site classification to protect network computers from malicious Web content while controlling employee access to dynamic, user-generated Web 2.0 content. Web content has evolved from a static information source to a sophisticated platform for 2-way communications, which can be a valuable productivity tool when adequately secured.
PAGE 2
User authentication HTTPS content inspection Handling special cases Explicit proxy deployment Transparent proxy deployment Highly available Web proxy In a proxy chain With Blue Coat ProxySG With Microsoft Internet Security and Acceleration (ISA) server For more information about deploying Web filtering software, see the Websense Web Security and Websense Web Filter Deployment Guide, and the appropriate deployment guide supplement for your network size.
PAGE 3
Disk space 2 disks: 100 GB for the operating system, Websense Content Gateway, and temporary data. 147 GB for caching If caching will not be used, the disk is not required. The caching disk: • Should have a minimum size of 2 GB, maximum 147 GB for optimal performance • Must be a raw disk (not a mounted file system) • Must be dedicated • Must not be part of a software RAID For best performance, use a 10K RPM SAS disk drive on a hardware RAID controller that has at least 64 MB of write-through cache.
PAGE 4
unless the issue is deemed a Red Hat Enterprise Linux-specific issue, at which point you must contact Red Hat directly for assistance. RPM compat-libstdc++-33-3.2.3-47.3.i386.rpm (or higher version of this package) GNU C library (glibc) version 2.5-42 or later. Note that Red Hat Enterprise Linux 5, update 3 ships with glibc version 2.5-34. Be sure to update it to version 2.5-42 or later. Websense Web filtering products, version 7.
PAGE 5
Note If you enable HTTPS content inspection (SSL) in a management cluster, you must configure each node manually for all SSL features. Another type of clustering supported by the Content Gateway is cross-cache clustering, a complex proxy deployment that allows any node in a proxy cluster to share cache contents across the other nodes. This type of cluster also includes the configuration sharing feature in management clustering previously described.
PAGE 6
User authentication Authentication is the process of verifying a user via a username and password. User authentication may be configured on Websense Content Gateway or in TRITON Web Security. Content Gateway authentication The proxy can be configured for transparent user authentication with NTLM, in which case users are not prompted for credentials, or for explicit (or manual) authentication, in which case users are required to enter a username and password for network access.
PAGE 7
servers. Rules may be defined for both types of authentication realms, but only one method (NTLM or LDAP) can be active at any time. See Websense Content Gateway Online Help, in the chapter titled Security, for detailed information about configuring all these proxy authentication options. TRITON - Web Security authentication You can configure user identification in TRITON - Web Security rather than on the proxy.
PAGE 8
IP addresses for which SSL decryption is not performed. See the chapter titled Scanning and SSL Bypass Options in TRITON - Web Security Help for information about enabling the SSL inspection bypass feature. Handling special cases Any Websense Content Gateway deployment must be able to handle Web site requests and applications that are not compatible with the proxy or that should bypass the proxy.
PAGE 9
For explicit proxy deployment, individual client browsers may be manually configured to send requests directly to the proxy. They may also be configured to download proxy configuration instructions from a Proxy Auto-Configuration (PAC) file. A group policy that points to a PAC file for configuration changes is a best practice for explicit proxy deployments. Another option is the use of Web Proxy AutoDiscovery (WPAD) to download configuration instructions from a WPAD server.
PAGE 10
custom internal applications Many of these programs are not developed with proxy compatibility in mind. For a successful transparent proxy deployment, the network must be configured to allow the proxy’s static bypass feature to work. See the “Static bypass rules” section, in the chapter titled Transparent Proxy Caching and ARM, in the Websense Content Gateway Online Help. Because traffic management is centralized, users cannot easily bypass the proxy.
PAGE 11
A router may also use Layer 2 (L2), which does not use GRE. Websense recommends the use of L2 if the router supports it. With L2 redirection, Content Gateway must be on the same subnet as the WCCP device (that is, Layer 2 adjacent). A proxy and a router communicate via a set of WCCP “Here I am” and “I see you” messages.
PAGE 12
A comparison of how some activities are handled in explicit and transparent proxy deployments appears in the following table: Activity Explicit Proxy Deployment Transparent Proxy Deployment Proxy Chain Client HTTP request Direct connection to proxy by browser to port 8080 (default) Redirected to proxy by network device using GRE encapsulation or by rewriting the L2 destination MAC address to the proxy’s address Direct connection to parent proxy from child proxy Exception management Exclude site, C
PAGE 13
switching options. This section summarizes some possibilities for highly available Web proxy deployments. Using explicit proxy As previously mentioned for the explicit proxy deployment, clients are specifically configured to send requests directly to a proxy. The configuration can be accomplished manually, or via a PAC file or a WPAD server. An explicit proxy deployment for high availability can benefit from the use of virtual IP failover.
PAGE 14
Active/Active In an active/active configuration with 2 proxies, more than one virtual IP address is assigned to the virtual IP address pool. At any point in time, one proxy handles the network traffic that is explicitly directed to it. This deployment is scalable for larger numbers of proxies. Clients requesting the IP address of a proxy can be crudely distributed using round robin DNS.
PAGE 15
With load balancing A load balancer is a network device that not only distributes specific client traffic to specific servers, but also periodically checks the status of a proxy to ensure it is operating properly and not overloaded. This monitoring activity is different from simple load distribution, which routes traffic but does not account for the actual traffic load on the proxy. A load balancer can detect a proxy failure and automatically re-route that proxy’s traffic to another, available proxy.
PAGE 16
Using transparent proxy In a transparent proxy deployment for high availability, traffic forwarding may be accomplished using a Layer 4 switch or a WCCP-enabled router. Routers or switches can redirect traffic to the proxy, detect a failed proxy machine and redirect its traffic to other proxies, and perform load balancing. Using a Layer 4 switch.
PAGE 17
specific proxy. In this scenario, WCCP distributes client requests based on the proxy server’s IP address, routing traffic to the proxy most likely to contain the requested information. In a proxy chain Websense Content Gateway can be deployed in a network that contains multiple proxy machines, including one or more third-party proxies. A proxy chain deployment can involve different scenarios, depending on where Websense Content Gateway is located in relation to the client.
PAGE 18
Websense Content Gateway is downstream A simple deployment has Websense Content Gateway as the downstream proxy, closest to the client. In this scenario, Websense Content Gateway security features are well positioned for maximum protection and network performance. In this scenario, use of Websense Content Gateway authentication to validate client credentials is preferred. You must disable authentication on the third-party proxy.
PAGE 19
If the third-party proxy can send the X-Forwarded-For header but not the X-Authenticated-User header, the following step is also required: Deploy an XID agent to facilitate client identification by Websense Content Gateway. For information about installing and deploying XID agents, see the Websense Web Security/Websense Web Filter installation and deployment guides.
PAGE 20
If you want to exclude SLL traffic from the parent proxy and tunnel the traffic directly to the origin server, enable the Tunnel Requests Bypass Parent option in the Configure tab Content Routing > Hierarchies. This option can be used for any tunneled traffic.
PAGE 21
Set Websense Content Gateway as the forwarding host (in the Blue Coat Management Console Configuration tab, Forwarding > Forwarding Hosts). In the Blue Coat Management Console Configuration tab, click Policy and select Visual Policy Manager. Click Launch and configure the header policy as follows: 1. In the Policy menu, select Add Web Access Layer and enter an appropriate policy name in the Add New Layer dialog box. 2. Select the Web Access Layer tab that is created. 3.
PAGE 22
Content Gateway to read the X-Forwarded-For and X-Authenticated-User headers sent by the downstream ISA server. Two versions of the plug-in are available: Websense-AuthForward32.dll for 32-bit ISA servers Websense-AuthForward64.dll for 64-bit ISA servers. Zip files for both versions are available for download at: http://installers.websense.com/Downloads/files/v7.5/full/ISAPlugin Install the plug-in as follows: 1. Copy the appropriate Websense-AuthForward.