Why and how should explicit HTTP connections to the CacheFlow appliance be denied from outside?


Article ID: 167485


Updated On:




A CacheFlow appliance may be configured with explicit HTTP connections enabled. This is done by enabling the ‘Explicit' HTTP proxy service on port 80. The primary purpose of allowing explicit HTTP connections to the CacheFlow on port 80 is to allow an L4 switch (redirecting HTTP user traffic to one or more CacheFlow appliances) to perform CacheFlow health checks.

When a CacheFlow appliance is deployed in a network location that is accessible from the internet (it is configured with a public IP, or is otherwise publicly accessible) it can unknowingly be turned into what is called an “open proxy” (an “open HTTP proxy” in this case). The primary use of  an “open proxy” is to get around the user’s network security. Having a network device discovered as an “open proxy” can lead to attacks that may overload the device, causing considerable performance degradation. Even after an “open proxy” has been secured, it may still likely be the subject of failed attacks, as it was previously discovered as one. Hence, it is important to safeguard against “open proxy” attacks upon your deployment of the CacheFlow appliance.


Important: Please note that it is not necessary to do this if you are not using CacheFlow health checks on your L4 switch.

To prevent your CacheFlow from being an “open proxy,” explicit traffic sent to the IP of the CacheFlow at port 80 needs to be restricted to a “permitted group” of client IPs. This access restriction can be done on any one of these network devices:

  • the edge router that is routing port 80 HTTP traffic to the L4 switch,
  • the L4 switch that is redirecting HTTP traffic to CacheFlow appliances,
  • a CacheFlow appliance.

In terms of performance, the most efficient approach is to apply this restriction at the edge router or on the L4 switch, rather than on every CacheFlow appliance in your network. Dropping unwanted packets as soon as they enter your network reduces the load on processing and directing/routing these packets within your network. Please consult the product documentation of your router or L4 switch for implementing this restriction on the device.

If you decide to restrict explicit access to port 80 on the CacheFlow appliance, you will need to do the following using “local policy” in the CLI:

  1. Define a ‘subnet’ of client subnets and IP addresses that are permitted explicit access to port 80 on the CacheFlow.
    This would definitely include your L4 switches. If you have HTTP test clients requiring explicit access to the HTTP proxy for troubleshooting customer related issues, then you will want to add these clients to this subnet as well. For example, name the subnet ‘allowed_explicit_clients’ to make the purpose of the subnet clear.
  2. Define an <Access> layer which will match on ‘client.connection.explicit’ condition being true, meaning it will apply only for explicit HTTP connections.
  3. Test the ‘client.address’ condition against ‘allowed_explicit_clients’ subnet.
    If it matches, then evaluation in this layer is done, and the connection will be allowed to proceed.
    If it does not match, it will proceed to the next line where an ‘exception’ will be set to ‘invalid_request’.
  4. Follow the access layer with an <Exception> layer, where matching on ‘invalid_request’ exception id will result in the ‘terminate_connection’ action being invoked and the connection will be dropped/denied.

Here is an example of “local policy” based on the above-mentioned steps:

; Policy Rules
<Access> client.connection.explicit=yes


        exception.id=invalid_request terminate_connection(yes)

define subnet allowed_explicit_clients      ; L4 switch running CacheFlow health checks  ; explicit HTTP proxy test clients

… [remainder of your “local policy” goes here, if any] …

In ‘(config)’ mode, use ‘inline policy local’ command to install the entire contents of your “local policy”.

(config)inline policy local <EOF>

[Your “local policy”]