Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
20 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
182 changes: 182 additions & 0 deletions content/nginx-one/nap-integration/add-signature-sets.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,182 @@
---
title: "Add signature sets and exceptions"
weight: 300
toc: true
nd-content-type: how-to
nd-product: NGINX One Console
---

This document describes how you can configure signature sets and signature exceptions in F5 WAF for NGINX policies. When you add a policy, NGINX One Console provides options to customize attack signatures to better protect your applications.

## Understanding signature sets and exceptions

Attack signatures are rules or patterns that identify attack sequences or classes of attacks on a web application. F5 WAF for NGINX includes predefined attack signatures grouped into signature sets.

### Signature set

A **signature set** is a collection of attack signatures with a specific name and purpose. These sets are predefined and can be enabled or disabled in your policy.

For example, you might have sets for SQL Injection Signatures, Cross-Site Scripting Signatures, or Buffer Overflow Signatures.

### Signature exception

A **signature exception** allows you to explicitly enable or disable individual attack signatures within a set. This gives you granular control over your policy. For example:
- If a signature in a set causes false positives (blocking legitimate traffic), you can create an exception to disable just that signature while keeping the rest of the set active.
- If you want to enable blocking for one specific attack signature rather than an entire set, you can create an exception to enable just that signature.

## Add signature sets

From NGINX One Console, select **App Protect > Policies**. In the screen that appears, select **Add Policy**. That action opens a screen where you can:

1. In **General Settings**, name and describe the policy.
1. Go to the **Web Protection** tab and select **Attack Signature Sets**. Here, you can:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: instead of the word tab I'd suggest suggest calling it a section

- View all enabled attack signature sets, including the default ones
- Add new signature sets
- Modify existing signature sets

### Configure signature sets

For each signature set, you can configure:
- **Alarm**: When enabled, matching requests are logged
- **Block**: When enabled, matching requests are blocked

For example, to configure Buffer Overflow Signatures to log but not block:

```json
{
"policy": {
"name": "buffer_overflow_signature",
"template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
"signature-sets": [
{
"name": "Buffer Overflow Signatures",
"alarm": true,
"block": false
}
]
}
}
```

### Remove signature sets

To remove a signature set from your policy, you have two options:

1. Disable the set by setting both `alarm` and `block` to `false`:

```json
{
"policy": {
"name": "no_xpath_policy",
"template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
"signature-sets": [
{
"name": "XPath Injection Signatures",
"block": false,
"alarm": false
}
]
}
}
```

1. Use the `$action` meta-property to delete the set (preferred for better performance):

```json
{
"policy": {
"name": "no_xpath_policy",
"template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
"signature-sets": [
{
"name": "XPath Injection Signatures",
"$action": "delete"
}
]
}
}
```

## Add signature exceptions

From the **Web Protection** tab, select **Attack Signature Exceptions**. This section allows you to override settings for individual signatures.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: same thing here. I'd suggest section instead of tab


1. Click **Add Item** to create a new exception.
1. Select the signature(s) you want to modify.
1. Configure the exception. For example, to disable a specific signature:

```json
{
"signatures": [
{
"name": "_mem_bin access",
"enabled": false,
"signatureId": 200100022
}
]
}
```

### Advanced exception configuration
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest removing this entire Advanced exception configuration section. The App Protect schema that we're using to validate policies doesn't include the top-level modifications section so the UI doesn't use or respect data defined there.


For more complex scenarios, you can use the `modifications` section:

```json
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-blocking formatting: As you can see from previous lines, if you include indentation, the format is nicer.

{
"modifications": [
{
"entityChanges": {
"enabled": false
},
"entity": {
"signatureId": 200001834
},
"entityType": "signature",
"action": "add-or-update"
}
]
}
```

To exclude multiple signatures, add each as a separate entity:

```json
{
"modifications": [
{
"entityChanges": {
"enabled": false
},
"entity": {
"signatureId": 200001834
},
"entityType": "signature",
"action": "add-or-update"
},
{
"entityChanges": {
"enabled": false
},
"entity": {
"signatureId": 200004461
},
"entityType": "signature",
"action": "add-or-update"
}
]
}
```

## Save and deploy your policy

After configuring signature sets and exceptions:

1. Select **Save Policy**. The policy JSON will be updated with your changes.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: the steps outlined here start by creating a new policy. The CTA text when creating a new policy is "Add Policy". The CTA text is "Save Policy" when editing an existing policy.

1. Your policy will appear in the list under the name you provided.
1. You can then [deploy]({{< ref "/nginx-one/nap-integration/deploy-policy.md/" >}}) the policy to either:
- An instance
- A Config Sync Group

