CacheGuard OS
User's Guide - Version 5.7.6



Web Server Cloaking

 You can implement the appliance in front of a group of Web servers to cloak against unwanted accesses. In this way, the appliance filters all Web traffic going to or coming from cloaked Web servers. This implementation is called the "reverse Web" mode or simply "rweb" mode. Implemented this way, the appliance acts as an IP firewall, a reverse Web proxy and a bandwidth shaper. Note that all available features in forwarding mode are also available in reverse mode so you can secure and optimise Web traffic exchanged with your Web servers. To inspect Web traffic content, the appliance acts as an HTTP SSL terminator.

To activate the reverse mode, use the command "mode". If the forwarding mode is no longer required it is better to deactivate it. To activate the "rweb" mode and deactivate the "web" (forwarding) mode use the following commands:

The command "rweb" allows you to configure the reverse mode.

Web Site definition

In reverse mode, the term "backend" (or "real") Web server refers to the cloaked Web server so the appliance becomes a virtual (or transparent) Web server. To configure the appliance to cloak a Web site you have to review the IP configuration on your Web servers. For instance, consider the Web site name www.example.com normally reachable at the IP address 192.168.1.254. To implement the reverse mode, real backend Web servers and the appliance should differ in their public IP addresses. In reverse mode, the public IP address of the appliance is its external IP address. The public IP address of a Web server is the IP address at which end users can reach the Web server. In the above example, we chose to assign the IP address 192.168.1.254 to the virtual Web site and change the public IP address of the backend Web server to 10.0.10.11. This way, no DNS modification is required to reach the name www.example.com. To implement this configuration use the following commands:

Load balancing

 The appliance may balance the Web traffic load on several real Web servers. To do so, just include additional backend Web servers to the pool of load balanced real Web servers. In the previous example, to add the backend HTTP server privately reachable at the IP address 10.0.10.12 use the following commands: Note that in the present appliance version, the load-balancing policy distributes the traffic on backend Web servers according to a hashing method based on the requested URL. This method is called CARP (Cache Array Routing Protocol). This load-balancing policy does not conserve application contexts, thus sessions are not sticky and the Web traffic distribution is optimised.

If your Web servers run applications that require that the same session sticks to the same real Web server you will most likely need to implement a dedicated load balancing equipment. But note that in most cases there are alternative solutions. For instance, if your Web servers use mod_jk or mod_wl which are apache plug-ins to connect respectively to Tomcat® and BEA WebLogic®, the session preservation is automatically managed by those plug-ins. Also if you use PHP and MySQL, there is an extension which is called session_mysql to assure the session preservation. That extension allows you to store your sessions in a MySQL database accessed from all your real Web servers.

High Availability

In a load-balancing configuration, the appliance uses a health checking mechanism to assure that all real Web servers run properly and are alive to serve HTTP requests. In case of a failure of a Web server, the failed Web server is automatically removed from the load balancing pool so no requests will be forwarded to it. Once the repared or replaced Web server is ready to be used, it will be automatically re- added to the load balancing pool. The health checking mechanism uses a TCP connect method to check the availability of real Web servers at their private IP address as configured with the command "rweb host". The checked TCP port is the standard HTTP port 80.

SSL Terminator
In reverse mode, the appliance acts as an SSL terminator for HTTPS Web sites to cloak. When the appliance acts as an SSL terminator, all Web traffic is encrypted between end users (Web surfers) and the appliance (The SSL terminator). Afterward, the appliance decrypts Web traffic before addressing real Web servers. The SSL termination on the appliance is mandatory to assure operation on Web contents (Filtering, HTTP compression...). In the previous example, to add the SSL encryption capability to the Web site www.example.com publicly reachable at the IP address 192.168.1.254 (With the name https:// www.example.com) use the following commands: At this stage, you can check the "apply" operation state using the command "apply report". When the apply operation is completed, an RSA private key, a self signed X.509 certificate and a CSR (Certificate Signed Request) are generated.

You can save the CSR on a trusted TFTP file server using the following command. To declare a file server as trusted use the commands "access file ; apply". To save the CSR in a file named www.example.com.csr located on a TFTP file server reachable at the IP address 10.0.10.1 use the following command:

Now you can submit the CSR to your CA (Certificate Authority) to obtain a signed certificate. After receiving your signed certificate file (and possibly the associated CA chain), put it on your trusted file server and use the following commands to import it (in this example we suppose the signed certificate filename is www.example.com.cert):

If you need to import a CA chain, replace the keyword "sslcert" by the keyword "sslchain" and remember to specify the appropriate CA chain filename. Be sure to always save your private keys and certificate information in a safe place. You can save a private key and other certificate related information to a trusted file server using the command "rweb").

