Deploying WAAS

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.

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.

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 protected with App-Embedded Defender
    - App ID.
  • For serverless functions
    - Function name.
In the event of scope overlap (when multiple rules are applied to the same resource scope), the first rule by order will apply and all others will not apply. You can reorder rules via the
Order
column in WAAS rule tables by dragging and dropping rules.

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:
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
    - Specify the resource collection the rule applies to. Collections are comprised of image names and one or more elements to which WAAS should attach itself in order to protect the web application. In the following example, the rule will apply to all containers created by the nginx image. 
  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:
  • 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)

Protection evaluation flow

WAAS offers a range of protection targeted at different attack vectors. Requests inspected by WAAS will be inspected in the following order of protections:
  • Bot protection
  • App firewall (OWASP Top-10)
  • API protection
  • DoS protection
WAAS will continue to inspect a request until "Prevent" or "Ban" actions are triggered, at which point the request will be blocked, and the evaluation flow will be halted.
For instance, assume all protections in bot protection are set to "Prevent". An incoming request originating from a bot and containing a SQL injection payload would be blocked by the bot protection (since it precedes the app firewall in the evaluation flow), and the SQL injection payload will not be assessed by the app firewall.
In a different scenario, suppose that all bot protections are set to "Alert" and all app firewall protections are set to "Prevent". A request originating from a bot containing a command injection payload will generate an alert event by bot protection and will be blocked by the app firewall protection.

Deploying WAAS

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 receive HTTP/HTTPS traffic.
  1. Open Console, and go to
    Defend > WAAS
    .
  2. Select the
    Container
    tab.
  3. Click
    Add Rule
    .
  4. Enter a
    Rule Name
    and
    Notes
    (Optional) for describing the rule.
  5. Choose the rule
    Scope
    by specifying the resource collection(s) to which it applies.
    Collections define a combination of image names and one or more elements to which WAAS should attach itself in order to protect the web application:
    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.
  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
      .
    2. Specify endpoint details:
    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 the allowed methods, parameters, types, etc. See detailed definition instructions in the API protection help page.
  9. Continue to
    App Firewall
    tab, select protections to enable and assign them with WAAS Actions.
  10. Continue to
    Access Control
    tab and select access controls to enable.
  11. Continue to
    DoS protection
    tab and configure DoS protection thresholds.
  12. Continue to
    Bot protection
    tab and select bot protections to enable.
  13. Click
    Save
    .
  14. 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
    .
  15. Test protected endpoint using the following sanity tests.
  16. Go to
    Monitor > Events
    , click on
    WAAS for containers
    and observe events generated.
    For more information please see the WAAS analytics help page

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 the application runs, define protected HTTP endpoints and select protections.
  1. Open Console, and go to
    Defend > WAAS
    .
  2. Select the
    Host
    tab
  3. Click
    Add Rule
    .
  4. Enter a
    Rule Name
    and
    Notes
    (Optional) for describing the rule.
  5. Choose the rule
    Scope
    by specifying the resource collection(s) to which it applies.
    Collections define a combination of hosts to which WAAS should attach itself in order to protect the web application:
    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.
  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
    2. Specify endpoint details:
    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 help page.
  9. Continue to
    App firewall
    tab, select protections to enable and assign them with WAAS Actions.
  10. Continue to
    Access Control
    tab and select access controls to enable.
  11. Continue to
    DoS protection
    tab and configure DoS protection thresholds.
  12. Continue to
    Bot protection
    tab and select bot protections to enable.
  13. Click
    Save
    .
  14. 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
    .
  15. Test protected endpoint using the following sanity tests.
  16. Go to
    Monitor > Events
    , click on
    WAAS for hosts
    and observe events generated.
    For more information please see the WAAS analytics help page

Deploying WAAS for Containers Protected By App-Embedded Defender