From NGINX One Console, you can [review and modify]({{< ref "/nginx-one/nap-integration/review-policy.md/" >}}) your saved policies at any time by selecting **App Protect > Policies**.

For a complete list of available signature sets and detailed information about attack signatures, see the [Attack Signatures]({{< ref "/waf/policies/attack-signatures.md" >}}) documentation.
39 changes: 39 additions & 0 deletions content/nginx-one/nap-integration/advanced-configurations.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
---
title: "Advanced configuration for NAP policies"
weight: 700
toc: true
nd-content-type: how-to
nd-product: NGINX One Console
---

This document consolidates advanced configuration options for parameters, URLs, and cookies in NGINX App Protect (NAP) policies. These configurations allow for fine-tuning security settings to meet specific application requirements. By centralizing these options, this guide provides a unified reference for creating granular and robust security policies.

## Shared Advanced Configuration Options

The following advanced configuration options are common to parameters, URLs, and cookies:

- **Length Restrictions**: Define maximum allowable lengths to prevent excessively long inputs that could indicate malicious activity.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Length restrictions only seem to apply to parameters from what I can tell from the policy schema. And currently the UI does not yet support a way to configure these without just directly modifying the JSON.

- **Meta Character Overrides**: Specify allowed or disallowed meta characters to ensure compliance with application-specific requirements.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Meta Character Overrides only seem to apply to parameters and URLs from what I can tell from the policy schema. And currently the UI does not yet support a way to configure these without just directly modifying the JSON.

- **Custom Signature Sets**: Apply custom signature sets to tailor attack detection mechanisms for specific use cases.

## Parameter-Specific Configuration Options

In addition to the shared options, parameters support the following advanced configurations:

- **Regular Expression Patterns**: Use regex patterns to validate parameter values against expected formats, enhancing security and reducing false positives.
- **Static Value Constraints**: Set fixed values for parameters to enforce strict compliance with predefined rules.
- **Numeric Value Ranges**: Define acceptable numeric ranges for parameters to prevent out-of-bound values.
Comment on lines +23 to +25
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI currently the UI does not yet support a way to configure these without just directly modifying the JSON.


## URL-Specific Configuration Options

In addition to the shared options, URLs support the following advanced configurations:

- **Content Type Profiles**: Configure content type profiles (e.g., JSON, XML, form-data) to validate request payloads.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently the UI does not yet support a way to configure these without just directly modifying the JSON.


## Cookie-Specific Configuration Options

In addition to the shared options, cookies support the following advanced configurations:

- **Mask Value in Logs**: Enable masking of cookie values in logs for enhanced security and privacy.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you called this out explicitly for cookies, parameters also supports a similar option which is also called "Mask value in logs" for consistency in the UI and that controls the sensitiveParameter property of the parameter item.


These configurations help create a more granular and specific security policy for your application. For detailed instructions on implementing these options, refer to the [Policy Parameter Reference]({{< ref "/waf/policies/parameter-reference.md" >}}).
173 changes: 173 additions & 0 deletions content/nginx-one/nap-integration/cookies-params-urls.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,173 @@
---
title: "Add cookies, parameters and urls"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
title: "Add cookies, parameters and urls"
title: "Add cookies, parameters and URLs"

weight: 400
toc: true
nd-content-type: how-to
nd-product: NGINX One Console
---

# Add cookies
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a markdown standard to include a blank line after each header

Cookies can be configured and managed directly within the policy editor by selecting the **Cookies** option.

## Cookie properties and types
Each cookie configuration includes:
- `Cookie Type`: `Explicit` or `Wildcard`. For details on explicit and wildcard matching, see the [Matching Types: Explicit vs Wildcard]({{< ref "/nginx-one/nap-integration/waf-policy-matching-types.md" >}}) section.
- `Cookie Name`: The name of the cookie to be monitored or protected
- `Enforcement Type`:
- **Allow**: Permits the cookie with optional attack signature checks
- **Disallow**: Blocks the use of the cookie entirely
- `Attack Signatures`: Indicates whether attack signatures and threat campaigns are enabled, disabled, or not applicable
- `Mask Value in Logs`: When enabled, the cookie's value will be masked in the request log for enhanced security and privacy

**⚠️ Important:** Attack Signatures are automatically set to "Not Applicable" when Enforcement Type is set to `Disallow` since the URL is explicitly blocked and signature checking is unnecessary.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**⚠️ Important:** Attack Signatures are automatically set to "Not Applicable" when Enforcement Type is set to `Disallow` since the URL is explicitly blocked and signature checking is unnecessary.
{{< call-out "important" >}}
**⚠️ Important:** Attack Signatures are automatically set to "Not Applicable" when Enforcement Type is set to `Disallow` since the URL is explicitly blocked and signature checking is unnecessary.
{{< /call-out >}}


