diff --git a/content/includes/nap-waf/build-from-official-nginx-image.md b/content/includes/nap-waf/build-from-official-nginx-image.md deleted file mode 100644 index 3125460de..000000000 --- a/content/includes/nap-waf/build-from-official-nginx-image.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -nd-docs: "DOCS-1509" ---- - -{{< call-out "note" >}} - While this example utilizes the official NGINX Open Source image as a base, the crucial requirement is that NGINX must be installed as a package from the official NGINX repository, rather than being compiled from source. -{{< /call-out >}} - -```dockerfile -# syntax=docker/dockerfile:1 - -# Base image -FROM nginx:1.25.5-bookworm - -# Install F5 WAF for NGINX v5 module -RUN --mount=type=secret,id=nginx-crt,dst=/etc/ssl/nginx/nginx-repo.crt,mode=0644 \ - --mount=type=secret,id=nginx-key,dst=/etc/ssl/nginx/nginx-repo.key,mode=0644 \ - apt-get update \ - && apt-get install --no-install-recommends --no-install-suggests -y \ - apt-transport-https \ - lsb-release \ - ca-certificates \ - wget \ - gnupg \ - && wget https://cs.nginx.com/static/keys/nginx_signing.key \ - && gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/nginx.gpg \ - --import nginx_signing.key \ - && chmod 644 /etc/apt/trusted.gpg.d/nginx.gpg \ - && printf "deb https://pkgs.nginx.com/app-protect-x-oss/debian `lsb_release -cs` nginx-plus\n" | \ - tee /etc/apt/sources.list.d/nginx-app-protect.list \ - && wget -P /etc/apt/apt.conf.d https://cs.nginx.com/static/files/90pkgs-nginx \ - && apt-get update \ - && apt-get install --no-install-recommends --no-install-suggests -y nginx=1.25.5-1~bookworm app-protect-module-oss \ - && apt-get remove --purge --auto-remove -y apt-transport-https lsb-release gnupg wget \ - && rm -rf /var/lib/apt/lists/* /etc/apt/sources.list.d/nginx-app-protect.list -``` diff --git a/content/includes/nap-waf/build-nginx-image-cmd.md b/content/includes/nap-waf/build-nginx-image-cmd.md deleted file mode 100644 index fb1e6e805..000000000 --- a/content/includes/nap-waf/build-nginx-image-cmd.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -nd-docs: "DOCS-1512" ---- - -{{< call-out "note" >}} -Never upload your F5 WAF for NGINX v5 images to a public container registry such as Docker Hub. Doing so violates your license agreement. -{{< /call-out >}} - -To build the image, execute the following command in the directory containing the `nginx-repo.crt`, `nginx-repo.key`, and `Dockerfile`. Here, `nginx-app-protect-5` is an example image tag. - - -```shell -sudo docker build --no-cache --platform linux/amd64 \ - --secret id=nginx-crt,src=nginx-repo.crt \ - --secret id=nginx-key,src=nginx-repo.key \ - -t nginx-app-protect-5 . -``` diff --git a/content/includes/nap-waf/bundles-volume-mount.md b/content/includes/nap-waf/bundles-volume-mount.md deleted file mode 100644 index c65050849..000000000 --- a/content/includes/nap-waf/bundles-volume-mount.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -nd-docs: "DOCS-1511" ---- - -To work with custom policy and logging profile bundles, these files must be accessible to the `waf-config-mgr` container. - -1. **Assumption**: Your bundle files are in `/bundles` on the host machine. -2. **Docker Compose Configuration**: In your `docker-compose.yml`, add a volume mount under the `waf-config-mgr` service to link the host directory `/bundles` to the same path inside the container. - -```yaml -... -waf-config-mgr: - container_name: waf-config-mgr - image: "private-registry.nginx.com/nap/waf-config-mgr:1.0.0" - volumes: - - /bundles:/bundles # Mounting the host directory to the container - - ... #existing volume mounts -``` - -By setting up this volume mount, the bundle files can be referenced within your NGINX configuration using the `/bundles` directory. - -For instance: - - ```nginx - app_protect_policy_file /bundles/custom_policy.tgz; - app_protect_security_log /bundles/custom_logging_profile.tgz syslog:server=localhost:514; - ``` diff --git a/content/includes/nap-waf/concept/apreload.md b/content/includes/nap-waf/concept/apreload.md deleted file mode 100644 index 4a172dc04..000000000 --- a/content/includes/nap-waf/concept/apreload.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -nd-docs: DOCS-000 ---- - -apreload is a tool that can update that can update the F5 WAF for NGINX configuration without having to reload NGINX if only the App Protect configuration is changed and the `nginx.conf` file remains unchanged. apreload does not affect the existing NGINX reload process and it functions in the same manner as before. - -#### Some Conditions Required for apreload to Work: - -- For apreload to work, NGINX must be started first. -- apreload may be used if the App Protect configuration (policies, log configuration files, global settings etc) have been modified, but the NGINX configuration hasn't changed.
- - Whenever `nginx.conf` file or any of its included files are modified, nginx reload must be used, rather than apreload. This will also update any changes in the App Protect configuration (policies, logging profiles, global settings). This applies also if only the App Protect directives have been modified in the `nginx.conf` file. -- apreload should be executed with the same user that executes NGINX to avoid any access error. -- apreload handles any changes in the content of the policy, with the exception of the name of the policy.
\ No newline at end of file diff --git a/content/includes/nap-waf/concept/attack-signatures.md b/content/includes/nap-waf/concept/attack-signatures.md deleted file mode 100644 index 1b56c1a9b..000000000 --- a/content/includes/nap-waf/concept/attack-signatures.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -nd-docs: DOCS-000 ---- - -Attack signatures are rules or patterns that identify attack sequences or classes of attacks on a web application and its components. You can apply attack signatures to both requests and responses. App Protect includes predefined attack signatures to protect your application against all attack types identified by the system. \ No newline at end of file diff --git a/content/includes/nap-waf/concept/basic-config-default-policy.md b/content/includes/nap-waf/concept/basic-config-default-policy.md deleted file mode 100644 index 3854b5a45..000000000 --- a/content/includes/nap-waf/concept/basic-config-default-policy.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -nd-docs: DOCS-000 ---- - -The base template is the common starting point to any policy you write. The default policy just reflects that template without any further modifications, thus we use the terms **base template** and **default policy** interchangeably. The default policy appears as follows - -```json -{ - "policy" : { - "name": "app_protect_default_policy", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" } - } -} -``` - -The default policy enforces violations by **Violation Rating**, the App Protect computed assessment of the risk of the request based on the triggered violations. - -- 0: No violation -- 1-2: False positive -- 3: Needs examination -- 4-5: Threat - -The default policy enables most of the violations and signature sets with Alarm turned ON, but not Block. These violations and signatures, when detected in a request, affect the violation rating. By default, if the violation rating is calculated to be malicious (4-5) the request will be blocked by the `VIOL_RATING_THREAT` violation. This is true even if the other violations and signatures detected in that request had the Block flag turned OFF. It is the `VIOL_RATING_THREAT` violation having the Block flag turned ON that caused the blocking, but indirectly the combination of all the other violations and signatures in Alarm caused the request to be blocked. By default, other requests which have a lower violation rating are not blocked, except for some specific violations described below. This is to minimize false positives. However, you can change the default behavior. For example, if you want to add blocking on a violation rating of 3 as well, enable blocking for the `VIOL_RATING_NEED_EXAMINATION` violation. - -The following violations and signature sets have a low chance of being false positives and are, therefore, configured by default to block the request regardless of its Violation Rating: -- High accuracy attack signatures -- Threat campaigns -- Malformed request: unparsable header, malformed cookie and malformed body (JSON or XML). diff --git a/content/includes/nap-waf/concept/external-references.md b/content/includes/nap-waf/concept/external-references.md deleted file mode 100644 index d0c2cdf31..000000000 --- a/content/includes/nap-waf/concept/external-references.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -nd-docs: DOCS-000 ---- - -External references in policy are defined as any code blocks that can be used as part of the policy without being explicitly pasted within the policy file. This means that you can have a set of pre-defined configurations for parts of the policy, and you can incorporate them as part of the policy by simply referencing them. This would save a lot of overhead having to concentrate everything into a single policy file. - -A perfect use case for external references is when you wish to build a dynamic policy that depends on moving parts. You can have code create and populate specific files with the configuration relevant to your policy, and then compile the policy to include the latest version of these files, ensuring that your policy is always up to date when it comes to a constantly changing environment. - -**Note**: Any update of a single file referenced in the policy will not trigger a policy compilation. This action needs to be done actively by reloading the NGINX configuration. - -To use the external references capability, in the policy file the direct property is replaced by "xxxReference" property, where xxx defines the replacement text for the property changed to singular (if originally plural) and notation converted from snake case to camelCase. For example, `modifications` section is replaced by `modificationsReference` and `data-guard` is replaced by `dataGuardReference`. \ No newline at end of file diff --git a/content/includes/nap-waf/concept/global-directives.md b/content/includes/nap-waf/concept/global-directives.md deleted file mode 100644 index 9efcabae7..000000000 --- a/content/includes/nap-waf/concept/global-directives.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -nd-docs: DOCS-000 ---- - -Global configuration consists of a series of `nginx.conf` directives at the `http` context controlling aspects that are not specific to a specific application. - -When applied to a cluster, all cluster members will get the same globals as expected. - -{{< call-out "note" >}} Whether an incoming request is inspected by F5 WAF for NGINX may be determined by the URL in the request. This happens if you configure `app_protect_enable` and `app_protect_policy_file` directives in the `location` scope. In the case where the URL itself has violations such as *bad unescape* or *illegal metacharacter* then the request might be assigned to a location in which F5 WAF for NGINX is disabled or has a relaxed policy that does not detect these violations. Such malicious requests will be allowed without inspection. In order to avoid this, it is recommended to have a basic policy enabled at the `http` scope or at least at the `server` scope to process malicious requests in a more complete manner.{{< /call-out >}} - -{{< bootstrap-table "table table-striped table-bordered table-sm table-responsive" >}} -|Directive Name | Syntax | Description | Default | -| ---| ---| ---| --- | -|app_protect_physical_memory_util_thresholds | app_protect_physical_memory_util_thresholds high= low= | Sets the physical memory utilization thresholds for entering (high) and exiting (low) failure mode. When the high threshold is exceeded the system enters failure mode until memory drops below the low threshold. Setting the value of 100 disables this feature. | high=low=100 (disabled) | -|app_protect_cpu_thresholds | app_protect_cpu_thresholds high= low= | Sets the CPU utilization thresholds for entering and exiting failure mode respectively: when the high threshold is exceeded the system enters failure mode until CPU drops below the low threshold. Setting the value of 100 disables this feature.
**Note**: The system does not enter failure mode during policy compilation after reload even if the threshold is exceeded. | high=low=100 (disabled) | -|app_protect_failure_mode_action | app_protect_failure_mode_action pass | drop | How to handle requests when the App Protect Enforcer cannot process them, either because it is down, disconnected or because of excessive CPU or memory utilization. There are two values:
  • **pass**: Pass the request without App Protect Enforcer inspection, a.k.a. "fail-open".
  • **drop**: Drop the request by returning the response "503 Service Unavailable", a.k.a. "fail-close".
| pass | -|app_protect_cookie_seed | app_protect_cookie_seed | A long randomized string that serves to generate the encryption key for the cookies generated by App Protect. The string should contain only alphanumeric characters and be no longer than 1000 characters. | Auto-generated random string | -|app_protect_compressed_requests_action | app_protect_compressed_requests_action pass | drop | Determines how to handle compressed requests. There are two values:
  • **pass**: Pass the request without App Protect Enforcer inspection, a.k.a. "fail-open".
  • **drop**: Drop the request by returning the response "501 Not Implemented", a.k.a. "fail-close".
**Note**: Starting with App Protect release version 4.6, this directive has been deprecated from the `nginx.conf` file. | drop | -|app_protect_request_buffer_overflow_action | app_protect_request_buffer_overflow_action pass | drop | Determines how to handle requests in case the NGINX request buffer is full and requests cannot be buffered anymore. There are two values:
  • **pass**: Pass the request without App Protect Enforcer inspection, a.k.a. "fail-open".
  • **drop**: Drop the request by resetting connection. No response page is returned, a.k.a. "fail-close".
