Imperva Cyber Community

 View Only

How to configure Imperva WAF Reverse Proxy mode

By Ira Miga posted 12-07-2020 09:22

  



In this blog, you will find 10 quick steps allowing you to configure basic Reverse Proxy mode using Imperva WAF for HTTP and HTTPS traffic and also a video with a walkthrough of the configuration process.


What is a proxy? What is the difference between Reverse and Forward proxy?

Proxy is a server that acts as a gateway between the web server and the internet. It is separating the end-users from the website they are trying to reach. 

A forward proxy is usually positioned at the network edge and regulates outbound traffic. It can, for example, block employees from visiting certain websites or improve user experience by caching external site content.

A reverse proxy is a server that is also positioned at the network edge, but this time its goal is to receive HTTP connections from the outside of the organization. It allows the proxy server to route the traffic and enforce policies.

In Reverse Proxy mode Imperva WAF is used as a proxy to rewrite traffic. It analyzes outside packets and creates a new packet that will be then forwarded to the webserver. This way reverse proxy allows connecting securely to the end-user, but ion clear text to the website, improving the performance.

Reverse Proxy mode is capable of deciphering Diffie-Hellman, enables URL rewrite, cookie signing, Client Certificate Authentication, where Imperva WAF validates the certificates, SSL termination, and more.

There are 2 types of Reverse Proxy modes: Kernel Reverse Proxy (KRP) and Transparent Reverse Proxy (TRP). 

Kernel Reverse Proxy is implemented in the kernel, but since version 14.1 this reverse proxy mode was enhanced to New Generation Reverse Proxy (NGRP), which is implemented in user-space. The traffic in NGRP is decrypted using OpenSSL that allows working with much wider cipher support.

Transparent Reverse Proxy is a mode, which is technically a bridge. Traffic is forwarded to the IP of the protected server, WAF terminates the connection and creates a new one to the server. This mode also supports SSL termination. In version 14.3 was introduced an enhanced mode of TRP - Advanced Bridge mode (ABR), which is using NGRP to process the traffic in the user-space instead of the kernel. 

Now let’s see how easy it is to configure NGRP mode to protect your webserver.

First, we will need a few prerequisites:

  1. A web server that supports both HTTP and HTTPS traffic and has an SSL certificate.
  2. We will need the ability to manage the server’s DNS record since the IP address of the server needs to be updated to the Imperva WAF IP address.
  3. And of course, we need Imperva MX and GW. GW needs to be configured to Reverse Proxy mode.

There are 2 options to do that:

  1. Using the CLI:

Impcfg → Manage SecureSphere Gateway→ Change Operation Mode →  Reverse Proxy

     2. Using MX GUI:

Setup → Gateways → Create New Gateway Group → Choose “Reverse Proxy” Gateway Mode.


Now when the prerequisites are covered, there are a few settings needed to be configured to set up the Reverse Proxy mode for Imperva WAF and protect your webserver.

The first step will be connecting to the MX GUI and making sure the GW is registered and running in the correct mode:


Note: My GW has Gen2 added automatically to its title, which means I’m using a version, where KRP was upgraded to NGRP. In this case, it’s version 14.3 and both my MX and GW are running on the GCP platform. This is one of the hints to recognize that you are using NGRP instead of KRP.

Also, if possible, I recommend moving the Server Group to Active mode, which allows seeing the blocking page right away and this way making sure the NGRP mode works as expected:

The next step will be creating an Alias and IP address for my Reverse Proxy. An alias represents the inbound IP address and the outbound IP address of the Reverse Proxy.

An alias consists of an alias name (appears in GUI) and a pair of these three items:

  • Device (for example, eth2) - not the management interface
  • IP address
  • Netmask

I will be using one-leg deployment and will just use my GW’s external IP address for that, so configuring Alias and IP address won't be needed.

The next step will be creating a Reverse Proxy rule:

Setup → Sites → Service Level → Reverse Proxy tab:

  1. Enter the RP parameters: Gateway IP Alias: any connection matching the alias and ports is directed to the RP; Gateway ports: multiple port numbers separated by commas can be entered here; Server Certificate: for SSL connections, select the certificate that your web server is using.
  2. Add a reverse proxy decision rule: Priority: in multiple of tens (10, 20, 30); Host: the hostname of the web server, where the traffic is directed to (www.example.com) or select Any; URL Prefix: the URL prefix, for which the traffic is to be directed to the Server IP, or select Any; Server IP: the RP sends the connection to this IP address; Server Port: the port, to which the connection is directed, the listening port of the web server; Encrypt: an option that allows encrypting traffic between the GW and the webserver.


Now I can test my configuration by accessing my webserver using GW’s external IP address. I should be able to create an alert and get a blocking page as well.

An additional step will be to update my DNS records with the new A record of the Reverse Proxy.

After the DNS changes are propagated, I can test access to the domain as well.

Now I would like to configure an HTTPS connection for the Reverse Proxy. The steps will be the same, with the addition of uploading an SSL certificate, then creating a Reverse Proxy rule, and testing again.

Watch this short video to see this basic configuration on my MX:



Let me know what additional content about the Reverse Proxy mode you would like to know and it will appear in my next blog!


#On-PremisesWAF(formerlySecuresphere)
9 comments
1098 views

Permalink

Comments

12-10-2020 08:27

Hi @Ira Miga

Thank you. I'll check this.​

12-10-2020 06:11

@Ira Miga


Thank you so much. :-)​

12-10-2020 06:10

@Oliver Naabay,

Oh, I understand now.
Yes, in NGRP we are using OpenSSL to decrypt traffic so everything supported in OpenSSL is supported. I'll find documentation and paste the link here.​ 
Thanks for clarifying!

12-10-2020 05:46

@Ira Miga

Yes. Currently they are using 13.3. Now they want to know if there is any document or link that state that v14.3 supports SHA384 algo. They are planning to upgrade their WAF.​

12-10-2020 05:44

@Oliver Naabay, do you mean version 14.3? In version 13 it wasn't supported yet.

12-10-2020 05:35

Hi Ira,

Do you have any link for any documentation? The management is requesting for any proof since they are having issues with servers running with SHA384 algorithm right now with WAF v13.3.

Thank you.

12-10-2020 05:21

Oliver Naabay

Yes, starting version 14.1 CA certificates signed with SHA384 are supported in NGRP mode, and in ABR mode starting version 14.3. 

12-10-2020 03:31

Hi Ira,

Would you know or if you have any support documents that this new version 14.3 supports SHA384 CA algorithm? The support gave us some links and release notes, but there's no statement regarding the support certificate.

Thank you.