Prisma Cloud Compute Edition Administrator’s Guide
    : WAAS custom rules
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma
    3. Prisma Cloud
    4. Prisma Cloud Compute Edition Administrator’s Guide
    5. WAAS
    6. WAAS custom rules
    Download PDF

    Prisma Cloud Compute Edition Administrator’s Guide

    WAAS custom rules

    Table of Contents

    WAAS custom rules

    WAAS custom rules offer an additional mechanism to protect your running web apps. Custom rules are expressions that give you a precise way to describe and detect discrete conditions in requests and responses. WAAS intercepts layer 7 traffic, passes it to Prisma Cloud for evaluation. Expressions let you inspect various facets of requests and responses in a programmatic way, then take action when they evaluate to true. Custom rules can be used in container, host, and app-embedded WAAS policies.
    Besides your own custom rules, Prisma Labs ships and maintains rules for newly discovered threats. These system rules are distributed via the Intelligence Stream. By default, they are shipped in a disabled state. You can review, and optionally activate them at any time. System rules cannot be modified. However, you can clone and customize them to fit your own specific needs.
    Before using custom rules, ensure Console and Defender run the same version of Prisma Cloud Compute. The minimum required version for a Defender appears when you add a custom rule to a policy. For example, if a Console runs a newer version, but Defenders have not been upgraded, using functionality only available in the newer version will result in a WAAS error. If this occurs, upgrade Defenders to match their Console’s version.

    Expression grammar

    Expressions let you examine the contents of requests and responses. The grammar lets you inspect various properties in an event. For example, you could write an expression that determines if an IP address falls inside a specific CIDR block.
    Expressions support the following types:
    • String.
    • String list.
    • String map.
    • Integer.
    • IP address (e.g. "192.168.0.1")
    • CIDR block (e.g. "192.168.0.0/16")
    Expressions have the following grammar:

    Request events

    Expressions can examine the following attributes of a request:
    Attribute
    Minimum Defender version
    Type
    Example
    req.host
    22.06
    Map of String
    req.headers (for matching on "Host" header use req.host)
    21.04
    Map of String
    req.header_names
    21.04
    String List
    req.header_values
    21.04
    String List
    req.cookies
    21.04
    Map of String
    req.cookie_names
    21.04
    String List
    req.cookie_values
    21.04
    String List
    req.query_params
    21.04
    Map of String
    req.query_param_names
    21.04
    String List
    req.query_param_values
    21.04
    String List
    req.body_param_values
    21.04
    String List
    req.http_method
    21.04
    String
    req.file_extension
    21.04
    String
    req.path
    21.04
    String
    req.ip
    21.04
    IP (written as string, parsed as IP if IP is valid)
    req.country_code
    21.04
    String
    req.body
    21.04
    String
    req.http_version
    21.04
    String
    req.http_scheme
    21.04
    String
    When gRPC is enabled, the req.body attribute may not be able to properly match on the body content if it is sent in binary form.

    Response events

    Expressions can examine the following attributes of a response.
    To examine server responses in custom rules, the rule type must be set to waas-response
    Attribute
    Minimum Defender version
    Type
    Example
    resp.status_code
    21.04
    Integer
    resp.content_type
    21.08
    String
    resp.body
    21.08
    String
    resp.headers
    21.08
    Map of String
    resp.header_names
    21.08
    String List
    resp.header_values
    21.08
    String List
    When gRPC is enabled, the resp.body attribute may not be able to properly match on the body content if it is sent in binary form.

    Transformation functions

    The following transformations are available to users creating custom rules:
    • lowercase
       - converts all characters to lowercase.
    • compressWhitespace
       - converts whitespace characters (32, \f, \t, \n, \r, \v, 160) to spaces (32) and then compresses multiple space characters into only one.
    • removeWhitespace
       - removes all whitespace characters.
    • urlQueryDecode
       - decodes URL query string.
    • urlPathDecode
       - decodes URL path string (identical to
      urlQueryDecode
       except that it does not unescape + to space).
    • unicodeDecode
       - normalizes unicode characters to their closest resemblance in ASCII format.
    • htmlEntityDecode
       - decodes HTML components in a given string.
    • base64Decode
       - decodes a base64-encoded string.
    • replaceComments
       - replaces each occurrence of a C-style comments (/* …​ */) with a single space (multiple consecutive occurrences of a space will not be compressed).
    • removeCommentSymbols
       - removes each comment symbol (/*, */) from a string.
    • removeTags
       - replaces encoded tag entities (<, >) with a single whitespace.

    JWT parsing functions

    • jwtPayload(<JWT string>) - returns a string representing the payload section of the JWT (simply the whole second part of the token, base64url decoded).
    To inspect if a string value associated with a key say "email_verified" is set to "false", use the following expression: jwtPayloadValue(req.headers["Authorization"], "email_verified") contains /^false$/
    For example, to check if the key "kid" contains the value matching a pattern: jwtHeaderValue(req.headers["Authorization"], "kid") contains /\.\.[\\\/]/
    • jwtValid(<JWT string>) - returns a boolean value which is true only if the input argument represents a JWT, and this JWT passed the following checks:
    • If the JWT is signed with a standard algorithm with a fixed-length output, the signature of the JWT should be of that known length.
    • If the JWT is signed with a standard symmetric-key algorithm, the header of the JWT does not contain a parameter that is meant to be used only with asymmetric algorithms (e.g. parameters used to identify a public key that is used to verify the JWT’s signature).
    • The JWT has not expired - check when the 'exp' (Expiration Time) claim is present.
    • The JWT’s has already been issued (issue time < current time) - checked when the 'iat' (Issued At) claim is present.
    • The JWT has already become valid ("not valid before" time < current time) - checked when the 'nbf' (Not Before) claim is present.
    The WAAS events for JWT custom rule violations are generated under
    Monitor > Events > WAAS for containers/hosts
    , with the attack type as
    Custom Rule
    .
    Limitations
    :
    • No signature verifications
      : The signature part of JWT is not verified. This verification should be handled by the application receiving the token.
    • Encrypted JWTs are not supported
      : The Encrypted Java Webtokens (JWEs) are not handled.

    Effects

    The following effects may be applied on HTTP requests/responses that match a WAAS custom rule:
    • Allow
       - The request is passed to the protected application, all other detections are not applied (e.g app firewall, bot protection, API protection, etc.). No audit is generated.
    • Alert
       - The request is passed to the protected application and an audit is generated for visibility.
    • Prevent
       - The request is denied from reaching the protected application, an audit is generated and WAAS responds with an HTML page 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). When the X-Forwarded-For HTTP header is included in the request headers, the ban will apply based on the first IP listed in the header value (true client IP). For custom rules defined in
    Out-of-Band
    , only
    Allow
     and
    Alert
     effects are allowed.

    Example expressions

    The following examples show how to use the expression grammar:
    • Special expression to determine if an IP address falls within a CIDR block:
    • Example of using a regular expression:
    • Determine if the request method matches a method in the array. Currently, you can only create custom arrays as part of the in operator.
    • Example using a selector:
    • Example of an expression with three conditions. All conditions must evaluate to true for there to be a match.
    • Example for detecting HTTP 1.0 requests sent to a path starting with /api/control/ with an "admin" cookie whose Base64 decoded value is set to "True".
    • Example for detecting successful login requests by checking the Set-Cookie header value using chained transformation functions.

    Write a WAAS custom rule

    Expression syntax is validated when you save a custom rule.
    1. Open Console, and go to
      Defend > WAAS
       >
      {Container | Host | App-Embedded | Agentless} > {In-line | Out-Of-Band}
      .
    2. Click
      Add rule
      .
    3. Enter a name for the rule.
    4. In
      Message
      , enter an audit message to be emitted when an event matches the condition logic in this custom rule.
      Use the following syntax to view the matched groups: <Your text>: %regexMatches
      Refer to the following screenshot:
    5. Select the rule type.
      You can write expressions for requests or responses. What you select here scopes the vocabulary available for your expression.
    6. Enter your expression logic.
      Press OPTION + SPACE to get a list of valid terms, expressions, operators, etc, for the given position.
      Use the example expressions here as a starting point for your own expression.
    7. Click
      Save
      .
      Your expression logic is validated before it is saved to the Console’s database.

    Activate WAAS custom rules

    A custom rule is made up of one or more conditions. Attach a custom rule to a WAAS policy rule to activate it.
    Custom rules are defined in
    Defend > Custom rules > WAAS
    . WAAS policy rules are defined in
    Defend > WAAS > {Container | Host | App-Embedded | Agentless} > {In-line | Out-Of-Band}
    .
    When attaching a custom rule to a WAAS policy rule, you specify the action to be taken when the expression evaluates to true (i.e. the expression matches). Supported actions for In-line WAAS policy are Disable, Allow, Alert, Prevent, and Ban. For Out-Of-Band/Agentless the only actions available are Disable, Allow, and Alert.
    Custom rules have priority over all other enabled WAAS protections. WAAS evaluates all custom rules that are attached, so you can get more than one audit if more than one custom rule matches.
    Prerequisites:
     You have already set up WAAS to protect an app, and there’s a rule for it under
    Defend > WAAS > {Container | Host | App-Embedded | Agentless} > {In-line | Out-Of-Band}
    . For more information about setting up an app, see Deploy WAAS.
    1. Open Console, and go to
      Defend > WAAS > {Container | Host | App-Embedded | Agentless} > {In-line | Out-Of-Band}
      .
    2. Select a rule under
      App list
      .
    3. Add app
       and then go to
      Custom rules
      .
    4. Select the effects to
      Auto-apply virtual patches
       to known CVEs vulnerabilities as detected by Prisma Cloud. The effect will be applied on HTTP requests/responses that match a WAAS custom rule.
      In addition to selecting the global effect for applying the virtual patch, you can also override the default effects by selecting
      user-selected custom rules
       that are always applied regardless of the global auto-apply virtual patch under
      Defend > WAAS > Container/Host/Agentless/App-embedded > {In-Line/Out-Of-Band}
      .
      The
      Auto-apply virtual patches
       are only applicable if the minimum Defender version is Kepler or greater.
    5. Select rules
       from the predefined list of custom rules and click
      Apply
      . Alternatively, you can also create your own custom rules, with
      Add rule
      .
      1. A list of available WAAS custom rules is displayed. Whenever a user creates a rule, the
        owner
         column is populated with the username. The owner column of virtual patches provided by Unit-42 researchers will have the value system.
      2. The minimum supported Defender version appears when you add the custom rule to a policy.
    6. Configure the effect for each custom rule.
      By default, the effect is set to
      Alert
      .
    7. Click
      Save
      .

    Recommended For You

    © 2023 Palo Alto Networks, Inc. All rights reserved.