Intro to Reverse Proxy

Version 3

     

     

    Introduction

     

    The idea behind a reverse proxy with McAfee Web Gateway is to make internal resources available to the public internet without compromising security. The added benefits are load balancing, caching, SSL encryption for servers that otherwise wouldn't be encrypted, and malware scanning and threat protection. My goal with this document is to provide a simple framework that can be expanded on to get a reverse proxy using McAfee Web Gateway up and running.

     

    Here's a diagram showing the basic concept of a reverse proxy:

     

    flow.png

     

    Pre-Requisites

     

    How do I get traffic to my reverse proxy?

     

    The first choice that has to be made is how to get traffic to your proxy. In that regard, there are a few options:

     

      • You can modify the DNS record for the server to point to the Web Gateway. This is the preferred method.
      • A firewall can be used to Port Forward traffic destined for the server over to the Web Gateway for proxying.
      • The Web Gateway can be deployed in Transparent Bridge to intercept and proxy the traffic originally destined for the server(s).  Click here for more info on Transparent Bridge deployments, https://community.mcafee.com/docs/DOC-5200.

     

     

    Proxy Port Configuration

     

    Two ports typically need to be enabled and listening in order to intercept web traffic - ports 80 and 443. Port 80 needs to be enabled to listen for normal HTTP traffic and port 443 is for HTTPS traffic. It is important that an asterisk be entered for 'Ports treated as SSL' for the port 443 configuration as we want all traffic that comes in on port 443 to be treated as SSL encrypted traffic.

     

    ports.png

     

    Server Certificate(s)

     

    A server certificate needs to be created that will be used to encrypt all traffic between the proxy and the end user. This certificate can be created right on the Web Gateway under Policy > Settings > Engines > SSL Client Context without CA. You could also import the certificate obtained from a certificate issuer or another source in the same location. Obtaining one from a trusted Certificate Authority would have the advantage that your end user browsers would automatically accept and trust this certificate.

     

    Note that you can import multiple certificates, one for each server that clients would be accessing (i.e intranet.company.local and webmail.company.local). In most cases where multiple hostnames would be proxied through the web gateway, it would be beneficial to use a wildcard certificate instead (i.e. *.company.local).

    Also consider that clients might be accessing resources directly via their IP address and that might result in certificate name mismatches. This is a very unlikely scenario though.

     

    You will need the certificate, private key and password if you wish to import the certificates. The certificates are created/imported under Policy > Settings > Engines > SSL Client Context without CA. Here you can see that I have a certificate for both the hostname and the IP.

     

    Note: It is important to enable the option "SSL-Scanner functionality applies only to client connection"!  Enabling this setting allows the Web Gateway to immediately perform the ssl handshake with the client.

     

    ssl_context_without_ca.png

     

    Reverse Proxy Rules (Framework)

    Reverse Proxy rules require a few standard components that we will introduce here as a framework. A rule set to get you started is attached at the end of this article. Keep in mind that especially for reverse proxy deployments, rules and functionality will vary widely depending or your individual needs. The standard components explained below are meant to give you a starting point and guidance but not a complete reverse proxy setup.

     

    Top Level Criteria

     

    You'll want to add criteria on to the top level of the Reverse Proxy rule set so that it only applies to requests that come in to the reverse proxy ports. You'll want to do the same for your Forward Proxy rule set if your Web Gateway is serving both functions. For this example, I have created a list called 'Reverse Proxy Ports' and put the ports 80 and 443 in that list. The list is used as criteria for both the forward and reverse proxy rule set.  Note the difference in operators used below ('is in' vs 'is not in').

     

    reverse_proxy_ports.png

    forward_proxy_ports.png

     

    Redirection to HTTPS

     

    One goal in this example is to always have the client talk to the Web Gateway securely using an SSL tunnel so that the traffic cannot be intercepted. We can do this by creating a rule that redirects all HTTP requests on port 80 to the original requested URL but this time using https:// rather than http://.

     

    redirect.png

     

    Client Context with Server Certificate and Content Inspection

     

    This rule set will allow the Web Gateway to terminate the SSL Connection and issue the web server's certificate to the client. This is where we're going to use the certificates that were imported as a pre-requisite.

     

    This rule set has two parts:

     

      1. Set Client Context: The rule is using the criteria 'Command.Name equals "CONNECT"' so that it only applies to the initial connection negotiation. We're restricting it to the CONNECT because the action is going to be 'Stop Cycle'. 'Stop Cycle' is used to allow the CONNECT to occur and establish Content Inspection so that we can see inside the tunnel. The Web Gateway will be the "web server" from the clients perspective.
      2. Enable Content Inspection: We need to have this rule to basically remind the proxy to continue the Content Inspection for all SSL traffic past the CONNECT phase.

     

    client_context.png

     

    Common Rules and Filters

     

    This section is where you can define the same types of Common Rules and Filters as you would normally with a forward proxy configuration such as Progress Indication, Caching, Malware Scanning, etc. These settings are all optional and customizable to your preferences.

     

    common_rules_filters.png

     

    Prevent Open Proxy

     

    It is very important to restrict access to your reverse proxy to prevent any internet user from using it as an open forward proxy. We can do this with a simple rule that checks to see if the request is for a resource that needs to be reverse proxied and if not then block that request. In this example I used the property URL.Host.BelongsToDomain.

     

    preventopenproxy.png

     

    Redirect to Internal Server

     

    All of the rules up until this point are directly tied to the frontend configuration (client-->Web Gateway) of the reverse proxy. This section focuses on the backend configuration (Web Gateway-->internal server) of the reverse proxy.

     

    ends.png

     

    You have many options in regards to how the traffic flow is handled. The entire communication can be HTTP or it can be HTTPS. It can also be HTTPS on the frontend while HTTP only on the backend, or vice-versa. You can configure this any way that you choose.

     

    We're going to use the Web Gateway to take a requested URL and re-write it to reflect the internal server. We'll also re-write the host header at the same time in case the internal server is used to host more than one domain or site.  We can't re-direct the client to an internal resource that is not publicly accessible so we need to have a way for the proxy to retrieve it on behalf of the client.  Therefore, we're using the "Next Hop Proxy" event to fulfill the request with the box for 'Proxy style requests' unchecked. This allows the reverse proxy to retrieve resources from a destination that was not the original destination sent over by the client and send it back to the client as if it was.  Using the next hop proxy method also adds the benefit of load balancing and failover for the web servers if you add more than one next hop proxy definition.

     

     

    HTTPS Example

     

    This is an example where the proxy needs to connect to the internal server securely using SSL/HTTPS. Here, we are adding two events on to the rule - the first re-writes the URL Host to the internal host and the 2nd enables the next hop proxy event to fulfill the request. Note: be sure to uncheck the box for 'Proxy style requests'.

     

    https_example.png

    HTTP Example

     

    This is an example of what the next hop proxy looks like when the server does not support SSL connections and the Web Gateway needs to talk to it using HTTP. Here we are switching the protocol to HTTP, re-writing the host to the internal address and fetching the content using the 'Next Hop Proxy' Event. Note: be sure to uncheck the box for 'Proxy style requests'.

     

    http_example.png

     

     

    Troubleshooting

     

    I have found that most troubleshooting can be done using Rule Engine Tracing. Please see this document for more information: https://community.mcafee.com/docs/DOC-5201.   Some examples of things you may have to troubleshoot are why you are receiving content from the wrong server, the SSL Handshake failing, or getting blocked by the Prevent Open Proxy rule.

     

    • "Page Cannot Be Displayed" (IE) or " (Error code: ssl_error_rx_record_too_long)" (FF) - Client Context is most likely not set correctly or Content Inspection is not being performed.
    • Web Gateway Block Page  - check to ensure that you have excluded any sites to be reverse proxied from the Prevent Open Proxy rule

     

     

    Conclusion

     

    We have now laid the foundation for a simple & secure reverse proxy rule set that should provide a framework to get you started with your own reverse proxy to suit your needs.

     

    Here I have attached the rule set that you may use to import and get started: