1. Overview

WAAS (Web-Application and API Security) can secure both containerized and non-containerized web applications. To deploy WAAS, create a new rule, and declare the entity to protect.

Although the deployment method varies slightly depending on the type of entity you’re protecting, the steps, in general, are:

  1. Define rule resource.

  2. Define application scope.

  3. Enable relevant protections.

2. Understanding WAAS rule resources and application scope

The WAAS rule engine is designed to let you tailor the best-suited protection for each part of your deployment. Each rule has two scopes:

  • Rule resources.

  • Application list.

2.1. Rule Resources

This scope defines, for each type of deployment, a combination of one or more elements to which WAAS should attach itself in order to protect the web application:

  • For containerized applications - Containers, images, namespaces, cloud account IDs, hosts.

  • For non-containerized applications - Host on which the application is running.

  • For containers protexted with App-Embedded Defender - App ID.

  • For serverless functions - Function name.

2.2. Application List

This scope defines the protected application’s endpoints within the deployment as a combination of one or more of the following:

  • Port (Required) - For containerized applications, the internal port on which the application is listening. For all other types, the externally facing port.

  • HTTP hostname - Default setting is set to * (wildcard indicating all hostnames)

  • Base path - Lets you apply protection policy on certain paths of the application (e.g. "/admin", "/admin/*", etc.)

  • TLS - TLS certificate to be used when expecting encrypted inbound traffic.

To better illustrate, consider the following deployment scenario for a web application running on-top of an NGINX cluster:

cnaf deployment example

In this example, different policies apply for different parts of the application. The steps for deploying a WAAS rule to protect the above described web application would be as follows:

  1. Define rule resources - The rule will apply to all containers created from the nginx image.

    waas rule scope
  2. Define protection policy for 'login', 'search' and 'product' endpoints - Set OWASP Top 10 protection to "Prevent" and geo-based access control to "Alert".

  3. Define protection policy for the application’s API endpoints - Set OWASP Top 10 and API protection to "Prevent" and HTTP header-based access control to "Alert".

Once the policy is defined, the rule overview shows the following rule resource and application definitions:

waas rule example
  • Rule Resources - Protection is applied to all NGINX images

  • Apps List - We deployed two policies each covering a different endpoint in the application (defined by HTTP hostname, port and path combinations)

3. Deploying WAAS

3.1. Deploying WAAS for Containers

To deploy WAAS for containerized web applications, create a new rule, specify the image name, define application endpoints and select protections. WAAS only needs to be applied to images that transmit and receive HTTP/HTTPS traffic.

  1. Open Console, and go to Defend > WAAS.

  2. Select the Container tab.

    waas deployment types
  3. Click Add Rule.

  4. Enter a Rule Name and Notes (Optional) for describing the rule.

  5. Define Rule Resources.

    The rule resource section defines for each type of deployment a combination of image names and one or more elements to which WAAS should attach itself in order to protect the web application:

    cnaf container rule resources
    Applying a rule to all images using a wild card (*) is invalid - instead, only specify your web application images.
  6. Click Add New App.

  7. In the App Definition tab, specify the endpoints in your web application that should be protected. Each defined application can have multiple protected endpoints. If you have a Swagger or OpenAPI file, click Import, and select the file to load. Otherwise, skip to the next step to manually define your application’s endpoints.

    cnaf import swagger
  8. If you do not have a Swagger or OpenAPI file, manually define each endpoint by specifying the host, port, and path.

    1. In the General App Setup tab, click Add Endpoint.

      cnaf add endpoint
    2. Specify endpoint details:

      waas endpoint lineitem
    3. Enter Port (required)

      Specify the TCP port listening for inbound HTTP traffic.

    4. Enter HTTP Hostname (optional, wildcards supported).

      HTTP host names are specified in the form of [hostname]:[external port].

      External port is defined as the TCP port on the host, listening for inbound HTTP traffic. If the the value of the external port is "80" for non-TLS endpoints or "443" for TLS endpoints it can be omitted. Examples: "*.example.site", "docs.example.site", "www.example.site:8080", etc.

    5. Enter Path (optional, wildcards supported):

      Base path for WAAS to match on, when applying protections.

      Examples: "/admin", "/" (root path only), "/*", /v2/api", etc.

    6. If your application uses TLS, set TLS to On. WAAS must be able to decrypt and inspect HTTPS traffic to function properly. To facilitate that, after creating all endpoints, upload your server’s certificate and private key - concatenate public cert and private key (e.g. cat server-cert.pem server-key > certs.pem).

    7. If your application uses HTTP/2, set HTTP/2 to On.

    8. Click Create Endpoint

    9. If your application requires API Protection, select the "API Protection" tab and define for each path allowed methods, parameters, types, etc. See detailed definition instructions in the API Protection section below.

  9. Continue to App Firewall tab, select WAAS protections to enable and assign them with WAAS Actions.

  10. Continue to Access Control tab and select WAAS Access Controls to enable.

  11. Click Save.

  12. You should be redirected to the Rule Overview page.

    Select the created new rule to display Rule Resources and for each application a list of protected endpoints and enabled protections.

    waas rule overview
  13. Test protected endpoint using the following cURL Test Commands