In some environments, Prisma Cloud Defender must be embedded directly inside the container it is protecting. This type of Defender is known as App-Embedded Defender. App-Embedded Defender can secure these types of containers with all WAAS protection capabilities.
The only difference is that App Embedded Defender runs as a reverse proxy to the container it’s protecting. As such, when you set up WAAS for App-Embedded, you must specify the exposed external port where App-Embedded Defender can listen, and the port (not exposed to the Internet) where your web application listens. WAAS for App-Embedded forwards the filtered traffic to your application’s port - unless an attack is detected and you set your WAAS for App Embedded rule to
Prevent
.
When testing your Prisma Cloud-protected container, be sure you update the security group’s inbound rules to permit TCP connections on the external port you entered in the WAAS rule. This is the exposed port that allows you to access your web application’s container. To disable WAAS protection, disable the WAAS rule, and re-expose the application’s real port by modifying the security group’s inbound rule.
To embed App-Embedded WAAS into your container or Fargate task:
  1. Open Console, and go to
    Defend > WAAS
    .
  2. Select the
    App Embedded
    tab.
  3. Click
    Add Rule
    .
  4. Enter a
    Rule Name
    and
    Notes
    (Optional) for describing the rule.
  5. Choose the rule
    Scope
    by specifying the resource collection(s) to which it applies.
    Collections define a combination of App IDs to which WAAS should attach itself in order to protect the web application:
  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 app’s endpoints.
  8. If you don’t 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 on
      Add Endpoint
      .
    2. Specify endpoint details:
    3. Enter
      Port (required)
      Specify TCP port, in the container, listening for inbound HTTP traffic
    4. Enter
      External Port (required)
      .
      External port is the TCP port for the App-Embedded Defender to listen on for inbound HTTP traffic.
    5. 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" non-TLS endpoints or "443" for TLS endpoints it can be omitted. Examples: "*.example.com", "docs.example.com", "www.example.com:8080", etc.
    6. Enter
      Path
      (optional, wildcards supported):
      Base path for WAAS to match on when applying protections.
      Examples: "/admin/", "/" (root path only), "/*", /v2/api/", etc.
    7. 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
      ).
    8. If your application uses HTTP/2, set
      HTTP/2
      to
      On
      .
    9. Click
      Create Endpoint
    10. 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 help page.
  9. Continue to
    App Firewall
    tab, select protections to enable and assign them with WAAS Actions.
  10. Continue to
    Access Control
    tab and select access controls to enable.
  11. Continue to
    DoS protection
    tab and configure DoS protection thresholds.
  12. Continue to
    Bot protection
    tab and select bot protections to enable.
  13. Click
    Save
    .
  14. You should be redirected to the
    Rule Overview
    page.
    Select the new rule to display
    Rule Resources
    and for each application a list of
    protected endpoints
    and
    enabled protections
    .
  15. Test protected container using the following sanity tests.
  16. Go to
    Monitor > Events
    , click on
    WAAS for App-Embedded
    and observe events generated.
    For more information please see the WAAS analytics help page

Deploying WAAS for serverless functions

When Serverless Defender is embedded in a function, it offers built-in web application firewall (WAF) capabilities, including protection against:
  • SQL injection (SQLi) attacks
  • Cross-site scripting (XSS) attacks
  • Command injection (CMDi) attacks
  • Local file system inclusion (LFI) attacks
  • Code injection attacks
Some protections are not available for WAAS serverless deployment.
Prerequisites:
You already embedded Serverless Defender into your function.
  1. Open Console and go to
    Defend > WAAS > Serverless
    .
  2. Click
    Add rule
    .
  3. Enter a rule name.
  4. Choose the rule
    Scope
    by specifying the resource collection(s) to which it applies.
    Collections define a combination of functions to which WAAS should attach itself in order to protect the web application:
  5. Select
    Alert
    or
    Prevent
    .
  6. Select the protections to enable.
  7. Enter the functions to protect.
    Use pattern matching to precisely target your rule.

WAAS Actions

HTTP requests that trigger WAAS protections are subject to one of the following actions:
  • Alert
    - Request is passed to the protected application and an audit is generated for visibility.
  • Prevent
    - Request is denied from reaching the protected application, an audit is generated and WAAS responds with an HTML banner indicating the request was blocked.
  • Ban
    - Can be applied on either IP or Prisma Session IDs. All requests originating from the same IP/Prisma Session to the protected application are denied for the configured time period (default is 5 minutes) following the last detected attack.
A message at the top of the page indicates the entity by which the ban will be applied (IP or Prisma Session ID).
To enable ban by Prisma Session ID, Prisma Session Cookies has to be enabled in the Advanced Settings tab. For more information please refer to the Advanced Settings help page.
WAAS implements state, which is required for banning user sessions by IP address. Because Defenders do not share state, any application that is replicated across multiple nodes must enable IP address stickiness on the load balancer.

Recommended For You