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

Web Server Cloaking

CacheGuard appliance can be implemented as a reverse Web proxy in front of a group of Web servers to protect them against (unwanted) direct accesses on the one hand, and to optimise the Web traffic exchanged with them on the other. This implementation is called the reverse mode (or rweb mode) and protected Web application reverse websites. All security and optimisation features available in CacheGuard-OS can join together to offer the best-ever security and network optimisation solution to protect Web application. You can find below all the advantages of this mode combined with others:

• Firewall: blocks unwanted network accesses to Web servers.
• Reverse Proxy: allows to do note expose Web servers directly to the internet.
• SSL Offloading: terminates SSL connections on the CacheGuard appliance in order to offload Web servers.
• WAF: the Web Application Firewall (WAF) blocks content attacks such as SQL injections.
• Load Balancing: allows to balance a website load on a group of Web servers.
• High Availability: allows service continuity in case of a failure on a CacheGuard appliance or a Web server.
• Caching: caches satic Web objects such as images to offload Web servers.
• HTTP Compression: saves the WAN bandwidth.
• Antivirus: blocks malware injections on Web pages.
• QoS: allows to shape the Web traffic and offer QoS to critical applications.

To activate the reverse mode, you can use the mode rweb on command. Then you must use the rweb command to configure this mode. For instance, the following commands allow you to activate the reverse mode and protect the Web server having the 10.0.10.11 IP address and hosting the www.example.com website name:

• mode rweb on
• ip external 192.168.1.1 255.255.255.0
• rweb site add www.example.com http
• rweb host www.example.com add rweb http 10.0.10.11
• apply

Anti Spoofing Note: a host is always specified alongside a network interface via which it is allowed to communicate in order to block any IP address spoofing. The rweb keyword in the "rweb host www.example.com add rweb http 10.0.10.11" command above, specifies that network interface. It represents the pseudo network interface named rweb in VLAN mode or the native internal network interface (in case where the VLAN mode is deactivated). Please refer to the rweb command manual for detailed information on this topic.

In reverse mode, CacheGuard appliance acts as a virtual Web server cloaking real Web servers (called hosts). Cloaked Web servers should then be publicly exposed with the CacheGuard appliance external IP address. For instance, in the example above, the www.example.com name should be publicly resolved to 192.168.1.1.

Load Balancing

If more than one host is associated to a website, the total load on that website is balanced over all its associated hosts. In addition, CacheGuard appliance continuously checks the availability of hosts and in case of a failure (unavailability) on a host, it no longer sends to it Web requests (ie. it removes it from the pool of load balanced hosts), hence providing websites high availability.

The default load balancing method consists of sending the same number of requests to each host. This method is called robin (for round-robin). When adding (associating) a host to a website name, an optional weight can be specified to configure the load balancing in order to solicit more or less that host. In addition, if the underlying Web application (running on hosts) of a website requires that a given Web client be always managed by the same host (to preserve any application context), you must activate the sticky load balancing for that website. Sticky connections are based on an inserted (by CacheGuard appliance) or on existing HTTP cookie that you must configure using the rweb command.

For instance, to complete the previous example, we can add the host having the 10.0.10.12 IP address to the pool of load balanced hosts and configure a round-robin sticky load balancing for the www.example.com website. The following command allows you to have such a configuration:

• rweb host www.example.com add rweb http 10.0.10.12
• rweb balancer www.example.com robin sticky
• apply

SSL Offloading

In order to allow a CacheGuard appliance to handle (inspect, cache...) Web contents in HTTPS (encrypted) traffic, it should be capable to decrypt it first to have an unencrypted access to its content. To this end, CacheGuard appliance acts as an SSL terminator for HTTPS websites that it manages. While communications between Web clients and HTTPS websites that are managed by a CacheGuard appliance are always encrypted, communications between the appliance and hosts can be encrypted (using HTTPS) as well as unencrypted (using HTTP).

When the HTTP protocol is used to communicate with hosts, CacheGuard appliance acts as an SSL off-loader for those hosts. It is important to note that in an SSL offloading configuration, every care should be taken to isolate unencrypted Web traffic between CacheGuard appliance and hosts in order to do not allow unauthorised access to that unencrypted traffic. The http keyword in the "rweb host www.example.com add rweb http 10.0.10.12" command above, specifies to use the SSL offloading for that host. To do not perform an SSL offloading for a host, you can use the https keyword instead of http. Refer to the rweb command manual for further information on this topic.

As an SSL off-loader, CacheGuard appliance must naturally have access to public SSL certificates and private keys associated to HTTPS websites that it manages. You can use the tls command to manage SSL certificates and private keys used by the appliance. The same website name can exist in HTTP and HTTPS versions. In this case, all requests on the HTTP version are forwarded to the HTTPS version by default (you can modify this behaviour if needed). In the previous example, to add the SSL encryption capability to the www.example.com website (publicly reachable at https://www.example.com/), you can use the following commands:

• tls server add myTLSObject
• tls server generate myTLSObject
• rweb site add www.example.com https myTLSObject
• apply

TLS Note: once the apply operation is completed, an RSA private key, a self signed X.509 SSL certificate and a CSR (Certificate Signed Request) are generated. You can save the CSR on a trusted file server and then submit it to your CA authority to be signed. The new official signed certificate can then be loaded into the CacheGuard appliance. You can refer to the access file and tls server command manuals to get help on how to load and save SSL certificates.