# Documentation Overview Check Point CloudGuard WAF documentation includes several sections. You can easily navigate between them using the menu on the left (on a mobile device, click ): * [**Getting Started** ](/getting-started/prepare-key-information)- Allows you to jump right into the setup. We recommend following the pages in the Getting Started section one after the other to quickly set up a working system. * [**Concepts**](/concepts/waf-as-a-service-waf-saas) - In-depth overview of key topics and concepts. Read the ones you find interesting, or read them all to get fully acquainted with how the product works. * [**Additional Security Engines**](/additional-security-engines/anti-bot-challenge-rules) - Technical overview of the additional security practices provided with CloudGuard WAF and steps to activate them. * [**Setup Instructions**](/setup-instructions/setup-custom-rules-and-exceptions-old) - Step-by-step guides for setting up additional configurations and options. * [**How To's**](/how-to/edit-web-application-api-settings) - Step-by-step guides for day-to-day operations and advanced features. * [**Troubleshooting**](/troubleshooting/waf-gateway-virtual-machine) - Guides for solving common issues with WAF for each deployment type. * [**References**](/references/agent-cli) - Detailed description of the Agent CLI, Management API, and Event Query language. * [**Resources**](/resources/github) - External materials related to the product. # What is CloudGuard WAF? CloudGuard WAF is a fully automated Web Application & API Security solution. It is powered by a patented machine learning engine which continuously analyzes users' HTTP/S requests as they visit the website or API. The analysis includes the application structure and how users interact with the content in order to identify patterns and automatically stop and block malicious requests and bad actors. ## Main features of CloudGuard WAF * **Machine Learning-based Application Firewall** - stop application layer attacks, including OWASP Top 10, with very minimal tuning and no false positives. Pre-emptive (no software updates) protection for zero-days such as Log4Shell and Spring4Shell. * **HTTPS Traffic inspection** - SSL certificates and private keys can be stored locally or in public cloud secrets storage (AWS/Azure) * **Integration into modern environments** and workloads (public cloud & Kubernetes) and CI/CD workflows supporting [**AWS**](/getting-started/deploy-enforcement-point/gateway-virtual-machine/aws)**,** [**Azure**](/troubleshooting/waf-gateway-virtual-machine/azure)**,** [**VMWare**](/getting-started/deploy-enforcement-point/gateway-virtual-machine/vmware)**,** [**Kubernetes Ingress**](/getting-started/deploy-enforcement-point/kubernetes)**,** [**Docker**](/getting-started/deploy-enforcement-point/docker)**,** [**Linux Servers**](/getting-started/deploy-enforcement-point/linux)**, or** [**as a Service**](/getting-started/deploy-enforcement-point/waf-as-a-service-waf-saas)**.** * **Ease of ongoing management and maintenance** – Enterprise Grade SaaS Web UI, GraphQL API, and Infrastructure-as-code using Terraform ## Additional Security Engines * [**Anti-Bot** ](/additional-security-engines/anti-bot)- Identify and stop automated attacks before they negatively impact the bottom line or customer experience * [**API Protection**](/additional-security-engines/api-protection) - Automatically detect API usage and sensitive content to provide security via visibility. Stop malicious API access and abuse. Enforce the API schema provided by the user or automatically detected by CloudGuard WAF. * [**File Security**](/additional-security-engines/file-security) - prevents malicious files from being uploaded by utilizing Check Point's Threat Cloud. * [**Intrusion Prevention System (IPS)**](/additional-security-engines/intrusion-prevention-system-ips) - protections for over 2,800 WEB CVEs, based on Check Point award-winning NSS-Certified IPS + Support for custom Snort 3.0 signatures. * [**Rate Limit**](/additional-security-engines/rate-limit) - Limit the number of requests to a matched URI within a configured time scope, according to the source identifier. * [**Snort Rules**](/additional-security-engines/snort-rules) - Enforce a set of Snort signatures in the same way regular IPS signatures are enforced. # Prepare key information It is recommended to prepare the information below before you start deployment, as it will help you in the configuration process. ## Target Environment and Deployment Type Identify where you are going to install CloudGuard WAF and enforce security. The environment and deployment type will define which [Enforcement Point](/getting-started/deploy-enforcement-point) applies to your project. You can read more about the different enforcement points in the [Gateways & Agents](/concepts/gateways-and-agents) section. Options are to deploy as: * As a Gateway/Virtual Machine in [AWS](/getting-started/deploy-enforcement-point/gateway-virtual-machine/aws), [Azure, ](/getting-started/deploy-enforcement-point/gateway-virtual-machine/azure)or VMware. * As[ a Service](/getting-started/deploy-enforcement-point/waf-as-a-service-waf-saas) in specified regions worldwide. Routing through the service is done by configuring the relevant DNS records for the site's domain. * in Kubernetes environments - It integrates with the most popular [NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx), [Kong Ingress Controller](https://github.com/Kong/kubernetes-ingress-controller), and as well as Istio Ingress Controller. * Using Docker in one of two main configurations: [Single Docker](/getting-started/deploy-enforcement-point/docker/single-docker) - a single Docker image containing a managed reverse proxy server and the CloudGuard WAF Security agent, or as [Dual D](/getting-started/deploy-enforcement-point/docker/dual-docker-nginx-kong-envoy-+-security-agent)ocker - NGINX Reverse Proxy Docker or Kong API Gateway Docker + CloudGuard WAF Security Agent Docker. * As an [add-on for NGINX](/getting-started/deploy-enforcement-point/linux), thus protects any applications and APIs served by NGINX Reverse Proxy. ### Data regions and Points of Presence (PoPs) Data Residency refers to the physical or geographical location where your data is stored. In the specific case of [WAF SaaS](/getting-started/deploy-enforcement-point/waf-as-a-service-waf-saas), there are also separate supported regions for Points of Presence (PoPs). They refer to the physical locations where our Reverse Proxy and WAF agents are deployed, directly influencing your applications' security efficiency and response time. According to your environment's location (for latency concerns) and, if applicable, regulation concerns, select the data region (and PoP if applicable) from the supported options. ## Application or API Configuration Details Collect the following information about the web application(s) or API(s) you are going to protect. You will need this to configure the CloudGuard WAF Assets. * What is the internal URL or IP address and port of the web application(s), API(s), or internal load balancer in front of them? These are often URLs that will only be accessible from your reverse proxy/security Gateway and not directly exposed to the Internet. * What is the external URL and port that you would like to expose to the users? \ For example - or . * In the common case, you use HTTPS, then depending on the deployment type, you should have access to the SSL certificate and private key (some deployments, like SaaS, do not require that you provide your certificates) * What is the best way to distinguish between users of the application or API? This is useful for the CloudGuard WAF machine learning process: * Specific header in the HTTP request * Specific key in an HTTP cookie * Specific key in HTTP JWT * IP address in the X-Forwarded-For header * IP address of the request # Log in to the Infinity Portal The [**Check Point Infinity Portal**](https://sc1.checkpoint.com/documents/Infinity_Portal/WebAdminGuides/EN/Infinity-Portal-Admin-Guide/Topics-Infinity-Portal/Introduction-to-Infinity-Portal.htm) is a web-based platform that hosts Check Point's Security-as-a-Service (SaaS) offerings. To get started with CloudGuard WAF the first thing you need is an account in the Check Point Infinity Portal. ## Check Point Infinity Portal Complete the following steps to log in and create a User Account and a Company Account in the Infinity Portal. #### **Step 1: Log In to Check Point Infinity Portal** Go to Check Point's Infinity Portal address - .\ Select the data region you wish to log into. {% hint style="warning" %} The data region cannot change for an account once created, and you will need to sign out if you wish to login to a different data region. {% endhint %} ![](/files/75Qz8HPG6UFzHOV16ElU) If you already have an account, log in and skip to Step 2. If you don't have an account yet, click ***Don't have an account? Register here*** and enter your details in the registration form. {% hint style="info" %} Make sure to select your data residency region from the available options correctly if this restriction is critical to your operation. This setting cannot be changed later. {% endhint %} The following example screenshot comes from the EU/US portal and so it includes the question about the data residency. ![](/files/uw743Ug2zHuJP2cKQUij) If this is the first time you used an email address in Infinity Portal, you will receive an email for initial login. Follow the link in the email until you are securely logged in. #### Step 2: Select your Account If this is the first time you use Infinity Portal, skip to Step 3. Your user can be associated with multiple accounts. Near the left side of the top banner of Infinity Portal it is possible to see the current account (in the example of the screenshot below it possible to see "*my-tenant-name*"). Make sure the selected account is the account you want to use for CloudGuard WAF. ![](/files/qiBa1X5AXkg02SeJxllu) #### Step 3: Select an Application Click on the Application Selector icon on the top left corner and select **WAF** in the **CloudGuard** pillar. ![](/files/CjVFebYe8ApvzGQ0EWiT) #### Step 4: Accept the Terms of Service and Privacy Policy Accept the Infinity Portal Terms of Service and the Privacy Policy by selecting the corresponding checkbox. ![](/files/IMJBIs3ozkVFbOpeWuaJ) # Protect a Web Application / API Check Point WAF provides a configuration wizard that allows you to set up everything you need for basic protection of your web application. Once you completed the wizard you can set up a Check Point WAF's AppSec Gateway or Agent to enforce security. ## New Asset Wizard #### Launch the configuration wizard: * When logged in to the management portal, click the **Policy** option in the main navigation menu on the left. You should see the **Check Point Getting Started** page. * In the **Policy -> Getting Started** page, then click **New Asset**. The configuration wizard should open. Follow these configuration steps in the **New Web Application / API** wizard:
#### Step 1: Application Details Complete the following details (which you have [prepared before](/getting-started/prepare-key-information)): * **Name** - choose a clear distinguishable name for your application * **Tags** (Optional) - can be used for searches * **Application URLs for users** - configure at least one host address with optional port. Check Point WAF will protect these hosts. Examples: * `https://www.acme.com` (listen to inbound traffic to this address on all ports) * `http://www.acme.com:80` (only listen to inbound traffic to this address on port 80) * `https://www.acme.com/sales` * `https://sales.acme.com` * `https://172.20.20.4:3000` * **Application URL for the reverse proxy function** - This URL is required, if the asset is secured by a Check Point WAF deployment in which the reverse proxy function is configured through the WAF Management. The Reverse Proxy translates the external URL, used by users, into an internal URL and forwards the request to it. This internal URL should be written here (See diagram). {% hint style="success" %} Multiple "**Application URL for the reverse proxy function"** to enable Load Balancing can be configured once asset has been created {% endhint %} {% hint style="success" %} For VM, SaaS, or managed Docker deployments, you must provide the internal URL (application, API, or internal load balancer). This URL should be accessible to the Reverse Proxy but not exposed externally. {% endhint %} #### Step 2: Platform and Deployment configuration 1. Choose a deployment method:
Check Point WAF can be deployed as: * **A pre-packaged Gateway** (Virtual Machine for secure managed reverse proxy): * In AWS * In Azure * In VMware * **WAF SaaS** - in supported regions world-wide (DNS configuration for your domain will change to its location) * **Single Docker -** A pre-packaged docker containing a secure managed reverse proxy.\ **Note** - a user can opt to manage the reverse proxy settings locally. * **Dual Docker** - A separate Reverse Proxy/API server Docker + WAF Agent Docker * **Linux** - An add-on to an existing/new NGINX Kubernetes Ingress * **Kubernetes** - An add-on to an existing/new supported Reverse Proxy/API Server. #### Step 3: Practices Select the Practices that you want to enable and their Mode:
Modes: * **Learn/Detect** - we recommend starting with this mode as it allows the Machine Learning engine to train and you can examine the system behavior, all while traffic is not affected. * **Prevent** - in this mode traffic will be blocked if malicious traffic is found. * **Disabled** in this mode the practice is not active. #### Step 4: GenAI Protection Use the GenAI Protection Settings to define how your application or API is secured, if you've enabled the GenAI Protection Practice in the previous step.
* **Request URI**: Enter the API endpoint for LLM prompts (e.g., /api/chat). * **Prompt Location:** Specify where the prompt appears in the request body (e.g., body.prompt). * **LLM Model**: Select the LLM your app uses. * **Expected Prompts**: Choose One: * Wide range – many different prompt types. * Specific – narrow, domain-focused prompts. * **Expected Users**: * All users (internal & external) * Internal roles (e.g., admin, sales) * External roles (e.g., customers, partners) * One specific role * **Application Description:** Add a short note on your app’s purpose to improve protection accuracy. #### Step 5: Learning Define how the Machine Learning engine should distinguish between different API or Human users and who the users are that can be trusted. 1. Select the method by which different users will be distinguished from one another: * **X-Forwarded-For Header** - When there is a Reverse Proxy or ALB between the Reverse Proxy the agent is running on, and the internet - the original source IP address cannot be seen on the networking level.\ This option allows the Nano-Agent to identify the original source IP inside the X-Forwarded-For header. No additional parameters are required in the common case where a single Reverse Proxy/ALB is found before the agent's deployment. {% hint style="info" %} In the less common case, where there is more than 1 reverse proxy and/or ALB deployments before the reverse proxy with Check Point WAF: * After the wizard is completed you must edit the created Web Application/API asset object. * Add the IP addresses of the previous hops, to allow the distinction between them and the original source address. This is explained in more details [here](/how-to/configure-contextual-machine-learning-for-best-accuracy). {% endhint %} * **Source IP** **Address** - The Nano-Agent uses the source IP address as the identifier. No additional parameters are required. {% hint style="info" %} Additional methods can be defined later by editing the Web Application/API asset object. These include: * **Cookie Key** - when you select this option, you need to add the key name within the cookie whose value is used as the unique identifier of the original source. * **HTTP Header** - when you select this option, you need to add the HTTP header name whose value is used as the unique identifier of the original source. * **JWT Key** - Authenticated API calls send a JSON Web Token (JWT) received by authentication API. This JWT usually contains identifying field. When you select this option, the value of one of the JWT keys can be used as the unique identifier of the original source. {% endhint %} 2\. If you do not intend to use additional methods, you may already define trusted sources that serve as a baseline for comparison for *benign behavior*, and how many Users/Addresses must exhibit similar activity for it to really be considered benign by the learning model\ (Otherwise it is recommended to perform this step after the wizard has been completed by editing the asset and after changing the method by which users are distinguished). ![](/files/OnkKGyxCgTIqgn2urt6R) #### Step 6: Certificate storage configuration and deployment instructions If, during the previous step, a "New Profile" option was selected, then the "Certificates" page will also prompt a decision, relevant for all Check Point WAF's AppSec Gateways or WAF SaaS assets that will connect to this profile, regarding where the certificates for HTTPS traffic will be stored. {% tabs %} {% tab title="WAF SaaS" %} For WAF SaaS deployment, you choose between a Check Point-managed certificate — **Wildcard** (covers all subdomains, the default) or **Specific** (a single domain) — or your own certificate (**BYOC**). {% hint style="warning" %} Completing the deployment requires actions after the wizard has ended, for each domain configured on the new asset: 1. If using a Check Point-managed certificate: proving ownership of the domain see Certificates Managed by Check Point. 2. If using your own certificate: uploading it see Bring Your Own Certificate (BYOC). 3. Configuring the DNS record for each domain so traffic to it will be routed to WAF SaaS. {% endhint %}
{% endtab %} {% tab title="Appsec Gateways" %} This decision is only relevant for the pre-packaged Gateway (Virtual Machine) option in AWS and Azure. In those cases it is possible to either select a secure vault in the relevant public cloud, or local storage. This configuration can be later changed by editing the created profile via **Cloud->Profiles.** If the "Existing Profile" option was selected, then it will not be possible to choose a different configuration from what is already set in this profile. Exact setup instructions for certificates will be available in the profile page. For Check Point WAF on AWS or Azure, there are two methods for storing certificates and private keys. For all other deployments only the first is available: * [On the WAF Gateway itself](https://waf-doc.inext.checkpoint.com/getting-started/deploy-enforcement-point/gateway-virtual-machine/vmware/store-certificates-on-gateway) - a simple procedure allows you to upload the certificates and private keys directly to your gateway(s) using Secure Copy Protocol (SCP/SSH). No further configuration is required - Check Point WAF will locate the local files automatically. * **Advantage**: you have full control of your secrets * **Disadvantage**: does not support automatic scaling * If you are using Check Point WAF on [AWS ](https://waf-doc.inext.checkpoint.com/getting-started/deploy-enforcement-point/gateway-virtual-machine/aws/store-certificates-in-aws)or [Azure ](https://waf-doc.inext.checkpoint.com/getting-started/deploy-enforcement-point/gateway-virtual-machine/azure/store-certificates-in-azure)you can store secrets in secured vaults of these platforms and Check Point WAF's AppSec Gateway can fetch it from there. {% endtab %} {% endtabs %} #### Step 7: Reporting During the Web Application onboarding it is possible to configure a new Report Trigger to send a summary report, based on your preferences to a list of email addresses or use an existing, pre-configured Report Trigger.
#### Step 7: Summary Review the configuration summary and choose how you would like to proceed.
By keeping the default selections and clicking **Done**, you can Publish & Enforce your settings and proceed to the **Profile** page, which includes instructions for deployment of an Check Point WAF's AppSec Gateway, WAF SaaS or Agent. You can also choose Advanced Settings to explore additional features and later proceed with enforcement point deployment. ### Deploy Enforcement Point - Gateway or Agent You are minutes away from protecting your Web Application. The last step is to deploy an Enforcement Point. See instructions here: {% content-ref url="/spaces/EWA4nfgNrSRL8dA6Kap7/pages/SK2esLt6SM0XOzN5wy9L" %} [Deploy Enforcement Point](/getting-started/deploy-enforcement-point) {% endcontent-ref %} # Protect a Web API CloudGuard WAF provides a configuration wizard that allows you to set up everything you need for basic protection of your web API, as well as the ability to automatically detect your API usage and schema, providing an extra layer of security via visibility. Once you completed the wizard you can set up a CloudGuard WAF's AppSec Gateway or Agent to enforce security. ## Web API Wizard #### Step 1: launch the configuration Wizard: 1. When logged in to the management portal, click the **Policy** option in the main navigation menu on the left. You should see the **Cloud Getting Started** page. 2. In the **Policy -> Getting Started** page, click **New Asset**, then Select **Web API.** The configuration wizard should open. ![](/files/cy16K8h0647qOyLT9SEy) Follow these configuration steps in the **New Web API** wizard: #### Step 2: API Server Details ![](/files/R0HGFLqjLkDfGeZWvOeR) Complete the following details (which you have [prepared before](/getting-started/prepare-key-information)): * Name - choose a clear distinguishable name for your API * Tags (Optional) - can be used for searches * API URLs for users - configure at least one host address with optional port. CloudGuard WAF will protect these hosts. Examples: * `https://www.acme.com` (listen to inbound traffic to this address on all ports) * `http://www.acme.com:80` (only listen to inbound traffic to this address on port 80) * `https://www.acme.com/api` * `https://sales.acme.com/api` * `https://172.20.20.4:3000` * Single application URL for the reverse proxy function - This URL is required, if the asset is secured by a CloudGuard WAF deployment in which the reverse proxy function is configured through the WAF Management. The Reverse Proxy translates the external URL, used by users, into an internal URL and forwards the request to it. This internal URL should be written here (See diagram). #### Step 3: Practices Select the Practices that you want to enable and their Mode: ![](/files/J3DvunOiJNCTLCgVRdeA) Activated modes for API Security: * **Learn/Detect** - we recommend starting with this mode as it allows the Machine Learning engine to train and you can examine the system behavior, all while traffic is not affected. * **Prevent** - in this mode traffic will be blocked if malicious traffic is found. Activated modes for API Discovery: * **Active** - API discovery does not block traffic, hence it only has a single "Active" mode. #### Step 4: Platform and Deployment configuration 1. Choose a deployment method:
CloudGuard WAF can be deployed as: * A pre-packaged Gateway (Virtual Machine for secure managed reverse proxy): * In AWS * In Azure * In VMware vSphere * WAF as a Service - in supported regions world-wide (DNS configuration for your domain will change to its location) * A pre-packaged docker containing a secure managed reverse proxy.\ **Note** - a user can opt to manage the reverse proxy settings locally. * A separate Reverse Proxy/API server Docker + WAF Agent Docker * An add-on to an existing/new NGINX Kubernetes Ingress * An add-on to an existing/new supported Reverse Proxy/API Server. {% hint style="warning" %} If you choose the option of a **Virtual Machine (VM)**, the option of **SaaS** or the option of a **managed docker**, you must also enter the internal URL of the application or API or internal load balancer so the reverse proxy function will know to which URL should these asset's external URL be forwarded. This URL must be accessible to the managed Reverse Proxy server but will not be exposed to the outside. This URL was configured in step 1 of the wizard. {% endhint %} #### Step 5: Learning Define how the Machine Learning engine should distinguish between different API sources and who the sources are that can be trusted. ![](/files/YewKs5CT2rskIUBgjZUF) 1. Select the method by which different sources will be distinguished from one another: * **X-Forwarded-For** **Header** - When there is a Reverse Proxy or ALB between the Reverse Proxy the agent is running on, and the internet - the original source IP address cannot be seen on the networking level.\ This option allows the Nano-Agent to identify the original source IP inside the X-Forwarded-For header. No additional parameters are required in the common case where a single Reverse Proxy/ALB is found before the agent's deployment. {% hint style="info" %} In the less common case, where there are more than 1 reverse proxy and/or ALB deployments before the reverse proxy with CloudGuard WAF: * After the wizard is completed you must edit the created Web Application/API asset object. * Add the IP addresses of the previous hops, to allow the distinction between them and the original source address. This is explained in more details [here](/how-to/configure-contextual-machine-learning-for-best-accuracy). {% endhint %} * **Source IP** Address- The Nano-Agent uses the source IP address as the identifier. No additional parameters are required. {% hint style="info" %} Additional methods can be defined later by editing the Web Application/API asset object. These include: * **Cookie Key** - when you select this option, you need to add the key name within the cookie whose value is used as the unique identifier of the original source. * **HTTP Header** - when you select this option, you need to add the HTTP header name whose value is used as the unique identifier of the original source. * **JWT Key** - Authenticated API calls send a JSON Web Token (JWT) received by authentication API. This JWT usually contains identifying field. When you select this option, the value of one of the JWT keys can be used as the unique identifier of the original source. {% endhint %} 2\. If you do not intend to use additional methods, you may already define trusted sources that serve as a baseline for comparison for *benign behavior*, and how many sources/Addresses must exhibit similar activity for it to really be considered benign by the learning model\ (Otherwise it is recommended to perform this step after the wizard has been completed by editing the asset and after changing the method by which sources are distinguished). ![](/files/I29a1AA3LpqxPe9Xhng9) #### Step 6: Certificate storage configuration and deployment instructions If, during the previous step, a "New Profile" option was selected, then the "Certificates" page will also prompt a decision, relevant for all CloudGuard WAF's AppSec Gateways that will connect to this profile, regarding where the certificates for HTTPS traffic will be stored. {% hint style="info" %} For the [WAF SaaS](/getting-started/deploy-enforcement-point/waf-as-a-service-waf-saas) option - Using your own issued certificates will be available in the future. {% endhint %} This decision is only relevant for the pre-packaged Gateway (Virtual Machine) option in AWS and Azure. In those cases it is possible to either select a secure vault in the relevant public cloud, or local storage. \ This configuration can be later changed by editing the created profile via **Cloud->Profiles.** If the "Existing Profile" option was selected, then it will not be possible to choose a different configuration from what is already set in this profile. {% hint style="info" %} Exact setup instructions for certificates will be available in the profile page. {% endhint %} For CloudGuard WAF on AWS or Azure, there are two methods for storing certificates and private keys. For all other deployments only the first is available: * [On the WAF Gateway itself](/getting-started/deploy-enforcement-point/gateway-virtual-machine/vmware/store-certificates-on-gateway) - a simple procedure allows you to upload the certificates and private keys directly to your gateway(s) using Secure Copy Protocol (SCP/SSH). No further configuration is required - CloudGuard WAF will locate the local files automatically. * **Advantage**: you have full control of your secrets * **Disadvantage**: does not support automatic scaling * If you are using CloudGuard WAF on [AWS ](/getting-started/deploy-enforcement-point/gateway-virtual-machine/aws/store-certificates-in-aws)or [Azure ](/getting-started/deploy-enforcement-point/gateway-virtual-machine/azure/store-certificates-in-azure)you can store secrets in secured vaults of these platforms and CloudGuard WAF's AppSec Gateway can fetch it from there. ![](/files/WpDVqwWo3SFzpwcjHqta) ![](/files/2Kvz6HVIxoelxGgkmb7z) For [WAF SaaS](/getting-started/deploy-enforcement-point/waf-as-a-service-waf-saas) deployment this page will support in the future the option of certificates provided by you. The available option is for WAF SaaS to provide the certificates. {% hint style="warning" %} Completing the deployment and providing certificates requires actions after the wizard has ended, for each domain configured on the new asset: 1. Proving ownership of each domain to allow issuing the certificates for it on WAF SaaS side. 2. Configuring the DNS record for each domain so traffic to it will be routed to WAF SaaS. {% endhint %}
For all other deployment options there is no configuration required WAF web management. However, instructions on how to install the certificates for each deployment appear in both wizard and later on when editing the profile in **Policy->Profiles**. ![](/files/OFkKYHAhzftyGGJDv02R) ![](/files/zlnZJNL6jXP3TTQ0lfBZ) ![](/files/vMUzY56aTjSy0g05wTo4) #### Step 7: Reporting During the Web Application onboarding it is possible to configure a new Report Trigger to send a summary report, based on your preferences to a list of email addresses or use an existing, pre-configured Report Trigger.
#### Step 8: Summary Review the configuration summary and choose how you would like to proceed. ![](/files/ej3rLqSSNa10eabUtozD) By keeping the default selections and clicking **Done**, you can Publish & Enforce your settings and proceed to the **Profile** page, which includes instructions for deployment of a CloudGuard WAF's AppSec Gateway, WAF SaaS or Agent. You can also choose Advanced Settings to explore additional features (such as in Step 6 below) and later proceed with enforcement point deployment. ### Deploy Enforcement Point - Gateway or Agent You are minutes away from protecting your Web API. The last step is to deploy an Enforcement Point. See instructions here: {% content-ref url="/pages/SK2esLt6SM0XOzN5wy9L" %} [Deploy Enforcement Point](/getting-started/deploy-enforcement-point) {% endcontent-ref %} ### API Discovery and API Schema Validation #### API Security CloudGuard WAF protects your API from malicious attacks, and if provided with a schema file, it can enforce it. However, this is not the only manner of security for API use. Maintaining and enforcing a secure schema file is a difficult task for a security officer. The developers of the web server add and change APIs, and even with a well-defined, well-reviewed and well-maintained schema file, an API can allow access of sensitive data in a way the schema file will not show. The frequency of changes to APIs can also cause much difficulty in keeping such a schema file well-reviewed and well-maintained. API discovery provides **security by visibility:** 1. Discovery of the initial schema. 2. Discovery of API additions/deletions, and changes to existing APIs. 3. Discovery of APIs with sensitive data. API discovery is the recommended way to maintain the schema file you can eventually, after a sufficient leaning period, use for Schema Validation. The flow of working with API discovery is explained in detail in this documentation: {% content-ref url="/pages/D9Vqj45KdjiWUa8pz2m2" %} [API Protection](/additional-security-engines/api-protection) {% endcontent-ref %} #### Activating schema validation if you already have a trusted schema file {% hint style="warning" %} Important reminder - The API discovery engine was designed to learn what API is actually being used. **Even if you have a well-maintained schema file for your API, it is still recommended to wait before activating the Schema Validation Security engine, until the API discovery practice has learned the actual API usage in your system and suggested a schema**. At that point we recommend comparing the suggested schema with the schema file you had, and deciding on the exact schema to enforce accordingly. {% endhint %} Once there is a well-maintained schema file, such as the schema the API discovery engine provides once it learned traffic to a high enough level, adding a schema file and activating the Schema Validation enforcement engine can further increase the security level by adding an [openAPI ](https://swagger.io/docs/specification/about/)schema file for your API.\ CloudGuard WAF will enforce the different unique applicative validations described in the schema file and alert upon attempts to use APIs in a way that does not match your schema. If you decide to skip API discovery (not recommended) and move directly to schema validation with your own well-maintained schema file, skip directly to the following documentation and use the option of uploading your own schema file: {% content-ref url="/pages/7dNevGhg9MFNjuwdoFQb" %} [Enforce API Schema](/additional-security-engines/api-protection/enforce-api-schema) {% endcontent-ref %} # Deploy Enforcement Point ## Overview CloudGuard WAF Enforcement Points are instances deployed in an environment that inspects traffic and enforce security policies. The Enforcement Points can have different form factors (Virtual Machine, Kubernetes Ingress, Docker container or Linux Agent) depending on the environment in which they are deployed. An enforcement point will be referred to as CloudGuard WAF's Gateway or Agent in this documentation. You can read more about the different enforcement points in the [Gateways & Agents](/concepts/gateways-and-agents) section. {% hint style="warning" %} While most deployment options below support a scalable solution behind a load balancer, there is no full sync High Availability (HA) option. The state between multiple instances within a single deployment is not synced. {% endhint %} | Platform | Reverse Proxy / API Server | WAF Agent | | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | | [AWS, Azure, VMWare](/getting-started/deploy-enforcement-point/gateway-virtual-machine) | Provided by Check Point and managed via WebUI/API/Terraform | Provided by Check Point and managed via WebUI/API/Terraform | | [WAF ](/getting-started/deploy-enforcement-point/waf-as-a-service-waf-saas)[as a Service](/getting-started/deploy-enforcement-point/waf-as-a-service-waf-saas) | Provided by Check Point as a Service and managed via WebUI | Provided by Check Point as a Service and managed via WebUI | | [Kubernetes Ingress](/getting-started/deploy-enforcement-point/kubernetes) | Provided and managed by Admin | Provided by Check Point and managed via WebUI/API/Terraform | | [Docker](/getting-started/deploy-enforcement-point/docker) |

Option 1: Provided by Check Point and managed via WebUI/API/Terraform.

Option 2: Managed by Admin while initial deployment can be provided by Check Point.
Initial deployment can be in the same container as the WAF agent or a separate one.

| Provided by Check Point and managed via WebUI/API/Terraform | | [Linux/NGINX/Kong](/getting-started/deploy-enforcement-point/linux) | Provided and managed by Admin | Provided by Check Point and managed via WebUI/API/Terraform | ## Enforcement Profile To deploy a CloudGuard WAF's AppSec Gateway or Agent you need an **Enforcement Profile** that determines the deployment type and other parameters related to the deployment. If you completed the **Web Application** or **Web API** configuration wizard, an **Enforcement Profile** was created for you by the configuration wizard. To view your profile, select **Policy**, then **Profiles** in the menu on the left. * If you have just one profile, the system will automatically present it. * If you have more than one profile, you will be presented with a list of profiles and you can select the one you wish to use. {% hint style="info" %} Profile Type cannot be changed but you can always create a new one by clicking **Back** to get the the Profiles selection screen and choosing **New** at the top toolbar. {% endhint %} ## Authentication Token To establish a secure communication between the CloudGuard WAF's AppSec Gateways or Agents and the Check Point Cloud an authentication token is required. You will be asked to enter this token during deployment either in CLI or in a web form. The token can be obtained by clicking the Copy button near the Token field. ![](/files/tAyti9aG3utyFHls2McN) {% hint style="warning" %} If the profile object was just created, make sure to "Enforce" the new configuration prior to using the copied authentication token. {% endhint %} {% hint style="info" %} According to security best practices, it is recommended to periodically rotate the token for all future new installations.\ Clicking on the ![](/files/iDNvTN0uQJx7wvqTUg8X) icon will invalidate the current token and create a new one that can be copied. Existing agents that were already registered are not affected.\ **Note** - Once rotated, in order to allow deployments of additional agents, replace all deployment scripts/configuration files/key vault entries that contain the now-invalid token. {% endhint %} ## Download & Deployment On the right side of a **Profile** page you will find the Download & Deployment instructions per the profile type you selected. You can follow the on-screen instructions or the more detailed instructions available in the next pages of the documentation. # Gateway/Virtual Machine ## Platforms CloudGuard WAF can be deployed as a VM on different platforms, containing a fully managed Reverse Proxy gateway, protected by a CloudGuard WAF Agent. Select your platform type below to see the corresponding deployment instructions: {% content-ref url="/pages/sGcllSYfYWe6rOuvIt7A" %} [AWS](/getting-started/deploy-enforcement-point/gateway-virtual-machine/aws) {% endcontent-ref %} {% content-ref url="/spaces/EWA4nfgNrSRL8dA6Kap7/pages/BkKSCw0vXRDV5C4ns1B0" %} [Azure](/getting-started/deploy-enforcement-point/gateway-virtual-machine/azure) {% endcontent-ref %} {% content-ref url="/spaces/EWA4nfgNrSRL8dA6Kap7/pages/iRVWiu51G8YhoXdOJGfY" %} [VMware](/getting-started/deploy-enforcement-point/gateway-virtual-machine/vmware) {% endcontent-ref %} {% hint style="info" %} A fully managed Reverse Proxy protected by a CloudGuard WAF Agent is also available as [container in docker](/getting-started/deploy-enforcement-point/docker) environment. {% endhint %} ## Certificates and Private Keys CloudGuard WAF's Gateways implement a reverse proxy that can serve pages to users over HTTPS. To use this capability, you need to provide a Certificate and Private keys that correspond to the site name(s) that users will access (e.g. , ). ### Storage options There are two methods for storing certificates and private keys when deploying on AWS or Azure. When deploying on VMWare, only the first option is available: * [On the WAF Gateway itself](/getting-started/deploy-enforcement-point/gateway-virtual-machine/azure/store-certificates-on-gateway) - a simple procedure allows you to upload the certificates and private keys directly to your gateway(s) using Secure Copy Protocol (SCP/SSH). No further configuration is required - CloudGuard WAF will locate the local files automatically. * **Advantage**: you have full control of your secrets * **Disadvantage**: does not support automatic scaling * If you are using CloudGuard WAF on [AWS ](/getting-started/deploy-enforcement-point/gateway-virtual-machine/aws/store-certificates-in-aws)or [Azure ](/getting-started/deploy-enforcement-point/gateway-virtual-machine/azure/store-certificates-in-azure)you can store secrets in secured vaults of these platforms and CloudGuard WAF's Gateway can fetch it from there. {% hint style="info" %} The certificates are fetched when CloudGuard WAF's Gateway first loads and checked again for updates every time you Enforce policy. {% endhint %} When deploying on Azure/AWS, storage selection occurs during the asset configuration wizard if a new profile is created. It is also available via **Cloud->Profiles** for CloudGuard WAF's Gateway profiles that enforce assets with HTTPS URLs. ![](/files/Nes5LMf1USsgZ9j52bn3) ![](/files/9jigMZXP1sv0UO4goGQh) For all other deployment options, the same location still contains "**Setup Instructions**" for the method to deploy certificates for HTTPS traffic. ### Multiple certificates When there are multiple Web Applications APIs, CloudGuard WAF's Gateway can automatically fetch the relevant certificates and private keys. **Example**: you have two applications and one API end-point to protect: * [www.acme.com](http://www.acme.com) * [www.acme.com/sales](http://www.acme.com/sales) * products.acme.com/catalog Consider two possible cases: 1. You have one wildcard certificate for \*.acme.com * Place the certificate on your gateway by following the instructions in the next section. CloudGuard WAF will use it for all relevant applications. 2. You have two certificates: (1) for [www.acme.com](http://www.acme.com) and (2) for products.acme.com * Place both certificates on your gateway by following the instructions in the next section. CloudGuard WAF will automatically use certificate 1 for the first two Applications/APIs and certificate 2 for the last Application. ### Validating the certificate of the internal server The reverse proxy takes incoming HTTP/S requests and forwards them to an internal server. When using HTTPS, the forwarded request to the internal server returns with a certificate which the best practice is to validate. [Advanced Reverse Proxy settings](/how-to/edit-reverse-proxy-advanced-settings-for-a-web-asset) include the configuration option for "**Trusted CA chain for protected server SSL verification**". Use this option to configure the trusted CA chain that will validate the certificate presented by the internal server for enhanced security. # AWS **Overview** {% hint style="info" %} If you are deploying a CloudGuard WAF AppSec Gateway to protect an existing production website, we recommend you also read the [HOW-TO guide for this particular deployment](/how-to/protect-an-existing-production-site-with-cloudguard-wafs-gateway). {% endhint %} CloudGuard WAF can be deployed as either a single virtual machine or Auto-Scaling Group in AWS. It acts as a reverse proxy where before / after you can deploy AWS Load Balancers:
{% hint style="warning" %} When deploying an auto-scaling group, the external load balancer is deployed automatically {% endhint %} ## Installation Follow these steps to deploy CloudGuard WAF in AWS using a supplied CloudFormation Template: #### Step 1: AWS Console Log in Log in to **AWS Console** and select the relevant region. #### Step 2: Activate CloudGuard WAF through the AWS Marketplace (Once per Region) Search for [CloudGuard WAF in AWS Marketplace](https://aws.amazon.com/marketplace/server/procurement?productId=d9ada83e-6d91-448f-8097-63a789504f5f). During activation, a form with a field to select one of the AWS regions, is shown. Select the region in which you wish to deploy CloudGuard WAF's Gateway. #### Step 3: Verify required permissions Verify that you have the required **IAM permissions:**
IAM permissions CloudFormation::DescribeStackEvents CloudFormation::DescribeStacks CloudFormation::ListStacks CloudFormation::ListStackResources CloudFormation::CreateStack elasticloadbalancing::DescribeLoadBalancers elasticloadbalancing::DescribeListeners elasticloadbalancing::DescribeTargetGroups elasticloadbalancing::CreateTargetGroup elasticloadbalancing::CreateListener elasticloadbalancing::CreateLoadBalancer elasticloadbalancing::ModifyTargetGroupAttributes elasticloadbalancing::ModifyLoadBalancerAttributes SNS::CreateTopic SNS::GetTopicAttributes SNS::Subscribe IAM::GetRolePolicy IAM::PutRolePolicy IAM::CreateInstanceProfile IAM::CreateRole IAM::AddRoleToInstanceProfile EC2::DescribeInternetGateways EC2::DescribeLaunchTemplates EC2::DescribeLaunchTemplateVersions EC2::DescribeKeyPairs EC2::DescribeSecurityGroups EC2::DescribeSubnets EC2::DescribeVpcs EC2::DescribeAccountAttributes EC2::CreateTags EC2::AuthorizeSecurityGroupIngress EC2::CreateLaunchTemplate EC2::CreateSecurityGroup EC2::RunInstances CloudWatch::PutMetricAlarm Health::DescribeEventAggregates **If you want AutoScaling setup:** AutoScaling::UpdateAutoScalingGroup AutoScaling::CreateAutoScalingGroup AutoScaling::DescribeAutoScalingGroups AutoScaling::DescribeScalingActivities AutoScaling::PutScalingPolicy AutoScaling::PutNotificationConfiguration **If you want to store certificates in AWS:** KMS::CreateGrant KMS::DescribeKey
#### Step 4: **Deployment using CloudFormation** Choose one of three deployment options : {% tabs %} {% tab title="Single Gateway into new VPC" %} ![](/files/t9Mdq6rXAmjm8r1I4ZZG) #### Choose the correct fulfillment option in the Marketplace offer:
**VPC Network Configuration** ![](/files/Nm4QgFBGVopBFEy9wGXA) * **Availability Zone** - The availability zone in which to deploy the instance. * **VPC CIDR** - If you launched the CloudFormation template to create a new VPC - The CIDR of the new VPC. * **Public Subnet CIDR** - The Public (Frontend) subnet of the CloudGuard WAF's Gateway. * **Private Subnet CIDR** - The Private (Backend) subnet of the CloudGuard WAF's Gateway. **EC2 Instance Configuration** ![](/files/9hOCjSNPN3Aa8TxcruUM) * **Gateway Name** - EC2 name. * **Gateway Instance type** - The machine size of the VM. Each machine size has its own compute price. See [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/). * Minimum requirements: c5.large * **Key name** - The EC2 Key Pair you created for this region. * **Auto Assign Public IP** - If selected Yes, then the solution has a public IP address. * **Enable AWS Instance Connect** - Amazon EC2 Instance Connect is a simple and secure way to connect to your instances using Secure Shell (SSH). See the [AWS EC2 User Guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html). **Check Point Settings** ![](/files/0YUXCIXmGu7hp2x1bGo5) * **Gateway’s Password hash** – The hashed password for the Gaia Administration Portal. User is set to ‘admin’.\ Use this command to create the hash:\ `openssl passwd -1 <`*`password`*`>`.\ \ It is also possible to create a password using the SHA512 algorithm as follows:\ `openssl passwd -6 <`*`password`*`>`. * **Infinity Next Agent Token** - The token copied from the profile.

Make sure you obtain the <token> from the Enforcement Profile page, Authentication section.

* **Fog Address (optional)** - Not used in production installations. The production cloud address is determined automatically. **Advanced Settings** ![](/files/bh73A3zCwPnS8OQ3X2Xq) * **Gateway Hostname (Optional)** - The Gaia Hostname. * **Bootstrap Script (Optional)** The default Security Group associated to the created VPC is defined with these ports for Inbound traffic: * TCP Port 22 - for SSH. * TCP Port 443 - for HTTPS. * TCP Port 30443 - The CloudGuard WAF Gateway's Web UI. * TCP Port 80 - for HTTP. * To configure a single CloudGuard WAF gateway installation with SSL, refer to [Infinity Next Deployment and Configuration](https://sc1.checkpoint.com/documents/Infinity_Portal/WebAdminGuides/EN/Infinity-Next-Admin-Guide/Topics-Infinity-Next/Infinity-Next-Deployment-and-Configuration.htm?tocpath=Infinity%20Next%20Deployment%20and%20Configuration%7C_____0#How-to-Manually-Upload-Certificates). {% endtab %} {% tab title="Single Gateway into existing VPC" %} ![](/files/lC4wjQZnpGhBgKHsKR5A) #### Choose the correct fulfillment option in the Marketplace offer:
**VPC Network Configuration** ![](/files/i0KaNK3NmVp2LLEnJlAq) * **VPC** - Select an existing Virtual Private Network from your region. * **Public Subnet CIDR** - Select the Public (Frontend) subnet of the CloudGuard WAF's AppSec Gateway from the available list. * **Private Subnet CIDR** - Select the Private (Backend) subnet of the CloudGuard WAF's AppSec Gateway from the available list. * **Internal route table (optional)** - keep empty. **EC2 Instance Configuration** ![](/files/9hOCjSNPN3Aa8TxcruUM) * **Gateway Name** - EC2 name. * **Gateway Instance type** - The machine size of the VM. Each machine size has its own compute price. See [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/). * Minimum requirements: c5.large * **Key name** - The EC2 Key Pair you created for this region. * **Auto Assign Public IP** - If selected Yes, then the solution has a public IP address. * **Enable AWS Instance Connect** - Amazon EC2 Instance Connect is a simple and secure way to connect to your instances using Secure Shell (SSH). See the [AWS EC2 User Guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html). **Check Point Settings** ![](/files/0YUXCIXmGu7hp2x1bGo5) * **Gateway’s Password hash** – The hashed password for the Gaia Administration Portal. User is set to ‘admin’.\ Use this command to create the hash:\ `openssl passwd -1 <`*`password`*`>`. * **Infinity Next Agent Token** - The token copied from the profile.

Make sure you obtain the <token> from the Enforcement Profile page, Authentication section.

* **Fog Address (optional)** - Not used in production installations. The production cloud address is determined automatically **Advanced Settings** ![](/files/bh73A3zCwPnS8OQ3X2Xq) * **Gateway Hostname (Optional)** - The Gaia Hostname * **Bootstrap Script (Optional)** A security group with the name suffix "\*\_PermissiveSecurityGroup" will be created and associated with the existing VPC. This security group is defined with these ports for Inbound traffic: * TCP Port 22 - for SSH. * TCP Port 443 - for HTTPS. * TCP Port 30443 - The CloudGuard WAF AppSec Gateway's Web UI. * TCP Port 80 - for HTTP. * To configure a single CloudGuard WAF AppSec gateway installation with SSL, refer to [Infinity Next Deployment and Configuration](https://sc1.checkpoint.com/documents/Infinity_Portal/WebAdminGuides/EN/Infinity-Next-Admin-Guide/Topics-Infinity-Next/Infinity-Next-Deployment-and-Configuration.htm?tocpath=Infinity%20Next%20Deployment%20and%20Configuration%7C_____0#How-to-Manually-Upload-Certificates). {% endtab %} {% tab title="Auto-Scaling group into existing VPC" %} ![](/files/0YnYa0ZkzdpO8aJ6m7TT) #### Choose the correct fulfillment option in the Marketplace offer:
#### VPC Network Configuration ![](/files/ZIPSN1fcEZEpOdPcfFVY) * **VPC** - Select an existing Virtual Private Network from your region. * **Gateways subnets** – Select at least two subnets in your VPC. The subnets must allow outbound traffic to the internet for communicating with CloudGuard WAF's Cloud. **EC2 Instance Details**
* **Auto Scaling Group name** - The name of the Auto Scaling Group. This name determines the VM's hostname prefix. * **Gateway Instance type** - The machine size of the VM. Each machine size has its own compute price. See [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/).\ Minimum requirements: **c5.large** * **Volume encryption** - EBS encryption of the instances volumes using AWS managed KMS key. Custom KMS keys are not supported.\ If regional encryption is used then both AWS managed and Custom KMS keys are supported. * **Allow access from** - Specifies the client IP addresses that can reach your instance. This IP address range must be in CIDR notation. * To add IP addresses after the deployment: 1. Go to your deployed Stack > Resources or go to Services > EC2 > Security Groups and select the relevant Security Group. 2. Click Edit inbound rules. 3. Below the Source field, enter a list of IP addresses. * **Key name** - The EC2 Key Pair you created for this region. * **Enable EC2 Instance Connect** - Amazon EC2 Instance Connect is a simple and secure way to connect to your instances using Secure Shell (SSH). See the [AWS EC2 User Guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html). * **Gateway’s Password hash (Optional)** – This relates to Check Point Gaia administration portal. Read the next section for further explanation. #### **Check Point Related Settings**
* **Gateway’s Password hash (Optional, appears in EC2 instance details section)** – The hashed password for the Gaia Administration Portal. User is set to ‘admin’. Use this command to create the hash: `openssl passwd -1 <`*`password`*`>`. * **Infinity Next Agent Token** - The token copied from the profile.

Make sure you obtain the <token> from the Enforcement Profile page, Authentication section.

* **Fog Address (optional)** - Not used in production installations. The production cloud address is determined automatically. * **Specify an S3 bucket for scaling events** - This option allows defining an S3 bucket (a new or existing one) which allows scaling events to occur without the need to connect to Check Point's cloud. It is recommended to use an S3 bucket so scaling events will be not be disrupted by temporary Internet connectivity issues, for example, as the new instance must get its software and policy.
* **Specify an S3 bucket name** - If you selected "existing S3 bucket" or "new S3 bucket", you must specify the name of the S3 bucket here. #### Auto Scaling Group Settings ![](/files/uQJccCniKunpiqrHKEJj) * **Type of the Load Balancer** - Choose whether you want to deploy a solution with network or application load balancer. {% hint style="warning" %} Note - For application load balancer, in order to configure the HTTP health checks the following settings must be added to the Infinity Next profile: Key: agent.rpmanager.nginxIncludeLines Value: server {listen 8117; return 200;} Key: agent.config.orchestration.healthCheckProbe.enable Value: false\ ![](/files/nZcoXDLFZjvtMFjI7tdA) {% endhint %} * **Scheme of the Load Balancer** - Choose if the load balancer should be Internal or External. * **Initial number of gateways** – The initial number of EC2 instances that is deployed together with the Auto Scaling Group. * **Maximum number of gateways** – The maximum number of EC2 instances the Auto Scaling Group can scale to. * **Bootstrap script (Optional)** - An optional script to run on the initial boot. * **Administrator email address (Optional)** - An email address to notify users about scaling events. {% endtab %} {% endtabs %} {% hint style="info" %} Creating the stack in AWS takes about 6-8 minutes. When the CloudGuard WAF EC2 loads it will automatically connect to Check Point, register using the token you provided and fetch your policy. Then, either [Store Certificates in AWS](/getting-started/deploy-enforcement-point/gateway-virtual-machine/aws/store-certificates-in-aws) or [Store Certificates on the Gateway](https://app.gitbook.com/o/NmlxbSkVNQHTmh0JtAB1/s/EWA4nfgNrSRL8dA6Kap7/~/changes/h5oX1fXrzha8sEBzZWYF/getting-started/deploy-appsec-gateway-agent/deployment-as-vm-gateway/store-certificates-on-the-gateway). If successful, you will see a green notification bar in this portal with a message that your Agent/Gateway successfully connected. {% endhint %}
Troubleshooting Tips * After launching the CloudFormation, you can monitor AWS resources creation progress in AWS console under the 'Resources' tab of the deployed parent and nested stacks.\ In any case of provisioning failure, the created resources will be deleted, and the reason of failure can be viewed under 'Events' tab of the failed stack. * Verify that you entered the correct Token taken from the profile page. Otherwise your AppSec Gateway will not be able to connect to Check Point cloud * Verify that the subnet where you deploy the AppSec Gateway have outbound internet connectivity * Verify that the chosen EC2 instance type is available in your region * Verify that you have sufficient IAM permissions as listed above to run the CloudFormation stack
#### Step 5: SSL Certificates Choose the desired SSL Certificates storage method: {% content-ref url="/spaces/EWA4nfgNrSRL8dA6Kap7/pages/HnnSNdbCBaph9CD2gbQB" %} [Store Certificates in AWS](/getting-started/deploy-enforcement-point/gateway-virtual-machine/aws/store-certificates-in-aws) {% endcontent-ref %} {% content-ref url="/spaces/EWA4nfgNrSRL8dA6Kap7/pages/sQRmqjD1Uo1WVzznmo8e" %} [Store certificates on Gateway](/getting-started/deploy-enforcement-point/gateway-virtual-machine/aws/store-certificates-on-gateway) {% endcontent-ref %} #### Step 6: Launch the stack To launch the Stack, select these two checkboxes: ![](/files/IfKbeeW6eQ1oGltoPnWq) {% hint style="warning" %} When deploying CloudGuard WAF Gateway without assets connected to the profile, the Gateway will be deployed with the Orchestrator nano-service only. In this case, a manual change in the LB health check configuration will need to be changed manually from port 5555 to port 8117. {% endhint %} # Store Certificates in AWS Follow these steps to store your certificate and private keys in AWS that can be used by CloudGuard WAF to process HTTPS traffic ### Note About Certificate Renewal {% hint style="warning" %} When a certificate is renewed, you must update the certificate manager according to the instructions below, then enforce policy again (even if configuration has not changed) by clicking on "**Enforce**" on the top bar of the web administration application for CloudGuard WAF in the portal, or by using [management API](/references/management-api). {% endhint %} ### Certificates Usage In order to use encrypted traffic (HTTPS) a managed reverse proxy must have access to the relevant certificates of the domains and URLs it exposes. **Example - you have two applications and one API endpoint to protect:** * [www.acme.com](http://www.acme.com) * [www.acme.com/sales](http://www.acme.com/sales) * products.acme.com/catalog
ExamplesCertificates usedRequired action
Case 1You have one wildcard certificate for *.acme.comPlace the certificate in the desired certificate storage by following the instructions below. CloudGuard WAF will use it for all relevant applications
Case 2You have two certificates: (1) for www.acme.com and (2) for products.acme.comPlace both certificates in the desired certificate storage by following the instructions below. CloudGuard WAF will automatically use certificate 1 for the first two Applications/APIs and certificate 2 for the last Application
### Setting a certificate in AWS certificate manager #### Step 1: AWS Console Log in to **AWS Console** and select the relevant Region. #### Step 2: **AWS Certificate Manager** Navigate to the **AWS Certificate Manager (ACM)** and import a PEM-encoded certificate and private key. {% hint style="warning" %} The certificate must be imported from a different certificate provider and only hosted by the ACM. Creation of the certificate via the ACM is not supported as this prevents access to the private key required in the next step. {% endhint %} #### Step 3: Prepare your private key for storage in **AWS Secrets Manager** Encode your private key into base64 using this command (Linux or Mac): *`openssl base64 -A -in -out `* You will need the output of the command in Step 4. #### Step 4: Store your private key as a secret Navigate to **AWS Secrets Manager** and click **Store a new secret:** ![](/files/zgz80TpfXW2xap93cuoZ) * Choose **Other types of secret**, and add a new secret key-value pair: * In the **key** cell enter: *private key* * In the **value** cell enter your private key as a *base64 encoded single string (the output of the openssl command above)*. * Set the **Encryption key** to: *aws/secretmanager* * Click **Next** {% hint style="info" %} It is recommended to copy the base64 encoded key into a text editor and then to the Secrets Manager to make sure it is copied correctly. Sometimes, copying directly from a terminal is not working well. {% endhint %} #### Step 5: Secret Name and Tags ![](/files/kHhjKriySYcZt1rI0uw3) * Enter the name of your secret in the **secret name** field * In the Tags section, add Key-Value Pair: * In the **key** cell enter: *certificate* * In the **value** cell enter the Amazon Resource Name (ARN) of the matching certificate that you placed in the **AWS Certificate Manager** (step 4 above). {% hint style="success" %} Repeat the above steps for each additional private key you have. You must store each private key as a separate secret. {% endhint %} #### Step 6: Launch CloudFormation Stack ![](/files/YfBikNB362nxjXeEJcMq) To launch the CloudFormation Stack, select the acknowledgement check boxes and click **Create stack**. {% hint style="info" %} The CloudFormation template allows you to input only two certificates and private keys. After the stack launches for additional certificates, go to the created IAM Role and edit the **GetCertificatesPolicy** and **GetSecretsPolicy** with the additional ARNs, after you repeat Steps 1-5. {% endhint %} #### Step 7: Enforce CloudGuard WAF Policy Open CloudGuard WAF Web Interface in your browser and click the **Enforce** button at the top bar. This will signal the Gateways to read the certificates from AWS. # Store certificates on Gateway ### Note About Certificate Renewal {% hint style="warning" %} When a certificate is renewed, you must update the certificate according to the instructions below, then enforce policy again (even if configuration has not changed) by clicking on "**Enforce**" on the top bar of the web administration application for CloudGuard WAF in the portal, or by using [management API](/references/management-api). {% endhint %} ### Certificates Usage In order to use encrypted traffic (HTTPS) a managed reverse proxy must have access to the relevant certificates of the domains and URLs it exposes. **Example - you have two applications and one API endpoint to protect:** * [www.acme.com](http://www.acme.com) * [www.acme.com/sales](http://www.acme.com/sales) * products.acme.com/catalog
ExamplesCertificates usedRequired action
Case 1You have one wildcard certificate for *.acme.comPlace the certificate in the desired certificate storage by following the instructions below. CloudGuard WAF will use it for all relevant applications
Case 2You have two certificates: (1) for www.acme.com and (2) for products.acme.comPlace both certificates in the desired certificate storage by following the instructions below. CloudGuard WAF will automatically use certificate 1 for the first two Applications/APIs and certificate 2 for the last Application
### Storing certificates locally on CloudGuard WAF's Gateway Follow these steps to store your certificates and private keys **locally on the gateway** that can be used by CloudGuard WAF to process HTTPS traffic: {% hint style="info" %} * **Advantage**: you have full control of your secrets * **Disadvantage**: does not support automatic scaling {% endhint %} #### **Step 1: Download command-line tool** The tool's purpose is to verify the certificate and key files and generate an output .pkg file with a unique name [Linux Download](https://sc1.checkpoint.com/nano-agent/certverify/linux/certverify)\ or run: *`wget https://sc1.checkpoint.com/nano-agent/certverify/linux/certverify && chmod +x certverify`* [Mac Download](https://sc1.checkpoint.com/nano-agent/certverify/darwin/certverify) [Windows Download](https://sc1.checkpoint.com/nano-agent/certverify/windows/certverify.exe) {% hint style="info" %} You can use this tool on any machine where you have the files, before you actually store them on your CloudGuard WAF's Gateway(s). {% endhint %} #### **Step 2: Run the command-line tool** Linux and Mac: * PEM certificates: *`./certverify --cert {certificate.pem} --key {private-key.key}`* * PFX certificates: *.`/certverify --cert {certificate.pfx} --pass {password}`* Windows: * PEM certificates : *`certverify --cert {certificate.pem} --key {private-key.key}`* * PFX certificates : *`certverify --cert {certificate.pfx} --pass {password}`* {% hint style="success" %} Repeat this step for each certificate/private key you wish to use {% endhint %} {% hint style="info" %} Only certificates that contain Subject Alternative Name (SAN) are supported {% endhint %} The tool will verify the certificate and key files, and generate an output .pkg file with a unique name that includes both. **Step 3: Store certificate and private key on your CloudGuard WAF Gateway using SCP** {% hint style="warning" %} You must store the files in directory /etc/certs on CloudGuard WAF's Gateway or else it will not be identified. If the commands below end with an error, navigate to /etc and make sure a directory exists called "certs" (in linux, use the `mkdir` command). {% endhint %} The input pkg file for this step is the uniquely named pkg output file of the previous step. * Linux or Mac: *`./scp {unique-name.pkg} admin@{gateway-ip}:/etc/certs`* * Windows: *`"C:\Program Files (x86)\WinSCP\WinSCP.com" /command "open scp://admin:{password}@{gateway-ip}" "put cert_cert.pkg /etc/certs/" "exit"`* {% hint style="success" %} Repeat this step for each certificate/private key you wish to use **and** for each CloudGUard WAF Gateway. {% endhint %} #### **Step 4: Enforce Policy** CloudGuard WAF will now use the relevant certificates with HTTPS clients that are trying to access your applications. #### **Step 5: Change relevant DNS entries** You can now change your DNS entries as relevant to point to your CloudGuard WAF Gateway IP or to a Load Balancer in front of several CloudGuard WAF's Gateways. # Azure ## Overview {% hint style="info" %} If you are deploying a CloudGuard WAF Gateway to protect an existing production website, we recommend you also read the [HOW-TO guide for this particular deployment](/how-to/protect-an-existing-production-site-with-cloudguard-wafs-gateway). {% endhint %} CloudGuard WAF can be deployed as either a single virtual machine or a Scale-Set in Azure. It acts as a reverse proxy where before / after you can deploy Azure Load Balancers:
{% hint style="info" %} Make sure you obtain the \ from the [Enforcement **Profile**](/getting-started/deploy-enforcement-point) page, **Authentication** section. You will need it in during agent deployment. ![](/files/tAyti9aG3utyFHls2McN) {% endhint %} ## Installation Follow these steps to deploy CloudGuard WAF in Azure using an ARM Template: #### Step 1: Azure Log in Log in to your Azure account. #### Step 2: Verify required permissions Verify that you have the required permissions:
Azure permissions Microsoft.Resources: Purchase Resource Validate Deployment Microsoft.Insights: Update autoscale setting Microsoft.Compute: Create or Update Virtual Machine Scale Set Microsoft.KeyVault: Update Access Policy Microsoft.Network: Create or Update Public Ip Address Create or Update Virtual Network Create or Update Route Table Create or Update Network Security Group Create or Update Load Balancer Microsoft.Storage: Update Storage Account Create If deploying VMSS with a new Azure Key Vault: Microsoft.KeyVault: Update Key Vault Write Secret
#### Step 3: **Deployment using ARM Template** * Open the CloudGuard WAF's Azure page: . * Click the blue "Get It Now" button to start the configuration wizard. #### You have two options to store certificates: {% content-ref url="/pages/ibANNodjYVMlrG3tt6Xs" %} [Store Certificates in Azure](/getting-started/deploy-enforcement-point/gateway-virtual-machine/azure/store-certificates-in-azure) {% endcontent-ref %} {% content-ref url="/pages/AwmS4FcuC3df9g66jPnV" %} [Store Certificates on Gateway](/getting-started/deploy-enforcement-point/gateway-virtual-machine/vmware/store-certificates-on-gateway) {% endcontent-ref %} # Store Certificates in Azure Follow the steps described in this page to store your certificate and private keys in Azure that can be used by CloudGuard WAF to process HTTPS traffic ### Note About Certificate Renewal {% hint style="warning" %} When a certificate is renewed, you must update the key vault according to the instructions below, then enforce policy again (even if configuration has not changed) by clicking on "**Enforce**" on the top bar of the web administration application for CloudGuard WAF in the portal, or by using [management API](/references/management-api). {% endhint %} ### Certificates Usage In order to use encrypted traffic (HTTPS) a managed reverse proxy must have access to the relevant certificates of the domains and URLs it exposes. **Example - you have two applications and one API endpoint to protect:** * [www.acme.com](http://www.acme.com) * [www.acme.com/sales](http://www.acme.com/sales) * products.acme.com/catalog
ExamplesCertificates usedRequired action
Case 1You have one wildcard certificate for *.acme.comPlace the certificate in the desired certificate storage by following the instructions below. CloudGuard WAF will use it for all relevant applications
Case 2You have two certificates: (1) for www.acme.com and (2) for products.acme.comPlace both certificates in the desired certificate storage by following the instructions below. CloudGuard WAF will automatically use certificate 1 for the first two Applications/APIs and certificate 2 for the last Application
### Setting a certificate as part of the CloudGuard WAF Template Wizard #### Pre-requisite if you plan to use an existing Azure Key Vault {% hint style="warning" %} When using an existing Azure Key Vault you first need to make sure it already contains all relevant PFX certificate/s and their password/s. See the section "[Adding a new certificate to an existing Azure Key Vault](#adding-a-new-certificate-to-an-existing-azure-key-vault)" for more information. {% endhint %} Only PFX certificates are supported. If you already have certificates in your existing Azure Key Vault, it is not possible in Azure to see if they are in PFX or PEM format until you download them from the Azure Web Console by clicking "Download in PFX/PEM format". If your existing certificates are in PEM format, it is possible to convert them the PFX format by using the following command in linux: ``` openssl pkcs12 -inkey -in -export -out ``` After this action follow the instructions in the "[Adding a new certificate to an existing Azure Key Vault](#adding-a-new-certificate-to-an-existing-azure-key-vault)" section. #### Step 1: HTTPS settings tab To store certificates and private Keys in Azure Key Vault, use the HTTPS settings Tab of CloudGuard WAF for Azure ARM Template wizard: ![](https://i2-s3-ui-static-content-10.s3.eu-west-1.amazonaws.com/certificates-profile/Certificates%20Azure/images/existing%20azure%20key%20vault.PNG) In the wizard **HTTPS settings tab**, follow these steps: #### **Step 2: Decide if you use an existing Azure key or creating a new one** Select whether you use HTTPS protocol and whether you have an existing Azure Key vault that already contains your SSL certificates, or want to create a new one. The ARM template automatically adds appropriate secret and certificate permissions to the Key Vault for the Scale Set resource. The granted permissions are ‘List’ and ‘Get’. {% hint style="info" %} Only certificates that contain Subject Alternative Name (SAN) are supported. {% endhint %} #### Step 3 option a: If you chose to create a new Azure Key Vault and upload certificates: ![](https://i2-s3-ui-static-content-10.s3.eu-west-1.amazonaws.com/certificates-profile/Certificates%20Azure/images/new%20azure%20key%20vault.PNG) * **Azure Key Vault name** * **Number of certificates to upload** - Each certificate has two entries in the Key Vault secrets, one for its certificate and one for its password. * **PFX certificate file** - A PKCS#12 archive that contains the Certificate Authority (CA) certificate and private key. The file name extension for PKCS#12 archives is .p12 or .pfx * **Description** - A description of the uploaded certificate. The uploaded certificates content is encoded to base64 format and stored as 'cert\[1-5]' in vault's secrets. A description is mandatory to keep track of them. {% hint style="info" %} The template allows up to 5 certificates. However - after initial deployment it is possible to add more certificates to the same location. {% endhint %} * **Certificate password** - Password used when exporting the PFX certificate. The password is encoded to base64 format and stored in the vault’s secrets as ‘cert\[1-5]-pw’. #### *Step 3 option b: If you chose to use an existing Azure Key Vault* This option allows you to use a previously created Azure Key Vault that contains PFX certificates for all your applicable HTTPS based assets in the Infinity Portal. The PFX certificate must contain both the certificate and the private key. It is not necessary to have the Key Vault in the same Resource Group as the deployed template, but it must be created in the same region. {% hint style="warning" %} Reminder: Read again the Pre-requisite section. When using an existing Azure Key Vault you first need to make sure it already contains PFX certificates and their passwords. See the section "[Adding a new certificate to an existing Azure Key Vault](#adding-a-new-certificate-to-an-existing-azure-key-vault)" for more information. {% endhint %} To configure the Key Vault’s access policies correctly, under **Enable Access to,** select the checkbox **Azure Virtual Machines for deployment**. ![](https://i2-s3-ui-static-content-10.s3.eu-west-1.amazonaws.com/certificates-profile/Certificates%20Azure/images/Azure_Permission_Model.png) *Finally, Click **Enforce** Policy in the Infinity Portal top bar* {% hint style="info" %} *The certificates are fetched when CloudGuard WAF's Gateway first loads and checked again for updates every time you Enforce policy.* {% endhint %} #### Notes * To attach a different Azure Key Vault to an already deployed Scale Set: 1. Create your Key Vault in the same region as your Scale Set with the Access Policy as described earlier 2. Go to the Scale Set resource and change the value field of the Tag named vault to your new Key Vault name. ### Adding a new certificate to an existing Azure Key Vault {% hint style="warning" %} If you already had an existing Azure Key Vault with certificates, before deploying your CloudGuard WAF's Gateway, you must make sure all existing certificates in the vault were added using the instructions in this section. {% endhint %} Only PFX certificates are supported. If your certificates are in PEM format, it is possible to convert them the PFX format by using the following command in linux: ``` openssl pkcs12 -inkey -in -export -out ``` #### Step 1: Import a certificate Follow the instructions in Azure documentation regarding [importing a certificate file](https://docs.microsoft.com/en-us/azure/key-vault/certificates/tutorial-import-certificate?tabs=azure-portal). Make sure you only import a supported certificate file (PFX) even if the examples in the documentation show an example for different types. Make sure you know what is the password of the certificate file for the next step (it is configured during the file's creation). #### Step 2: Add the certificate's password to the secrets section For CloudGuard WAF's Gateway to associate automatically the PFX's password, you must create a password-type entry in the secrets storage of the Azure Key Vault. Its name must be **\-pw** and its value will be the password of the certificate. {% hint style="info" %} For example, if you imported a certificate entry named "my-website-cert", then the password entry name must be "my-website-cert-pw" {% endhint %} #### Step 3: Create a new Web asset or add a URL to an existing asset Navigate to the Infinity Portal and create a new Asset or add an Application URL to an existing Asset, and then click **Enforce** policy. # Store Certificates on Gateway ### Note About Certificate Renewal {% hint style="warning" %} When a certificate is renewed, you must update the certificate according to the instructions below, then enforce policy again (even if configuration has not changed) by clicking on "**Enforce**" on the top bar of the web administration application for CloudGuard WAF in the portal, or by using [management API](/references/management-api). {% endhint %} ### Certificates Usage In order to use encrypted traffic (HTTPS) a managed reverse proxy must have access to the relevant certificates of the domains and URLs it exposes. **Example - you have two applications and one API endpoint to protect:** * [www.acme.com](http://www.acme.com) * [www.acme.com/sales](http://www.acme.com/sales) * products.acme.com/catalog
ExamplesCertificates usedRequired action
Case 1You have one wildcard certificate for *.acme.comPlace the certificate in the desired certificate storage by following the instructions below. CloudGuard WAF will use it for all relevant applications
Case 2You have two certificates: (1) for www.acme.com and (2) for products.acme.comPlace both certificates in the desired certificate storage by following the instructions below. CloudGuard WAF will automatically use certificate 1 for the first two Applications/APIs and certificate 2 for the last Application
### Storing certificates locally on CloudGuard WAF's Gateway Follow these steps to store your certificate and private keys on the gateway that can be used by CloudGuard WAF to process HTTPS traffic: {% hint style="info" %} * **Advantage**: you have full control of your secrets * **Disadvantage**: does not support automatic scaling {% endhint %} #### **Step 1: Download command-line tool** The tool's purpose is to verify the certificate and key files and generate an output .pkg file with a unique name. [Linux Download](https://sc1.checkpoint.com/nano-agent/certverify/linux/certverify) or run: *`wget https://sc1.checkpoint.com/nano-agent/certverify/linux/certverify && chmod +x certverify`* [Mac Download](https://sc1.checkpoint.com/nano-agent/certverify/darwin/certverify) [Windows Download](https://sc1.checkpoint.com/nano-agent/certverify/windows/certverify.exe) {% hint style="info" %} You can use this tool on any machine where you have the files, before you actually store them on your CloudGuard WAF Gateway(s). {% endhint %} #### **Step 2: Run the command-line tool** Linux and Mac: * PEM certificates: *`./certverify --cert {certificate.pem} --key {private-key.key}`* * PFX certificates: *.`/certverify --cert {certificate.pfx} --pass {password}`* Windows: * PEM certificates : *`certverify --cert {certificate.pem} --key {private-key.key}`* * PFX certificates : *`certverify --cert {certificate.pfx} --pass {password}`* {% hint style="success" %} Repeat this step for each certificate/private key you wish to use. {% endhint %} {% hint style="info" %} Only certificates that contain Subject Alternative Name (SAN) are supported. {% endhint %} The tool will verify the certificate and key files, and generate an output .pkg file with a unique name that includes both. **Step 3: Store certificate and private key on your CloudGuard WAF Gateway using SCP** {% hint style="warning" %} You must store the files in directory /etc/certs on CloudGuard WAF Gateway or else they will not be identified.\ If the commands below end with an error, navigate to /etc and make sure a directory exists called "certs" (in linux, use the `mkdir` command). {% endhint %} The input pkg file for this step is the uniquely named pkg output file of the previous step. * Linux or Mac: *`./scp {unique-name.pkg} admin@{gateway-ip}:/etc/certs`* * Windows: *`"C:\Program Files (x86)\WinSCP\WinSCP.com" /command "open scp://admin:{password}@{gateway-ip}" "put cert_cert.pkg /etc/certs/" "exit"`* {% hint style="success" %} Repeat this step for each certificate/private key you wish to use **and** for each CloudGuard WAF Gateway. {% endhint %} #### **Step 4: Enforce Policy** CloudGuard WAF will now use the relevant certificates with HTTPS clients that are trying to access your applications. #### **Step 5: Change relevant DNS entries** You can now change your DNS entries as relevant to point to your CloudGuard WAF Gateway IP or to a Load Balancer in front of several CloudGuard WAF's Gateways. # VMware ## Overview {% hint style="info" %} If you are deploying a CloudGuard WAF Gateway to protect an existing production website, we recommend you also read the [HOW-TO guide for this particular deployment](/how-to/protect-an-existing-production-site-with-cloudguard-wafs-gateway). {% endhint %} CloudGuard WAF can be deployed as either a single virtual machine or several virtual machines in VMware vSphere. It acts as a reverse proxy where before / after you can deploy load balancer.
## Installation Follow these steps to deploy CloudGuard WAF in **VMware vSphere 6.5** and above: {% hint style="info" %} **Minimal configuration for CloudGuard WAF VM is:** 2\*vCPU, 4GB RAM, 50GB Disk **Recommended configuration for CloudGuard WAF VM is:** 4\*vCPU, 8GB RAM, 50GB Disk {% endhint %} #### Step 1: Download the CloudGuard WAF installation package for VMware Download the software archive and extract the files from here: The file will be a zipped file with the prefix "**Check\_Point\_CloudGuard\_Infinity\_Next\_Gateway\_V**\*". Unzip it to extract the included 4 files (a **vmdk** file, an **ovf** file, an **mf** file and a **cert** file). #### Step 2: Launch vSphere Web Client Open a Web browser and enter the URL of your vCenter's vSphere Web Client e.g:\ https\://{vcenter\_server\_ip\_address\_or\_fqdn}/vsphere-client #### Step 3: Deploy OVF Template * Go to either the **Hosts and Clusters** or **VMs and Templates** tab and right-click on the data center to deploy the VM in.
* Click Deploy OVF Template. * Go to Local file and select the four extracted files. ![](/files/Orf4KHB2WOlY6vKPPLWx) #### Step 4: Complete the necessary details of the OVF deployment forms * Click **Next** until you get to Review details where you can find details about the certificate, product version, and more. Click **Next** again once you have reviewed them. ![](/files/nBbi36Q2aMqOgXiZE50K) * Select storage, network, and customize the template options as you wish. * **Select storage** - allows changing the VM Storage Policy such as the virtual disk format (thin or thick provisioning) and selecting the exact storage volume to use.\ Make sure you have at least X free size of storage for CloudGuard WAF's Gateway. * **Select networks** - The network chosen for the VM must include internet connectivity to Check Point's cloud network. If needed it will be possible later to create more than the single interface that is automatically configured. * **Customize template** - There are several required fields to fill before clicking "Next": ![](/files/3ZdAhlhzxlWzgVHlPeG8) 1. **Hostname** - a valid linux hostname (e.g. no spaces). 2. **Default Gateway Address** 3. **Admin password** - set the password used by the user 'admin' when connecting via terminal, ssh, or web portal. 4. **IP address & subnet** - A valid routable IP address and subnet of the main interface for this VM. 5. **Primary DNS** - The address of the DNS server to be used by the CloudGuard WAF Gateway. 6. **(Usually not required) Proxy Configuration** - This is for the less common case where internet access from the CloudGuard WAF VM can only go through a main proxy server. ![](/files/UzDTuqAEZca9uArheQft) 1. **(Not required) NTP Server Configuration** - If you want the time configuration for this machine to use an NTP server such as ntp.checkpoint.com or an NTP server for your organization. 2. **Infinity Next Agent Token** - Required to be added twice. The token copied from the WAF Gateway profile. 3. The form allows an advanced administrator to add their own custom configuration commands to run automatically at the end of the deployment operation. Those commands can be Linux commands or [Gaia Clish commands](https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_Gaia_AdminGuide/Topics-GAG/Gaia-Clish-Commands.htm): 1. **(Not required) Additional Clish Commands** - The commands must be encoded in Base64. You can optionally add any additional configuration commands using the [Check Point Gaia Clish commands](https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_Gaia_AdminGuide/Topics-GAG/Gaia-Clish-Commands.htm) if relevant to your network. The method to do it is as follows: 1. Prepare a file in a Linux environment with the Clish command/s you wish to run.\ (If the file was originally created in Windows, copy it to Linux and run dos2unix on it before continuing to the next step) 2. Run the following command: ***cat \ | base64 -w 0*** 3. The output of this command should be copied and pasted into the "Additional Clish Commands" box in the "Customize Template" form. 2. **(Not Required) Advanced Configuration Settings** - The commands must be encoded in Base64. You can optionally add any additional Linux bash configuration commands. The method to do it is as follows (the same as with Clish commands): 1. Prepare a file in a Linux environment with the Linux command/s you wish to run.\ (If the file was originally created in Windows, copy it to Linux and run dos2unix on it before continuing to the next step) 2. Run the following command: ***cat \ | base64 -w 0*** 3. The output of this command should be copied and pasted into the "Advanced Configuration Settings" box in the "Customize Template" form. {% hint style="info" %} Make sure you obtain the \ from the [Enforcement **Profile**](/getting-started/deploy-enforcement-point) page, **Authentication** section. ![](/files/tAyti9aG3utyFHls2McN) {% endhint %} * Click **Next** and then **Finish**. The deployment starts. * Power on the new VM that was created. {% hint style="info" %} To access the Cloud, the Gateway requires access to DNS and to the Internet in port 443. If you wish to limit access to specific IPs or URL, a list of Check Point operated regional public Fogs can be found in the management portal, under **Support->FAQ** {% endhint %} #### Step 5: Power on the newly created VM Locate the newly created machine on the VCenter, right click the object and select "**Power On**". ![](/files/dpDBZPrGm5QiYh3UnRCJ) After a few minutes, the CloudGuard WAF Gateway will connect to the CloudGuard WAF Management portal and you will be able to view its details on the **Policy->Agents** view. {% hint style="warning" %} It is recommended that Time Zone will be configured using the networking administration portal of the newly created CloudGuard WAF Gateway. {% endhint %} For advanced networking configurations as well as time zone configuration: {% content-ref url="/pages/fapitA77mywwVY9Qv7db" %} [Configure networking in VMware Deployments](/getting-started/deploy-enforcement-point/gateway-virtual-machine/vmware/configure-networking-in-vmware-deployments) {% endcontent-ref %} #### Step 6 (optional): Store certificates {% content-ref url="/pages/YZVC9UcNtyWUucZtNcKr" %} [Store Certificates on Gateway](/getting-started/deploy-enforcement-point/gateway-virtual-machine/azure/store-certificates-on-gateway) {% endcontent-ref %} # Store Certificates on Gateway ### Note About Certificate Renewal {% hint style="warning" %} When a certificate is renewed, you must update the certificate according to the instructions below, then enforce policy again (even if configuration has not changed) by clicking on "**Enforce**" on the top bar of the web administration application for CloudGuard WAF in the portal, or by using [management API](/references/management-api). {% endhint %} ### Certificates Usage In order to use encrypted traffic (HTTPS) a managed reverse proxy must have access to the relevant certificates of the domains and URLs it exposes. **Example - you have two applications and one API endpoint to protect:** * [www.acme.com](http://www.acme.com) * [www.acme.com/sales](http://www.acme.com/sales) * products.acme.com/catalog
ExamplesCertificates usedRequired action
Case 1You have one wildcard certificate for *.acme.comPlace the certificate in the desired certificate storage by following the instructions below. CloudGuard WAF will use it for all relevant applications
Case 2You have two certificates: (1) for www.acme.com and (2) for products.acme.comPlace both certificates in the desired certificate storage by following the instructions below. CloudGuard WAF will automatically use certificate 1 for the first two Applications/APIs and certificate 2 for the last Application
### Storing certificates locally on CloudGuard WAF Gateway Follow these steps to store your certificate and private keys on the gateway that can be used by CloudGuard WAF to process HTTPS traffic: {% hint style="info" %} * **Pros**: you have full control of your secrets. * **Cons**: Method fits a single gateway deployment, not an auto-scaled deployment. {% endhint %} #### **Step 1: Download command-line tool** The tool's purpose is to verify the certificate and key files and generate an output .pkg file with a unique name. [Linux Download](https://sc1.checkpoint.com/nano-agent/certverify/linux/certverify)\ or run: *`wget https://sc1.checkpoint.com/nano-agent/certverify/linux/certverify && chmod +x certverify`* [Mac Download](https://sc1.checkpoint.com/nano-agent/certverify/darwin/certverify) [Windows Download](https://sc1.checkpoint.com/nano-agent/certverify/windows/certverify.exe) {% hint style="info" %} You can use this tool on any machine where you have the files, before you actually store them on your CloudGuard WAF's Gateway(s). {% endhint %} #### **Step 2: Run the command-line tool** Linux and Mac: * PEM certificates: *`./certverify --cert {certificate.pem} --key {private-key.key}`* * PFX certificates: *.`/certverify --cert {certificate.pfx} --pass {password}`* Windows: * PEM certificates : *`certverify --cert {certificate.pem} --key {private-key.key}`* * PFX certificates : *`certverify --cert {certificate.pfx} --pass {password}`* {% hint style="success" %} Repeat this step for each certificate/private key you wish to use. {% endhint %} {% hint style="info" %} Only certificates that contain Subject Alternative Name (SAN) are supported. {% endhint %} {% hint style="warning" %} The private key must have .key suffix. {% endhint %} The tool will verify the certificate and key files, and generate an output .pkg file with a unique name that includes both. **Step 3: Store certificate and private key on your CloudGuard WAF Gateway using SCP** {% hint style="warning" %} You must store the files in directory /etc/certs on the CloudGuard WAF Gateway or else it will not be identified.\ If the commands below end with an error, navigate to /etc and make sure a directory exists called "certs" (in linux, use the `mkdir` command). {% endhint %} The input pkg file for this step is the uniquely named pkg output file of the previous step. * Linux or Mac: *`./scp {unique-name.pkg} admin@{gateway-ip}:/etc/certs`* * Windows: *`"C:\Program Files (x86)\WinSCP\WinSCP.com" /command "open scp://admin:{password}@{gateway-ip}" "put cert_cert.pkg /etc/certs/" "exit"`* {% hint style="success" %} Repeat this step for each certificate/private key you wish to use **and** for each CloudGuard WAF Gateway. {% endhint %} #### **Step 4: Enforce Policy** CloudGuard WAF will now use the relevant certificates with HTTPS clients that are trying to access your applications. #### **Step 5: Change relevant DNS entries** You can now change your DNS entries as relevant to point to your CloudGuard WAF Gateway IP or to a Load Balancer in front of several CloudGuard WAF's Gateways. # Configure networking in VMware Deployments When installing a CloudGuard WAF [Gateway in a VMware](/getting-started/deploy-enforcement-point/gateway-virtual-machine/vmware) deployment, after initial installation, an administrator might require networking changes. ## Browsing to the networking administration portal of the CloudGuard WAF Gateway Using a browser from a machine with access to the CloudGuard WAF gateway, browse to:\ **https\://\:30443** At first login, use the username 'admin' and the password that was set up during initial deployment. Afterwards you may have configured additional users and/or changed passwords. ## **Networking Configuration Options** The browser will now show the administration portal following your login credentials as you set them during the [OVF deployment](/getting-started/deploy-enforcement-point/gateway-virtual-machine/vmware). ![](/files/E1XTqqslW6N87xfYByIp) ### Network Interfaces Additional network interfaces can be configured here: ![](/files/iL9G1FytITJfhIgCio3n) ### Hosts and DNS DNS configuration including additional DNS servers on top of the primary address can be configured here: ![](/files/OOAoHWUk9PmZoVNwnlb0) ### Routing Configuration Additional routes or changes to the default route can be configured here: ![](/files/DLYcMMOME5BzYkeznXRC) ### Time Configuration The time zone configuration and any changes between automatic NTP-based time configuration to manual can be configured here: ![](/files/4x6TvZeYZk7svLzN9dDK) # WAF-as-a-Service (WAF SaaS) ## Overview Check Point WAF SaaS delivers the full security capabilities of Check Point WAF—without the need for complex deployment. It simplifies protection by routing your domain’s traffic through Check Point's cloud-based service, where traffic is inspected and forwarded securely to your internal servers. In addition to streamlined deployment, WAF SaaS enhances your security posture with advanced DDoS protection. The service operates as a reverse proxy, inspecting incoming traffic and applying Check Point WAF security policies before passing requests to your origin servers.
## Check Point WAF SaaS Points of Presence (PoPs) When setting up your Check Point WAF SaaS account, you selected a **data region**. This defines your **data residency**—the physical or geographic location where your data is stored—and determines the region of the **Infinity Portal** where you can view and manage configurations and logs. For more information, see: {% content-ref url="/pages/vEPYjTAMpjJWA0oAZhy2" %} [WAF-as-a Service (WAF SaaS)](/concepts/waf-as-a-service-waf-saas) {% endcontent-ref %} ### Deployment #### Prerequisites * **DNS Ownership:** You must control the DNS settings for the domain you’re protecting. * **Origin Accessibility**\ · Whitelist all Check Point WAF SaaS IPs on your internal web server.\ · If you’ve just spun up a new server, you may temporarily expose it publicly for this initial phase—but *must* lock it down immediately after WAF goes live. #### Instructions: To protect your web application with **Check Point WAF SaaS**, follow these steps: #### Step 1: Create a New Asset Define the website you want to protect. * Enter the **public URLs** (e.g. `www.example.com`) * Provide the **upstream origin URL** (e.g. your internal server’s IP or hostname) {% hint style="info" %} Depending on your license, Check Point WAF SaaS does not impose any limitation on the number of root domains it can support. {% endhint %} {% hint style="success" %} If you want to integrate your WAF with an existing AWS CloudFront follow the steps here: [Integrating WAF SaaS with AWS CloudFront](/getting-started/deploy-enforcement-point/waf-as-a-service-waf-saas/integrating-waf-saas-with-aws-cloudfront) {% endhint %}
#### Step 2: Connect to a WAF SaaS Profile Link your asset to a **new or existing WAF SaaS profile**.\ This profile contains your security policies and PoP settings, such as the geographical region in the world where you traffic will be processed.
{% hint style="info" %} You can configure multi-region deployment for this domain. See [*How to Configure Multi-Region Deployment*](/how-to/configure-multi-region-deployment-in-waf-saas) for more details. {% endhint %} **3. Select a Certificate Management Option** Choose how SSL/TLS certificates will be handled: * **Check Point Managed -Managed Certificate**\ Let us generate and renew your certificates automatically using Let’s Encrypt. * **Bring Your Own Certificate**\ Upload an existing certificate and private key (PEM format).
#### Step 4: Complete Certificate Configuration Follow the detailed instructions based on the option selected in Step 3: {% tabs %} {% tab title="Certificates Managed by Check Point" %} When using **Check Point ‑managed certificates**, setup is mostly automatic. However, for **each domain** protected by **WAF SaaS in a specific region**, you must complete the following steps to ensure traffic is fully secured. {% hint style="success" %} **When to perform these steps** * When creating a new asset * When adding new domains to an existing asset * When attaching a WAF SaaS profile to an asset that wasn’t previously protected * When editing a domain (remove the old one *after* adding and configuring the new one) {% endhint %} **Prove Domain Ownership** To authorizes Check Point to issue certificates for your domain using Let’s Encrypt, Follow the steps bellow: 1. In the Infinity Portal, go to **Policy → Profiles**. 2. Select the **Check Point WAF SaaS profile** created during the Asset setup. 3. Find the domain marked as “Pending Action” and click it. 4. Copy the **DNS CNAME record** shown under the domain ownership verification step. 5. In your DNS provider’s console, **add the CNAME record** with the name and value provided. {% hint style="warning" %} You must complete this step **for each domain** individually (e.g. `www.myapp.com` and `api.myapp.com`) {% endhint %} {% hint style="success" %} When you onboard a new domain that's already covered by an existing wildcard certificate, Check Point WAF SaaS automatically attaches that certificate instead of issuing a new one — onboarding completes immediately instead of waiting on issuance and validation. {% endhint %}
{% endtab %} {% tab title="Bring Your Own Certificate (BYOC) " %} While Check Point WAF SaaS offers managed public SSL/TLS certificates signed by Let’s Encrypt, you may choose to use your **own certificate and private key,** ideal for compliance needs or existing certificate infrastructure. {% hint style="success" %} Your private key is **end-to-end encrypted** during upload, ensuring complete confidentiality and security. {% endhint %} To configure HTTPS traffic with your own certificates, follow the steps below: #### Upload Certificate and Private Key 1. In the Infinity Portal, navigate to **Policy → Profiles**. 2. Select the **Check Point** **WAF SaaS profile** linked to your asset. 3. For each domain listed, click on it and: * Upload the **public certificate** (PEM format) * Upload the **private key** * Ensure the certificate includes the **full chain** {% hint style="success" %} **Reusing an Uploaded Certificate**\ Instead of uploading a new certificate for every domain, select **My certificates** in a domain's **Certificates & Domain Management** panel to open **Select Certificate** — a list of certificates you've already uploaded, showing each one's name, type (Specific/Wildcard), and expiration date. From here you can select an existing certificate to attach to this domain, upload a new one, or delete a certificate you no longer need. {% endhint %} {% hint style="warning" %} Unlike Check Point-managed certificates, BYOC certificates are not auto-renewed. As a certificate approaches expiration, the portal displays a live countdown warning (e.g. "This certificate will not be auto-renewed. Please renew it within the next N days."). Renew and re-upload your certificate before it expires to avoid a validation failure or downtime. {% endhint %}
{% endtab %} {% endtabs %} You can switch a domain from BYOC to a Check Point-managed certificate (or vice versa) at any time, with no downtime — the previous certificate stays active until the new one validates. #### Step 5: Connect your domain to WAF SaaS {% hint style="warning" %} Before performing this stage, disable any existing AWS CloudFront configuration for your website's address if you have any. {% endhint %} Once the previous step is completed, a new **CNAME value** will be generated (this may take up to 30 minutes). 1. In your DNS configuration, replace the existing CNAME record for your domain with the **new CNAME value** issued by Check Point.
#### Step 6: Allow WAF SaaS to Access Your Origin Server To ensure smooth traffic flow between WAF SaaS and your internal web server: 1. **Allow incoming traffic** from the IP addresses provided in the **WAF SaaS deployment form**. 2. **Do not remove** existing access rules until: * 72 hours have passed (to allow full DNS propagation), and * You have confirmed successful traffic flow through WAF SaaS. {% hint style="info" %} If the origin was previously publicly accessible, restrict access to only WAF SaaS IPs after DNS switchover.\ If you were using another reverse proxy, consider removing its IPs from the access list after confirming the switch. {% endhint %}
#### **Step 7: Test Access to Your Site** After completing the above steps: * Confirm that the website is reachable over HTTPS. * Verify that traffic is flowing through WAF SaaS (you can check headers or logs in the Infinity Portal). * Double-check that your origin server is **no longer publicly accessible** (unless intentionally exposed). {% hint style="info" %} While DNS changes typically take just a few hours, allow up to **72 hours** for full global propagation before making final changes. {% endhint %} {% hint style="danger" %} Make sure you have not left a publicly exposed domain in your previous environment! {% endhint %} # Certificates Managed by Check Point When using **Check Point WAF‑managed certificates**, setup is mostly automatic. However, for **each domain** protected by **Check Point WAF SaaS in a specific region**, you must complete the following steps to ensure traffic is fully secured. {% hint style="success" %} **When to perform these steps** * When creating a new asset * When adding new domains to an existing asset * When attaching a WAF SaaS profile to an asset that wasn’t previously protected * When editing a domain (remove the old one *after* adding and configuring the new one) {% endhint %} **Step 1: Prove Domain Ownership** This step authorizes **Check Point** to issue certificates for your domain using Let’s Encrypt. 1. In the Infinity Portal, go to **Policy → Profiles**. 2. Select the **Check Point WAF SaaS profile** created during the Asset setup. 3. Find the domain marked as “Pending Action” and click it. 4. Copy the **DNS CNAME record** shown under the domain ownership verification step. 5. In your DNS provider’s console, **add the CNAME record** with the name and value provided. {% hint style="warning" %} You must complete this step **for each domain** individually (e.g. `www.myapp.com` and `api.myapp.com`) {% endhint %}
**Step 2: Connect your domain to Check Point WAF SaaS** {% hint style="warning" %} Before performing this stage, disable any existing AWS CloudFront configuration for your website's address if you have any. {% endhint %} Once ownership is verified, a new **CNAME value** will be generated (this may take up to 30 minutes). 1. In your DNS configuration, replace the existing CNAME record for your domain with the **new CNAME value** issued by Check Poimt
. **Step 3: Allow Check Point WAF SaaS to Access Your Origin Server** To ensure smooth traffic flow between WAF SaaS and your internal web server: 1. **Allow incoming traffic** from the IP addresses provided in the **Check Point WAF SaaS deployment form**. 2. **Do not remove** existing access rules until: * 72 hours have passed (to allow full DNS propagation), and * You have confirmed successful traffic flow through WAF SaaS. {% hint style="info" %} If the origin was previously publicly accessible, restrict access to only WAF SaaS IPs after DNS switchover.\ If you were using another reverse proxy, consider removing its IPs from the access list after confirming the switch. {% endhint %} **Step 4: Test Access to Your Site** After completing the above steps: * Confirm that the website is reachable over HTTPS. * Verify that traffic is flowing through WAF SaaS (you can check headers or logs in the Infinity Portal). * Double-check that your origin server is **no longer publicly accessible** (unless intentionally exposed). {% hint style="info" %} While DNS changes typically take just a few hours, allow up to **72 hours** for full global propagation before making final changes. {% endhint %} {% hint style="danger" %} Make sure you have not left a publicly exposed domain in your previous environment! {% endhint %} #### Certificate Reuse When you onboard a new domain that's already covered by an existing wildcard certificate, WAF SaaS automatically attaches that certificate instead of issuing a new one — onboarding completes immediately instead of waiting on issuance and validation. #### Switching Certificate Types On an existing domain's **Certificates & Domain Management** panel, you can switch between **Certificates managed by Check Point** (Wildcard or Specific) and **My certificates** (BYOC) at any time. The previous certificate stays active until the new one is validated, so there is no downtime during the switch. #### Renewal Check Point-managed certificates are renewed automatically before they expire, provided the DNS ownership CNAME record added in Step 1 remains in place in your DNS provider's records. If that record is removed, automatic renewal will fail and the certificate must be restored manually. # Bring Your Own Certificate (BYOC) While Check Point WAF SaaS offers managed public SSL/TLS certificates signed by Let’s Encrypt, you may choose to use your **own certificate and private key**—ideal for compliance needs or existing certificate infrastructure. {% hint style="success" %} Your private key is **end-to-end encrypted** during upload, ensuring complete confidentiality and security. {% endhint %} To configure HTTPS traffic with your own certificates, follow the steps below: **Step 1: Upload Certificate and Private Key** 1. In the Infinity Portal, navigate to **Policy → Profiles**. 2. Select the **Check Point WAF SaaS profile** linked to your asset. 3. For each domain listed, click on it and: * Upload the **public certificate** (PEM format) * Upload the **private key** * Ensure the certificate includes the **full chain** * Extra attributes or text outside the PEM block are not allowed {% hint style="info" %} This process must be repeated for **each domain**, e.g., `www.myapp.com` and `api.myapp.com`. {% endhint %} **Step 2: Connect your domain to WAF SaaS** {% hint style="warning" %} Before performing this stage, disable any existing AWS CloudFront configuration for your website's address if you have any. {% endhint %} Once the environment is ready, a **CNAME value** will be generated for your domain (this may take up to 30 minutes). 1. In your DNS provider’s configuration, **replace the existing CNAME record** with the new value provided by CloudGuard. Once DNS records have propagated, your domain’s traffic will flow through WAF SaaS and be securely routed to your internal web server. **Step 3:** **Allow WAF SaaS to Access Your Origin Server** To ensure smooth traffic flow between WAF SaaS and your internal web server: 1. **Allow incoming traffic** from the IP addresses provided in the **WAF SaaS deployment form**. 2. **Do not remove** existing access rules until: * 72 hours have passed (to allow full DNS propagation), and * You have confirmed successful traffic flow through WAF SaaS. {% hint style="info" %} If the origin was previously publicly accessible, restrict access to only WAF SaaS IPs after DNS switchover.\ If you were using another reverse proxy, consider removing its IPs from the access list after confirming the switch. {% endhint %} **Step 4: Test access to your site** After completing the above steps: * Confirm that the website is reachable over HTTPS. * Verify that traffic is flowing through WAF SaaS (you can check headers or logs in the Infinity Portal). * Double-check that your origin server is **no longer publicly accessible** (unless intentionally exposed). {% hint style="danger" %} Make sure you have not left a publicly exposed domain in your previous environment! {% endhint %} #### Reusing an Uploaded Certificate Instead of uploading a new certificate for every domain, select **My certificates** in a domain's **Certificates & Domain Management** panel to open **Select Certificate** — a list of certificates you've already uploaded, showing each one's name, type (Specific/Wildcard), and expiration date. From here you can select an existing certificate to attach to this domain, upload a new one, or delete a certificate you no longer need. #### Switching Certificate Types You can switch a domain from BYOC to a Check Point-managed certificate (or vice versa) at any time, with no downtime — the previous certificate stays active until the new one validates. #### Renewal — Important {% hint style="warning" %} Unlike Check Point-managed certificates, BYOC certificates are not auto-renewed. As a certificate approaches expiration, the portal displays a live countdown warning (e.g. "This certificate will not be auto-renewed. Please renew it within the next N days."). Renew and re-upload your certificate before it expires to avoid a validation failure or downtime. {% endhint %} # Integrating WAF SaaS with AWS CloudFront This guide walks you through integrating the Check Point WAF with your existing AWS CloudFront distribution. {% hint style="danger" %} The WAF must be deployed *after* CloudFront, since CloudFront is the entry point exposed to the public internet. {% endhint %} ### Prerequisites Before starting, make sure you have: * An active **Check Point WAF subscription** with access to the WAF management UI. * An existing **AWS CloudFront distribution** configured with your domain. * Access to **update your DNS records**. ### Deployment #### 1. Deploy WAF SaaS Follow the instructions bellow: {% content-ref url="/pages/vEPYjTAMpjJWA0oAZhy2" %} [WAF-as-a Service (WAF SaaS)](/concepts/waf-as-a-service-waf-saas) {% endcontent-ref %} in step 1 (Define the website you want to protect) - make sure to input * Enter the **public URLs** (e.g. `www.example.com`) * Use the **internet-facing domain**, not the CloudFront domain. * Provide the **upstream origin URL** (e.g. your CloudFront origin) * Do **not** set the upstream server as CloudFront — this is a common mistake.
*** #### 2. Copy the WAF DNS Endpoint Once the asset has been created the WAF will provides a **WAF DNS endpoint** (e.g., `xxxx.checkpoint.com`).
#### 3. Update CloudFront Configuration - Review Current Origin (Before Change) 1. Open your CloudFront distribution in the **AWS Console**. 2. Under **Origins**, review the current configuration (typically pointing to your application server or load balancer). #### 4. Update CloudFront Configuration - Change Origin to WAF 1. Edit the **origin configuration**. 2. Set the **Origin Domain Name** to the **WAF DNS endpoint** from Step 2.2. 3. Save changes.
#### 5. Deploy and Verify Changes After saving, CloudFront will redeploy with the new settings. Once deployed, traffic will flow: ``` Internet → CloudFront → WAF → Application Origin ``` #### 6. DNS Considerations * If **DNS already points to CloudFront** (recommended), no changes are needed. * If DNS was pointing **directly to your origin**, update it to point to the **CloudFront distribution domain**. #### 7. Validation 1. Visit your domain (e.g., `https://www.example.com`). 2. In the **WAF logs**, confirm that requests are reaching the WAF. You have successfully integrated Check Point WAF with CloudFront. # Configure CDN Caching ### Overview CDN caching enables you to control how your web application assets are cached at the edge. By defining caching parameters and applying them to specific URL paths, you can: * Reduce origin load * Improve response latency * Control cache freshness CDN caching is configured per asset using a **CDN Caching practice** and **Caching Configuration parameters**, available via the **CDN Caching tab** in the asset view. {% hint style="info" %} Available only for assets associated with a WAF SaaS profile.\ If no WAF SaaS profile is attached, the CDN Caching tab displays a placeholder indicating that the feature is available only for assets with WAF SaaS profile. {% endhint %} {% hint style="info" %} **Planned Enhancements:** * Path-based invalidation * Improved invalidation status visibility * Cache monitoring (hit/miss ratio insights) If you're interested in any of the enhancements reach out to your check point contact {% endhint %} #### **Limitations:** * Assets sharing the same domain must use identical caching configuration if CDN caching is enabled on more than one of them * Two parameters within the same practice cannot define identical path patterns * Root domains are currently not supported * Only HTTPS (port 443) is supported * Non-standard ports are not supported ### Configuration #### Prerequisites * Completed domain deployment * WAF SaaS profile attached to the asset #### Enable CDN Caching CDN caching can be configured either during asset creation or on an existing asset. * During asset creation: CDN caching can be enabled as part of the setup wizard.\ When enabled, the created asset is automatically associated with a default CDN Caching practice, including predefined caching parameters. * **Default Caching Parameters:** * System-defined and **read-only** * Cannot be edited * Can be removed from a practice * Additional parameters can be created and added * For an existing asset with a WAF SaaS profile, navigate to the CDN Caching tab to create a new practice and define or attach caching parameters. CDN caching is managed using **practices** and **parameters**: * **Practice:** controls whether CDN caching is enabled * **Parameter:** defines how requests matching specific paths are cached ### Practice
Each Practice includes: * **Parameters** – Name of the caching parameters * **Paths** – URL patterns matched by the parameter * **Caching Policy** – Defines TTL and cache key behavior * **Used By** – Number of assets using this parameter The toolbar allows creating, editing, and removing parameters. ### Parameter
Each parameter includes: * **Name** * **Paths** – URL path patterns * **Caching Policy** - Cache behavior settings, including: * TTL * Headers * Query strings * Cookies Each Parameter also offers a "Used By" view, which indicates by what assets and domain it is used and also allows direct navigation to each asset.
Path Matching Path matching is based on pattern matching. * Matching is case-sensitive * A leading `/` is optional and implicitly assumed ### Supported Wildcards * `*` — matches 0 or more characters * `?` — matches exactly 1 character ### Examples | | | | ------------ | ------------------ | | `/images/*` | `/images/logo.png` | | `*.jpg` | `image.jpg` | | `/file?.txt` | `/file1.txt` | | `/api/v1/*` | `/api/v1/users` | #### Additional Constraints * Maximum pattern length is 255 characters * Patterns are case-sensitive (e.g., `*.jpg` does not match `LOGO.JPG`) * Supported Characters: `_ - . * $ / ~ " ' @ : + &` #### Most Specific Match Wins When multiple parameters match a request, the most specific path pattern is applied. More specific patterns: * Match a narrower set of requests * Contain fewer wildcards * Include longer or more detailed paths #### Example Parameters: * `/a/*` * `/a/b/*` Request:\ /a/b/file.png → `/a/b/*` is applied #### Example Parameters: * `*.jpg` * `/images/*.jpg` Request:\ /images/logo.jpg → `/images/*.jpg` is applied > Evaluation is based on specificity, even if parameters are displayed alphabetically in the UI.
Caching Policy Caching policies define how responses are cached. #### TTL (Time to Live) TTL determines how long a response is cached. * Default TTL is used when no caching headers are present * Minimum TTL enforces a lower bound * Maximum TTL enforces an upper bound TTL works together with response headers to determine the final cache duration. #### Cache Key The cache key determines whether requests are treated as identical or different. It is based on selected request attributes such as: * Headers * Query strings * Cookies #### Key Behavior * If a value is **included** in the cache key → requests with different values are cached separately * If a value is **ignored** → requests are treated as identical for caching purposes #### Example If query strings are ignored: * `/image.png?size=small` * `/image.png?size=large` → Both requests may use the same cached response If query strings are included:\ → Each variation may create a separate cache entry Choosing fewer attributes increases cache hit ratio, while including more attributes increases granularity. #### Cache Hit vs Miss Cache behavior can be inspected using tools such as `curl` by checking response headers. For example: curl -I Depending on the environment and configuration, response headers may indicate whether the response was served from cache or fetched from the origin.
#### Sharing Parameters Across Practices * Default parameters cannot be edited * The **Used By** view provides visibility into all usages **Additional Notes:** * A parameter can be used in multiple practices * Changes affect all usages * Removing a parameter from a practice does not delete it Caching parameters are reusable across multiple practices and assets. ### Cache Invalidation
* Executed asynchronously * Applied per domain * May take several minutes Cache invalidation forces cached content to be refreshed. {% hint style="info" %} Cache invalidation is currently available via UI only {% endhint %}
CDN API CDN caching configuration is available via the GraphQL API. You can: * Create and update caching practices * Create and update caching parameters {% hint style="info" %} Cache invalidation is not currently available via the API {% endhint %} #### API Access The API can be accessed using GraphQL clients (such as Postman), or via the Infinity Portal: #### Available Operations #### Queries * Query.getCachingConfigurationParameter * Query.getAllCachePolicies * Query.getCachingPractice #### Mutations * Mutation.newCachingConfigurationParameter * Mutation.updateCachingConfigurationParameter * Mutation.newCachingPractice * Mutation.updateCachingPractice
# Kubernetes ## Overview CloudGuard WAF for Kubernetes protects vulnerable applications and APIs running in Kubernetes environments. It integrates with the most popular [NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx), [Kong Ingress Controller](https://github.com/Kong/kubernetes-ingress-controller), and as well as Istio Ingress Controller, and serves as a secure HTTP/S load balancer for one or more [Services](https://kubernetes.io/docs/concepts/services-networking/service/) inside Kubernetes [clusters](https://kubernetes.io/docs/concepts/architecture/). **For Kong and Istio dedicated instructions, click here:** {% content-ref url="/pages/7ShXYDMIRmJzDB5guMhN" %} [NGINX Application Security](/getting-started/deploy-enforcement-point/kubernetes/nginx-application-security) {% endcontent-ref %} {% content-ref url="/pages/xnZjSrWpwh4dnB3hdV1v" %} [Kong Application Security](/getting-started/deploy-enforcement-point/kubernetes/kong-application-security) {% endcontent-ref %} {% content-ref url="/pages/dzBAN1gbjM4rR7XU0gzJ" %} [Istio Application Security](/getting-started/deploy-enforcement-point/kubernetes/istio-application-security) {% endcontent-ref %} {% content-ref url="/pages/SOPaCmd2FkrjlvVpBHE1" %} [Envoy Application Security (Injector)](/getting-started/deploy-enforcement-point/kubernetes/envoy-application-security-injector) {% endcontent-ref %} {% hint style="info" %} Kubernetes [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) exposes HTTP/S routes from outside the cluster to [services](https://kubernetes.io/docs/concepts/services-networking/service/) within the cluster. Traffic routing is controlled by rules defined on the Ingress resource. {% endhint %} # Kong Application Security The Kong Ingress controller and CloudGuard WAF for Kubernetes agent are deployed together with a single Helm chart. The configuration of the Kong Ingress controller is done with common methods for configuring Ingress using both Kubernetes Ingress resources or Kong Ingress resources. This diagram shows an example of a Kubernetes service exposed outside the Kubernetes cluster with an Kong Ingress controller protected with CloudGuard WAF.
## Prerequisites * Kong version 1.22.0+ cluster with [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) enabled with Cluster admin permissions * [Helm 3 Package Manager](https://helm.sh/docs/intro/install/) installed on your local machine * The `kubectl` and `wget` command-line tools installed on your bastion or platform that you use to access the Kubernetes cluster ## Installation #### Step 1: Download Helm chart Run the following command depending on your Kubernetes version: `wget https://github.com/CheckPointSW/Infinity-Next/raw/main/deployments/cp-k8s-appsec-kong-2.22.0.tgz -O cp-k8s-appsec-kong-2.22.0.tgz` #### Step 2: Install Helm chart Make sure you obtained the token from the [Enforcement Profile](/getting-started/deploy-enforcement-point) page first, you will need it in the command to deploy the Helm chart. {% hint style="info" %} Obtain the \ from the **Profile** page, **Authentication** section. ![](/files/tAyti9aG3utyFHls2McN) {% endhint %} Run the following command depending on your Kubernetes version (**Note** - package file names contain the name appsec - short for "Application Security" provided by CloudGuard WAF): `helm install cp-k8s-appsec-kong-2.22.0.tgz --name-template cp-appsec --set appsec.agentToken="" --create-namespace -n kong` #### Step 3: Create SSL/TLS Secret (optional if the servers do not use HTTPS) Kubernetes Secrets are used for TLS termination of the Ingress resource. The public/private key pair must already exist before creating the Secret. Read more about Kubernetes TLS Secrets in the [Official Kubernetes Documentation](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets). Create a Kubernetes SSL/TLS Secret using the following command with the public key certificate for `--cert` .PEM-encoded and matching the private key for `--key`: `kubectl create secret tls --key --cert $` #### Step 4: Configure the Ingress resource 1. Edit your ingress.yaml with your favorite editor 2. If needed add the following annotation: `kubernetes.io/ingress.class: "nginx"`
ingress.yaml example The ingress.yaml in this example exposes two Kubernetes Services in the 'applications-ns' namespace: * portal-svc (port 8080) exposed through portal.acme.com on port 443 * api-svc (port 80) exposed through api.acme.com on port 80 ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress namespace: applications-ns annotations: kubernetes.io/ingress.class: "nginx" spec: tls: - hosts: - portal.acme.com secretName: tls rules: - host: portal.acme.com http: paths: - path: / pathType: Prefix backend: service: name: portal-svc port: number: 8080 - host: api.acme.com http: paths: - path: / pathType: Prefix backend: service: name: api-svc port: number: 80 ```
#### Step 5: Deploy the Ingress In environments that can allow short downtime, uninstall the older ingress and install the new one. `kubectl apply -f ingress.yaml` In environments that require zero-downtime: 1. Redirect your DNS traffic from the old ingress to the new ingress 2. Log traffic from both controllers during this changeover 3. Uninstall the old ingress once traffic has fully drained from it # Kong Application Security Using Lua PlugIn CloudGuard WAF for Kong is deployed using a Helm chart that includes a namespace-level webhook. This webhook monitors changes to the Kong IngressGateway deployment and automatically adds the necessary agent and attachment to the deployment. The configuration of the Kong Ingress controller follows standard practices for setting up gateway and virtual service resources to expose your applications. This diagram shows an example of a Kubernetes service exposed outside the Kubernetes cluster with an Istio Ingress controller protected with CloudGuard WAF.
## Prerequisites * Kong version 1.22.0+ cluster with [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) enabled with Cluster admin permissions * [Helm 3 Package Manager](https://helm.sh/docs/intro/install/) installed on your local machine * The `kubectl` and `wget` command-line tools installed on your bastion or platform that you use to access the Kubernetes cluster ## Installation #### Step 1: Update your Helm chart to use the Kong image that includes the open-appsec plugin: Add the following section to your helm install or upgrade command, do update your Kong helm chart. For Kong OSS: ``` --set image.repository=checkpoint/infinity-next-kong-k8s-plugin --set image.tag=latest ``` For Kong Enterprise Gateway: ``` --set image.repository=checkpoint/infinity-next-kong-gateway-k8s-plugin \ --set image.tag=latest ``` #### Step 2: Create a Kong Plugin and apply a resource to activate the plugin: ``` apiVersion: configuration.konghq.com/v1 kind: KongPlugin metadata: name: cloudguard-waf-kong-plugin config: {} plugin: cloudguard-waf-kong-plugin ``` ``` kubectl apply -f cloudguard-waf-kong-plugin.yaml -n ``` #### Step 3: Deploy the CloudGuard WAF Helm Chart: ``` helm install cloudguard-waf-injector \ oci://registry-1.docker.io/checkpoint/cloudguard-waf-injector \ --version \ --set webhook.objectSelector.labelName="app.kubernetes.io/name" \ --set webhook.objectSelector.labelValue=kong \ --set kind=kong \ --set appsec.persistence.enabled=false \ --set appsec.agentToken= \ -n ``` Make sure you obtained the token from the [Enforcement Profile](/getting-started/deploy-enforcement-point) page first, you will need it in the command to deploy the Helm chart. {% hint style="info" %} Replace \ with the latest tag in this repository - {% endhint %} {% hint style="info" %} Obtain the \ from the **Profile** page, **Authentication** section. ![](/files/tAyti9aG3utyFHls2McN) {% endhint %} #### Step 4: Label your namespace and deployment: CloudGuard WAF webhook will function only when this flag is added to the Kong Ingress Controller environment. To add the flag, run the following command: ``` kubectl label namespace inject-waf-attachment="true" --overwrite kubectl label deployment app.kubernetes.io/name=kong --overwrite ``` Restart your ingress gateway deployment: ``` kubectl rollout restart deployment -n ``` # Istio Application Security {% hint style="warning" %} This feature is currently in Early Availability and is available only upon request from the local Check Point team. {% endhint %} CloudGuard WAF for Istio is deployed using a Helm chart that includes a namespace-level webhook. This webhook monitors changes to the Istio IngressGateway deployment and automatically adds the necessary agent and attachment to the deployment. The configuration of the Istio Ingress controller follows standard practices for setting up gateway and virtual service resources to expose your applications. This diagram shows an example of a Kubernetes service exposed outside the Kubernetes cluster with an Istio Ingress controller protected with CloudGuard WAF.
## Prerequisites * Istio version 1.20.0+ cluster * [Helm 3 Package Manager](https://helm.sh/docs/intro/install/) installed on your local machine * The `kubectl` and `wget` command-line tools installed on your bastion or platform that you use to access the Kubernetes cluster ## Installation #### Step 1: Download Helm chart Run the following command: `wget https://cloudguard-waf.i2.checkpoint.com/downloads/helm/cloudguard-waf-istio.tgz` {% hint style="info" %} The webhook only manages deployment in the same namespace where it is installed, so it should be deployed on the relevant istio-ingress gateway namespace. Note to change the <`ingress-gateway namespcae`> to the relevant one. {% endhint %} #### Step 2: Install Helm chart Make sure you obtained the token from the [Enforcement Profile](/getting-started/deploy-enforcement-point) page first, you will need it in the command to deploy the Helm chart. {% hint style="info" %} Obtain the \ from the **Profile** page, **Authentication** section. ![](/files/tAyti9aG3utyFHls2McN) {% endhint %} Run the following command: ``` helm install cloudguard-waf-istio.tgz \ --name-template cloudguard-waf-istio \ -n \ --set token= \ --set webhook.objectSelector.labelValue=istio-ingress \ --set webhook.objectSelector.labelName=app \ ``` #### Step 3: Add the CloudGuard WAF label to your ingress-gateway namespace CloudGuard WAF webhook will function only when this flag is added to the Istio Ingress Controller environment. To add the flag, run the following command: ``` kubectl label namespace inject-waf-attachment="true" --overwrite ``` #### Step 4: Restart your ingress gateway deployment Run the following command: ``` kubectl rollout restart deployment -n ``` ## Un-Installation In order to remove the CloudGuard WAF Nano Agent from your Istio Ingress Controller, follow these steps. #### Step 1: Remove Helm chart Run the following command: ``` helm upgrade --reuse-values --set removeWaf=true cloudguard-waf-istio ./cloudguard-waf-istio.tgz -n ``` **Step 2: Remove the CloudGuard WAF label from your ingress-gateway namespace** Run the following command: ``` kubectl label namespace inject-waf-attachment ``` #### Step 3: Restart your ingress gateway deployment Run the following command: ``` kubectl rollout restart deployment istio-ingressgateway -n ``` # NGINX Application Security {% hint style="warning" %} **Update on Ingress NGINX Retirement and CloudGuard WAF Migration Options** With the recent announcement about the retirement of Ingress NGINX on Kubernetes, we want to clarify how this affects existing CloudGuard WAF + Ingress NGINX deployments. While Ingress NGINX will receive best-effort maintenance only until **March 2026**, CloudGuard WAF will continue to provide updated Helm charts and full support for as long as new Ingress NGINX Helm charts are available. However, because long-term updates are not guaranteed, we recommend planning a transition to a supported Gateway API–based solution. **Compatibility When Using theManagement UI** Management UI remain fully compatible with Gateway API–based ingress solutions and other Kubernetes APIs, as all CloudGuard WAF configuration is performed centrally and does not depend on the specific ingress controller. **Supported Gateway API Solutions** Cloud Guard already integrates with several ingress/gateway controllers: * **Kong API Gateway** — Supported via Helm + Webhook integration. * **Istio Ingress Gateway** — Supported via Helm + Webhook integration. We continue to evaluate additional gateway and ingress solutions. Please don't hesitate to reach out to Check point Support for any suggestions or requests. {% endhint %} The NGINX Ingress controller and CloudGuard WAF for Kubernetes agent are deployed together with a single Helm chart. The configuration of the NGINX Ingress controller is done with common methods for configuring Ingress using both Kubernetes Ingress resources or NGINX Ingress resources. This diagram shows an example of a Kubernetes service exposed outside the Kubernetes cluster with an Ingress controller protected with CloudGuard WAF. ![](/files/HCaQbP5T7NkqNRNlsnON) ## Prerequisites * AWS Elastic Kubernetes Service (EKS) or Azure Kubernetes Service (AKS) * For an NGINX-based ingress controller: Kubernetes 1.16.0+ cluster with [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) enabled with Cluster admin permissions * [Helm 3 Package Manager](https://helm.sh/docs/intro/install/) installed on your local machine * The `kubectl` and `wget` command-line tools installed on your bastion or platform that you use to access the Kubernetes cluster ## Installation #### Step 1: Download Helm chart Run the following command depending on your Kubernetes version: {% tabs %} {% tab title="1.19.0 and above " %} `wget https://cloudguard-waf.i2.checkpoint.com/downloads/helm/ingress-nginx/cp-k8s-appsec-nginx-ingress-4.12.1.tgz -O cp-k8s-appsec-nginx-ingress-4.12.1.tgz` {% endtab %} {% tab title="1.16.0 - 1.18.20" %} `wget https://cloudguard-waf.i2.checkpoint.com/downloads/helm/ingress-nginx/cp-k8s-appsec-nginx-ingress-3.35.0.tgz -O cp-k8s-appsec-nginx-ingress-3.35.0.tgz` {% endtab %} {% endtabs %} #### Step 2: Install Helm chart Make sure you obtained the token from the [Enforcement Profile](/getting-started/deploy-enforcement-point) page first, you will need it in the command to deploy the Helm chart. {% hint style="info" %} Obtain the \ from the **Profile** page, **Authentication** section. ![](/files/tAyti9aG3utyFHls2McN) {% endhint %} Run the following command depending on your Kubernetes version (**Note** - package file names contain the name appsec - short for "Application Security" provided by CloudGuard WAF): {% tabs %} {% tab title="1.19.0 and above" %} `helm install cp-k8s-appsec-nginx-ingress-4.12.1.tgz --name-template cp-appsec`\ `--set appsec.agentToken=""` {% endtab %} {% tab title="1.16.0 - 1.18.20" %} `helm install cp-k8s-appsec-nginx-ingress-3.35.0.tgz --name-template cp-appsec`\ `--set appsec.agentToken=""` {% endtab %} {% endtabs %} #### Step 3: Create SSL/TLS Secret (optional if the servers do not use HTTPS) Kubernetes Secrets are used for TLS termination of the Ingress resource. The public/private key pair must already exist before creating the Secret. Read more about Kubernetes TLS Secrets in the [Official Kubernetes Documentation](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets). Create a Kubernetes SSL/TLS Secret using the following command with the public key certificate for `--cert` .PEM-encoded and matching the private key for `--key`: `kubectl create secret tls --key --cert $` #### Step 4: Configure the Ingress resource 1. Edit your ingress.yaml with your favorite editor 2. If needed add the following annotation: `kubernetes.io/ingress.class: "nginx"`
ingress.yaml example The ingress.yaml in this example exposes two Kubernetes Services in the 'applications-ns' namespace: * portal-svc (port 8080) exposed through portal.acme.com on port 443 * api-svc (port 80) exposed through api.acme.com on port 80 ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress namespace: applications-ns annotations: kubernetes.io/ingress.class: "nginx" spec: tls: - hosts: - portal.acme.com secretName: tls rules: - host: portal.acme.com http: paths: - path: / pathType: Prefix backend: service: name: portal-svc port: number: 8080 - host: api.acme.com http: paths: - path: / pathType: Prefix backend: service: name: api-svc port: number: 80 ```
#### Step 5: Deploy the Ingress In environments that can allow short downtime, uninstall the older ingress and install the new one. `kubectl apply -f ingress.yaml` In environments that require zero-downtime: 1. Redirect your DNS traffic from the old ingress to the new ingress 2. Log traffic from both controllers during this changeover 3. Uninstall the old ingress once traffic has fully drained from it # Envoy Application Security (Injector) CloudGuard WAF for Envoy Gateway is deployed using a Helm chart that includes a namespace-level webhook. This webhook monitors changes to the Envoy Gateway deployment and automatically injects the required WAF agent and attachment into the gateway pods. The configuration of Envoy Gateway follows standard practices for defining gateway resources and routing traffic to your services.
### Prerequisites * Envoy Gateway deployed in your Kubernetes cluster * Envoy image must use: `envoyproxy/envoy:contrib-` Kubernetes cluster with RBAC enabled and cluster-admin permissions * Helm 3 installed on your local machine * kubectl installed and configured to access your cluster * A profile created in the CloudGuard UI with the agent token copied and policy set to **Enforce** ### Installation #### Step 1 – Create profile and copy token Create any profile in the CloudGuard UI, copy the agent token, and ensure the policy is set to **Enforce**. ### Installation #### Step 1 – Create profile and copy token Create any profile in the CloudGuard UI, copy the agent token, and ensure the policy is set to **Enforce**. #### Step 2 – Label the gateway namespace ``` kubectl label namespace inject-waf-attachment="true" --overwrite ``` #### Step 3 – Label the Deployment Ensure your Envoy Gateway Deployment includes the labels required by the webhook.objectSelector: * webhook.objectSelector.labelName * webhook.objectSelector.labelValue Example: ``` kubectl label deployment