Vital Security9.0 Supported Topologies · 2013. 3. 19. · Series Version 9.0 Scanning Servers and...

Software Release 9.0

Vital Security™ Supported Topologies

Vital Security Supported Topologies

Page ii

Copyright © Copyright 1996-2008. Finjan Software Inc. and its affiliates and subsidiaries (“Finjan”). All rights reserved.

All text and figures included in this publication are the exclusive property of Finjan and are for your personal and non-commercial use. You may not modify, copy, distribute, transmit, display, perform, reproduce, publish, license, create derivative works from, transfer, use or sell any part of its content in any way without the express permission in writing from Finjan. Information in this document is subject to change without notice and does not present a commitment or representation on the part of Finjan.

The Finjan technology and/or products and/or software described and/or referenced to in this material are protected by registered and/or pending patents including U.S. Patents No. 3952315, 6092194, 6154844, 6167520, 6480962, 6209103, 6298446, 6353892, 6804780, 6922693, 6944822, 6993662, 6965968, 7058822, 7076469, 7155743, 7155744 and may be protected by other U.S. Patents, foreign patents, or pending applications.

Finjan, Finjan logo, Vital Security, Vulnerability Anti.dote and Window-of-Vulnerability are trademarks or registered trademarks of Finjan. Sophos is a registered trademark of Sophos plc. McAfee is a registered trademark of McAfee Inc. Kaspersky is a registered trademark of Kaspersky Lab. Websense® is a registered trademark of Websense, Inc. IBM® Proventia® is a registered trademark of IBM Corporation. Microsoft and Microsoft Office are registered trademarks of Microsoft Corporation. All other trademarks are the trademarks of their respective owners.

For additional information, please visit www.finjan.com or contact one of our regional offices:

USA: San Jose 2025 Gateway Place Suite 180 San Jose, CA 95110, USA Toll Free: 1 888 FINJAN 8 Tel: +1 408 452 9700 Fax: +1 408 452 9701 [email protected]

Europe: UK 4

th Floor, Westmead House, Westmead,

Farnborough, GU14 7LP, UK Tel: +44 (0)1252 511118 Fax: +44 (0)1252 510888 [email protected]

USA: New York Chrysler Building 405 Lexington Avenue, 35th Floor New York, NY 10174, USA Tel: +1 212 681 4410 Fax: +1 212 681 4411 [email protected]

Europe: Germany Alte Landstrasse 27, 85521 Ottobrun, Germany Tel: +49 (0)89 673 5970 Fax: +49 (0)89 673 597 50 [email protected]

Israel/Asia Pacific Hamachshev St. 1, New Industrial Area Netanya, Israel 42504 Tel: +972 (0)9 864 8200 Fax: +972 (0)9 865 9441 [email protected]

Europe: Netherlands Printerweg 56 3821 AD Amersfoort, Netherlands Tel: +31 334 543 555 Fax: +31 334 543 550 [email protected]

Catalog Name: VSST-TB - 9.0 -2

Email: [email protected]

Internet: www.finjan.com

Vital Security Supported Topologies

Page iii

Table of Contents

1. System Overview 1

2. All in One vs. Distributed Topology 2

3. Managing the Policy Server and Scanning Server 2

4. Supported Topologies 3 4.1 Basic Topologies 3 4.2 Proxy Chain Mode 6 4.3 ICAP Redirection 8 4.4 Authentication Services 11 4.5 Load Balancing 13 4.6 NG-8100 Appliance 16 4.7 Web Cache Communication Protocol 19

Appendix – Topology Summary 23

Supported Topologies

Page 1 Finjan proprietary and confidential

1. System Overview Located at the gateway to your network, the Vital Security Web Appliance monitors all traffic between your company and the Web. It identifies the “true type” of the content, scans it, then allows or blocks the content in line with the rules and policies that you and your organization define. You can also configure the extent of transaction logging and the generating of reports.

The following functional servers are incorporated:

