Protect an existing production site with CloudGuard WAF's Gateway
Last updated
Last updated
When a production site already exists, the deployment of a CloudGuard WAF AppSec Gateway in front of it can be done in a gradual manner, so that the actual change of all traffic to go through the CloudGuard WAF AppSec Gateway, thus protecting the production web server, is done after testing.
The starting position is a production web server, that has an interface that can be reached through the internet using a URL (or multiple URLs). In our example it will be my-website.com.
The URL/s are translated via DNS to either the IP address of the web server, or to an IP address which is translated and/or routed to the web server.
The CloudGuard WAF AppSec gateway deployed will need to be connected to the same exposed network on one hand, and have access to the production server.
Decide beforehand what should be the Layer 4 networking configuration that allows the CloudGuard WAF AppSec Gateway to reach the production server.
The production web server cannot be accessed from the CloudGuard WAF AppSec Gateway through its existing URL/s. Either create a secondary internal URL for the web server and add DNS configuration for it, or use its IP address if it is a static address.
By the end of this stage - the traffic to the site's URL/s won't be protected yet.
Use the instructions to deploy and configure CloudGuard WAF's AppSec Gateway where your production web server is deployed, be it AWS, Azure or VMWare.
When configuring your assets, make sure to configure the URL (or all URLs) used by the production site as the Web Application/API URL/s.
Make sure to configure the web server's internal URL or IP address as the URL under the "Reverse Proxy" section for each of your web assets, if you have more than one.
For the purposes of a quick test you can use an IP address and later add an internal URL for the protected web server. If you do that, do not forget to change the asset/s configuration so the CloudGuard WAF's reverse proxy functionality will use this URL.
Despite this deployment, users browsing to the site's URL (in our example my-website.com) will continue to reach the production web server directly without CloudGuard WAF's protection, because we made no change preventing the production server from being accessible through the same URL.
It is recommended that before moving forward you will verify that in the CloudGuard WAF UI there are no evidence of error notifications in regards to the deployment. In each HTTPS-based asset you should also see green "V" check marks for each HTTPS-based URL noting the certificate installation for it was successful.
Use a machine that has network connectivity to the exposed interface of CloudGuard WAF's AppSec Gateway. To clarify - the test client machine should be able to reach CloudGuard WAF's AppSec Gateway via its IP address.
Modify the local hosts file on the client so that the URL used for the production site (in our example my-website.com) will be translated for this client only, to the exposed IP address of CloudGuard WAF's AppSec Gateway, which is determined according to your deployment.
Browse to your production site from the test client as if you are browsing to it from the internet and verify the web site operates normally.
In the CloudGuard WAF Administration Web Portal you can look at events issued according to your logging configuration.
Once testing is done and you are ready, make the necessary change so that browsing to the website's public URL/s (in our example my-website.com) will reach CloudGuard WAF's AppSec Gateway instead of the production web server. This may involve one of the following:
Changing the DNS configuration for your URL to use a different IP address.
Changing Static NAT configuration so that the exposed static IP address of your public URL will be translated into CloudGuard WAF's AppSec Gateway's IP address.
If the interface through which the production server formerly accepted requests is no longer in use (for example, if a secondary interface was created for the traffic between CloudGuard WAF's AppSec Gateway and the production web server) - consider removing it.
The benefit of removing it is avoiding accidental exposure without CloudGuard WAF's protection. The benefit of keeping it is for troubleshooting purposes if you want to temporarily allow traffic to the web server without going through CloudGuard WAF's AppSec Gateway.