For a complete list of configurable cookie properties and options, see the [Cookie Configuration Parameters]({{< ref "/waf/policies/parameter-reference.md" >}}) documentation under the `cookies` section.

## Cookie violations
Click on **Edit Configuration** to configure cookie violations. The following violations can be configured for cookies:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our style guide pushes "Submit" over "Click"

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you mean "Select" and not "Submit"? e.g. Select **Edit Configuration**

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I believe it should be "Select", as Travis suggested the same. Thanks for catching this.


- `VIOL_COOKIE_EXPIRED`: Triggered when a cookie's timestamp is expired
- `VIOL_COOKIE_LENGTH`: Triggered when cookie length exceeds the configured limit
- `VIOL_COOKIE_MALFORMED`: Triggered when cookies are not RFC-compliant
- `VIOL_COOKIE_MODIFIED`: Triggered when domain cookies have been tampered with

For each violation type, you can:
- Set the enforcement action
- Toggle `alarm` and `block` settings

For more details about enforcement modes, see the [Glossary]({{< ref "/nginx-one/glossary.md#nginx-app-protect-waf-terminology" >}}), specifically the entry: **Enforcement mode**.

See the [Supported Violations]({{< ref "/waf/policies/violations.md#supported-violations" >}}) for additional details.

## Adding a cookie to your policy
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this has been noted before -- avoid the "ing" nouns like "Adding"

Suggested change
## Adding a cookie to your policy
## Add a cookie to your policy


1. Choose Cookie Type:
- Select either `Explicit` for exact cookie matching or `Wildcard` for pattern-based matching

1. Configure Basic Properties:
- Enter the `Cookie Name`
- Choose whether to mask the cookie value in logs

1. Set Enforcement:
- Choose whether to allow or disallow the cookie
- If `Allow Cookie` is selected, you can optionally enable attack signatures
- **⚠️ Important:** Attack signatures cannot be enabled for disallowed cookies.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also see previous formatting for "Important"


1. Optional: Configure Attack Signatures
- If enabled, you can overwrite attack signatures for this specific cookie
- For details on signature configuration, refer to the documentation on [Add Signature Sets]({{< ref "/nginx-one/nap-integration/add-signature-sets.md/" >}})

1. Select **Add Cookie** to save your configuration

# Add parameters
Parameters can be configured and managed directly within the policy editor by selecting the **Parameters** option.

## Parameter properties and types
Each parameter configuration includes:
- `Parameter Type`: `Explicit` or `Wildcard`. For details on explicit and wildcard matching, see the [Matching Types: Explicit vs Wildcard]({{< ref "/nginx-one/nap-integration/waf-policy-matching-types.md" >}}) section.
- `Name`: The name of the parameter
- `Location`: Where the parameter is expected (URL query string, POST data, etc.)
- `Value Type`: The expected type of the parameter value (e.g., alpha-numeric, integer, email)
- `Attack Signatures`: Whether attack signature checking is enabled for this parameter
- `Mask Value in Logs`: When enabled, the parameter's value will be masked in the request log for enhanced security and privacy

For a complete list of configurable cookie properties and options, see the [Parameter Configuration Parameters]({{< ref "/waf/policies/parameter-reference.md" >}}) documentation under the `parameters` section.

## Parameter violations
Select **Edit Configuration** to configure parameter violations. The following violations can be configured for parameters:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Future issue: we need to set up common content with content/includes/nap-waf/config/common/supported-violations.md

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


- `VIOL_PARAMETER`: Triggered when an illegal parameter is detected
- `VIOL_PARAMETER_ARRAY_VALUE`: Triggered when an array parameter value is illegal
- `VIOL_PARAMETER_DATA_TYPE`: Triggered when parameter data type doesn't match configuration
- `VIOL_PARAMETER_EMPTY_VALUE`: Triggered when a parameter value is empty but shouldn't be
- `VIOL_PARAMETER_LOCATION`: Triggered when a parameter is found in wrong location
- `VIOL_PARAMETER_NAME_METACHAR`: Triggered when illegal meta characters are found in parameter name
- `VIOL_PARAMETER_NUMERIC_VALUE`: Triggered when numeric parameter value is outside allowed range
- `VIOL_PARAMETER_REPEATED`: Triggered when a parameter name is repeated illegally
- `VIOL_PARAMETER_STATIC_VALUE`: Triggered when a static parameter value doesn't match configuration
- `VIOL_PARAMETER_VALUE_LENGTH`: Triggered when parameter value length exceeds limits
- `VIOL_PARAMETER_VALUE_METACHAR`: Triggered when illegal meta characters are found in parameter value
- `VIOL_PARAMETER_VALUE_REGEXP`: Triggered when parameter value doesn't match required pattern