♦ Policy Server: A centralized repository and administration point for system configuration and security policy settings. The settings defined in the Policy Server are “pushed” to all Scanning Servers such that the system is always updated.

♦ Log Server: A short-term centralized repository for transactional information. The transactional information is generated by the Scanning Servers and queued in Log Relays, after which they are aggregated to the centralized repository. The Log Server is a subset of the Policy Server.

♦ Report Server: A long-term centralized repository for transactional information. The transactional information is generated by the Scanning Servers and queued in Log Relays, after which they are aggregated to the centralized repository. The Report Server is a subset of the Policy Server.

♦ Scanning Servers: Multiple servers that scan content using the various scanning engines, including Finjan's proactive scanning technology, and enforce the predefined policy regarding that content.

♦ Authentication Device: a special device, used to authenticate users before they can browse the Internet. The Authentication Device communicates with an Active Directory in order to authenticate the users.

The following physical components can be incorporated in the full system deployment:

♦ Load Balancer: When the amount of traffic exceeds a Scanning Server’s capacity, or following redundancy requirements, the deployment includes several Scanning Servers. A Load Balancer balances the load of incoming requests traffic between all active Scanning Servers. The load balancer can be any 3rd party load balancer.

♦ Caching Server: A deployment can include a Cache Appliance NG-6600 or any other third party caching server. The caching server can be connected to the Scanning Servers via an upstream proxy or downstream proxy.

Although Vital Security supports many possible topologies, the following have been successfully tested and are therefore fully supported by Finjan.



If none of these topologies address your needs, please contact your local Finjan representative for the appropriate deployment. The supported topologies are categorized into the following groups:

♦ Basic topologies – including both single and multiple Scanning Server topologies.

♦ Third party based topologies – topologies that include other components such as caching servers and Layer 7 switches.

2. All in One vs. Distributed Topology Finjan’s Vital Security appliance can be installed in different operational modes:

♦ All in One

♦ Distributed Topology (Policy Server and Scanning Server) When working in All in One mode, a single server is used both for scanning the traffic and for managing the security policies, Logs, Reports and Updates. When an All in One device is used to manage an additional Scanning device, it provides additional scanning capabilities. The device should be set to receive a scanning throughput of about 50% of the maximum scanning capabilities of a standalone device. This enables the All in One device to perform other tasks required of it.

For more information about sizing, please contact your Finjan representative.

Working in a distributed topology, where the Policy Server and Scanning Server are installed on separate and dedicated hardware allows more flexibility and maintainability to the Policy Server (users are not affected by the load / availability of the Policy Server).

NOTE: An All in One does not include an Authentication Device.

3. Managing the Policy Server and Scanning Server In all the topologies presented in this document the Policy Server does not appear in the topology (unless the topology is All in One), due to the fact that the Policy Server can be located anywhere in the network, so long as it can communicate with the Scanning Server.

In all management configurations, ensure that the IP address and Hostname of the Management unit is configured in the browser’s list of servers that should not be accessed via the proxy. This will ensure that



active content which is used by the Management Console is not accidentally blocked by the scanning proxy rules. To ensure proper communication between Vital Security Web Appliance Series Version 9.0 Scanning Servers and Policy Server, several ports have to be open on the firewall. For detailed information, please refer to the Port Mapping Feature Description.

4. Supported Topologies The following Topologies are supported with Vital Security Software Release 9.0.

4.1 Basic Topologies

4.1.1 Simple Proxy mode In the Simple Proxy mode, users are configured to work with a proxy server. In this mode the users use the IP address of the Scanning Server as their proxy server for HTTP (default port 8080), HTTPS scanning (default port 8443) and FTP (default port 2121).

The Scanning Server can be located either behind a firewall, in the DMZ (see Figure 1) or on the same network as the users.

Figure 1: Simple Proxy Mode (DMZ)



Figure 2: Simple Proxy Mode (Same network)

The traffic flow is as follows:

1. The user initiates a connection to the Internet (HTTP, HTTPS, or FTP). The user sends the request to its proxy server, which is the Scanning Server.

