Protect an existing production site with an AppSec Gateway
When a production site already exists, the deployment of an 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 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 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 AppSec Gateway to reach the production server.
The production web server cannot be accessed from the 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.
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 AppSec'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 AppSec'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 AppSec 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 the AppSec Gateway. To clarify - the test client machine should be able to reach the 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 the 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.
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 the AppSec Gateway instead of the production web server. This may involve one of the following:
- 1.Changing the DNS configuration for your URL to use a different IP address.
- 2.Changing Static NAT configuration so that the exposed static IP address of your public URL will be translated into the 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 the AppSec Gateway and the production web server) - consider removing it.
The benefit of removing it is avoiding accidental exposure without CloudGuard AppSec'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 the AppSec Gateway.