CacheGuard-OS
User's Guide - Version UF-2.1.1


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/offloader.

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 website you have to review the IP configuration on your Web servers. For instance, consider the website 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 website 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 total Web 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: The default load balancing method consists in sending the same number of requests to each backend Web server. This method is called robin (for round-robin). An optional weight can be specified when adding a real Web server to balance more or less a real server.

If the Web application running on backend Web server requires that the same Web client always be redirected to the same backend Web server you need to activate the stickiness connectivity for the load balancing. Sticky connections are based on an inserted HTTP cookie. To configure a round-robin sticky load balancing for the previous reverse website use the following commands:

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 Offloading
In reverse mode, the appliance acts as an SSL offloader for HTTPS websites to cloak. When the appliance acts as an SSL offloader, all Web traffic are encrypted between Web clients and the appliance (the SSL offloader). Afterward, the appliance decrypts Web traffic before addressing real Web servers. The SSL offloading in the appliance is mandatory to assure operations on Web contents such as filtering, caching and compressing. In the previous example, to add the SSL encryption capability to the website www.example.com publicly reachable at https://www.example.com (where the name www.example.com is resolved to the 192.168.1.254 IP address) 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 my-certificate.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 an intermediate CA certificate), put it on your trusted file server and use the following commands to import it (in this example we suppose that the signed certificate filename is my-certificate.certificate):

Be sure to always save your private keys and certificate information in a safe place. You can save a private key and other SSL certificate related objects to a trusted file server using the command "rweb" followed by appropriate options. Please note that SAN (Subject Alternate Names) and wildcards certificates are supported. Please refer to the rweb documentation for further information on creating such a certificate.

A Complete Sample

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

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

Because this website is very strategic for your 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 website are overloaded because they spend too much time delivering static objects. You can provide solutions for all these issues with CacheGuard Appliance. In our example, 3 real servers host the website 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 website 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 users located all over the world. Also your internet 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 website is estimated at 300 Kbps (30% of 1 Mbps) Our solution is to implement 2 appliances in high availability mode with four physical 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 my-certificate.key and my-certificate.certificate 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 network switch failure is also assured. In this implementation a minimum of 300 Kbps is reserved for the website secure.example.com, which is a secured website 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 users) coming from the internet. 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.
Copyright (C) 2009-2023 CacheGuard - All rights reserved