For each violation type, you can:
- Set the enforcement action
- Toggle `alarm` and `block` settings

For more details about enforcement modes, see the [Glossary]({{< ref "/nginx-one/glossary.md#nginx-app-protect-waf-terminology" >}}), specifically the entry: **Enforcement mode**.

See the [Supported Violations]({{< ref "/waf/policies/violations.md#supported-violations" >}}) for additional details.

## Adding a parameter to your policy

1. Choose Parameter Type:
- Select either `Explicit` for exact parameter matching or `Wildcard` for pattern-based matching

1. Configure Basic Properties:
- Enter the parameter `Name`
- Select the `Location` where the parameter is expected
- Choose the `Value Type` (alpha-numeric, integer, email, etc.)
- Set the `Data Type` if applicable

1. Set Security Options:
- Choose whether to enable attack signatures
- Decide if parameter value should be masked in logs which sets `sensitiveParameter` in [Parameter Configuration Reference]({{< ref "/waf/policies/parameter-reference.md" >}})

1. Optional: Configure Attack Signatures
- If enabled, you can overwrite attack signatures for this specific parameter
- For details on signature configuration, refer to the documentation on [Add Signature Sets]({{< ref "/nginx-one/nap-integration/add-signature-sets.md/" >}})

1. Select **Add Parameter** to save your configuration

# Add urls
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# Add urls
# Add URLs

URLs can be configured and managed directly within the policy editor by selecting the **URLs** option.

## URL properties and types
Each URL configuration includes:
- `URL Type`: `Explicit` or `Wildcard`. For details on explicit and wildcard matching, see the [Matching Types: Explicit vs Wildcard]({{< ref "/nginx-one/nap-integration/waf-policy-matching-types.md" >}}) section.
- `Method`: Specifies which HTTP methods are allowed (`GET`, `POST`, `PUT`, etc.)
- `Protocol`: The protocol for the URL (`HTTP`/`HTTPS`)
- `Enforcement Type`:
- **Allow**: Permits access to the URL with optional attack signature checks
- **Disallow**: Blocks access to the URL entirely
- `Attack Signatures`: Indicates whether attack signatures and threat campaigns are enabled, disabled, or not applicable

**⚠️ Important:** Attack Signatures are automatically set to "Not Applicable" when Enforcement Type is set to `Disallow` since the URL is explicitly blocked and signature checking is unnecessary.

For a complete list of configurable URL properties and options, see the [URL Configuration Parameters]({{< ref "/waf/policies/parameter-reference.md" >}}) documentation under the `urls` section.

## URL violations
Select **Edit Configuration** to configure URL violations. The following violations can be configured for URLs:

- `VIOL_URL`: Triggered when an illegal URL is accessed
- `VIOL_URL_CONTENT_TYPE`: Triggered when there's an illegal request content type
- `VIOL_URL_LENGTH`: Triggered when URL length exceeds the configured limit
- `VIOL_URL_METACHAR`: Triggered when illegal meta characters are found in the URL

For each violation type, you can:
- Set the enforcement action
- Toggle `alarm` and `block` settings

For more details about enforcement modes, see the [Glossary]({{< ref "/nginx-one/glossary.md#nginx-app-protect-waf-terminology" >}}), specifically the entry: **Enforcement mode**.

See the [Supported Violations]({{< ref "/waf/policies/violations.md#supported-violations" >}}) for additional details.

## Adding a URL to your policy

1. Choose URL Type:
- Select either `Explicit` for exact URL matching or `Wildcard` for pattern-based matching

1. Configure Basic Properties:
- Enter the `URL` path
- Select allowed `Method(s)` (e.g., `GET`, `POST`, *)
- Choose the `Protocol` (`HTTP`/`HTTPS`)

1. Set Enforcement:
- Choose whether to allow or disallow the URL
- If `Allow URL` is selected, you can optionally enable attack signatures
- **⚠️ Important:** Attack signatures cannot be enabled for disallowed URLs.

1. **Optional**: Configure Attack Signatures
- If enabled, you can overwrite attack signatures for this specific URL
- For details on signature configuration, refer to the documentation on [Add Signature Sets]({{< ref "/nginx-one/nap-integration/add-signature-sets.md/" >}})

1. Select **Add URL** to save your configuration
Loading