| pass | -|app_protect_user_defined_signatures | app_protect_user_defined_signatures | Imports the user-defined tagged signature file with the respective tag name from the provided path. Multiple instances of this directive are supported. In order to import multiple signatures files, each file must have a different tag. | N/A | -|app_protect_reconnect_period_seconds| app_protect_reconnect_period_seconds
**Value type**: number with decimal fraction
**Value Range**: 0-60. 0 is illegal | Determines the period of time between reconnect retries of the module to the web application firewall (WAF) engine. The time unit is seconds.| 5 | -{{< /bootstrap-table >}} \ No newline at end of file diff --git a/content/includes/nap-waf/concept/graphql-profile.md b/content/includes/nap-waf/concept/graphql-profile.md deleted file mode 100644 index c23175f8d..000000000 --- a/content/includes/nap-waf/concept/graphql-profile.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -nd-docs: DOCS-000 ---- - -The GraphQL Profile defines the GraphQL properties that are enforced by the security policy. - -The profile can be added by the security engineers to make sure that GraphQL apps are bound to the same security settings defined in the profile. Different GraphQL apps can have different profiles based on the security needs. - -The GraphQL Profile includes: - -- **Security enforcement**: whether to detect signatures and/or metacharacters and optionally an exception (a.k.a override) list of signatures that need to be disabled in the context of this profile. -- **Defense attributes**: special restrictions applied to the GraphQL traffic. The below example shows the customized GraphQL properties. -- **responseEnforcement**: whether to block Disallowed patterns and provide the list of patterns against the `disallowedPatterns` property. - -GraphQL profile example: - -In the GraphQL profile example below, we changed the "defenseAttributes" to custom values. You can customize these values under the "defenseAttributes" property. Add a list of disallowed patterns to the "disallowedPatterns" field (for example, here we've added pattern1 and pattern2). - -```shell -"graphql-profiles" : [ - { - "attackSignaturesCheck" : true, - "defenseAttributes" : { - "allowIntrospectionQueries" : false, - "maximumBatchedQueries" : 10, - "maximumQueryCost" : "any", - "maximumStructureDepth" : 10, - "maximumTotalLength" : 100000, - "maximumValueLength" : 100000, - "tolerateParsingWarnings" : false - }, - "description" : "", - "metacharElementCheck" : false, - "name" : "response_block", - "responseEnforcement" : { - "blockDisallowedPatterns" : true, - "disallowedPatterns":["pattern1","pattern2"] - } - } - ] -``` \ No newline at end of file diff --git a/content/includes/nap-waf/concept/grpc-logging.md b/content/includes/nap-waf/concept/grpc-logging.md deleted file mode 100644 index 88fc1678d..000000000 --- a/content/includes/nap-waf/concept/grpc-logging.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -nd-docs: DOCS-000 ---- - -Security log for gRPC requests has unique fields: `uri`, `grpc_method`, and `grpc_service`. Also, since the content of gRPC requests is binary (Protocol Buffers), it is better transferred in Base64 encoding. Hence, it is recommended to use the `headers` and `request_body_base64` fields instead of the `request` field. A new predefined log format called `grpc` should be used in all gRPC locations that also use policies with gRPC Content Profiles. -The `grpc` format also contains the above new gRPC fields (`grpc_service` and `grpc_method`). See [Available Security Log Attributes]({{< ref "/nap-waf/v5/logging-overview/security-log#available-security-log-attributes" >}}). - -F5 WAF for NGINX provides three security log bundles for gRPC: `log_grpc_all`, `log_grpc_illegal` and `log_grpc_blocked` using the `grpc` format with three filters: all requests, illegal requests, and blocked requests respectively. Unless you have special logging format requirements, the best practice is to use one of these bundles in all gRPC locations with the `app_protect_security_log` directive. - -Here is a typical example: - -```nginx -server { - server_name my_grpc_service.com; - location / { - app_protect_enable on; - app_protect_policy_file "/etc/app_protect/conf/policy_with_grpc_profile.tgz"; - app_protect_security_log_enable on; - app_protect_security_log "/etc/app_protect/conf/log_grpc_all.tgz" stderr; - grpc_pass grpcs://grpc_backend; - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/concept/strict-policy.md b/content/includes/nap-waf/concept/strict-policy.md deleted file mode 100644 index 06a7c44f1..000000000 --- a/content/includes/nap-waf/concept/strict-policy.md +++ /dev/null @@ -1,22 +0,0 @@ -The Strict Policy is recommended as a starting point for applications requiring a higher level of security. Just like all other policies it is based on the base template, so it detects and blocks everything the default policy does. -To obtain the Strict Policy, execute the following command: - -```shell -sudo docker run --rm -v $(pwd):$(pwd) --entrypoint='' private-registry.nginx.com/nap/waf-compiler:1.0.0 cat /etc/app_protect/conf/NginxStrictPolicy.json -``` - -Replace the `1.0.0` with the actual release version. - -In addition the Strict Policy also **blocks** the following: -- Requests that have a Violation Rating of 3, "Needs examination". This occurs because the `VIOL_RATING_NEED_EXAMINATION` violation's block flag is enabled in the strict policy. -- Requests with the `VIOL_EVASION` violation (evasion techniques). -- Requests with violations that restrict options in the request and response: HTTP method, response status code and disallowed file types. - -{{< call-out "note" >}} Other violations, specifically attack signatures and metacharacters, which are more prone to false positives, still have only Alarm turned on, without blocking, contributing to the Violation Rating as in the Default policy.{{< /call-out >}} - -In addition, the Strict policy also enables the following features in **alarm only** mode: -- **Data Guard**: masking Credit Card Number (CCN), US Social Security Number (SSN) and custom patterns found in HTTP responses. - -- **HTTP response data leakage signatures**: preventing exfiltration of sensitive information from the servers. -- **More restrictive limitations**: mainly sizing and parsing of JSON and XML payloads. -- **Cookie attribute insertion**: the Strict policy adds the **Secure** and **SameSite=lax** attributes to every cookie set by the application server. These attributes are enforced by the browsers and protect against session hijacking and CSRF attacks respectively. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/additional-config-options.md b/content/includes/nap-waf/config/common/additional-config-options.md deleted file mode 100644 index d9bdd6b10..000000000 --- a/content/includes/nap-waf/config/common/additional-config-options.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -nd-docs: "DOCS-1552" ---- - -#### XFF Headers and Trust - -XFF trust is disabled by default but can be enabled. - -In this example, we use the default configuration but enable the trust of XFF header. - -```json -{ - "policy": { - "name": "xff_enabled", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "general": { - "customXffHeaders": [], - "trustXff": true - } - } -} -``` - - -In this example, we configure a policy with a custom-defined XFF header. - -```json -{ - "policy": { - "name": "xff_custom_headers", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "general": { - "customXffHeaders": [ - "xff" - ], - "trustXff": true - } - } -} -``` - -#### Blocking Page Customization - -You can customize the blocking page text and formatting to suit your particular design requirements. - -In this example, we use the default configuration but modify the response page that is displayed to the customer. - -```json - { - "policy": { - "name": "blocking_page", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "response-pages": [ - { - "responseContent": "Custom Reject PageThis is a custom response page; it is supposed to overwrite the default page with custom text.

Your support ID is: <%TS.request.ID()%>

[Go Back]", - "responseHeader": "HTTP/1.1 200 OK\r\nCache-Control: no-cache\r\nPragma: no-cache\r\nConnection: close", - "responseActionType": "custom", - "responsePageType": "default" - } - ] - } -} -``` - - -#### AJAX Response Page for Single Page Applications (SPAs) - -There is a special scenario where default or regular custom response pages cannot be used. SPAs (Single Page Applications) are applications that provide application functionality within the boundaries of a single HTML page. Once a SPA application has been loaded in the browser, it typically makes REST API calls to remote resources expecting JSON response bodies rather than HTML markup. If this SPA application were to receive a default HTML-formatted block page, it would not be able to interpret this, likely causing an application error. - -A way to handle such a situation is via configuring an AJAX response page. The AJAX response page will cause a pop-up to appear on the client browser, informing them that the request has been blocked. - -In this example, we set up an AJAX response page. - -```json -{ - "policy": { - "name": "NGINX-SPA", - "description": "Policy with AJAX response page enabled for blocking AJAX requests", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "enforcementMode": "blocking", - "response-pages": [ - { - "responsePageType": "ajax", - "ajaxEnabled": true, - "ajaxPopupMessage": "My customized popup message! Your support ID is: <%TS.request.ID()%>" - } - ] - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/additional-policy-features.md b/content/includes/nap-waf/config/common/additional-policy-features.md deleted file mode 100644 index ce5395a0e..000000000 --- a/content/includes/nap-waf/config/common/additional-policy-features.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -nd-docs: "DOCS-1592" ---- - -{{}} -|Feature | Description | -| ---| --- | -|Enforcement by Violation Rating | By default block requests that are declared as threats, that is, their Violation Rating is 4 or 5. It is possible to change this behavior: either disable enforcement by Violation Rating or block also request with Violation Rating 3 - needs examination. See section on [basic configuration](#policy-configuration) below. | -|Large Request Blocking | To increase the protection of resources at both the NGINX Plus and upstream application tiers, all requests that are larger than 10 MB in size are blocked. When these requests are blocked, a `VIOL_REQUEST_MAX_LENGTH` violation will be logged.| -|Request size checks | Upper limit of request size as dictated by the maximum buffer size of 10 MB; Size checks for: URL, header, Query String, whole request (when smaller than the maximum buffer), cookie, POST data. By default all the checks are enabled with the exception of POST data and whole request. The user can enable or disable every check and customize the size limits. | -|Malformed cookie | Requests with cookies that are not RFC compliant are blocked by default. This can be disabled. | -|Status code restriction | Illegal status code in the range of 4xx and 5xx. By default only these are allowed: 400, 401, 404, 407, 417, 503. The user can modify this list or disable the check altogether. | -|Blocking pages | The user can customize all blocking pages. By default the AJAX response pages are disabled, but the user can enable them. | -{{}} \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/anti-automation.md b/content/includes/nap-waf/config/common/anti-automation.md deleted file mode 100644 index 5a76d4f71..000000000 --- a/content/includes/nap-waf/config/common/anti-automation.md +++ /dev/null @@ -1,185 +0,0 @@ ---- -nd-docs: "DOCS-1575" ---- - -Anti Automation provides basic bot protection by detecting bot signatures and clients that falsely claim to be browsers or search engines. The `bot-defense` section in the policy is enabled by default. Anti Automation encompasses both Bot Signatures and Header Anomalies, each of which can be disabled separately. - -As new bot signatures are identified, they will be accessible for [download and installation]({{< ref "/nap-waf/v4/admin-guide/install.md#updating-app-protect-bot-signatures" >}}) so that your system will always have the most up-to-date protection. You can update the bot signatures without updating the App Protect release. Similarly, you can update App Protect without altering the bot signature package, unless you upgrade to a new NGINX Plus release. - -#### Bot Signatures - -Bot Signatures provide basic bot protection by detecting bot signatures in the User-Agent header and URI. -Each bot signature belongs to a bot class. Search engine signatures such as `googlebot` are under the trusted_bots class, but App Protect performs additional checks of the trusted bot's authenticity. If these checks fail, it means that the respective client impersonated the search engine in the signature and it will be classified as class - `malicous_bot`, anomaly - `Search engine verification failed`, and the request will be blocked, irrespective of the class's mitigation actions configuration. -An action can be configured for each bot class, or may also be configured per each bot signature individually: -* `ignore` - bot signature is ignored (disabled) -* `detect` - only report without raising the violation - `VIOL_BOT_CLIENT`. The request is considered `legal` unless another violation is triggered. -* `alarm` - report, raise the violation, but pass the request. The request is marked as `illegal`. -* `block` - report, raise the violation, and block the request - -In this example we show how to enable bot signatures using the default bot configuration: - -```json - -{ - "policy": { - "name": "bot_defense_policy", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "bot-defense": { - "settings": { - "isEnabled": true - } - } - } -} -``` - -The default actions for classes are: `detect` for `trusted-bot`, `alarm` for `untrusted-bot`, and `block` for `malicious-bot`. In this example, we enabled bot defense and specified that we want to raise a violation for `trusted-bot`, and block for `untrusted-bot`. - -```json -{ - "policy": { - "name": "bot_defense_policy", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "bot-defense": { - "settings": { - "isEnabled": true - }, - "mitigations": { - "classes": [ - { - "name": "trusted-bot", - "action": "alarm" - }, - { - "name": "untrusted-bot", - "action": "block" - }, - { - "name": "malicious-bot", - "action": "block" - } - ] - } - } - } -} -``` - -In this example, we override the action for a specific signature (python-requests) - -```json -{ - "policy": { - "name": "bot_defense_policy", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "bot-defense": { - "settings": { - "isEnabled": true - }, - "mitigations": { - "signatures": [ - { - "action": "ignore", - "name": "python-requests" - } - ] - } - } - } -} -``` - -#### Bot Signatures Update File - -Starting with F5 WAF for NGINX release 4.7, the bot signature file `included_bot_signatures`, is located at the following path: `/opt/app-protect/var/update_files/bot_signatures/included_bot_signatures`. This will be part of the **app-protect-bot-signatures** package. - -This file contains an up-to-date list of all bot signatures that have been updated with the new bot signature package. This list is automatically generated as a part of the **app-protect-bot-signatures** package and follows a format similar to the README-style text file found in the attack signature. This file contains essential information which includes: - -- Bot name -- Bot type -- Bot classification/category - - -#### List of Trusted Bots - -This is a list of the trusted bots that are currently part of the bot signatures. As the title suggests, these bot signatures belong to the `trusted-bot` class and currently all are search engines. - -{{}} -|Bot Name | Description | -| ---| --- | -|Ask | [Ask.com engine](https://www.ask.com) | -|Baidu | [Baidu search engine](https://www.baidu.com/) | -|Baidu Image Spider | [Baidu search engine for images](https://image.baidu.com/) | -|Bing | [Microsoft Bing search engine](https://www.bing.com/) | -|BingPreview | [Microsoft Bing page snapshot generation engine](https://www.bing.com/) | -|Daum | [Daum search engine](https://www.daum.net/) | -|DuckDuckGo Bot | [DuckDuckGo search engine](https://duckduckgo.com/) | -|fastbot | [fastbot search engine](https://www.fastbot.de/) | -|Google | [Google search engine](https://www.google.com/) | -|MojeekBot | [Mojeek search engine](https://www.mojeek.com/) | -|Yahoo! Slurp | [Yahoo search engine](https://www.yahoo.com/) | -|Yandex | [Yandex search engine](https://yandex.com/) | -|YioopBot | Yioop search engine | -{{}} - - -#### Header Anomalies - -In addition to detecting Bot Signatures, by default F5 WAF for NGINX verifies that a client claiming to be a browser is indeed one by inspecting the HTTP headers. -Each request receives a score, is categorized by anomaly, and is enforced according to the default configured anomaly action: - - -{{}} -|Range | Anomaly | Action | Class | -| ---| ---| ---| --- | -|0-49 | None | None | Browser | -|50-99 | Suspicious HTTP Headers Presence or Order | Alarm | Suspicious Browser | -|100 and above | Invalid HTTP Headers Presence or Order | Block | Malicious Bot | -| Non Applicable | SEARCH_ENGINE_VERIFICATION_FAILED | Block | Malicious Bot | -{{}} - - -Notice that the default scores for each anomaly can be changed. In this example, we override the score and action of the default bot configuration: - -```json - -{ - "policy": { - "name": "bot_anomalies_and_signatures", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "bot-defense": { - "mitigations": { - "anomalies": [ - { - "name": "Suspicious HTTP Headers", - "action": "alarm", - "scoreThreshold": 50 - }, - { - "name": "Invalid HTTP Headers", - "action": "block", - "scoreThreshold": 99 - } - ] - } - } - } -} - -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/associating-graphql-profiles.md b/content/includes/nap-waf/config/common/associating-graphql-profiles.md deleted file mode 100644 index 6956777bc..000000000 --- a/content/includes/nap-waf/config/common/associating-graphql-profiles.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -nd-docs: "DOCS-1607" ---- - -The last step is to associate the GraphQL profiles with the URLs. As with JSON and XML profiles, in order for a GraphQL Profile to become effective, it has to be associated with a URL that represents the service. Add the GraphQL profile name which you defined previously under the GraphQL profiles in the name field. For example, here we have defined two GraphQL profiles with the "name": "Default" and "My Custom Profile" under the urlContentProfiles. Later we also associated these profiles in "graphql-profiles". - -GraphQL configuration example: - -In this example we define a custom GraphQL profile and use it on one URL, while assigning the default profile to another one. - -```shell -{ - "name": "graphql_policy", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "caseInsensitive": false, - "enforcementMode": "blocking", - - "graphql-profiles": [ - { - "attackSignaturesCheck": true, - "defenseAttributes": { - "allowIntrospectionQueries": true, - "maximumBatchedQueries": "any", - "maximumQueryCost": "any", - "maximumStructureDepth": "any", - "maximumTotalLength": "any", - "maximumValueLength": "any", - "tolerateParsingWarnings": true - }, - "description": "Default GraphQL Profile", - "metacharElementCheck": true, - "name": "Default", - "responseEnforcement": { - "blockDisallowedPatterns": false - } - }, - { - "attackSignaturesCheck": true, - "defenseAttributes": { - "allowIntrospectionQueries": true, - "maximumBatchedQueries": "any", - "maximumQueryCost": "any", - "maximumStructureDepth": "any", - "maximumTotalLength": "400", - "maximumValueLength": "any", - "tolerateParsingWarnings": false - }, - "description": "my custom Profile", - "metacharElementCheck": true, - "name": "My Custom Profile", - "responseEnforcement": { - "blockDisallowedPatterns": true, - "disallowedPatterns": ["pattern1", "pattern2"] - } - } - ], - "urls": [ - { - "$action": "delete", - "method": "*", - "name": "*", - "protocol": "http", - "type": "wildcard" - }, - { - "isAllowed": true, - "name": "/graphql", - "protocol": "http", - "type": "explicit", - "performStaging": false, - "urlContentProfiles": [ - { - "contentProfile": { - "name": "Default" - }, - "headerValue": "*", - "headerName": "*", - "headerOrder": "default", - "type": "graphql" - } - ] - }, - { - "isAllowed": true, - "name": "/mygraphql", - "protocol": "http", - "type": "explicit", - "performStaging": false, - "urlContentProfiles": [ - { - "contentProfile": { - "name": "My Custom Profile" - }, - "headerValue": "*", - "headerName": "*", - "headerOrder": "default", - "type": "graphql" - } - ] - } - ] -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/associating-profiles-urls.md b/content/includes/nap-waf/config/common/associating-profiles-urls.md deleted file mode 100644 index 32759a008..000000000 --- a/content/includes/nap-waf/config/common/associating-profiles-urls.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -nd-docs: "DOCS-1555" ---- - -As with JSON and XML profiles, in order for a gRPC Content Profile to become effective, it has to be associated with a URL that represents the service. However, in the sample policy above, the profile was apparently not associated with any URL and yet the profile is active. How did this happen? By setting `associateUrls` with `true`, App Protect **implicitly** creates the URL based on the package and service name as defined in the IDL file and associates the profile with that URL. In this example, the URL is `/myorg.services.photo_album/*`. Note it is a wildcard URL so that all methods in this service match it in its suffix; for example `/myorg.services.photo_album/get_photos` represents the `get_photos` RPC method. - -Automatic association with URLs (`associateUrls` is `true`) is the recommended method of configuring gRPC protection, but if your gRPC services are mapped to URLs in a different manner, you can always explicitly associate a gRPC Content Profile with a different or an additional URL than the one implied by the service name, as in this example: - -```json -{ - "policy": { - "name": "my-special-grpc-service-policy", - "grpc-profiles": [ - { - "name": "special_service_profile", - "associateUrls": false, - "defenseAttributes": { - "maximumDataLength": "any", - "allowUnknownFields": true - }, - "attackSignaturesCheck": true, - "idlFiles": [ - { - "idlFile": { - "$ref": "file:///grpc_files/special_service.proto" - }, - "isPrimary": true - } - ] - } - ], - "urls": [ - { - "name": "/services/unique/special/*", - "method": "POST", - "type": "wildcard", - "isAllowed": true, - "urlContentProfiles": [ - { - "contentProfile": { - "name": "special_service_profile" - }, - "headerName": "*", - "headerOrder": "default", - "headerValue": "*", - "type": "grpc" - } - ] - }, - { - "name": "*", - "type": "wildcard", - "method": "*", - "$action": "delete" - } - ] - } -} -``` - -You can always override the properties of the URL with the gRPC Content Profile even if you use `associateUrls` to `true`. For example, you can turn off meta character checks by adding `"metacharsOnUrlCheck": false` within the respective URL entry. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/attack-types.md b/content/includes/nap-waf/config/common/attack-types.md deleted file mode 100644 index 520850bd6..000000000 --- a/content/includes/nap-waf/config/common/attack-types.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -nd-docs: "DOCS-1570" ---- - -Each signature, factory or user-defined, and violation has an **Attack Type**, the attack vector it protects from. When you create a user-defined signature you associate it with the most appropriate attack type from the list below. If you do not find an Attack Type that matches the threat for which your signature was written, use `Other Application Activity` Attack Type. Attach Types are also useful as part of the filter in user-defined signature **sets**. - -Following is the full list of Attack Types supported in App Protect. Use the **name** of the Attack Type to reference it within the signature or signature set filter. - -{{}} -|Attack Type Name | Description | -| ---| --- | -|Abuse of Functionality | Abuse of Functionality is an attack technique that uses a web site's own features and functionality to consume, defraud, or circumvent access controls mechanisms. | -|Authentication/Authorization Attacks | Authentication/Authorization Attacks occur when a web site permits an attacker to access sensitive content or functionality without having to properly authenticate, or authorize, that resource. | -|Buffer Overflow | Buffer Overflow could be triggered when data written to memory exceeds the allocated size of the buffer for that data. This could lead to the Denial of Service or arbitrary code execution. | -|Cache Poisoning | Cache poisoning is an attack against the integrity of an intermediate Web cache repository, in which genuine content cached for an arbitrary URL is replaced with spoofed content. | -|Command Execution | Web applications can be tricked to execute operating system commands, injected from a remote machine, if user supplied input is not properly checked by the web application. | -|Cross-site Request Forgery | An attacker exploits the web application's assumption and trust that the authenticated user is purposely sending requests to perform actions or commands, while in fact the attacker is causing the user to send the commands without the user's knowledge or consent. | -|Cross Site Scripting (XSS) | Cross Site Scripting (XSS) occurs when a web application does not sanitize user-supplied input and places it directly into the page returned to the user. Usually, the attacker will submit malicious JavaScript, VBScript, ActiveX, HTML, or Flash code to the vulnerable web site. | -|Denial of Service | A denial-of-service (DoS) attack represents a family of attacks aimed to exhaust the application server resources up to a point that the application cannot respond to legitimate traffic, either because it has crashed, or because its slow response renders it effectively unavailable. | -|Detection Evasion | An attempt is made to evade detection of the attack on a web server, by obfuscating the attack using various methods such as encodings and path manipulation. | -|Directory Indexing | This is a directory listing attempt which can lead to information disclosure and possible exposure of sensitive system information. Directory Indexing attacks usually target web servers that are not correctly configured, or which have a vulnerable component that allows Directory Indexing. | -|Forceful Browsing | This attack occurs when an attacker is directly accessing a URL, which could grant access to a restricted part of the web site. | -|HTTP Parser Attack | HTTP parser attack targets the functionality of the HTTP parser in order to crash it or force the parser to work abnormally. | -|HTTP Request Smuggling Attack | Specially crafted HTTP messages can manipulate the web server or cache's standard behavior. This can lead to XSS, and cache poisoning. | -|HTTP Response Splitting | Specially crafted HTTP messages can manipulate the web server or cache's standard behavior. This can lead to XSS, and cache poisoning. | -|Information Leakage | Sensitive information may be present within HTML comments, error messages, source code, or simply left in files which are accessible by remote clients. In addition, attackers can manipulate the application to reveal classified information like credit card numbers. This can lead to the disclosure of sensitive system information which may be used by an attacker to further compromise the system. | -|Insecure Deserialization | This is an attack against an application that receives serialized objects. An application which does not restrict which objects might be deserialized could be exploited by attackers sending specific object called 'gadgets', that could trigger arbitrary code execution when deserialized. | -|Insecure File Upload | Many applications allow uploading files to the server, such as images or documents. An application that does not correctly restrict the type of the uploaded files or the upload folder path can be exploited by attackers to upload files, called 'WebShells', containing malicious code that later will be executed or override the server configuration. | -|JSON Parser Attack | This attack targets the functionality of the JSON parser in order to crash it or force the parser to work abnormally. | -|LDAP Injection | If user-supplied input is not correctly sanitized, the attacker could change the construction of LDAP statements. Successful exploitation results in information gathering, system integrity compromise, and possible modification of the LDAP tree. | -|Malicious File Upload | Malicious file upload occurs when a user tries to upload a malicious file to the web application. This could allow remote attackers to cause Server Infection, Network Infection, Buffer Overflow and Remote Comma Execution. | -|Non-browser Client | An attempt is made by a non-browser client to explore the site. | -|Other Application Attacks | This is an attack which targets the web application and does not fall in any predefined category. | -|Parameter Tampering | By changing certain parameters in a URL or web page form, attackers can successfully attack the web application business logic. | -|Path Traversal | Path traversal can be used to bypass the web server root and request various files, including system files or private directories and resources. This attack can lead to information disclosure, and possible exposure of sensitive system information. | -|Predictable Resource Location | By making educated guesses, the attacker could discover hidden web site content and functionality, such as configuration, temporary, backup, or sample files. This can lead to the disclosure of sensitive system information which may be used by an attacker to compromise the system. | -|Remote File Include | Remote File Inclusion attacks allow attackers to run arbitrary code on a vulnerable website. | -|Server Side Code Injection | An attacker can submit server-side code by invalidated input. The web server, when parsing malicious input, may execute operating system commands or access restricted files. | -|Server-Side Request Forgery (SSRF) | Some applications receive a URL as input and use it to exchange data with another service. An attacker could provide special URLs to read or update internal resources such as localhost services, cloud metadata servers, internal network web applications or HTTP enabled databases. | -|Server-Side Template Injection | Some applications use server-side templates for better modularity. This attack occurs when a non-sanitized input containing template directives is embedded into a server-side template which then leads to execution of the injected code when rendered. | -|Session Hijacking | An attacker can steal a valid web session from legitimate users in order to gain unauthorized access. | -|SQL-Injection | SQL-Injection occurs when a web application does not sanitize user-supplied input, and places it directly into the SQL statement. This attack allows remote attackers to run SQL statements on the internal database. | -|Trojan/Backdoor/Spyware | This is an attack initiated by some form of malicious code. | -|Vulnerability Scan | An attempt is made using an automatic tool to scan a web server, or an application running on a web server, for a possible vulnerability. | -|XML External Entities (XXE) | This is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. | -|XML Parser Attack | This attack targets the functionality of the XML parser in order to crash it or force the parser to work abnormally. | -|XPath Injection | XPath-Injection occurs when a web application does not sanitize user-supplied input but places it directly into the XML document query. Successful exploitation results in information gathering and system integrity compromise. | -{{}} \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/basic-signature-sets-included-in-app-protect.md b/content/includes/nap-waf/config/common/basic-signature-sets-included-in-app-protect.md deleted file mode 100644 index 43d69be2d..000000000 --- a/content/includes/nap-waf/config/common/basic-signature-sets-included-in-app-protect.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -nd-docs: "DOCS-1568" ---- - -These signatures sets are included but are not part of the default template. - -- All Response Signatures -- All Signatures -- Generic Detection Signatures -- Generic Detection Signatures (High Accuracy) -- Generic Detection Signatures (High/Medium Accuracy) -- High Accuracy Signatures -- Low Accuracy Signatures -- Medium Accuracy Signatures -- OWA Signatures -- WebSphere signatures -- HTTP Response Splitting Signatures -- Other Application Attacks Signatures -- High Accuracy Detection Evasion Signatures \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/bidirectional-streaming-overview.md b/content/includes/nap-waf/config/common/bidirectional-streaming-overview.md deleted file mode 100644 index f55ad2820..000000000 --- a/content/includes/nap-waf/config/common/bidirectional-streaming-overview.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -nd-docs: "DOCS-1565" ---- - -A gRPC service can have a stream of messages on each side: client, server, or both. Bidirectional Streaming leverages HTTP/2 streaming capability, namely the ability to send multiple gRPC messages from either side ended by the message having the `END_STREAM` flag set to 1. - -The Bidirectional Streaming will: - -1. Accept streaming services on either or both sides (client or server) and send a sequence of messages using a read-write stream. -2. Inspect the client messages in the stream and log them one by one. -3. In case of blocking action: - - Send the blocking response. - - Close the stream on both directions. -4. Pass the server messages through without inspection. - -
The below image demonstrates bidirectional streaming (client-side and server-side streaming): - -{{< img src="/grpc/grpc_streaming.png" alt="gRPC Streaming" >}} -
\ No newline at end of file diff --git a/content/includes/nap-waf/config/common/clickjacking-protection.md b/content/includes/nap-waf/config/common/clickjacking-protection.md deleted file mode 100644 index ed7e6f747..000000000 --- a/content/includes/nap-waf/config/common/clickjacking-protection.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -nd-docs: "DOCS-1611" ---- - -Clickjacking refers to a technique used by malicious actors to embed remote website content into their malicious websites, tricking the end users to click on the embedded frames triggering actions the users were not aware of, such as liking a certain Facebook page or giving a restaurant a 5 star rating. To protect against such attacks, F5 WAF for NGINX uses the `X-Frame-Options` header capabilities. The `X-Frame-Options` header is injected by F5 WAF for NGINX to indicate to the browser whether it should embed the content or not. Please note that this additional layer of security is available only in browsers that support the `X-Frame-Options` headers. - -##### Configuration - -`X-Frame-Options` can be configured as follows: -- X-Frame-Options: `deny` - This option will prevent the browser from displaying the content in a frame, regardless of the website trying to do so. -- X-Frame-Options: `only-same` - This option allows the browser to display the content in a frame only if it comes from the same website. - -Please note that a third configuration option was available but it was deprecated by RFC and is not supported by F5 WAF for NGINX. - -To enable this protection in F5 WAF for NGINX, we enable the feature for a URL (or for all URLs, via the wildcard URL), and then set the value to be assigned to the `X-Frame-Options` header. Following is an example of a policy enabling the feature for the URL `/clickme`, and using `only-same` as the value for the `X-Frame-Options` header: - -```json -{ - "name": "x_frame_options", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "urls": [ - { - "name": "/clickme", - "type": "explicit", - "method": "*", - "isAllowed": true, - "clickjackingProtection": true, - "allowRenderingInFrames": "only-same" - } - ] -} -``` - -In the following example, a policy is created with Clickjacking enabled for the URL `/clickme`, and using `DENY` as the value for the `X-Frame-Options` header: - -```json -{ - "name": "x_frame_options", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "urls": [ - { - "name": "/clickme", - "type": "explicit", - "method": "*", - "isAllowed": true, - "clickjackingProtection": true, - "allowRenderingInFrames": "never" - } - ] -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/configure-client-authorization.md b/content/includes/nap-waf/config/common/configure-client-authorization.md deleted file mode 100644 index 81388383d..000000000 --- a/content/includes/nap-waf/config/common/configure-client-authorization.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -nd-docs: "DOCS-1571" ---- - -```nginx -load_module modules/ngx_http_app_protect_module.so; - -http { - server { - listen 127.0.0.1:8080; - server_name localhost; - - location / { - auth_request /scan; - proxy_pass http://localhost:8888; - } - location /scan { - proxy_pass http://localhost:8081$request_uri; - } - } - - server { - listen 127.0.0.1:8081; - server_name localhost; - - location /scan { - app_protect_enable on; - proxy_pass http://localhost:8888; - } - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/configure-nginx-mirror.md b/content/includes/nap-waf/config/common/configure-nginx-mirror.md deleted file mode 100644 index 1a5f75833..000000000 --- a/content/includes/nap-waf/config/common/configure-nginx-mirror.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -nd-docs: "DOCS-1561" ---- - -```nginx -load_module modules/ngx_http_app_protect_module.so; - -http { - log_format test $uri; - - server { - listen 127.0.0.1:8080; - server_name localhost; - - location / { - app_protect_enable on; - mirror /mirror; - } - - location /mirror { - log_subrequest on; - access_log test$args.log test; - } - } -} - -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/configure-njs.md b/content/includes/nap-waf/config/common/configure-njs.md deleted file mode 100644 index 266180b6a..000000000 --- a/content/includes/nap-waf/config/common/configure-njs.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -nd-docs: "DOCS-1579" ---- - -```nginx -load_module modules/ngx_http_app_protect_module.so; -load_module modules/ngx_http_js_module.so; - -http { - js_include service.js - - server { - listen 127.0.0.1:8080; - server_name localhost; - - location / { - app_protect_enable on; - proxy_pass http://127.0.0.1:8081$request_uri; - } - } - - server { - listen 127.0.0.1:8081; - server_name localhost; - - location / { - js_content foo; - } - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/configure-ranges.md b/content/includes/nap-waf/config/common/configure-ranges.md deleted file mode 100644 index 1e13c9e84..000000000 --- a/content/includes/nap-waf/config/common/configure-ranges.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -nd-docs: "DOCS-1544" ---- - -```nginx -load_module modules/ngx_http_app_protect_module.so; - -http { - - server { - listen 127.0.0.1:8080; - server_name localhost; - - location / { - app_protect_enable on; - proxy_pass http://127.0.0.1:8081$request_uri; - } - } - - server { - listen 127.0.0.1:8081; - server_name localhost; - - location / { - proxy_pass http://1.2.3.4$request_uri; - proxy_force_ranges on; - } - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/configure-slice.md b/content/includes/nap-waf/config/common/configure-slice.md deleted file mode 100644 index 413a113bf..000000000 --- a/content/includes/nap-waf/config/common/configure-slice.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -nd-docs: "DOCS-1613" ---- - -```nginx -load_module modules/ngx_http_app_protect_module.so; - -http { - server { - listen 127.0.0.1:8080; - server_name localhost; - - location / { - app_protect_enable on; - proxy_pass http://127.0.0.1:8081$request_uri; - } - } - - server { - listen 127.0.0.1:8081; - server_name localhost; - - location / { - proxy_pass http://1.2.3.4$request_uri; - slice 2; - proxy_set_header Range $slice_range; - } - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/configure-static-location.md b/content/includes/nap-waf/config/common/configure-static-location.md deleted file mode 100644 index 750905c70..000000000 --- a/content/includes/nap-waf/config/common/configure-static-location.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -nd-docs: "DOCS-1581" ---- - -```nginx -load_module modules/ngx_http_app_protect_module.so; - -http { - server { - listen 127.0.0.1:8080; - server_name localhost; - - location / { - app_protect_enable on; - proxy_pass http://127.0.0.1:8080/proxy/$request_uri; - } - - location /proxy { - default_type text/html; - return 200 "Hello! I got your URI request - $request_uri\n"; - } - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/csrf-protection.md b/content/includes/nap-waf/config/common/csrf-protection.md deleted file mode 100644 index fe7b0314c..000000000 --- a/content/includes/nap-waf/config/common/csrf-protection.md +++ /dev/null @@ -1,161 +0,0 @@ ---- -nd-docs: "DOCS-1590" ---- - -CSRF (Cross-Site Request Forgery) is an attack vector in which the victim user that visits a sensitive site such as a bank account, is lured to click on a malicious link attempting a fraudulent operation on that sensitive site. The link may be sent over email or in a hidden frame in another site. F5 WAF for NGINX provides protection against CSRF attacks by validating the Origin header for AJAX POST requests (default configuration). - -##### CSRF Configuration - -There are several settings that can be configured to enable CSRF protection, some are global while others are specific. Following is a list of all the settings that can be configured to enable or customize the CSRF settings: -1. In the `csrf-protection` section, enable CSRF protection. This is a global configuration option and applies to all policy elements. -2. Enable the CSRF violation `VIOL_CSRF` in the violations section (the violation is already enabled in `Alarm` mode in the base template). This is a global configuration option and applies to all policy elements. -3. In the `csrf-urls` section, the user can define method and URL configurations. By default, the wildcard URL `*` with the `POST` method is configured to enforce Origin validation. The default configuration can be deleted to allow for customized configuration for specific methods and URLs. -4. In the `urls` section, you can enable CSRF protection for specific URLs, and define a list of acceptable origins. If the wildcard URL `*` is selected, the configuration becomes global for all URLs. Otherwise, the configuration is applicable only to the specified URL. -5. In the `host-names` section, you can add a list of the domains that are to be accepted when comparing the origin to the hostnames. The user can enable or disable the inclusion of subdomains. This is a global configuration option and applies to all policy elements. - -Please note that: -- Both `VIOL_CSRF` and `csrf-protection` settings need to be enabled for CSRF protection to be active. Disabling either setting will disable CSRF protection altogether. -- Configuring `urls` is required only if there are external origins that have to be allowed. -- `host-names` are internal, owned by the application and used by clients to reach it. The `crossDomainAllowedOrigin` in the `urls` are external domains, from other applications, that we wish to allow as origins. - -##### CSRF Enforcement - -If CSRF is enabled in the violation section and in the `csrf-protection` settings, when receiving a request to a URL that matches one of the `csrf-urls` and all its conditions: method and parameters (if applicable there), then the following conditions must be met: - -1. Origin header must exist in the request. -2. The domain name from the Origin header must match any of the following criteria: - * The Host header in the same request. - * One of the hostnames in the policy. - * One of the allowed origins in the matching URL entity in the policy. - -If the first condition is not met, the validation will fail with the message "Origin header validation failed: Origin is absent". If the second condition fails to match any of the items, the validation will fail with the message "Origin header validation failed: Origin is not allowed". - -##### CSRF Configuration Examples - -In the following example, CSRF Protection is enabled globally (in `Block` mode) with no customization: - -```json -{ - "policy": { - "applicationLanguage": "utf-8", - "name": "csrf_default", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "blocking-settings": { - "violations": [ - { - "name": "VIOL_CSRF", - "alarm": true, - "block": true - } - ] - }, - "csrf-protection": { - "enabled": true - } - } -} -``` - -In the following example, the policy is configured with the following items: -- Enable CSRF Protection globally (in `Block` mode). -- Delete the default wildcard CSRF URL and define a new custom one. -- Define a policy-wide hostname domain without its subdomains. - -```json -{ - "policy": { - "applicationLanguage": "utf-8", - "name": "example_2", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "blocking-settings": { - "violations": [ - { - "name": "VIOL_CSRF", - "alarm": true, - "block": true - } - ] - }, - "csrf-protection": { - "enabled": true - }, - "csrf-urls": [ - { - "$action": "delete", - "method": "POST", - "url": "*" - }, - { - "enforcementAction": "verify-origin", - "method": "POST", - "url": "/operation.aspx" - } - ], - "host-names": [ - { - "name": "example.com", - "includeSubdomains": false - } - ] - } -} -``` - -In the following example, the policy is configured with the following items: -- Enable CSRF Protection globally (violation already in `Alarm` mode in the default policy). -- Delete the default wildcard CSRF URL and define a new custom one. -- Define a policy-wide hostname domain with subdomains. -- Add a custom URL "myurl" where CSRF enforcement is enabled, and define a custom origin for this URL. - -```json -{ - "policy": { - "applicationLanguage": "utf-8", - "name": "example_3", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "csrf-protection": { - "enabled": true - }, - "csrf-urls": [ - { - "$action": "delete", - "method": "POST", - "url": "*" - }, - { - "enforcementAction": "verify-origin", - "method": "POST", - "url": "/csrfurl" - } - ], - "host-names": [ - { - "name": "example.com", - "includeSubdomains": true - } - ], - "urls": [ - { - "name": "/myurl", - "html5CrossOriginRequestsEnforcement": { - "enforcementMode": "enforce", - "crossDomainAllowedOrigin": [ - { - "includeSubDomains": false, - "originName": "foo.com", - "originPort": "all", - "originProtocol": "http/https" - } - ] - } - } - ] - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/custom-log-configuration.md b/content/includes/nap-waf/config/common/custom-log-configuration.md deleted file mode 100644 index 59a231191..000000000 --- a/content/includes/nap-waf/config/common/custom-log-configuration.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -nd-docs: "DOCS-1585" ---- - -A new directive `app_protect_custom_log_attribute` will be added to the `nginx.conf` file. You can set this directive at all scopes: http, server and location. The setting at the location scope overrides the setting in the server and/or http scopes and the server scope overrides the http scope. The `app_protect_custom_log_attribute` directive syntax will consist of a **name/value** or **key/value** pair i.e. "app_protect_custom_log_attribute ". - -Example Configuration: - -In the below example, we are configuring the `app_protect_custom_log_attribute` directive at the server and location level where we define the **key/value** pair as one string. - -```nginx - -user nginx; -load_module modules/ngx_http_app_protect_module.so; -error_log /var/log/nginx/error.log debug; - -events { - worker_connections 65536; -} -server { - - listen 80; - - server_name localhost; - proxy_http_version 1.1; - app_protect_custom_log_attribute ‘environment' 'env1'; - - location / { - - app_protect_enable on; - app_protect_custom_log_attribute gateway gway1; - app_protect_custom_log_attribute component comp1; - proxy_pass http://172.29.38.211:80$request_uri; - } - } -``` - -The **key/value** pair will be 'environment env1', ‘gateway gway1’ and ‘component comp1’ in the above examples, i.e. - -- app_protect_custom_log_attribute environment env1; -- app_protect_custom_log_attribute gateway gway1; -- app_protect_custom_log_attribute component comp1; - -The above key/value pair will be parsed as below: - -```shell -"customLogAttributes": [ - { - "name": "gateway", - "value": "gway1" - }, - { - "name": "component", - "value": "comp1" - }, -] -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/custom-log-errors-warnings.md b/content/includes/nap-waf/config/common/custom-log-errors-warnings.md deleted file mode 100644 index b9684fee0..000000000 --- a/content/includes/nap-waf/config/common/custom-log-errors-warnings.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -nd-docs: "DOCS-1560" ---- - -An error message "`app_protect_custom_log_attribute` directive is invalid" will be displayed in the Security Log if the below conditions are met: - -1. If the `app_protect_custom_log_attribute` exceeds the maximum number of 10 directives -2. If the `app_protect_custom_log_attribute` exceeds the maximum name length of 64 chars -3. If the `app_protect_custom_log_attribute` exceeds the maximum value of 64 chars - -Error message example: - -```shell -app_protect_custom_log_attribute directive is invalid. Number of app_protect_custom_log_attribute directives exceeds maximum -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/custom-log-logging-reporting.md b/content/includes/nap-waf/config/common/custom-log-logging-reporting.md deleted file mode 100644 index 0e2ba3e01..000000000 --- a/content/includes/nap-waf/config/common/custom-log-logging-reporting.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -nd-docs: "DOCS-1609" ---- - -When `app_protect_custom_log_attribute` is assigned to a particular location/server/http context, it will appear in the `json_log` field as a new JSON property called "customLogAttributes" at the top level. The property will not appear if no `app_protect_custom_log_attribute` directive was assigned. - -Attributes at the http level applies to all servers and locations unless a specific server or location overrides the same key with a different value. Same goes for the server level and all locations under it. In the below example, the "environment" attribute will appear in logs of all locations under that server. - -Security logging example in json_log: - -```json -""customLogAttribute"":[{""name"":""component"",""value"":""comp1""},{""name"":""gateway"",""value"":""gway1""}]}" -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/custom-log-overview.md b/content/includes/nap-waf/config/common/custom-log-overview.md deleted file mode 100644 index a8bdff796..000000000 --- a/content/includes/nap-waf/config/common/custom-log-overview.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -nd-docs: "DOCS-1614" ---- - -Custom dimensions log entries feature refers to the new configuration in F5 WAF for NGINX, where the new directive called `app_protect_custom_log_attribute` is assigned to a particular location or server or http level in the `nginx.conf` file. The need is to be able to add custom identifiers to the respective location and/or server and identify requests in the Security Log by those identifiers. - -The `app_protect_custom_log_attribute` directive will be used to track the assigned location/server/http dimension of each request by adding the `app_protect_custom_log_attribute` to the **Security Logs** a.k.a **Request Logs**. Since it is a custom attribute a customer can set, that custom attribute will appear for every request log entry that was handled by that location/server. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/custom-log-things-to-remember.md b/content/includes/nap-waf/config/common/custom-log-things-to-remember.md deleted file mode 100644 index 97e18eae5..000000000 --- a/content/includes/nap-waf/config/common/custom-log-things-to-remember.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -nd-docs: "DOCS-1589" ---- - -The `app_protect_custom_log_attribute` directive has a few limitations which should be kept in mind while configuring this directive: - -- Key and value strings are limited to 64 chars -- Maximum possible directive numbers are limited to 10 (in total) in each context i.e. Limit of 10 keys and values \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/deny-allow-never-log-lists.md b/content/includes/nap-waf/config/common/deny-allow-never-log-lists.md deleted file mode 100644 index 24c7b0e5f..000000000 --- a/content/includes/nap-waf/config/common/deny-allow-never-log-lists.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -nd-docs: "DOCS-1604" ---- - -It is possible to define IP addresses or ranges for which the traffic will always be allowed or denied or never logged despite the rest of the configuration settings in the policy. - -1. **Always Allowed** (`"blockRequests": "never"`) - requests from this IP range will be passed even if they have blocking violations. -2. **Always Denied** (`"blockRequests": "always"`) - requests from this IP range will be always blocked even if they have no other blocking violations. The `VIOL_BLACKLISTED_IP` violation will be triggered in this case and its block flag must be set to `true` in order for the request to be actually blocked. -3. **Never Log** (`"neverLogRequests": true`) - requests from this IP range will not be logged even if they were supposed to be in the logging configuration. Note this is independent of the other setting, so the same IP range can be both denied (or allowed) and yet never logged. - -In this IPv4 example, we use the default configuration while enabling the deny list violation. In the configuration section, we define: - -- An always allowed IP 1.1.1.1 -- An always denied IP 2.2.2.2 -- An always allowed range of IPs 3.3.3.0/24 -- An allowed range of IPs 4.4.4.0/24 which should never log - -```json -{ - "policy": { - "name": "allow_deny", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_BLACKLISTED_IP", - "alarm": true, - "block": true - } - ] - }, - "whitelist-ips": [ - { - "blockRequests": "never", - "neverLogRequests": false, - "ipAddress": "1.1.1.1", - "ipMask": "255.255.255.255" - }, - { - "blockRequests": "always", - "ipAddress": "2.2.2.2", - "ipMask": "255.255.255.255" - }, - { - "blockRequests": "never", - "neverLogRequests": false, - "ipAddress": "3.3.3.0", - "ipMask": "255.255.255.0" - }, - { - "blockRequests": "never", - "neverLogRequests": true, - "ipAddress": "4.4.4.0", - "ipMask": "255.255.255.0" - } - ] - } -} -``` - -{{< call-out "note" >}} -The above configuration assumes the IP address represents the original requestor. However, it is also common that the client address may instead represent a downstream proxy device as opposed to the original requestor's IP address. In this case, you may need to configure F5 WAF for NGINX to prefer the use of an `X-Forwarded-For` (or similar) header injected to the request by a downstream proxy in order to more accurately identify the *actual* originator of the request. [See the XFF Headers and Trust](#xff-headers-and-trust) for information regarding the additional settings required for this configuration. -{{< /call-out >}} - - -Here's an example of IPv6 notation with a single address and an IP subnet with a 120-bit prefix: - -The first address is a single IP address, because the mask is all f's. Since this is a default value, there is no need to specify the mask in this case. The second address is a subnet of 120 bits (out of the 128 of an IPv6 address). The trailing 8 bits (128-120) must be **zero** in both the mask and the address itself. - -```json -{ - "policy": { - "name": "allow_deny", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_BLACKLISTED_IP", - "alarm": true, - "block": true - } - ] - }, - "whitelist-ips": [ - { - "ipAddress": "2023::4ef3", - "ipMask": "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff", - "blockRequests": "never" - }, - { - "ipAddress": "2034::2300", - "ipMask": "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ff00", - "blockRequests": "never" - }, - ] - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/detect-base64-string-values.md b/content/includes/nap-waf/config/common/detect-base64-string-values.md deleted file mode 100644 index 15d262132..000000000 --- a/content/includes/nap-waf/config/common/detect-base64-string-values.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -nd-docs: "DOCS-1563" ---- - -The Detect Base64 feature allows F5 WAF for NGINX to detect whether values in string fields in gRPC payload are Base64 encoded. When a value is detected as Base64 encoded F5 WAF for NGINX will enforce the configured signatures on the decoded value __and__ on the original value. - -This feature is disabled by default and can be enabled by setting `decodeStringValuesAsBase64` to `enabled`. - -This has to be used with care because Protocol Buffer protocol is supposed to carry binary fields of "bytes" type and, thus, trying to decode strings as Base64 may lead to false positives. Using Base64-encoded strings for binary data is usually not a good practice but, if the protected app still does that, then enable Base64 detection. - -```json -{ - "policy": { - "applicationLanguage": "utf-8", - "name": "valid_string_encoding_policy", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "idl-files": [ - { - "fileName": "valid_string.proto", - "link": "file:///tmp/grpc/valid_string.proto" - } - ], - "grpc-profiles": [ - { - "name": "base64_decode_strings", - "description": "My first profile", - "idlFiles": [ - { - "idlFile": { - "fileName": "valid_string.proto" - } - }], - "decodeStringValuesAsBase64": "enabled" - } - ] - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/detect-base64.md b/content/includes/nap-waf/config/common/detect-base64.md deleted file mode 100644 index 9bc3e96f4..000000000 --- a/content/includes/nap-waf/config/common/detect-base64.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -nd-docs: "DOCS-1593" ---- - -The Detect Base64 feature allows F5 WAF for NGINX to detect whether values in headers, cookies, and parameters are Base64 encoded. When an entity is detected as Base64 encoded F5 WAF for NGINX will enforce the configured signatures on the decoded value, instead of on the original value. - -This feature is disabled by default or by setting the `decodeValueAsBase64` to `disabled`. - -There is a small risk that the system will wrongly detect a field value as Base64 decodable, when it's actually not. In that case signatures will not be detected properly. To mitigate this, set `decodeValueAsBase64` to `disabled` on known non Base64 entities. - -```json -{ - "policy": { - "name": "detect_base64", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "cookies": [ - { - "name": "username", - "type": "explicit", - "decodeValueAsBase64": "disabled" - } - ], - "parameters": [ - { - "name": "catchPhrase", - "type": "explicit", - "decodeValueAsBase64": "disabled" - } - ], - "headers": [ - { - "name": "Catch-Phrase", - "type": "explicit", - "decodeValueAsBase64": "disabled" - } - ] - } -} -``` - -If `decodeValueAsBase64` is set to `required`, then a violation is raised if the value is not Base64 decodable. - -In this example we already know which specific entity values are Base64 decodable, so we set the value of `decodeValueAsBase64` to `required` to raise a violation if the value is not Base64 decodable: -```json -{ - "policy": { - "name": "detect_base64", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_PARAMETER_VALUE_BASE64", - "alarm": true, - "block": true - } - ] - }, - - "cookies": [ - { - "name": "mySession", - "type": "explicit", - "decodeValueAsBase64": "required" - } - ], - "parameters": [ - { - "name": "myId", - "type": "explicit", - "decodeValueAsBase64": "required" - } - ], - "headers": [ - { - "name": "My-Header", - "type": "explicit", - "decodeValueAsBase64": "required" - } - ] - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/disallow-application-use-geolocation.md b/content/includes/nap-waf/config/common/disallow-application-use-geolocation.md deleted file mode 100644 index 9d605a922..000000000 --- a/content/includes/nap-waf/config/common/disallow-application-use-geolocation.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -nd-docs: "DOCS-1547" ---- - -For applications protected by app protect, you can use Geolocation enforcement to restrict or allow application use in specific countries. You can adjust the lists of which countries or locations are allowed or disallowed in a app protect security policy. If the user tries to access the web application from a location that is not allowed, the `VIOL_GEOLOCATION` violation will be triggered. By default, all locations are allowed, and the alarm and block flags are enabled. - -Requests from certain locations, such as RFC-1918 addresses or unassigned global addresses, do not include a valid country code. The geolocation is shown as **N/A** in both the request and the list of geolocations. You have the option to disallow N/A requests whose country of origination is unknown. - -For example, in the policy provided below, within the "disallowed-geolocations" section, "countryCode": IL and "countryName": Israel have been included. This signifies that requests originating from these locations will raise an alarm, trigger the `VIOL_GEOLOCATION` violation and will be blocked. - - -```shell -"general": { - "customXffHeaders": [], - "trustXff": true - }, -"disallowed-geolocations" : [ - { - "countryCode" : "IL", - "countryName" : "Israel" - } - ], -"blocking-settings": { - "violations": [ - { - "name": "VIOL_GEOLOCATION", - "alarm": true, - "block": true - } - ] -} - -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/disallowed-file-types.md b/content/includes/nap-waf/config/common/disallowed-file-types.md deleted file mode 100644 index a2466410d..000000000 --- a/content/includes/nap-waf/config/common/disallowed-file-types.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -nd-docs: "DOCS-1556" ---- - -The following file types are disallowed by default: - -* bak, bat, bck, bkp, cfg, conf, config, ini, log, old, sav, save, temp, tmp -* bin, cgi, cmd, com, dll, exe, msi, sys, shtm, shtml, stm -* cer, crt, der, key, p12, p7b, p7c, pem, pfx -* dat, eml, hta, htr, htw, ida, idc, idq, nws, pol, printer, reg, wmz \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/do-nothing-and-user-defined-parameters.md b/content/includes/nap-waf/config/common/do-nothing-and-user-defined-parameters.md deleted file mode 100644 index 5627e1b85..000000000 --- a/content/includes/nap-waf/config/common/do-nothing-and-user-defined-parameters.md +++ /dev/null @@ -1,351 +0,0 @@ ---- -nd-docs: "DOCS-1586" ---- - -The do-nothing in urlContentProfiles allows the user to avoid inspecting or parsing the content in a policy, and instead handle the request's header according to the specifications outlined in the security policy. - -In this example, we configure do-nothing content types for a specific user-defined URL: - -```json -{ - "policy" : { - "name": "ignore_body", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "urls": [ - { - "method": "*", - "name": "*", - "type": "wildcard", - "urlContentProfiles": [ - { - "headerName": "*", - "headerOrder": "default", - "headerValue": "*", - "type": "do-nothing" - } - ] - } - ] - } -} -``` - - -#### User-Defined Parameters - -So far, we have been managing the default parameter or * entity. What if we want to give specific attributes to specific parameters? This can be done by creating and configuring the user-defined parameters. This feature gives the user full control over what the parameter should include, where it should be located and allows for granularity in configuring each and every parameter. Here you can: - -- Create unique parameters and specify attributes for each. -- Define what data type the parameter should contain. -- Define the allowed location where you expect to see a parameter. -- Define minimum/maximum values and minimum/maximum lengths for a parameter. -- Define whether a parameter is mandatory or not. -- Define whether the parameter can have empty values or not. -- Define whether to inspect a parameter for violations, attack signatures, or meta-characters. -- Decide whether to exclude certain violations, attack signatures, or meta-characters for a parameter. - -In the following example, we configure two parameters. The first one, `text`, takes string values (here configured as alpha-numeric), and limits the length of the allowed string between 4 and 8 characters. Any string below or above these values will trigger the violation `VIOL_PARAMETER_VALUE_LENGTH`. Note that we enable this violation to *block* the violating request. - -The second parameter, `query`, is added to the policy just to avoid a false positive condition due to a specific signature, `200002835`. Suppose you realized that whenever this signature detected on this parameter, it was false positive. You would like to disable this signature, but only in the context of this parameter. The signature will still be detected on values of other parameters. - -```json -{ - "policy": { - "name": "user_defined_parameters_data_types", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_PARAMETER_VALUE_LENGTH", - "alarm": true, - "block": true - } - ] - }, - "parameters": [ - { - "name": "text", - "type": "explicit", - "parameterLocation": "any", - "mandatory": false, - "allowEmptyValue": false, - "allowRepeatedParameterName": false, - "sensitiveParameter": false, - "valueType": "user-input", - "dataType": "alpha-numeric", - "checkMinValueLength": true, - "checkMaxValueLength": true, - "minimumLength": 4, - "maximumLength": 8 - }, - { - "name": "query", - "type": "explicit", - "valueType": "user-input", - "dataType": "alpha-numeric", - "signatureOverrides": [ - { - "enabled": false, - "signatureId": 200002835 - } - ] - } - ] - } -} -``` - -In the next example, we configure a numeric parameter. This parameter accepts only integer values and allows values between 9 and 99 (non-inclusive). If the request includes anything other than an integer, it will trigger the `VIOL_PARAMETER_DATA_TYPE` violation. If the parameter value falls beyond or below the desired values, it will trigger the `VIOL_PARAMETER_NUMERIC_VALUE` violation. Note that if you change the values of `exclusiveMin` and `exclusiveMax` to false, values equal to the boundary values will be accepted (namely 9 and 99). - -```json -{ - "policy": { - "name": "user_defined_parameters_data_types", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_PARAMETER_NUMERIC_VALUE", - "alarm": true, - "block": true - }, - { - "name": "VIOL_PARAMETER_VALUE_LENGTH", - "alarm": true, - "block": true - }, - { - "name": "VIOL_PARAMETER_STATIC_VALUE", - "alarm": true, - "block": true - }, - { - "name": "VIOL_PARAMETER_DATA_TYPE", - "alarm": true, - "block": true - } - ] - }, - "parameters": [ - { - "name": "number", - "type": "explicit", - "parameterLocation": "any", - "mandatory": false, - "allowEmptyValue": false, - "allowRepeatedParameterName": false, - "sensitiveParameter": false, - "valueType": "user-input", - "dataType": "integer", - "checkMinValue": true, - "checkMaxValue": true, - "minimumValue": 9, - "maximumValue": 99, - "exclusiveMin": true, - "exclusiveMax": true - } - ] - } -} -``` - -For increased granularity, you can configure whether the parameter value is also a multiple of a specific number. This is useful when you wish to limit the input to specific values. The following example configures a parameter that accepts values in the range of 0 to 10 and are only multiples of 3. This means that the accepted values are 3, 6 and 9. Any other value will trigger the `VIOL_PARAMETER_NUMERIC_VALUE` violation. - -```json -{ - "policy": { - "name": "user_defined_parameters_data_types", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_PARAMETER_NUMERIC_VALUE", - "alarm": true, - "block": true - }, - { - "name": "VIOL_PARAMETER_VALUE_LENGTH", - "alarm": true, - "block": true - }, - { - "name": "VIOL_PARAMETER_STATIC_VALUE", - "alarm": true, - "block": true - }, - { - "name": "VIOL_PARAMETER_DATA_TYPE", - "alarm": true, - "block": true - } - ] - }, - "parameters": [ - { - "name": "multiples", - "type": "explicit", - "parameterLocation": "any", - "mandatory": false, - "allowEmptyValue": false, - "allowRepeatedParameterName": false, - "sensitiveParameter": false, - "valueType": "user-input", - "dataType": "integer", - "checkMinValue": true, - "checkMaxValue": true, - "minimumValue": 0, - "maximumValue": 10, - "checkMultipleOfValue": true, - "multipleOf": 3 - } - ] - } -} -``` - -Another very useful example is when the user wants to limit the parameter to a single context, like in a header or a query string. If the same variable appears in a different location, it will trigger the `VIOL_PARAMETER_LOCATION` violation. - -```json -{ - "policy": { - "name": "user_defined_parameters_misc_test", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_PARAMETER_NUMERIC_VALUE", - "alarm": true, - "block": true - }, - { - "name": "VIOL_PARAMETER_VALUE_LENGTH", - "alarm": true, - "block": true - }, - { - "name": "VIOL_PARAMETER_STATIC_VALUE", - "alarm": true, - "block": true - }, - { - "name": "VIOL_PARAMETER_DATA_TYPE", - "alarm": true, - "block": true - }, - { - "name": "VIOL_PARAMETER_LOCATION", - "alarm": true, - "block": true - } - ] - }, - "parameters": [ - { - "name": "headerparam", - "type": "explicit", - "parameterLocation": "header", - "mandatory": false, - "allowEmptyValue": false, - "allowRepeatedParameterName": false, - "sensitiveParameter": false, - "valueType": "user-input", - "dataType": "alpha-numeric", - "checkMinValueLength": false, - "checkMaxValueLength": false - } - ] - } -} -``` - -Another very useful example is the following configuration. It has: -- A sensitive parameter `mypass` that should be masked in the logs. -- A parameter `empty` that is allowed to be empty. -- A parameter `repeated` that can be repeated multiple times. -- A parameter `mandatory` that is mandatory for all requests. - -Note that new violations were enabled so that the configuration becomes effective. - -```json -{ - "policy": { - "name": "user_defined_parameters_misc_test", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_PARAMETER_EMPTY_VALUE", - "alarm": true, - "block": true - }, - { - "name": "VIOL_PARAMETER_REPEATED", - "alarm": true, - "block": true - }, - { - "name": "VIOL_MANDATORY_PARAMETER", - "alarm": true, - "block": true - }, - { - "name": "VIOL_PARAMETER", - "alarm": true, - "block": true - } - ] - }, - "parameters": [ - { - "name": "mypass", - "type": "explicit", - "parameterLocation": "any", - "sensitiveParameter": true, - "valueType": "auto-detect" - }, - { - "name": "empty", - "type": "explicit", - "parameterLocation": "any", - "mandatory": false, - "allowEmptyValue": true, - "allowRepeatedParameterName": false, - "sensitiveParameter": false, - "valueType": "auto-detect" - }, - { - "name": "repeated", - "type": "explicit", - "parameterLocation": "any", - "mandatory": false, - "allowEmptyValue": false, - "allowRepeatedParameterName": true, - "sensitiveParameter": false, - "valueType": "auto-detect" - }, - { - "name": "mandatory", - "type": "explicit", - "parameterLocation": "any", - "mandatory": true, - "allowEmptyValue": false, - "allowRepeatedParameterName": false, - "sensitiveParameter": false, - "valueType": "auto-detect" - } - ] - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/enforcer-cookie-settings.md b/content/includes/nap-waf/config/common/enforcer-cookie-settings.md deleted file mode 100644 index c128b3978..000000000 --- a/content/includes/nap-waf/config/common/enforcer-cookie-settings.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -nd-docs: "DOCS-1608" ---- - -F5 WAF for NGINX generates its own cookies and adds them on top of the application cookies. - -These are called Enforcer Cookies. - -You can control the attributes within these cookies: - -* `httpOnlyAttribute`: Whether or not to add HttpOnly attribute, value is either `true` or `false`, default is **true**. -* `secureAttribute`: Whether or not to add Secure attribute, value is either `always` or `never`, default is **always**. -* `sameSiteAttribute`: In which mode to add SameSite attribute, value is one of: `none-value`, `lax`, `strict` or `none`, default is **strict**. Use `none` in order to not add this attribute to the cookie at all. - -In this example, we configure HttpOnly to be `true`, Secure to be `never`, and SameSite to be `strict`. - -```json -{ - "policy": { - "name": "cookie_attrs_configured", - "template": { "name":"POLICY_TEMPLATE_NGINX_BASE" }, - "enforcer-settings": { - "enforcerStateCookies": { - "httpOnlyAttribute": true, - "secureAttribute": "never", - "sameSiteAttribute": "strict" - } - } - } -} -``` - -* `httpOnlyAttribute`: Default value was `true` for all policies. -* `secureAttribute`: Default value was `never` in the default policy, and `always` in the strict and API policies. -* `sameSiteAttribute`: Default value was `lax` in the default and API policies, and `strict` in the strict policy. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/evasion-techniques-subviolations.md b/content/includes/nap-waf/config/common/evasion-techniques-subviolations.md deleted file mode 100644 index b4250c0ba..000000000 --- a/content/includes/nap-waf/config/common/evasion-techniques-subviolations.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -nd-docs: "DOCS-1542" ---- - -The following table specifies the Evasion Techniques sub-violation settings. All are supported in F5 WAF for NGINX. - -{{}} -|Sub-Violation | Default Template | Description | -| ---| ---| --- | -|%u decoding | Enabled | Performs Microsoft %u unicode decoding (%UXXXX where X is a hexadecimal digit). For example, the system turns a%u002fb to a/b. The system performs this action on URI and parameter input to evaluate if the request contains an attack. | -|Apache whitespace | Enabled | The system detects the following characters in the URI: 9 (0x09), 11 (0x0B), 12 (0x0C), and 13 (0x0D). | -|Bad unescape | Enabled | The system detects illegal HEX encoding. Reports unescaping errors (such as %RR). | -|Bare byte decoding | Enabled | The system detects higher ASCII bytes (greater than 127). | -|Directory traversals | Enabled | Ensures that directory traversal commands like ../ are not part of the URL. While requests generated by a browser should not contain directory traversal instructions, sometimes requests generated by JavaScript have them. | -|IIS backslashes | Enabled | Normalizes backslashes (\\) to slashes (/) for further processing. | -|IIS Unicode codepoints | Enabled | Handles the mapping of IIS specific non-ASCII codepoints. Indicates that, when a character is greater than '0x00FF', the system decodes %u according to an ANSI Latin 1 (Windows 1252) code page mapping. For example, the system turns a%u2044b to a/b. The system performs this action on URI and parameter input. | -|Multiple decoding | Enabled: 3 | The system decodes URI and parameter values multiple times according to the number specified before the request is considered an evasion. | -{{}} \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/filetypes-and-responses.md b/content/includes/nap-waf/config/common/filetypes-and-responses.md deleted file mode 100644 index cc8231a63..000000000 --- a/content/includes/nap-waf/config/common/filetypes-and-responses.md +++ /dev/null @@ -1,191 +0,0 @@ ---- -nd-docs: "DOCS-1617" ---- - -A user can enable/disable specific file types in the policy. - -In this example, we enable the file type violation in blocking mode. In the detailed configuration, we allow the \* wildcard entity which would allow all file types by default. In the last section, we explicitly disable the `bat` file type. This is an example of allowing all, but specifically blocking (via deny list) certain items. You may add as many file types as you wish, each declared in its own curly brackets, along with the `"allowed": false` directive. - -```json -{ - "policy": { - "name": "policy1", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_FILETYPE", - "alarm": true, - "block": true - } - ] - }, - "filetypes": [ - { - "name": "*", - "type": "wildcard", - "allowed": true, - "checkPostDataLength": false, - "postDataLength": 4096, - "checkRequestLength": false, - "requestLength": 8192, - "checkUrlLength": true, - "urlLength": 2048, - "checkQueryStringLength": true, - "queryStringLength": 2048, - "responseCheck": false - }, - { - "name": "bat", - "allowed": false - } - ] - } -} -``` - - -#### Response Signatures -All Response Signatures are attack signatures detected on the response side, in contrast to the request side. - - -#### Restrict Response Signatures - -Restrict Response Signatures enhancement assists the users in saving time by limiting the search for response signatures to a specified amount. You can enable the signature verification in the response by setting the `responseCheck` parameter to true. However, the restriction of certain signatures is set in the policy and then enforced by the App Protect. - -In the policy base template under the "filetypes" section, make sure you enable the `responseCheck` attribute for `responseCheckLength` to work properly. The default value of `responseCheck` parameter is set to false. - -The `responseCheckLength` parameter refers to the number of uncompressed bytes in the response body prefix that are examined for signatures. The `responseCheckLength` field will be added with the default value of **20000** bytes which means that the first 20,000 bytes of the response body will undergo signature verification. - -Restrict Response Signature example: - -In the below policy example, in the "filetypes" section, the `responseCheck` parameter is set to true, indicating that response check will be enabled. -When enforcing signatures on the response, we have the flexibility to restrict the portion of the response body that requires validation. In this case, the policy is configured with `responseCheckLength` set to 1000, signifying that only the initial 1000 bytes of the response body will undergo signature verification. - -```json -{ - "policy": { - "name": "response_signatures_block", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "filetypes": [ - { - "name": "*", - "type": "wildcard", - "responseCheck": true, - "responseCheckLength": 1000 - } - ], - "signature-sets": [ - { - "name": "All Response Signatures", - "block": true, - "alarm": true - } - ] - } -} -``` - -#### How Does Restrict Response Signature Check Work? - -The response signature check is always done on the configured `responseCheckLength` as described above. Usually F5 WAF for NGINX will buffer only that part of the response saving memory and CPU, but in some conditions the whole response may have to be buffered, such as when the response body is compressed. - -#### Allowed Methods - -In the policy, you can specify what methods to allow or disallow. - -In this example, we enable the illegal method violation in blocking mode. In the methods configuration, we define which of the methods are allowed. If a method is allowed by default, it can be disallowed via `"$action": "delete"`. In the following example we disallow the default allowed method `PUT` by removing it from the default enforcement. For illustrative purposes this example also has all the other methods that are allowed by default defined in the configuration, but in practicality they do not actually need to be included explicitly to be allowed: - - -```json -{ - "policy": { - "name": "blocking_policy", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_METHOD", - "alarm": true, - "block": true - } - ] - }, - "methods": [ - { - "name": "GET" - }, - { - "name": "POST" - }, - { - "name": "HEAD" - }, - { - "name": "PUT", - "$action": "delete" - }, - { - "name": "PATCH" - }, - { - "name": "DELETE" - }, - { - "name": "OPTIONS" - } - ] - } -} -``` - -#### Custom Method Enforcement - -To enable any custom method other than the above mentioned HTTP standard methods, the user must configure the specific modules that allow those methods. NGINX will reject any custom method other than the standard allowed HTTP methods GET, POST, PUT, DELETE, HEAD, and OPTIONS. - -For example, see currently supported [WebDAV Methods](https://nginx.org/en/docs/http/ngx_http_dav_module.html). - -#### Response Codes - -Response codes are a general setting that defines which response codes are acceptable, while all others will be blocked. - -In this example, we enable the response status codes violation in blocking mode. In the general configuration, we define which of the response codes are allowed. This would mean that all others will be considered as illegal response codes and will be blocked. In this configuration, you specify a list of comma-separated response codes that are allowed. - - -```json -{ - "policy": { - "name": "allowed_response", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_HTTP_RESPONSE_STATUS", - "alarm": true, - "block": true - } - ] - }, - "general": { - "allowedResponseCodes": [ - 400, - 401, - 403, - 404, - 502, - 499 - ] - } - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/first-match-principle.md b/content/includes/nap-waf/config/common/first-match-principle.md deleted file mode 100644 index 60caf2f69..000000000 --- a/content/includes/nap-waf/config/common/first-match-principle.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -nd-docs: "DOCS-1572" ---- - -The policy enforcement operates on the **first match** principle. This principle is applied when multiple conditions match or are similar, indicating that any incoming requests that match the first condition will be processed. In the following example, the "override_rules_example2" policy uses two override rules: "this_rule_will_match" and "non_matching_rule". Since both conditions match, the first match principle will be applied, and requests with "api" in the URI will be processed. It will reference an external policy file named "NginxStrictPolicy.json" to override the current policy. . - -For example: - -```shell -{ - "policy": { - "name": "override_rules_example2", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "override-rules": [ - { - "name": "this_rule_will_match", - "condition": "uri.contains('api')", - "actionType": "replace-policy", - "override": { - "$ref": "file:///NginxStrictPolicy.json" - } - }, - { - "name": "non_matching_rule", - "condition": "uri.contains('api') and not clientIp == '192.168.0.10'", - "actionType": "extend-policy", - "override": { - "policy": { - "enforcementMode": "transparent" - } - } - } - ] - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/forward-proxy-conf.md b/content/includes/nap-waf/config/common/forward-proxy-conf.md deleted file mode 100644 index eca8f09bc..000000000 --- a/content/includes/nap-waf/config/common/forward-proxy-conf.md +++ /dev/null @@ -1,20 +0,0 @@ -Enable Forward Proxy Settings for IP Intelligence Client. - -To configure proxy settings, edit the client configuration file: -Path: -```shell -/etc/app_protect/tools/iprepd.cfg -``` -Example configuration: -```shell -EnableProxy=True -ProxyHost=5.1.2.4 -ProxyPort=8080 -ProxyUsername=admin # Optional -ProxyPassword=admin # Optional -CACertPath=/etc/ssl/certs/ca-certificates.crt # Optional -``` -After saving the changes, restart the client to apply the new settings. -```shell -/opt/app_protect/bin/iprepd /etc/app_protect/tools/iprepd.cfg > ipi.log 2>&1 & -``` diff --git a/content/includes/nap-waf/config/common/geolocation-override-rules.md b/content/includes/nap-waf/config/common/geolocation-override-rules.md deleted file mode 100644 index 56394ded4..000000000 --- a/content/includes/nap-waf/config/common/geolocation-override-rules.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -nd-docs: "DOCS-1567" ---- - -The below example represents a security policy for a web application. The policy named as "override_rule_example" is based on a template called "POLICY_TEMPLATE_NGINX_BASE." The policy is set to operate in "blocking" mode, which means it will prevent certain activities. - -There's a specific configuration under "general" that deals with custom headers for cross-origin requests, specifically the "xff" header. The policy is configured to trust this header. - -In the "override-rules" section there is one override rule named "myFirstRule." This rule is set up to trigger when the geolocation of a request is identified as 'IL' (Israel). When this condition is met, the action taken is to extend the policy, but with a change in enforcement mode to "transparent." - -In simpler terms, when someone tries to access the web application from Israel ('IL'), the security policy will be adjusted to allow the access but in a more transparent manner, meaning it won't block the access but may monitor it differently. - -```json -{ - "policy": { - "name": "override_rule_example", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "enforcementMode": "blocking", - "general": { - "customXffHeaders": ["xff"], - "trustXff": true - }, - "override-rules": [ - { - "name": "myFirstRule", - "condition": "geolocation == 'IL'", - "actionType": "extend-policy", - "override": { - "policy": { - "enforcementMode": "transparent" - } - } - } - ] - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/geolocation-overview.md b/content/includes/nap-waf/config/common/geolocation-overview.md deleted file mode 100644 index 9502ba761..000000000 --- a/content/includes/nap-waf/config/common/geolocation-overview.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -nd-docs: "DOCS-1615" ---- - -Geolocation refers to the process of assessing or determining the geographic location of an object. This feature helps in identifying the geographic location of a client or web application user. - -In F5 WAF for NGINX, the Enforcer will look up the client IP address in the Geolocation file included in the app protect package, and extract the corresponding [ISO 3166](https://www.iso.org/obp/ui/#search) two-letter code, representing the country. For instance, "IL" denotes Israel. This information is denoted as "geolocation" in the condition and is also included in the request reporting. diff --git a/content/includes/nap-waf/config/common/graphql-advanced-config.md b/content/includes/nap-waf/config/common/graphql-advanced-config.md deleted file mode 100644 index 30221b397..000000000 --- a/content/includes/nap-waf/config/common/graphql-advanced-config.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -nd-docs: "DOCS-1551" ---- - -The below sections provides details about enabling GraphQL with advanced configuration. - -In advanced configuration, GraphQL policy consists of GraphQL Violations, GraphQL Profile and the URL section. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/graphql-define-url-settings.md b/content/includes/nap-waf/config/common/graphql-define-url-settings.md deleted file mode 100644 index 9a4e59b5b..000000000 --- a/content/includes/nap-waf/config/common/graphql-define-url-settings.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -nd-docs: "DOCS-1588" ---- - -The second step to configure GraphQL is to define the URL settings. Set the values for "isAllowed": **true**, "name": **/graphql** in the URLs section, which means URLs with **/graphql** name are permitted. This path will be used for all GraphQL API requests. - -Under the "urlContentProfiles" settings define the GraphQL profile name, headerValue: `*` (wildcard), headerName: `*` (wildcard), headerOrder: `default` (allowing any GraphQL URL request with any headerValue, headerName and type should be `graphql`. - -There are no restrictions on the number of GraphQL profiles that can be added by the user. - -GraphQL URL example: - -```shell - "urls": [ - { - "$action": "delete", - "method": "*", - "name": "*", - "protocol": "http", - "type": "wildcard" - }, - { - "isAllowed": true, - "name": "/graphql", - "protocol": "http", - "type": "explicit", - "performStaging": false, - "urlContentProfiles": [ - { - "contentProfile": { - "name": "Default" - }, - "headerValue": "*", - "headerName": "*", - "headerOrder": "default", - "type": "graphql" - } - ] - } - ] -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/graphql-overview.md b/content/includes/nap-waf/config/common/graphql-overview.md deleted file mode 100644 index f06189e83..000000000 --- a/content/includes/nap-waf/config/common/graphql-overview.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -nd-docs: "DOCS-1595" ---- - -GraphQL is an API technology that has grown rapidly in recent years and is continuing to gain traction. GraphQL is a query language designed for APIs to use in the development of client applications that access large data sets with intricate relations among themselves. It provides an intuitive application and flexible syntax for describing data requirements.
- -GraphQL provides a more efficient, powerful and flexible alternative to REST APIs. This makes it easier to retrieve the data you require in a single request and helps in overcoming challenges which include under-fetching and over-fetching of data. GraphQL also enables faster front-end development without the need for new API endpoints (GraphQL works on a single endpoint), great backend analytics using GraphQL queries and a structured schema and type system. - -GraphQL also allows the client to specify exactly what data it needs, reducing the amount of data transferred over the network and improving the overall performance of the application. - -In the following sections, you will learn more about enabling GraphQL configuration (using basic and advanced configuration) plus GraphQL security, GraphQL profile and URL settings. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/graphql-response-pages.md b/content/includes/nap-waf/config/common/graphql-response-pages.md deleted file mode 100644 index 73ed50f16..000000000 --- a/content/includes/nap-waf/config/common/graphql-response-pages.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -nd-docs: "DOCS-1557" ---- - -A GraphQL error response page is returned when a request is blocked. This GraphQL response page, like other blocking response pages, can be customized, but the GraphQL JSON syntax must be preserved for them to be displayed correctly. The default page returns the GraphQL status code Blocking Response Page (BRP) and a short JSON error message which includes the support ID. - -For example: - -```shell -"response-pages": [ - { - "responsePageType": "graphql", - "responseActionType": "default", - "responseContent": "{\"errors\": [{\"message\": \"This is a custom GraphQL blocking response page. Code: BRP. Your support ID is: <%TS.request.ID()%>\"}]}" - } - ] -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/graphql-security.md b/content/includes/nap-waf/config/common/graphql-security.md deleted file mode 100644 index e898cd8e8..000000000 --- a/content/includes/nap-waf/config/common/graphql-security.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -nd-docs: "DOCS-1566" ---- - -Securing GraphQL APIs with F5 WAF for NGINX involves using WAF to monitor and protect against security threats and attacks. GraphQL, like REST, is usually [served over HTTP](http://graphql.org/learn/serving-over-http/), using GET and POST requests and a proprietary [query language](https://graphql.org/learn/schema/#the-query-and-mutation-types). It is prone to the typical Web APIs security vulnerabilities, such as injection attacks, Denial of Service (DoS) attacks and abuse of flawed authorization. - -Unlike REST, where Web resources are identified by multiple URLs, GraphQL server operates on a single URL/endpoint, usually **/graphql**. All GraphQL requests for a given service should be directed to this endpoint. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/graphql-violations.md b/content/includes/nap-waf/config/common/graphql-violations.md deleted file mode 100644 index bc4748339..000000000 --- a/content/includes/nap-waf/config/common/graphql-violations.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -nd-docs: "DOCS-1578" ---- - -F5 WAF for NGINX introduces four new violations specific to GraphQL: `VIOL_GRAPHQL_FORMAT`, `VIOL_GRAPHQL_MALFORMED`, `VIOL_GRAPHQL_INTROSPECTION_QUERY` and `VIOL_GRAPHQL_ERROR_RESPONSE`.
- -Under the "blocking-settings," user can either enable or disable these violations. Note that these violations will be enabled by default. Any changes to these violation settings here will override the default settings. The details regarding logs will be recorded in the security log.
- -See also the [Violations](#violations) section for more details. - -While configuring GraphQL, since the GraphQL violations are enabled by default, you can change the GraphQL violations settings i.e. alarm: `true` and block: `false` under the "blocking settings". In this manner, the GraphQL profile detects violations but does not block the request. They may contribute to the Violation Rating, which, if raised above 3, will automatically block the request. - -However, setting the alarm and block to `true` will enforce block settings and App Protect will block any violating requests. - -See below example for more details: - -```shell -{ - "name": "graphql_policy", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "caseInsensitive": false, - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_GRAPHQL_FORMAT", - "alarm": true, - "block": false - }, - { - "name": "VIOL_GRAPHQL_MALFORMED", - "alarm": true, - "block": false - }, - { - "name": "VIOL_GRAPHQL_INTROSPECTION_QUERY", - "alarm": true, - "block": false - }, - { - "name": "VIOL_GRAPHQL_ERROR_RESPONSE", - "alarm": true, - "block": false - } - ] - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/grpc-bidirectional-stream-enforcement.md b/content/includes/nap-waf/config/common/grpc-bidirectional-stream-enforcement.md deleted file mode 100644 index 468da8b55..000000000 --- a/content/includes/nap-waf/config/common/grpc-bidirectional-stream-enforcement.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -nd-docs: "DOCS-1606" ---- - -#### Client Request Flow - -Bidirectional Enforcement is per message; each message is buffered and processed (doing all the inspection actions according to the policy: signatures, metacharacters, and other violations) on its own. The following section provides more details on receiving a client event: - -- The request header and each of the messages in the client stream is enforced **separately**. -- The Enforcer issues a separate security log message per each message containing the violations found on it (if any). Refer to the [gRPC Violations](#grpc-violations) section for more details on gRPC violations. There is also a separate log message per request headers opening the stream. -- Then the Enforcer decides on the action that results from the violations just as it does for a regular HTTP request, but in gRPC it is done **per message** rather than the per whole stream. So if a message needs to be blocked, a blocking response is sent to the client and the stream is closed, but all the messages that preceded the blocked message have already been sent to the server. -- A special case is when the request headers message had blocking violations. In that case, the blocking response is sent right away, ignoring any messages the client may have sent afterward. The security log will just reflect the headers in this case. See more details in the [Sending Blocking Response in Bidirectional Streaming](#sending-blocking-response-in-bidirectional-streaming) section below. - -#### Server Response Flow - -gRPC server messages are not processed. All gRPC messages (unary or streaming) including the headers and trailer messages, are sent directly to the client (without sending them to the Enforcer). - -#### Sending Blocking Response in Bidirectional Streaming - -The blocking response comes as the **trailers** message is sent to the client on behalf of the server. At the same time, the server gets the `END_STREAM` frame to ensure streams on both sides are closed. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/grpc-content-profiles.md b/content/includes/nap-waf/config/common/grpc-content-profiles.md deleted file mode 100644 index dbdffe203..000000000 --- a/content/includes/nap-waf/config/common/grpc-content-profiles.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -nd-docs: "DOCS-1616" ---- - -The gRPC Content Profile contains all the definitions for protecting a gRPC service. It is similar in nature to the **JSON and XML profiles** handling JSON and XML traffic respectively. Roughly it includes: -- **The IDL files** of the protected gRPC service. This is essential for App Protect to be able to parse the API messages and determine whether they are legal and what needs to be inspected for security. [For more info regarding including an external file]({{< ref "#including-an-external-json-schema-file" >}}). -- **Security enforcement**: whether to detect signatures and/or metacharacters and optionally an exception (a.k.a override) list of signatures that need to be disabled in the context of this profile. -- **Defense attributes**: special restrictions applied to the gRPC traffic. This includes a size limit for the gRPC messages in the request, and whether to tolerate fields that are not defined in the definition of the Protocol Buffer messages. - -Let's look at an example: - -Assume you have a service with this IDL: - -```proto -syntax = "proto3"; - -package myorg.services; - -import "common/messages.proto"; - -service photo_album { - rpc upload_photo (Photo) returns (OperationResult) {}; - rpc get_photos (Condition) returns (PhotoResult) {}; -} - -message Photo { - string name = 1; - bytes image = 2; -} - -message PhotoResult { - repeated Photo photos = 1; - OperationResult res = 2; -} -``` - -The definitions of `OperationResult` and `Condition` messages are in the imported file found in `common/messages.proto` which we will not list here. The two files need to be referenced in the gRPC Content Profile. Here is the policy with the profile example: - -#### Policy with the profile example: - -```json -{ - "policy": { - "name": "my-grpc-service-policy", - "grpc-profiles": [ - { - "name": "photo_service_profile", - "associateUrls": true, - "defenseAttributes": { - "maximumDataLength": 100000, - "allowUnknownFields": false - }, - "attackSignaturesCheck": true, - "signatureOverrides": [ - { - "signatureId": 200001213, - "enabled": false - }, - { - "signatureId": 200089779, - "enabled": false - } - ], - "metacharCheck": true, - "idlFiles": [ - { - "idlFile": { - "$ref": "file:///grpc_files/album.proto" - }, - "isPrimary": true - }, - { - "idlFile": { - "$ref": "file:///grpc_files/common/messages.proto" - }, - "importUrl": "common" - } - ] - } - ], - "urls": [ - { - "name": "*", - "type": "wildcard", - "method": "*", - "$action": "delete" - } - ] - } -} -``` - -The profile in this example enables checking of attack signatures and disallowed metacharacters in the string-typed fields within the service messages. Two signatures are disabled. The profile also limits the size of the messages to 100KB and disallows fields that are not defined in the IDL files. - -The main IDL file, `album.proto` is marked as `primary`. The file it imports, `messages.proto`, is marked as secondary, that is, `isPrimary` is `false` and so should be any imported file. In order for App Protect to be able to match it to the import statement, the file location should be specified as done in the example above using the `importUrl` property. - -An alternative and probably more convenient way to specify all the IDL files, the primary and all its imports, direct and indirect, is to bundle them into a single tar file in the same directory structure as they are expected by the import statements. In this case, you will have to specify which of the files in the tarball is the primary one. The supported formats are `tar` and `tgz`. App Protect will identify the file type automatically (tar, gzipped tar, or JSON) and handle it accordingly. Following the above example: - -```json -"idlFiles": [{ - "idlFile": { - "$ref": "file:///grpc_files/album_service_files.tgz" - }, - "primaryIdlFileName": "album_service.proto" -}] -``` - -Note the deletion of the `*` URL in the above policy. This is required if you want to accept only requests pertaining to the gRPC services exposed by your apps. If you decide to leave this catch-all URL, App Protect will accept other traffic including gRPC requests, applying policy checks such as signature detection. However, it will not apply to any gRPC-specific protection on them. diff --git a/content/includes/nap-waf/config/common/grpc-handling-slow-post-attacks.md b/content/includes/nap-waf/config/common/grpc-handling-slow-post-attacks.md deleted file mode 100644 index 78c430827..000000000 --- a/content/includes/nap-waf/config/common/grpc-handling-slow-post-attacks.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -nd-docs: "DOCS-1599" ---- - -Slow POST attack mitigation - A client sending messages very slowly for a long time may be cut off by resetting the connection. - -In gRPC, a connection is considered "slow" if a message takes more than 10 seconds to process. In other words, the slow connection timer will be reset when a message ends and not when the whole request ends. This way, a limit is applied on the number of concurrent messages rather than the number of concurrent gRPC connections (streams), as many of them may be idle. - -The number of slow connections is limited to 25. Once another connection becomes slow it is reset. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/grpc-message-compression.md b/content/includes/nap-waf/config/common/grpc-message-compression.md deleted file mode 100644 index ff28c8674..000000000 --- a/content/includes/nap-waf/config/common/grpc-message-compression.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -nd-docs: "DOCS-1574" ---- - -Currently, Message Compression is not supported. Therefore, a violation `VIOL_GRPC_MALFORMED` will be raised and the connection will be blocked if a compressed message is sent. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/grpc-protection-unary-traffic.md b/content/includes/nap-waf/config/common/grpc-protection-unary-traffic.md deleted file mode 100644 index e479c85a4..000000000 --- a/content/includes/nap-waf/config/common/grpc-protection-unary-traffic.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -nd-docs: "DOCS-1558" ---- - -gRPC is a remote API standard and is an alternative to OpenAPI. If your applications expose gRPC APIs, F5 WAF for NGINX can protect them by parsing the messages; making sure they comply with the API definition; and enforcing security restrictions - such as size limits, detecting attack signatures, threat campaigns, and suspicious metacharacters in message string field values. -In the following sections, you will learn how to configure gRPC protection in the policy using gRPC Content Profiles. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/grpc-response-pages.md b/content/includes/nap-waf/config/common/grpc-response-pages.md deleted file mode 100644 index 11f7efc51..000000000 --- a/content/includes/nap-waf/config/common/grpc-response-pages.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -nd-docs: "DOCS-1597" ---- - -A gRPC error response page is returned when a request is blocked. The default page returns gRPC status code `UNKNOWN` (numeric value of 2) and a short textual message that includes the support ID. You can customize any of these two by configuring a custom gRPC response page in your policy. - -```json -{ - "policy": { - "name": "my-special-grpc-service-policy", - "response-pages": [ - { - "responsePageType": "grpc", - "grpcStatusCode": "INVALID_ARGUMENT", - "grpcStatusMessage": "Operation does not comply with the service requirements. Please contact your administrator with the following number: <%TS.request.ID()%>" - } - ] - } -} -``` - -The `grpcStatusCode` expects one of the [standard gRPC status code values](https://grpc.github.io/grpc/core/md_doc_statuscodes.html). \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/grpc-server-reflection.md b/content/includes/nap-waf/config/common/grpc-server-reflection.md deleted file mode 100644 index e8cab8f9e..000000000 --- a/content/includes/nap-waf/config/common/grpc-server-reflection.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -nd-docs: "DOCS-1610" ---- - -[gRPC Server Reflection](https://grpc.github.io/grpc/core/md_doc_server_reflection_tutorial.html) provides information about publicly-accessible gRPC services on a server, and assists clients at runtime to construct RPC requests and responses without precompiled service information. gRPC Server reflection is not currently supported in App Protect. If Server Reflection support is required, App Protect must be disabled on the reflection URIs by adding a location block such as this: - -```nginx -server { - location /grpc.reflection { - app_protect_enable off; - grpc_pass grpc://grpc_backend; - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/grpc-size-limits.md b/content/includes/nap-waf/config/common/grpc-size-limits.md deleted file mode 100644 index 407f6cb2c..000000000 --- a/content/includes/nap-waf/config/common/grpc-size-limits.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -nd-docs: "DOCS-1619" ---- - -The maximum total request size is applied to each message on its own, rather than to the total stream messages. By default, the maximum gRPC message size is 4MB. -You can configure different sizes in the declarative policy, like the 100K in the [Policy Example File](#policy-with-the-profile-example). If a message is sent with a size larger than that value, a `GRPC_FORMAT` violation is raised. If a message is sent with a size larger than 10MB, a `GRPC_MALFORMED` and `REQUEST_MAX_LENGTH` violation is raised. - -There is no limit to the number of messages in a stream. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/grpc-slow-post-attacks.md b/content/includes/nap-waf/config/common/grpc-slow-post-attacks.md deleted file mode 100644 index 55dc41ed9..000000000 --- a/content/includes/nap-waf/config/common/grpc-slow-post-attacks.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -nd-docs: "DOCS-1637" ---- - -A Slow POST attack or Slow HTTP POST attack is a type of denial of service attack. The attacker sends a legitimate HTTP POST request with the header Content-Length specified. The attacker then proceeds to send this content slowly. The server establishes a connection to the client and keeps it open to receive the request that it thinks is legitimate. - -The attacker sends several such requests and effectively occupies the server’s entire connection pool. As a result, it blocks the service for other legitimate users and results in a denial of service. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/grpc-violations.md b/content/includes/nap-waf/config/common/grpc-violations.md deleted file mode 100644 index e93bac516..000000000 --- a/content/includes/nap-waf/config/common/grpc-violations.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -nd-docs: "DOCS-1562" ---- - -There are three violations that are specific to gRPC. They are all enabled in the default policy. See also the [Violations](#violations) section. - -- `VIOL_GRPC_MALFORMED`: This violation is issued when a gRPC message cannot be parsed according to its expected definition. This violation **blocks** in the default policy. -- `VIOL_GRPC_FORMAT`: This violation is issued when any of the definitions in the `defenseAttributes` of the profile are violated; for example, the maximum total size is exceeded. -- `VIOL_GRPC_METHOD`: This violation is issued when the gRPC method is unrecognized in the configured IDL. - -The violation `VIOL_METHOD` (not to be confused with the above `VIOL_GRPC_METHOD`) is not unique to gRPC, but in the context of a gRPC Content Profile, it is issued in special circumstances. Since gRPC mandates using the `POST` method on any gRPC request over HTTP, any other HTTP method on a request to URL with gRPC Content Profile will trigger this violation, even if the respective HTTP method is allowed in the policy. So, in our first example above, the request `GET /myorg.services.photo_album/get_photos` will trigger `VIOL_METHOD` even though `GET` is among the allowed HTTP methods in the policy (by the base template). \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/handling-xml-and-json-content.md b/content/includes/nap-waf/config/common/handling-xml-and-json-content.md deleted file mode 100644 index 60b132bf9..000000000 --- a/content/includes/nap-waf/config/common/handling-xml-and-json-content.md +++ /dev/null @@ -1,300 +0,0 @@ ---- -nd-docs: "DOCS-1545" ---- - -#### XML and JSON Content Profiles - -By default every request with a Content-Type header containing XML or JSON is expected to have an XML or JSON body, respectively. Consequently, a series of checks are performed to ensure that the body is indeed well-formed as XML or JSON, and certain restrictions are enforced on the size and content of that body. These restrictions are specified in **XML and JSON profiles**. These configuration structures are associated with URLs and optionally also with Parameters, in case parameters that are known to have XML or JSON values are defined. One of the most powerful restrictions in a JSON profile is enforcing a schema with which the content must comply. This will be detailed in the next section. - -The default Base template comes with default JSON and XML profiles, both called "default". They are associated to the * URL based on the values of the Content-Type header as described above. You can use those profiles on other URLs or Parameters in your policies, and you can also create your own custom JSON and XML profiles to customize the checks that you want on your content. - -Let's assume you have a JSON registration form under the URL `/register`. It is a small form, and it makes sense to limit its size to 1000 characters and its nesting depth to 2. Here is a policy that enforces this: - -```json -{ - "policy": { - "name": "json_form_policy", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "json-profiles": [ - { - "name": "reg_form_prof", - "defenseAttributes": { - "maximumArrayLength": "any", - "maximumStructureDepth": 2, - "maximumTotalLengthOfJSONData": 1000, - "maximumValueLength": "any", - "tolerateJSONParsingWarnings": false - } - } - ], - "urls": [ - { - "name": "/register", - "method": "POST", - "type": "explicit", - "attackSignaturesCheck": true, - "clickjackingProtection": false, - "disallowFileUploadOfExecutables": false, - "isAllowed": true, - "mandatoryBody": false, - "methodsOverrideOnUrlCheck": false, - "urlContentProfiles": [ - { - "headerName": "*", - "headerValue": "*", - "headerOrder": "default", - "type": "json", - "contentProfile": { - "name": "reg_form_prof" - } - } - ] - } - ] - } -} -``` - -The enforcement on the JSON payload is defined in the `reg_form_prof` JSON profile. This profile is attached to the `/register` URL. Note JSON content is always expected for this URL - it applies to all header name and value combinations, and no other content option exists for this URL. Also note that we limited the method to `POST` in this URL. A POST request to this URL with a body that is not well-formed JSON will trigger the `VIOL_JSON_MALFORMED` violation. - -If the body of the request is legal JSON, but violates any of the restrictions in the `reg_form_prof` JSON profile, for example has a nesting depth of 3, then you should expect the `VIOL_JSON_FORMAT` violation with details on what exactly was wrong with the JSON payload. - -Let's assume that in your JSON registration there is a specific field that should be Base64 encoded. -we can set the value of `handleJsonValuesAsParameters` to `true` on the profile level, -and set the value of `decodeValueAsBase64` to `required` on the parameter level. -Here is a policy that enforces this: - -```json -{ - "policy": { - "name": "json_parse_param_policy", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "caseInsensitive": false, - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_PARAMETER_VALUE_BASE64", - "alarm": true, - "block": true - } - ] - }, - "parameters": [ - { - "name": "*", - "type": "wildcard", - "parameterLocation": "any", - "valueType": "user-input", - "dataType": "alpha-numeric", - "decodeValueAsBase64": "required" - } - ], - "json-profiles": [ - { - "name": "Default", - "defenseAttributes": { - "tolerateJSONParsingWarnings": true - }, - "handleJsonValuesAsParameters": true, - "validationFiles": [] - } - ] - } -} -``` - -{{< call-out "note" >}} -Defining a JSON or XML profile in a policy has no effect until you assign it to a URL or Parameter you defined in that policy. Profiles can be shared by more than one URL and/or Parameter. -{{< /call-out >}} - -#### Applying a JSON Schema - -If a schema for the JSON payload exists, it can be attached to the JSON profile and App Protect will enforce it along with the other restrictions. - -Here is a sample JSON schema for a registration form. It contains personal details: - -```json -{ - "$schema": "http://json-schema.org/draft-07/schema#", - "title": "Person", - "type": "object", - "additionalProperties": false, - "properties": { - "firstName": { - "type": "string", - "description": "The person's first name." - }, - "lastName": { - "type": "string", - "description": "The person's last name." - }, - "age": { - "description": "Age in years which must be equal to or greater than zero.", - "type": "integer", - "minimum": 0 - } - } -} -``` - -Embedding the schema into the `reg_form_prof` JSON profile should be done in the following way: -- Add an object containing the JSON schema to the `json-validation-files` array, which details all the available JSON schema validation files available in the profile. A unique `fileName` should be specified, and the escaped contents of the JSON schema added via the `contents` keyword. -- Associate the specific JSON schema to the `reg_form_prof` JSON profile by adding a `validationFiles` array object and set the `fileName` in the `jsonValidationFile` object to the JSON schema `fileName`. -- All JSON schema files including external references must be added in this way to both the `json-validation-files` array and associated with the JSON profile. The `isPrimary` should be set on the object containing the primary JSON schema. - -This yields the following policy: - -```json -{ - "policy": { - "name": "json_form_policy_inline_schema", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "json-validation-files": [ - { - "fileName": "person_schema.json", - "contents": "{\r\n \"$schema\": \"http://json-schema.org/draft-07/schema#\",\r\n \"title\": \"Person\",\r\n \"type\": \"object\",\r\n \"properties\": {\r\n \"firstName\": {\r\n \"type\": \"string\",\r\n \"description\": \"The person's first name.\"\r\n },\r\n \"lastName\": {\r\n \"type\": \"string\",\r\n \"description\": \"The person's last name.\"\r\n },\r\n \"age\": {\r\n \"description\": \"Age in years which must be equal to or greater than zero.\",\r\n \"type\": \"integer\",\r\n \"minimum\": 0\r\n }\r\n }\r\n}" - } - ], - "json-profiles": [ - { - "name": "reg_form_prof", - "defenseAttributes": { - "maximumArrayLength": "any", - "maximumStructureDepth": "any", - "maximumTotalLengthOfJSONData": 1000, - "maximumValueLength": "any", - "tolerateJSONParsingWarnings": false - }, - "validationFiles": [ - { - "isPrimary": true, - "jsonValidationFile": { - "fileName": "person_schema.json" - } - } - ] - } - ], - "urls": [ - { - "name": "/register", - "type": "explicit", - "method": "POST", - "attackSignaturesCheck": true, - "clickjackingProtection": false, - "disallowFileUploadOfExecutables": false, - "isAllowed": true, - "mandatoryBody": false, - "methodsOverrideOnUrlCheck": false, - "urlContentProfiles": [ - { - "contentProfile": { - "name": "reg_form_prof" - }, - "headerName": "*", - "headerOrder": "default", - "headerValue": "*", - "type": "json" - } - ] - } - ] - } -} -``` - -When a request to the `/register` URL is `POST`-ed with JSON content that does not comply with the above schema, the `VIOL_JSON_SCHEMA` violation is triggered. In the default base template, the `alarm` flag is turned on for this violation and if it is triggered, it affects Violation Rating. In addition, you can turn on the `block` flag so that this violation will also block when triggered. - -**Notes:** -- The schema file is embedded as a quoted string; therefore you must escape the quotes inside the schema itself. -- We removed the nesting depth check in the JSON profile because it is enforced by the schema. It is not an error to leave the sizing checks together with the schema enforcement, but usually the schema has more accurate restrictions and leaving the profile restriction might be redundant in the best case or cause false positives in the worst. - -#### Including an External JSON Schema File - -Schema files are often developed as part of the application, independently from the App Protect Policy. It is often desirable to keep it in a separate file and reference it from the policy using a URL. Just as in all externally referenced policy sections, the JSON schema file can reside either in the NGINX file system (the default directory `/etc/app_protect/conf` is assumed if only the filename is specified in the `file:` URL, that is: `file:///my_schema.json` refers to the file located at `/etc/app_protect/conf/my_schema.json`), or on a remote Web server, typically, your source control system. - -In this example the file is in the default directory: - -```json -{ - "policy": { - "name": "json_form_policy_external_schema", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "json-validation-files": [ - { - "fileName": "person_schema.json", - "link": "file://person_schema.json" - } - ], - "json-profiles": [ - { - "name": "reg_form_prof", - "defenseAttributes": { - "maximumArrayLength": "any", - "maximumStructureDepth": "any", - "maximumTotalLengthOfJSONData": 1000, - "maximumValueLength": "any", - "tolerateJSONParsingWarnings": false - }, - "validationFiles": [ - { - "isPrimary": true, - "jsonValidationFile": { - "fileName": "person_schema.json" - } - } - ] - } - ], - "urls": [ - { - "name": "/register", - "type": "explicit", - "method": "POST", - "attackSignaturesCheck": true, - "clickjackingProtection": false, - "disallowFileUploadOfExecutables": false, - "isAllowed": true, - "mandatoryBody": false, - "methodsOverrideOnUrlCheck": false, - "urlContentProfiles": [ - { - "contentProfile": { - "name": "reg_form_prof" - }, - "headerName": "*", - "headerOrder": "default", - "headerValue": "*", - "type": "json" - } - ] - } - ] - } -} -``` - -The schema file is identified by the `filename` property. It is a good practice to keep the `filename` identical to the one on the URL path, but it is not an error to have different names for each. - -if you want to reference the file externally, replace the content of the `link` property with an HTTP or HTTPS URL: - -```json -{ - "json-validation-files": [ - { - "fileName": "person_schema.json", - "link": "https://git.mydomain.com/my_app/person_schema.json" - } - ] -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/http-compliance-subviolations.md b/content/includes/nap-waf/config/common/http-compliance-subviolations.md deleted file mode 100644 index 338b0a8e4..000000000 --- a/content/includes/nap-waf/config/common/http-compliance-subviolations.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -nd-docs: "DOCS-1576" ---- - -The following table specifies the HTTP Compliance sub-violation settings. All are supported in F5 WAF for NGINX, but not all are enabled in the default App Protect security template. The table specifies which. Some of the checks are enforced by NGINX Plus and App Protect only gets a notification. **Note:** In this case, the request is **always** blocked regardless of the App Protect policy. - - -{{}} -|Sub-Violation | Default Template | Enforced by | Description | -| ---| ---| ---| --- | -|Unparsable request content | Enabled | NGINX | This violation is triggered when the system's parser cannot parse the message. | -|Several Content-Length headers | Enabled | NGINX | More than one content-length header is a non RFC violation. Indicates an HTTP response splitting attack. | -|POST request with Content-Length: 0 | Disabled | App Protect | POST request is usually sent with request body. This sub-violation is issued when a request has empty or no body at all. | -|Null in request | Enabled | Null in header - NGINX, null in body - App Protect | The system issues a violation for requests with a NULL character anywhere in the request (except for a NULL in the binary part of a multipart request). | -|No Host header in HTTP/1.1 request | Enabled | NGINX | Examines requests using HTTP/1.1 to see whether they contain a "Host" header. | -|Multiple host headers | Enabled | NGINX | Examines requests to ensure that they contain only a single "Host" header. | -|Host header contains IP address | Enabled | App Protect | The system verifies that the request's host header value is not an IP address to prevent non-standard requests. | -|High ASCII characters in headers | Enabled | App Protect | Checks for high ASCII characters in headers (greater than 127). | -|Header name with no header value | Disabled | App Protect | The system checks for a header name without a header value. | -|CRLF characters before request start | N/A | NGINX | **Note:** NGINX strips any CRLF characters before the request method. The system **DOES NOT** issue a violation.| -|Content length should be a positive number | Enabled | NGINX | The Content-Length header value should be greater than zero; only a numeric positive number value is accepted. | -|Chunked request with Content-Length header | Enabled | App Protect | The system checks for a Content-Length header within chunked requests. | -|Check maximum number of parameters | Enabled | App Protect | The system compares the number of parameters in the request to the maximum configured number of parameters. When enabled, the default value for number of maximum number of parameters is 500. | -|Check maximum number of headers | Enabled | App Protect | The system compares the request headers to the maximal configured number of headers. | -|Unescaped space in URL | Enabled | App Protect | The system checks that there is no unescaped space within the URL in the request line. Such spaces split URLs introducing ambiguity on picking the actual one. when enabled, the default value for number of unescaped space in URL is 50.| -|Body in GET or HEAD requests | Disabled | App Protect | Examines GET and HEAD requests which have a body. | -|Bad multipart/form-data request parsing | Enabled | App Protect | When the content type of a request header contains the substring "Multipart/form-data", the system checks whether each multipart request chunk contains the strings "Content-Disposition" and "Name". If they do not, the system issues a violation. | -|Bad multipart parameters parsing | Enabled | App Protect | The system checks the following:
  1. A boundary follows immediately after request headers.
  2. The parameter value matches the format: 'name="param_key";\\r\\n.
  3. A chunked body contains at least one CRLF.
  4. A chunked body ends with CRLF.
  5. Final boundary was found on multipart request.
  6. There is no payload after final boundary.


If one of these is false, the system issues a violation. | -|Bad HTTP version | Enabled | NGINX | Enforces legal HTTP version number (only 0.9 or higher allowed). | -|Bad host header value | Enabled | NGINX | Detected non RFC compliant header value. | -| Check maximum number of cookies | Enabled | App Protect | The system compares the request cookies to the maximal configured number of cookies. When enabled, the default value for number of maximum cookies if unmodified is 100. | -{{}} \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/important-things-override-rules.md b/content/includes/nap-waf/config/common/important-things-override-rules.md deleted file mode 100644 index c065639cb..000000000 --- a/content/includes/nap-waf/config/common/important-things-override-rules.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -nd-docs: "DOCS-1549" ---- - -Here are some key points to remember regarding the Override Rules feature: - -- To ensure efficient compilation time and optimal resource allocation for policies, there are limitations in place. Currently, policies have a maximum limit of 10 rules and a maximum of 5 clauses in a condition. These limitations help maintain better performance and manageability. A compilation error will not occur if a policy file contains more than 5 clauses or 10 overrides. -- The replacement policy should not include any override rules. Override rules should be used to extend or switch to a different policy, rather than being part of the replacement policy itself. -- Each override rule will be compiled as a separate policy, whether extending the main policy or switching to a new one. The enforcer will switch to the policy that corresponds to the matched rule, but the main policy name will be reported along with the override rule property. -- The URI, host, and user-agent strings in the request will be treated as plain ASCII characters and won't undergo language decoding. If any of these strings contain non-ASCII characters, they may be misinterpreted and may not comply with rules that expect specific values in the conditions. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/ip-groups-override-rules.md b/content/includes/nap-waf/config/common/ip-groups-override-rules.md deleted file mode 100644 index e9c2ff0f5..000000000 --- a/content/includes/nap-waf/config/common/ip-groups-override-rules.md +++ /dev/null @@ -1,62 +0,0 @@ -#### IP-Address-Lists feature as part of Override Rules feature. - -The Override Rules feature allows you to override original or parent policy settings. - -Rules are defined using specific conditions, which can include an IP Address Lists based on the declarative policy JSON schema. - -When triggered, the rule is applied to the _clientIp_ attribute using the _matches_ function. - -'clientIp.matches(ipAddressLists["standalone"])' - -Here is a policy example: - -```json -{ - "policy": { - "name": "ip_group_override_rule", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "caseInsensitive": false, - "enforcementMode": "blocking", - "ip-address-lists": [ - { - "name": "standalone", - "ipAddresses": [ - { - "ipAddress": "1.1.1.1/32" - } - ] - } - ], - "override-rules": [ - { - "name": "myRule1", - "condition": "clientIp.matches(ipAddressLists['standalone'])", - "actionType": "extend-policy", - "override": { - "policy": { - "enforcementMode": "transparent" - } - } - } - ] - } -} -``` - -The previous example policy contains an IP address lists with the name "standalone", used for the override rule condition "clientIp.matches(ipAddressLists['standalone'])". -The condition means that the rule enforcement is applied and override base policy enforcement when clientIp is matched to one of ipAddresses in ipAddressList with name "standalone". -The value used for the override condition must exist and exactly match the name in "ip-address-lists". - -#### Possible errors - -| Error text | Input | Explanation | -| -----------| ------------- | ------------ | -| _Invalid field invalidList_ | _clientIp.matches(invalidList['standalone']);_ | An incorrect keyword was used instead of _ipAddressLists_ | -| _Invalid value empty string_ | _clientIp.matches(ipAddressLists['']_ | An empty name was provided | -| _Failed to compile policy - 'ipGroupOverridePolicy'_ | _uri.matches(ipAddressLists['standalone']);_ | Used _ipAddressLists_ without the _clientIP_ attribute | - - - diff --git a/content/includes/nap-waf/config/common/ip-groups-overview.md b/content/includes/nap-waf/config/common/ip-groups-overview.md deleted file mode 100644 index d1729a7d0..000000000 --- a/content/includes/nap-waf/config/common/ip-groups-overview.md +++ /dev/null @@ -1,81 +0,0 @@ -IP address lists is a feature to organize lists of allowed and forbidden IP addresses across several lists with common attributes. - -This allows you to control unique policy settings for incoming requests based on specific IP addresses. - -Each IP address list contains a unique name, enforcement type (_always_, _never_ and _policy-default_), and list of IP addresses. - - -An example of a declarative policy using IP address lists configuration: - -```json -{ - "policy": { - "name": "IpGroups_policy", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "caseInsensitive": false, - "enforcementMode": "blocking", - "ip-address-lists": [ - { - "name": "Standalone", - "description": "Optional Description", - "blockRequests": "policy-default", - "setGeolocation": "IN", - "ipAddresses": [ - { - "ipAddress": "1.2.3.4/32" - }, - { - "ipAddress": "1111:fc00:0:112::2" - } - ] - } - ] - } -} - -``` -The example with IP-Group definition in external file external_ip_groups.json: - -```json -{ - "policy": { - "name": "IpGroups_policy2", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "caseInsensitive": false, - "enforcementMode": "blocking", - "ip-address-lists": [ - { - "name": "external_ip_groups", - "description": "Optional Description", - "blockRequests": "always", - "setGeolocation": "IL", - "$ref": "file:///tmp/policy/external_ip_groups.json" - } - ] - } -} -``` -Example of the file external_ip_groups.json - -```json -{ - "name": "External IP address lists", - "description": "Optional Description", - "blockRequests": "always", - "setGeolocation": "IR", - "ipAddresses": [ - { - "ipAddress": "66.51.41.21" - }, - { - "ipAddress": "66.52.42.22" - } - ] -} -``` diff --git a/content/includes/nap-waf/config/common/ip-intelligence-conf.md b/content/includes/nap-waf/config/common/ip-intelligence-conf.md deleted file mode 100644 index 6b253b4e5..000000000 --- a/content/includes/nap-waf/config/common/ip-intelligence-conf.md +++ /dev/null @@ -1,121 +0,0 @@ - - -F5 WAF for NGINX provides an IP Intelligence feature, which allows customizing the enforcement based on the source IP of the request to limit access from IP addresses with questionable reputation. Please note that: -- The IP intelligence feature is **disabled** by default and needs to be installed, enabled, and configured within the policy. -- To review the installation steps, please refer to the administration guide: [App Protect v4]({{< ref "/nap-waf/v4/admin-guide/install.md#Prerequisites" >}}) / [App Protect v5]({{< ref "/nap-waf/v5/admin-guide/install.md#Prerequisites" >}}) -- The system must have an active Internet connection and a working DNS. -- If NGINX App Protect is behind a firewall, ensure external access to vector.brightcloud.com over port 443 - this is the IP Intelligence server used for data retrieval. -- If NGINX App Protect accesses the Internet through a forward proxy server, ensure that it is configured correctly [App Protect v4]({{< ref "/nap-waf/v4/configuration-guide/configuration.md#ip-intelligence-forward-proxy-configuration" >}}) / [App Protect v5]({{< ref "/nap-waf/v5/configuration-guide/configuration.md##ip-intelligence-forward-proxy-configuration" >}}). - -Once installed, make sure to enable the feature in the two relevant sections of the policy: -1. By enabling the corresponding violation in the violation list: `"name": "VIOL_MALICIOUS_IP"` and assigning the appropriate `block` and `alarm` values to the violation. - -2. By enabling the feature in the corresponding IP Intelligence JSON section: `"ip-intelligence": {"enabled": true}` and defining actions for the IP Intelligence categories listed below. - -An example policy where both elements are enabled, and all the IP intelligence categories are configured to `block` and `alarm` can be found here: - -```json -{ - "policy": { - "name": "ip_intelligency_policy", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "caseInsensitive": false, - "enforcementMode": "blocking", - "blocking-settings": { - "violations": [ - { - "name": "VIOL_MALICIOUS_IP", - "alarm": true, - "block": true - } - ] - }, - "ip-intelligence": { - "enabled": true, - "ipIntelligenceCategories": [ - { - "category": "Anonymous Proxy", - "alarm": true, - "block": true - }, - { - "category": "BotNets", - "alarm": true, - "block": true - }, - { - "category": "Cloud-based Services", - "alarm": true, - "block": true - }, - { - "category": "Denial of Service", - "alarm": true, - "block": true - }, - { - "category": "Infected Sources", - "alarm": true, - "block": true - }, - { - "category": "Mobile Threats", - "alarm": true, - "block": true - }, - { - "category": "Phishing Proxies", - "alarm": true, - "block": true - }, - { - "category": "Scanners", - "alarm": true, - "block": true - }, - { - "category": "Spam Sources", - "alarm": true, - "block": true - }, - { - "category": "Tor Proxies", - "alarm": true, - "block": true - }, - { - "category": "Web Attacks", - "alarm": true, - "block": true - }, - { - "category": "Windows Exploits", - "alarm": true, - "block": true - } - ] - } - } -} -``` - -This policy will basically block `"block": true` all IP addresses that are part of any threat category and add a log entry `"alarm": true` for the transaction. - -The IP address database is managed by an external provider and is constantly updated (every 1 minute by default). The database also categorizes IP addresses into one or more threat categories. These are the same categories that can be configured individually in the IP intelligence section: -- Anonymous Proxy -- BotNets -- Cloud-based Services -- Denial of Service -- Infected Sources -- Mobile Threats -- Phishing Proxies -- Scanners -- Spam Sources -- Tor Proxies -- Web Attacks -- Windows Exploits - -Note that since the IP address database is constantly updated, IP address enforcement is also expected to change. IP Addresses may be added, removed, or moved from one category to another based on the reported activity of the IP address. diff --git a/content/includes/nap-waf/config/common/json-web-token-overview.md b/content/includes/nap-waf/config/common/json-web-token-overview.md deleted file mode 100644 index b34cf6265..000000000 --- a/content/includes/nap-waf/config/common/json-web-token-overview.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -nd-docs: "DOCS-1550" ---- - -JSON Web Token (JWT) is a compact and self-contained way to represent information between two parties in a JSON (JavaScript Object Notation) format and is commonly used for authentication and authorization. With NGINX App Protect now it is possible to control access to its application using JWT validation. F5 WAF for NGINX validates the authenticity and well-formedness of JWTs coming from a client, denying access to the service exclusively when the validation process fails. JWT is mainly used for API access. - -When a user logs in to a web application, they might receive a JWT, which can then be included in subsequent requests to the server. The server can validate the JWT to ensure that the user is authenticated to access the requested resources. - -Now F5 WAF for NGINX provides JSON Web Token (JWT) protection. F5 WAF for NGINX will be placed in the path leading to the application server and will handle the token for the application. This includes: - -1. Validating the token's existence and ensuring its correct structure for specific URLs. -2. Verifying the token's signature based on provisioned certificates. -3. Check the validity period of the token. -4. Extract the user identity from the token and use it for logging and session awareness. - -The JSON Web Token consists of three parts: the **Header**, **Claims** and **Signature**. The first two parts are in JSON and Base64 encoded when carried in a request. The three parts are separated by a dot "." delimiter and put in the authorization header of type "Bearer", but can also be carried in a query string parameter. - -- **Header**: It contains information about the type of token (usually "JWT") and the cryptographic algorithm being used to secure the JSON Web Signature (JWS). - -- **Claims**: This part contains claims, which refers to the statements or assertions about an entity (typically, the user) that the token is issued for. Claims are **key/value** pairs contained within the token's payload. The claims is the second part of a JWT and typically looks like this: - - ```json - { - "sub": "1234567890", - "name": "John Doe", - "iat": 1654591231, - "nbf": 1654607591, - "exp": 1654608348 - } - ``` - -In example above, the payload contains several claims: - -- sub (Subject) - Represents the subject of the JWT, typically the user or entity for which the token was created. - -- name (Issuer) - Indicates the entity that issued the JWT. It is a string that identifies the issuer of the token. - -- iat (Issued At) - Indicates the time at which the token was issued. Like exp, it is represented as a timestamp. - -- nbf (Not Before) - Specifies the time before which the token should not be considered valid. - -- exp (Expiration Time) - Specifies the expiration time of the token. It is represented as a numeric timestamp (for example, 1654608348), and the token is considered invalid after this time. - -These claims provide information about the JWT and can be used by the recipient to verify the token's authenticity and determine its validity. Additionally, you can include custom claims in the payload to carry additional information specific to your application. - -- **Signature** - To create the signature part, the header and payload are encoded using a specified algorithm and a secret key. This signature can be used to verify the authenticity of the token and to ensure that it has not been tampered with during transmission. The signature is computed based on the algorithm and the keys used and also Base64-encoded. - -#### F5 WAF for NGINX supports the following types of JWT: - -JSON Web Signature (JWS) - JWT content is digitally signed. The following algorithm can be used for signing: - -- RSA/SHA-256 (RS256 for short) - -Here is an example of a Header: describes a JWT signed with HMAC 256 encryption algorithm: - -```json -{ - "alg": "RS256", - "typ": "JWT" -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/json-web-tokens-attack-sigs.md b/content/includes/nap-waf/config/common/json-web-tokens-attack-sigs.md deleted file mode 100644 index 4ad55d12e..000000000 --- a/content/includes/nap-waf/config/common/json-web-tokens-attack-sigs.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -nd-docs: "DOCS-1602" ---- - -Attack signatures are detected within the JSON values of the token, i.e. the header and claims parts, but not on the digital signature part of the token. The detection of signatures, and specifically which signatures are recognized, depends on the configuration entity within the Policy. Typically, this configuration entity is the Authorization HTTP header or else, the header or parameter entity configured as the location of the token in the access profile. - -If the request doesn't align with a URL associated with an Access Profile, an attempt is made to parse the "bearer" type Authorization header, but no violations are raised, except for Base64. More information can be found below: - -1. Token parsed successfully - No violations are detected when enforced on URL with or without access profile. - -2. There are more or less than two dots in the token - `VIOL_ACCESS_MALFORMED` is detected when enforced on URL with access profile. - -3. Base64 decoding failure - `VIOL_ACCESS_MALFORMED` is detected when enforced on URL with access profile. `VIOL_PARAMETER_BASE64` is detected when enforced with access profile. - -4. JSON parsing failure - `VIOL_ACCESS_MALFORMED` is detected when enforced on URL with access profile. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/json-web-tokens-other-references.md b/content/includes/nap-waf/config/common/json-web-tokens-other-references.md deleted file mode 100644 index c79eb0dd0..000000000 --- a/content/includes/nap-waf/config/common/json-web-tokens-other-references.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -nd-docs: "DOCS-1573" ---- - -For more information about JSON Web Token (JWT) see below reference links: - -- [The definition of the JSON Web Token (JWT)](https://datatracker.ietf.org/doc/html/rfc7519) -- [Specification of how tokens are digitally signed](https://datatracker.ietf.org/doc/html/rfc7515) -- [The format of the JSON Web Key (JWK) that needs to be included in the profile for extracting the public keys used to verify the signatures](https://datatracker.ietf.org/doc/html/rfc7515) -- [Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)](https://datatracker.ietf.org/doc/html/rfc7520) \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/json-web-tokens-violation-rating.md b/content/includes/nap-waf/config/common/json-web-tokens-violation-rating.md deleted file mode 100644 index 67875b1b9..000000000 --- a/content/includes/nap-waf/config/common/json-web-tokens-violation-rating.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -nd-docs: "DOCS-1584" ---- - -The default violation rating is set to the level of **5** regardless of any violation. Any changes to these violation settings here will override the default settings. The details regarding logs will be recorded in the security log. All violations will be disabled on upgrade. - -See also the [Violations](#violations) section for more details. \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/json-web-tokens-violations.md b/content/includes/nap-waf/config/common/json-web-tokens-violations.md deleted file mode 100644 index efcad7a2a..000000000 --- a/content/includes/nap-waf/config/common/json-web-tokens-violations.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -nd-docs: "DOCS-1594" ---- - -F5 WAF for NGINX introduces three new violations specific to JWT: `VIOL_ACCESS_INVALID`, `VIOL_ACCESS_MISSING` and `VIOL_ACCESS_MALFORMED`. - -Under the "blocking-settings," user can either enable or disable these violations. Note that these violations will be enabled by default. The details regarding logs will be recorded in the security log. - -See the below example for these violations. - -```shell -{ - "policy": { - "name": "jwt_policy", - "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, - "blocking-settings": { - "violations": [ - { - "alarm": true, - "block": false, - "name": "VIOL_ACCESS_INVALID" - }, - { - "alarm": true, - "block": false, - "name": "VIOL_ACCESS_MISSING" - }, - { - "alarm": true, - "block": false, - "name": "VIOL_ACCESS_MALFORMED" - } - ] - } - } -} -``` \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/modifying-configurations.md b/content/includes/nap-waf/config/common/modifying-configurations.md deleted file mode 100644 index 557d97eae..000000000 --- a/content/includes/nap-waf/config/common/modifying-configurations.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -nd-docs: "DOCS-1591" ---- - -What we have been seeing so far has been related to making changes by actually overriding specific configuration values. What would happen in the case we wanted to remove a specific configuration entity from the policy. For example, let's say we have added file types "aaa", "bbb", and "ccc", and now we wish to remove "bbb" from the list of disallowed file types. Deleting this entity from the declarative configuration file will simply mean that this entity will be left intact when the policy is rebuilt, meaning that the entity is still in the disallowed file types list. To resolve such situations, we have a `modifications` section where we can force modification where otherwise it is not possible using direct declarative configuration. - -There is a specific section named `modifications` where we can configure items to be removed/deleted or forcefully modified in the policy. - -In this example, we specify that we wish to remove the file type **log** from the disallowed file types list. - -```json -{ - "policy": { - "name": "modifying_disallowed_file_types", - "template": { - "name": "POLICY_TEMPLATE_NGINX_BASE" - }, - "applicationLanguage": "utf-8", - "enforcementMode": "blocking" - }, - "modifications": [ - { - "entityChanges": { - "type": "explicit" - }, - "entity": { - "name": "log" - }, - "action": "delete", - "entityType": "filetype" - } - ] -} -``` - -#### entityType List - -The below list provides information about the `entityType` which can be used in the `modifications` section of the App Protect policy: - -- blocking-settings/evasion -- blocking-settings-general -- blocking-settings/http-protocol -- blocking-settings/violation -- bot-defense/mitigations/anomaly -- bot-defense/mitigations/browser -- bot-defense/mitigations/class -- bot-defense/mitigations/signature -- bot-defense/settings -- browser-definition -- character-set -- cookie -- cookie-settings -- csrf-protection -- csrf-url -- data-guard -- enforcer-settings -- filetype -- general -- graphql-profile -- grpc-profile -- header -- header-settings -- host-name -- json-profile -- method -- parameter -- response-page -- signature -- sensitive-parameter -- signature-setting -- url -- whitelist-ip -- xml-profile \ No newline at end of file diff --git a/content/includes/nap-waf/config/common/nginx-app-protect-waf-terminology.md b/content/includes/nap-waf/config/common/nginx-app-protect-waf-terminology.md deleted file mode 100644 index ce32ad960..000000000 --- a/content/includes/nap-waf/config/common/nginx-app-protect-waf-terminology.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -nd-docs: "DOCS-1605" -files: - - content/nap-waf/v5/configuration-guide/configuration.md - - content/nginx-one/glossary.md ---- - -This guide assumes that you have some familiarity with various Layer 7 (L7) Hypertext Transfer Protocol (HTTP) concepts, such as Uniform Resource Identifier (URI)/Uniform Resource Locator (URL), method, header, cookie, status code, request, response, and parameters. - - -{{}} -|Term | Definition | -| ---| --- | -|Alarm | If selected, the F5 WAF for NGINX system records requests that trigger the violation in the remote log (depending on the settings of the logging profile). | -|Attack signature | Textual patterns which can be applied to HTTP requests and/or responses by F5 WAF for NGINX to determine if traffic is malicious. For example, the string `