2. The Scanning Server processes the request (identifying the user, authenticating the user if required and finding the user’s policy) and if the content is allowed, then the Scanning Server issues a new request to the original destination server.

3. The returning traffic is processed again by the Scanning Server (the Scanning Server is the originator of the session) and only after processing, the end-user receives the data (or block message).

4.1.2 Transparent Mode In the Simple Transparent mode, users are not configured to work with a proxy server. In this mode the users send their requests directly to the IP address of the original web server. A Layer 4 traffic redirector (as appears in Figure 3) intercepts all HTTP, HTTPS and FTP traffic to the Scanning Server (using the original destination IP of the HTTP (or FTP) server.

In order to configure the proxy to work in transparent mode, transparency has to be enabled (Settings Devices Scanning Server General Click Enable in the Transparent Proxy Mode tab.)



Figure 3: Proxy Configuration for Transparent Mode

Another way of achieving user transparency is by including a firewall rule which uses destination NAT for all HTTP and HTTPS (and possibly FTP) traffic. When users send HTTP or HTTPS traffic, this traffic is passed via the firewall. The destination NAT rule changes the destination IP address from the original web server in the Internet, to the IP address of the Vital Security Scanning Server. The traffic then reaches the Vital Security Scanning Server, which scans the traffic and fetches the information from the Internet. Returning traffic is scanned again and returned to the user.

Figure 4: Simple Transparent Mode


1. The user initiates a connection to the Internet (HTTP, HTTPS or FTP). The user sends the request to the original server such that the destination IP address of the request is the IP address of the real server.



2. The layer 4 switch transparently redirects all HTTP, HTTPS and FTP traffic to the Vital Security Scanning Server, which then processes the request (identifying the user, authenticating the user if required and finding the user’s policy) and if the content is allowed, the Scanning Server issues a new request to the original destination server.

3. The returning traffic is processed again by the Scanning Server (the Scanning Server is the originator of the session) and only after processing, does the end-user receive the data (or block message) using the original server IP as the source IP address (i.e. as if the user communicates with the original server).

4.2 Proxy Chain Mode Vital Security Web Appliance can be installed as the Next Proxy of the existing proxy in the network. In this topology, the users can be configured to work with a proxy server (the existing proxy in the network) or the users can be transparently redirected to the proxy server (depending on the network topology and proxy transparency support).

In the Proxy Chain Topology, the Scanning Server can be out-of-line or in-line (connected with two interfaces).

Figure 5: Proxy Chain Mode (with Scanning Server out-of-line)



Figure 6: Chain Mode (with Scanning Server in-line)

NOTE: If user authentication is required verify that the proxy server supports Authentication Pass-through or forward user credentials via http headers. If this feature is supported, then when the Web Appliances request user authentication and the proxy server passes the request to the user.

The out-of-line topology is preferred, since in case of Scanning Server failure, it is easier to neutralize the redirection to the Scanning Server (if required).

If the corporate proxy is also a caching proxy which does not support IP spoofing, only one security policy can be enforced by the Scanning Servers.


1. The user initiates a connection to the Internet (HTTP, HTTPS, or FTP). Depending on the network topology, the user sends the request either to the original server if the first proxy is a transparent proxy, or directly to the IP address of the proxy server, if the proxy server is non-transparent.

2. After the first proxy has processed the request, it sends it in a proxy format to the Vital Security Scanning Server which then processes the request (identifying the user, authenticating the user if required and finding the user’s policy) and if the content is allowed, the Scanning Server issues a new request to the original destination server.

3. The returning traffic is processed again by the Scanning Server (the Scanning Server is the originator of the session) and only after processing does it send the traffic to the first proxy, which forwards it to the end-user after the first proxy has processed the traffic.



4.3 ICAP Redirection The Internet Content Adaption Protocol (ICAP) is a protocol that provides basic redirection to HTTP traffic. Many organizations may already implement a caching solution, where the cache server supports ICAP redirection (for example, Blue Coat). If the cache server supports ICAP redirection, the Vital Security Web Appliance can be installed in ICAP mode, without the need to change the existing network topology.

ICAP is a client – server protocol, which requires both ICAP client and ICAP server in order to operate properly. Finjan’s Vital Security Web Appliance can be installed as an ICAP Server. An ICAP server is a server that accepts ICAP requests arriving from an ICAP Client (for example, Blue Coat’s cache server). An ICAP client can redirect HTTP traffic (or portion of the traffic) to an ICAP server for additional processing, before sending the traffic to the Internet.

4.3.1 Basic ICAP Mode with a single Scanning Server Using ICAP, the client has to configure their browser settings to work with a proxy server, which is the ICAP client’s IP. Once the ICAP client processes the request (or reply) it forwards it to the Scanning Server in ICAP format.

Figure 7: Scanning Sever in ICAP Mode

4.3.2 Basic Load Balancing in ICAP Mode In addition to the basic ICAP capabilities described in section 4.3.1 Basic ICAP Mode with a single Scanning Server, an ICAP Client can redirect traffic to multiple Scanning Servers, and thereby add the high availability functionality to the network as well as scalability. The topology, as described in Figure 8 shows an ICAP client with multiple Scanning Servers. In such a topology, the Scanning Servers must have the same configuration. Configuration of both ICAP modes (REQMOD and RESPMOD) is required.



Figure 8: Basic Load Balancing in ICAP Mode

4.3.3 Advantages and Disadvantages of ICAP The advantages of using the ICAP topologies are as follows:

♦ Easy deployment – an existing proxy scan be easily configured to use the Scanning Servers as ICAP Server without any impact on the end-users.

♦ Control over content – organization with specific needs can increase performance by configuring their ICAP client to only send certain files for scanning by the ICAP Server.

The disadvantages of using the ICAP topologies are as follows:

♦ The ICAP topologies have similar security disadvantages of having a downstream Proxy. Most ICAP clients are Caching Servers so it’s possible that an item which was already cached will be served to a non-authorized user of a different security policy.

♦ When ICAP is implemented, there is the need to scan each transaction twice – once in REQMOD and another in RESPMOD. This adds an additional two hops to the traffic flow.

♦ Traffic originating from the ICAP Client – the Scanning Servers, must be treated differently and must be excluded from the ICAP treatment, in case it uses the same interface to connect to the internet.

4.3.4 ICAP Redirection vs. Proxy Chain Mode Both ICAP redirection and Proxy Chain Mode can be used in existing networks with minimal topology changes, however, Proxy Chain Mode is preferred over ICAP redirection for the following reasons:



♦ Protocol independent: although the ICAP protocol is RFC based (RFC 3507) and respected by Finjan Vital Security Web Appliance, some vendors may not respect the RFC and have interoperability issues with ICAP implementation.

♦ Ease of Configuration: most proxy servers allow the administrator to configure the next proxy by simply configuring the next proxy IP address and port, while ICAP configuration request knowledge in the ICAP protocol, as well as configuring the REQMOD and RESPMOD.

♦ Debug-ability: It is much easier to debug native HTTP than debug ICAP traffic. In case system administrator has to debug the entire system, it is easier to:

• Read capture files of HTTP traffic.

• Configure a user to work directly with the Scanning Server and bypass the proxy server in order to identify the source of the problem.

♦ Number of hops: When working with ICAP Redirection, there are an additional two hops for each transaction. Traffic flow is as follows: The user send the traffic to the proxy server (1), the proxy server redirects the traffic to the Scanning Server (2), the Scanning Server scans the traffic and responds to the proxy (3), the proxy sends the request to the Internet (4) and the reply (5) is forwarded via ICAP to the Scanning Server (6) which scans the traffic and replies to the proxy (7), which then sends the traffic to the user (8).

Figure 9: Traffic Flow with ICAP Redirection



♦ When working in Proxy Chain Mode, the traffic flow is as follows: The users send the traffic to the proxy server (1), the proxy server forwards the traffic to the next proxy, which is the Scanning Server (2), the Scanning Server scans the request and retrieves the content from the Internet (3). When the traffic arrives from the Internet (4) it is scanned by the Scanning Server, which replies to the Proxy that originally made the request (5). The proxy server receives the traffic from the Scanning Server and sends it to the user (6).

Figure 10: Traffic Flow with Proxy Chain Mode

NOTE: When deploying in ICAP mode, make sure the Scanning Servers and Policy Server are allowed to access the Internet so they can perform pre-fetching and retrieve updates. If necessary, configure the HTTP devices and update mechanism to use the ICAP Client’s address as Proxy for Internet access.

ICAP requires configuration of the ICAP modes: REQMOD and RESPMOD.

For more information about ICAP configuration and integration with Blue Coat Secure Gateway, refer to the Setup and Configuration Guide, Chapter 4.

4.4 Authentication Services Enterprise networks are built from different topologies for which different device types and configurations are used. End-user identification and authentication can be performed via various tools, devices, network equipment and through the use of different protocols. The ability to identify the user during the web transaction is crucial in order to isolate threats



and enable policy enforcement with a specific behavior for each user or group. The option to identify and/or authenticate the user is dependent on the network layout, the security rules that are used in the network and the capability to integrate with an external authentication device. There is no common single solution that can fit all organizations and therefore an enterprise solution should be flexible enough to offer support for multiple topologies.

Figure 11: Authentication Device Topology

In this topology the Scanning Server does not communicate with any of the LAN appliances directly but rather uses the HTTP redirect method as a response to the end-user HTTP request when there is a need to authenticate a user.

The Scanning Servers are set up and configured with the overall network topology structure in order to choose the right Authentication Device to redirect to. Once an HTTP request arrives, the Scanning Server uses an identification policy to decide whether and how to identify the user behind this session. If authentication is required, an HTTP redirect response is sent back to the end-user browser with the URL information of the relevant Authentication Device. As a result, the browser issues an HTTP call to the Authentication Device URL. The Authentication Device receives the HTTP request and initiates its own identification policy. In most cases it will issue an authentication challenge while communicating with the end-user browser. It then uses the authentication credentials that are received from the remote browser and authenticates them with the Active Directory which acts as an Authentication Server.

The Authentication Device can be configured to work with multiple active directories, even those that are not in a trust relationship.



NOTE: Since authentication requires redirection to the Authentication Device it is supported only for HTTP. In order to authenticate also HTTPS and FTP the Authentication Device must be configured as the HTTPS and FTP proxy.

When working with Authentication Device it is assumed that all http user-agents support cookies.

Authentication Device cannot be used as a subset of policy server in policy HA topologies.

The Scanning Server can also perform Authentication. For more information on Authentication, please refer to the Authentication and Identification Feature Description.


1. The user initiates an HTTP connection to a server in the Internet and sends the request to the proxy server, which is the Scanning Server.

2. The Scanning Server replies with HTTP 302 Redirect response to the end-user browser and redirects the end user to the Authentication Device.

3. The end-user then opens a new connection to the Authentication Device, requesting for the original URL.

4. The Authentication Device replies with HTTP 407 – Authentication required and close the connection.

5. The end-user then opens a new connection and sends its credentials to the Authentication device. The Authentication device communicates with the AD/LDAP/Authentication server and authenticates the user based on the collected credentials.

6. Once the Authentication process is completed and the user is authentication, the Authentication Device redirects the user, using HTTP 302 Redirect back to the Scanning Server.

4.5 Load Balancing

4.5.1 Load Balancing Multiple Scanning Servers in Proxy Mode Using a third party load balancer, it is possible to scale up and add additional Scanning Servers based on network growth and load of the Scanning Servers.



In Figure 12, all the users in the network are configured to work with a proxy server for HTTP (default port 8080), HTTPS (default port 8443) and FTP (default port 8080). The IP address of the proxy server in the user’s browser is the Virtual IP of the load balancer. The load balancer has a single farm with all the Scanning Servers in the farm. The default gateway of the Scanning Servers is the internal interface of the load balancer (the Scanning Servers IP address should be part of the same network as the internal interface of the load balancer). The default gateway of the load balancer is the Firewall. The load balancer performs periodical health checks in order to verify that the Scanning Servers are active and available to serve the users. In case of failure of a Scanning Server, the traffic is distributed among the rest of the available Scanning Servers (the users will, however, have to re-establish their connection). In this topology, the load balancer has a redundant load balancer, working in the Vendor’s Proprietary Redundancy Protocol mode (VRRP mode).

For more information about load balancing, please refer to the Load Balancing Vital Security Scanning Servers Technical Brief.

NOTE: The Policy Server must communicate directly with all the Scanning Servers in the network and not via the VIP, therefore, all the Scanning Servers must be configured on the Policy Server.

Figure 12: Load Balancing Multiple Scanning Servers in Proxy Mode

4.5.2 Load Balancing Multiple Scanning Servers in Transparent Mode Using a third party load balancer, it is possible to scale up and add additional Scanning Servers based on network growth and load of the Scanning Servers. In Figure 13, the users in the network do not have any browser settings and are sending their requests directly to the original web and FTP



servers (HTTPS is not supported in transparent mode). The load balancer, installed in-line, intercepts users’ traffic and redirects the traffic to the best available server (based on load balancing algorithm). In this topology, the load balancer has a single farm with all the Scanning Servers in the farm. The default gateway of the Scanning Servers is the internal interface of the load balancer (the Scanning Servers IP address should be part of the same network as the internal interface of the load balancer). The default gateway of the load balancer is the Firewall. The load balancer performs periodical health checks in order to verify that the Scanning Servers are active and available to serve the users. In case of failure of a Scanning Server, the traffic is distributed among the rest of the available Scanning Servers (the users will, however, have to re-establish their connection). In this topology, the load balancer has a redundant load balancer, working in Vendor’s Proprietary Redundancy Protocol mode (VRRP mode).

NOTE: The Policy Server must communicate directly with all the Scanning Servers in the network and not via the VIP, therefore, all the Scanning Servers must be configured on the Policy Server.

Figure 13: Load Balancing Multiple Scanning Servers in Transparent Mode


1. The user initiates a connection to a server in the Internet (HTTP, HTTPS or FTP) and sends the request to the proxy server, which is a virtual IP address, belonging to the load balancer and represents the cluster of Scanning Servers.

2. Based on the load balancing decision, the Load Balancer changes the original destination IP (the virtual IP) as well as the destination IP address and destination MAC address to the IP and MAC of the selected Scanning Servers.



4.6 NG-8100 Appliance Vital Security™ Web Appliance NG-8100 is Finjan’s real-time web security solution, recommended for enterprises/organizations with up to 250,000+ users. This solution delivers unmatched web security in a high performance, scalable and high availability integrated blade server appliance. NG-8100 utilizes Finjan’s patented real-time content inspection technology to secure corporate networks against all types of web-borne attacks, including Spyware, Phishing, Trojans, obfuscated malicious code and other types of malicious content. This solution can be integrated Nortel Networks Layer 2-7 Gigabit Ethernet Switch Module Load Balancer to ensure compliance with the high performance and availability requirements of large enterprise networks.

Two main topologies are supported by the NG-8100:

♦ Distributed topology using Nortel Layer 2-3 Switch or Cisco® Intelligent Gigabit Ethernet Switch

♦ Load Balancing of the Scanning Servers using Nortel Layer 4-7 Switch

4.6.1 Multiple Scanning Servers for different users groups using the Nortel Layer 2-3 Switch Using the Nortel Layer 2-3 switch or the Cisco Intelligent Gigabit Ethernet switch with the Vital Security NG-8100 series, different users groups can be configured to work with different blades for different Scanning Servers for HTTP, HTTPS and FTP. In case transparency is required, a Layer 4 switch can be used in order to transparently redirect all HTTP and FTP traffic to the Scanning Servers in case of Scanning Server failure.



Figure 14: Multiple Scanning Servers for different users groups using the Nortel Layer 2-3 Switch

NOTE: In case of a Scanning Server failure there is no automatic failover. System administrators will have to manually change the proxy settings of the users configured to the failed Scanning Server or to manually replace the failed blade.

4.6.2 Load Balancing the Scanning Servers using the ICAP Protocol Using the Nortel Layer 2-3 Switch or the Cisco Intelligent Gigabit Ethernet Switch with the Vital Security NG-8100 series, traffic is distributed to the Scanning Server via the ICAP protocol by an ICAP client (such as Blue Coat). In this topology, the Scanning Servers are configured as ICAP servers.

4.6.3 Load Balancing the Scanning Servers using Nortel Layer 2-7 switch When using the Nortel Layer 2-7 Switch, all the users are configured to send their web traffic (HTTP, HTTPS and FTP) to a virtual IP address, which is managed by the Layer 2-7 Switch. The Layer 2-7 Switch distributes user traffic among the available Scanning Server based on a user defined load balancing algorithm (such as round-robin, least users, etc). In case of Scanning Server failure, users are transparently redirected to another available Scanning Server.



Figure 15: Load Balancing of Scanning Server with Nortel Layer 2-7 Switch

4.6.4 Multi-Site Load Balancing using NG-8000 and Nortel Layer 2-7 Switch For large organizations that need to install Scanning Servers in two different sites, this topology provides site redundancy by using Nortel layer 2-7 Switch. In this topology, end users are configured to send their requests to a proxy server, which is a VRRP address, handled by both NG-8000. When both NG-8000 are up and running, only one of them is managing all traffic and considered to be the master, which is responsible for the VRRP address. When end users send their requests to the VRRP address, the Nortel layer 2-7 Switch makes a load balancing decision and redirects the end-user to one of the Scanning Servers, based on the load balancing algorithm. In case all Scanning Servers at one of the sites fail, the other Scanning Servers, on the other site are still available to serve the user’s requests.

NOTE: For this topology, it is mandatory to have layer 2 connectivity between the two locations.



Figure 16: Multi-Site Load Balancing using NG-8000 and Nortel Layer 2-7 Switch

4.7 Web Cache Communication Protocol Given that WCCP allows integration between WCCP enabled routers and switches, using the Vital Security System in transparent mode means that there is no need to configure the end user’s browser settings, since the redirection is performed by the WCCP enabled router. The end user sends the request to the original server, and the WCCP enabled router intercepts the request and redirects it to one of the Scanning Servers. The Scanning Server then scans the traffic and creates a new request (using the Scanning Server IP address as the source IP) and sends it to the original server.

The introduction of WCCP allows the Vital Security system to support the following topologies

4.7.1 Single Router with a Single Scanning Server This topology is the basic WCCP topology. All web traffic is redirected to a single Scanning Server. Based on the router’s configuration, traffic will be sent directly to the Internet if the Scanning Server fails.



Figure 17: Single Router and Single Scanning Server

4.7.2 Single Router with Multiple Scanning Servers In this topology, multiple Scanning Servers are connected to a single router, and the router load balances traffic (equally) among all the Scanning Servers. Failure in a single Scanning Server does not affect the network since the other Scanning Servers take over and handle traffic.

Figure 18: Single Router and Multiple Scanning Servers

4.7.3 Multiple Routers with Multiple Scanning Servers In this topology, multiple routers (or switches) are connected to multiple Scanning Servers. Each Scanning Server receives traffic from multiple routers.



Figure 19: Multiple Routers and Multiple Scanning Servers

4.7.4 WCCP and Authentication In this topology traffic intercepted by the WCCP enabled router is redirected to the Scanning Server, which in turn redirects the user to the authentication device. After the authentication process is completed, the Scanning Server provides the information to the authenticated user.

Figure 20: WCCP and Authentication Device



4.7.5 Mobile Users Protection Protecting mobile users is critical for organizations in order to prevent them from being infected while they are out of the organization’s network. When a mobile user is out of the office and his/her laptop is not protected, there is a real danger that the user will get infected. A Trojan can be injected into the user’s laptop; data can be stolen from the user and the user may be exposed to many security risks.

Vital Security allows protecting mobile users while they are on the move, out of the corporate network, working from their home, traveling, or while connecting to any other unprotected network.

In this topology, the user can access the Scanning Server via a VPN connection (or otherwise) to the Scanning Server. The browser is configured to use a proxy server, which is the IP address of the Scanning Server. The user must establish a session (VPN or otherwise) with the firewall prior to the browsing of the Internet.

NOTE: When allowing remote users to access the Scanning Server, make sure that the User Access List is configured to allow this connection.

Figure 17: VPN Access between the Client and the Firewall



Appendix – Topology Summary

Placement Topology (assuming placement in DMZ)

Advantages Disadvantages Notes

Simple Proxy mode PC > FW > Finjan > FW > Web

♦ Full Authentication with MS AD

♦ Simple to install and manage (proxy.pac; AD-GPO; login scripts)

♦ Requires configuration changes on clients

♦ User credentials are passed in the DMZ

♦ May require load balancers





Proxy Chain Mode (Proxy Ahead or Upstream Proxy) PC > FW > Proxy > Finjan > FW > Web

♦ No configuration changes required on clients

♦ Cached objects are downloaded from the Proxy server which minimizes delays (improved performance)

♦ Cached content is not subject to the latest security updates, nor to policy changes on Finjan

♦ Finjan cannot log access to cached content

♦ Depends on proxy to authenticate and pass user ID in http header

♦ May not be possible to set different policies for different users/groups of cached objects


♦ If a policy regarding valid content changes, Finjan cannot prevent subsequent access to this data





Proxy Chain Mode (Proxy Behind or Downstream Proxy) PC > FW > Finjan > Proxy > FW > Web

♦ Proxy server controls timing and content availability behavior

♦ More secure - configuration changes on Finjan will scan any previously cached objects

♦ Can forward usernames and IP addresses in http header to proxy (if supported)

♦ Finjan has to scan every response - even if cached


♦ All accesses to cached content are subject to the logging policy, and are potentially logged by Finjan Vital Security





Transparent Mode PC > FW > Switch > FW > Web

Finjan

♦ No special browser configuration is required

♦ Transparent to users

♦ Must configure Layer 4 router/switch

♦ Identification limited to IP Address

♦ User authentication requires that the web client application support http redirects and cookies


♦ May not work with very old browsers which do not provide host information

♦ Agents and other programs that do not work with authentication may be allowed by rule so they won’t be blocked

♦ Transparency is unidirectional, upstream devices will see Finjan IP





ICAP PC > FW > Proxy > FW > Web

Finjan

♦ No configuration changes required on clients

♦ Caching good data

♦ Inherent load balancing between cluster of Finjan appliances

♦ Configuration changes on Finjan may affect cached objects in Proxy

♦ There is about an 8% loss due to ICAP protocol overhead, but this can be offset by having the Proxy filter out protocols Finjan doesn’t need to process such as streaming video

♦ Only Blue Coat and NetCache are supported





Web Cache Communication Protocol PC > FW > WCCP > FW > Web

Finjan

♦ No special browser configuration is required

♦ Transparent to users

♦ Usage of existing equipment

♦ Build-in load balancing and failover

♦ Must configure router/switch

♦ User authentication requires that the web client application support http redirects and cookies

♦ Transparency is unidirectional, upstream devices will see Finjan IP

♦ The IOS must support WCCP.

Vital Security9.0 Supported Topologies · 2013. 3. 19. · Series Version 9.0 Scanning Servers and...

Documents

Transcript of Vital Security9.0 Supported Topologies · 2013. 3. 19. · Series Version 9.0 Scanning Servers and...