A Complete Sample

 Consider the Web site named secure.example.com. Because the confidentiality is very important you want to allow only the HTTPS protocol with this Web site - HTTP has to be banned.

The available bandwidth is not large enough and you don't want to penalise internal Web usage because you want to host this Web site. Also secure.example.com is not the only hosted Web site even if it should be reachable at all times.

Because this Web site is very strategic for the business, it requires a very high level of availability and it should not be unavailable more the 20 minutes per month. Lastly, real Web servers hosting that Web site are overloaded because they spend too much time delivering static objects. You can provide solutions for all these issues with the unique integrated appliance, CacheGuard OS.

In our example, 3 real servers host the Web site secure.example.com and are privately reachable at the following IP addresses: 10.0.10.1, 10.0.10.2, 10.0.10.3. The secure.example.com Web site is publicly reachable at the IP address 192.168.1.11 so the appliance hosts this IP address.

The Internet connectivity is asymmetric so the download speed is 20 Mbps and uploads are done with a rate of 2 Mbps. The Internet router has two IP addresses: One private IP address associated to its LAN interface and one public IP address associated to its WAN interface and reachable by Web surfers located all over the world. Also the router is configured to NAT its public IP address to the IP address 192.168.1.11 for the HTTPS port (443).

We want to reserve 1 Mbps bandwidth for all hosted Web applications and a reasonable required bandwidth for outgoing Web traffic for our secure.example.com Web site is estimated at 300 Kbps (30% of 1 Mbps) Our solution is to implement 2 appliances in high availability mode with 4 network interfaces on each. To configure the first appliance use the following commands:

At this stage we have to wait for the termination of the command "apply". Afterward, the generated SSL certificate and private key should be saved on a file server to import into the second appliance (the two appliances should share the same SSL certificate). To do so we suppose we have already declared the TFTP file server 10.0.10.1 as trusted using the command "access file".

To save the generated SSL key and certificate respectively in the files secure.example.com.key and secure.example.com.cert located on the TFTP file server 10.0.10.1 use the following commands:

The second appliance has a symmetric configuration. To configure the second appliance use the following commands: Now both appliances are configured in an active/passive HA (High Availability) mode that supports failure on different stages (a single appliance, a network interface, a Web server). Moreover, if each logical network interface of the appliance is connected to two redundant switches (using the bonding mechanism) a switch failure is also assured. In this implementation a minimum of 300 Kbps is reserved for the Web site secure.example.com, which is a secured Web site because we use SSL. We've clocked real Web servers with our two appliances so real Web servers are never accessed directly by end users (Web surfers). Each appliance act as an IP firewall to block unwanted intrusion and as a WAF (Web Application Firewall) to block malicious well-known Web requests.

You can improve this implementation by using an active/active mode to share the total load between both appliances and assure that in case of a failure on one appliance the second appliance has an up-to-date cache. To do so, you can use a round robin DNS mechanism or a network load balancing mechanism. If you're using a DNS round robin mechanism, the Web site name secure.example.name should be resolved to two IP addresses, let say 192.168.1.11 and 192.168.1.12.

In our previous example, because we've used a NAT method on the Internet router to reach our appliances, the DNS round robin mechanism would not be possible. To simplify we suppose that 192.168.1.11 are 192.168.1.12 are publicly reachable and therefore no NAT method is required.

The first appliance remains active for the IP address 192.168.1.11 and becomes passive for the IP address 192.168.1.12 while the second appliance has a symmetric configuration in which the IP address 192.168.1.11 is passive and the IP address 192.168.1.12 is active. To implement such a configuration we use the following commands on the first appliance:

The second appliance has a symmetric configuration. Use the following commands on the second appliance:

Copyright (C) 2002-2011 CacheGuard - All rights reserved