3.2. Deploying WAAS for hosts

To deploy WAAS to protect a host running a non-containerized web application, create a new rule, specify the host(s) where it run, define application endpoints and select protections.

  1. Open Console, and go to Defend > WAAS.

  2. Select the Host tab

    waas deployment types host
  3. Click Add Rule.

  4. Enter a Rule Name and Notes (Optional) for describing the rule.

  5. Define Rule Resources.

    The rule resource section defines the hosts to which WAAS should attach itself in order to protect the web application:

    cnaf host rule resources
    Applying a rule to all hosts using a wild card (*) is invalid and a waste of resources. WAAS only needs to be applied to hosts that run applications that transmit and receive HTTP/HTTPS traffic.
  6. Click Add New App.

  7. In the App Definition tab, specify the endpoints in your web application that should be protected. Each defined application can have multiple protected endpoints. If you have a Swagger or OpenAPI file, click Import, and select the file to load. Otherwise, skip to the next step to manually define your application’s endpoints.

    cnaf import swagger
  8. If you don’t have a Swagger or OpenAPI file, manually define each endpoint by specfying the host, port, and path.

    1. In the General App Setup tab, click on Add Endpoint

      cnaf add endpoint
    2. Specify endpoint details:

      waas endpoint lineitem
    3. Enter Port (required).

      Specify TCP port, in the container, listening for inbound HTTP traffic

    4. Enter HTTP Hostname (optional, wildcards supported).

      HTTP host names are specified in the form of [hostname]:[external port].

      External port is defined as the TCP port on the host, listening for inbound HTTP traffic. If the value of the external port is "80" for non-TLS endpoints or "443" for TLS endpoints it can be omitted. Examples: "*.example.site", "docs.example.site", "www.example.site:8080", etc.

    5. Enter Path (optional, wildcards supported):

      Base path for WAAS to match on when applying protections.

      Examples: "/admin/", "/" (root path only), "/*", /v2/api/", etc.

    6. If your application uses TLS, set TLS to On. WAAS must be able to decrypt and inspect HTTPS traffic to function properly. To facilitate that, after creating all endpoints, upload your server’s certificate and private key - concatenate public cert and private key (e.g. cat server-cert.pem server-key > certs.pem).

    7. If your application uses HTTP/2, set HTTP/2 to On.

    8. Click Create Endpoint

    9. If your application requires API Protection, select the "API Protection" tab and define for each path allowed methods, parameters, types, etc. See detailed definition instructions in the API Protection section below.

  9. Continue to App Firewall tab, select WAAS protections to enable and assign them with WAAS Actions.

  10. Continue to Access Control tab and select WAAS Access Controls to enable.

  11. Click Save.

  12. You should be redirected to the Rule Overview page.

    Select the created new rule to display Rule Resources and for each application a list of protected endpoints and enabled protections.