brute-force-attack-preventions
-| detectionCriteria |
-object |
-Specifies configuration for detecting distributed brute force attacks. |
- |
-
-
| loginAttemptsFromTheSameIp |
object |
Specifies configuration for detecting brute force attacks from IP Address. |
|
-
+
| loginAttemptsFromTheSameUser |
object |
Specifies configuration for detecting brute force attacks for Username. |
|
-
-measurementPeriod |
-integer minimum: 60 maximum: 90000 |
-Defines detection period (measured in seconds) for distributed brute force attacks. |
- |
-
-preventionDuration |
-
-- integer minimum: 60 maximum: 90000
-- string
- |
-Defines prevention period (measured in seconds) for distributed brute force attacks. |
-
-- Integer values
-- "unlimited"
- |
-
-
reEnableLoginAfter |
integer minimum: 60 maximum: 90000 |
Defines prevention period (measured in seconds) for source-based brute force attacks. |
|
-
+
sourceBasedProtectionDetectionPeriod |
integer minimum: 60 maximum: 90000 |
Defines detection period (measured in seconds) for source-based brute force attacks. |
|
-
+
| url |
object |
Reference to the URL used in login URL configuration (policy/login-pages). This login URL is protected by Brute Force Protection feature. |
@@ -858,52 +834,6 @@ brute-force-attack-preventions
-detectionCriteria
-
-
-
-
-
-
-
-
-
-
-
-
-action
|
-string |
-Specifies action that is applied when one of the defined thresholds (credentialsStuffingMatchesReached, failedLoginAttemptsRateReached) is reached.
-
-
-- alarm: The system will log the login attempt.
-- alarm-and-client-side-integrity: The system determines whether the client is a legal browser or a bot by sending a page containing JavaScript code and waiting for a response. Legal browsers are able to execute JavaScript and produce a valid response, whereas bots cannot. A login attempt is logged if the client successfully passes the Client Side Integrity challenge.
-
- |
-
-- alarm
-- alarm-and-client-side-integrity
- |
-
-
-credentialsStuffingMatchesReached |
-integer minimum: 1 maximum: 10000 |
-After configured threshold (number of detected login attempts that match known leaked credentials library) defined action will be applied for the next login attempt. |
- |
-
-
-failedLoginAttemptsRateReached |
-integer minimum: 1 maximum: 10000 |
-After configured threshold (number of failed login attempts within measurementPeriod) defined action will be applied for the next login attempt. |
- |
-
-
-
loginAttemptsFromTheSameIp
@@ -929,17 +859,11 @@ loginA
- alarm: The system will log the login attempt.
- alarm-and-blocking-page: The system will log the login attempt, block the request and send the Blocking page.
-- alarm-and-client-side-integrity: The system determines whether the client is a legal browser or a bot by sending a page containing JavaScript code and waiting for a response. Legal browsers are able to execute JavaScript and produce a valid response, whereas bots cannot. A login attempt is logged if the client successfully passes the Client Side Integrity challenge.
-- alarm-and-drop: The system will log the login attempt and reset the TCP connection.
-- alarm-and-honeypot-page: The system will log the login attempt, block the request and send the Honeypot page. The Honeypot page is used for attacker deception. The page should look like an application failed login page. Unlike with the Blocking page, when the Honeypot page is sent an attacker is not able to distinguish a failed login response from a mitigation. As a result, the attacker will not change identity (Source IP or Device ID) and the brute force attack will be rendered ineffective. The Honeypot page is recommended when mitigation is request blocking.
- alarm
- alarm-and-blocking-page
-- alarm-and-client-side-integrity
-- alarm-and-drop
-- alarm-and-honeypot-page
|
@@ -980,12 +904,10 @@ logi
- alarm: The system will log the login attempt.
-- alarm-and-client-side-integrity: The system determines whether the client is a legal browser or a bot by sending a page containing JavaScript code and waiting for a response. Legal browsers are able to execute JavaScript and produce a valid response, whereas bots cannot. A login attempt is logged if the client successfully passes the Client Side Integrity challenge.
- alarm
-- alarm-and-client-side-integrity
|
diff --git a/content/nap-waf/v4/configuration-guide/configuration.md b/content/nap-waf/v4/configuration-guide/configuration.md
index 8441b62f8..e96be795c 100644
--- a/content/nap-waf/v4/configuration-guide/configuration.md
+++ b/content/nap-waf/v4/configuration-guide/configuration.md
@@ -655,15 +655,43 @@ claims['address'] = "{ \"address\": { .... } }" # JSON structs can be accessed u
### Overview
-Brute force attacks are attempts to break in to secured areas of a web application by trying exhaustive,
+Brute force attacks are attempts to break in to secured areas of a web application by trying exhaustive,
systematic, username/password combinations to discover legitimate authentication credentials.
-To prevent brute force attacks, WAF tracks the number of failed attempts to reach login pages
-with enforced brute force protection. When brute force patterns are detected,
-the WAF policy considers it to be an attack if the failed logon rate increased significantly or
-if failed logins reached a maximum threshold.
+To prevent brute force attacks, NGINX App Protect WAF monitors IP addresses, usernames, and the number of failed login attempts beyond a maximum threshold.
+When brute force patterns are detected, the NGINX App Protect WAF policy either trigger an alarm or block the attack if the failed
+login attempts reached a maximum threshold for a specific username or coming from a specific IP address.
+To enable brute force protection, at least one login page must be created.
+---
+
+### Login page policy example
+
+A login page specifies the login URL that users must pass through to get authenticated. The configuration of a login URL includes the URL itself, the username and passwords parameters and the validation criteria (how we know that a login was successful or failed)
+```json
+ "login-pages": [
+ {
+ "accessValidation" : {
+ "responseContains": "Success"
+ },
+ "authenticationType": "form",
+ "url" : {
+ "method" : "*",
+ "name" : "/html_login",
+ "protocol" : "http",
+ "type" : "explicit"
+ },
+ "usernameParameterName": "username",
+ "passwordParameterName": "password"
+ }
+ ]
+```
+
+{{< note >}} For further configuration details, see NGINX App Protect WAF Declarative Policy Guide [Declarative Policy guide]({{< relref "/nap-waf/v4/declarative-policy/policy/#policy/login-pages" >}}). {{< /note >}}
+
+---
### Brute force policy example
+Example1: A single brute force configuration is applied universally to all login pages.
```json
{
"policy": {
@@ -676,10 +704,6 @@ if failed logins reached a maximum threshold.
"brute-force-attack-preventions" : [
{
"bruteForceProtectionForAllLoginPages" : true,
- "detectionCriteria" : {
- "action" : "alarm",
- "failedLoginAttemptsRateReached" : 100
- },
"loginAttemptsFromTheSameIp" : {
"action" : "alarm",
"enabled" : true,
@@ -690,16 +714,51 @@ if failed logins reached a maximum threshold.
"enabled" : true,
"threshold" : 3
},
- "measurementPeriod" : 900,
- "preventionDuration" : "3600",
"reEnableLoginAfter" : 3600,
"sourceBasedProtectionDetectionPeriod" : 3600
}
]
}
}
+```
+Example2: Different brute force configurations can be defined for individual login pages.
+```json
+{
+ "policy": {
+ "name": "BruteForcePolicySpec",
+ "template": {
+ "name": "POLICY_TEMPLATE_NGINX_BASE"
+ },
+ "applicationLanguage": "utf-8",
+ "enforcementMode": "blocking",
+ "brute-force-attack-preventions" : [
+ {
+ "bruteForceProtectionForAllLoginPages" : false,
+ "loginAttemptsFromTheSameIp" : {
+ "action" : "alarm",
+ "enabled" : true,
+ "threshold" : 20
+ },
+ "loginAttemptsFromTheSameUser" : {
+ "action" : "alarm",
+ "enabled" : true,
+ "threshold" : 3
+ },
+ "reEnableLoginAfter" : 3600,
+ "sourceBasedProtectionDetectionPeriod" : 3600,
+ "url": {
+ "method": "*",
+ "name": "/html_login",
+ "protocol": "http"
+ }
+ }
+ ],
+
+ }
+}
```
+{{< note >}} For further configuration details, see NGINX App Protect WAF Declarative Policy Guide [Declarative Policy guide]({{< relref "/nap-waf/v4/declarative-policy/policy/#policy/brute-force-attack-preventions" >}}). {{< /note >}}
## Custom Dimensions Log Entries
diff --git a/content/nap-waf/v5/configuration-guide/configuration.md b/content/nap-waf/v5/configuration-guide/configuration.md
index 09463695b..1121f7688 100644
--- a/content/nap-waf/v5/configuration-guide/configuration.md
+++ b/content/nap-waf/v5/configuration-guide/configuration.md
@@ -791,15 +791,46 @@ To enable mTLS in NGINX, you need to perform the following steps:
## Brute Force Attack Preventions
-Brute force attacks are attempts to break in to secured areas of a web application by trying exhaustive,
+### Overview
+
+Brute force attacks are attempts to break in to secured areas of a web application by trying exhaustive,
systematic, username/password combinations to discover legitimate authentication credentials.
-To prevent brute force attacks, WAF tracks the number of failed attempts to reach login pages
-with enforced brute force protection. When brute force patterns are detected,
-the WAF policy considers it to be an attack if the failed logon rate increased significantly or
-if failed logins reached a maximum threshold.
+To prevent brute force attacks, NGINX App Protect WAF monitors IP addresses, usernames, and the number of failed login attempts beyond a maximum threshold.
+When brute force patterns are detected, the NGINX App Protect WAF policy either trigger an alarm or block the attack if the failed
+login attempts reached a maximum threshold for a specific username or coming from a specific IP address.
+To enable brute force protection, at least one login page must be created.
+
+---
+
+### Login page policy example
+
+A login page specifies the login URL that users must pass through to get authenticated. The configuration of a login URL includes the URL itself, the username and passwords parameters and the validation criteria (how we know that a login was successful or failed)
+```json
+ "login-pages": [
+ {
+ "accessValidation" : {
+ "responseContains": "Success"
+ },
+ "authenticationType": "form",
+ "url" : {
+ "method" : "*",
+ "name" : "/html_login",
+ "protocol" : "http",
+ "type" : "explicit"
+ },
+ "usernameParameterName": "username",
+ "passwordParameterName": "password"
+ }
+ ]
+```
+
+{{< note >}} For further configuration details, see NGINX App Protect WAF Declarative Policy Guide [Declarative Policy guide]({{< relref "/nap-waf/v5/declarative-policy/policy/#policy/login-pages" >}}). {{< /note >}}
+
+---
### Brute force policy example
+Example1: A single brute force configuration is applied universally to all login pages.
```json
{
"policy": {
@@ -812,11 +843,6 @@ if failed logins reached a maximum threshold.
"brute-force-attack-preventions" : [
{
"bruteForceProtectionForAllLoginPages" : true,
- "detectionCriteria" : {
- "action" : "alarm",
- "detectDistributedBruteForceAttack" : true,
- "failedLoginAttemptsRateReached" : 100
- },
"loginAttemptsFromTheSameIp" : {
"action" : "alarm",
"enabled" : true,
@@ -827,16 +853,51 @@ if failed logins reached a maximum threshold.
"enabled" : true,
"threshold" : 3
},
- "measurementPeriod" : 900,
- "preventionDuration" : "3600",
"reEnableLoginAfter" : 3600,
"sourceBasedProtectionDetectionPeriod" : 3600
}
]
}
}
+```
+Example2: Different brute force configurations can be defined for individual login pages.
+```json
+{
+ "policy": {
+ "name": "BruteForcePolicySpec",
+ "template": {
+ "name": "POLICY_TEMPLATE_NGINX_BASE"
+ },
+ "applicationLanguage": "utf-8",
+ "enforcementMode": "blocking",
+ "brute-force-attack-preventions" : [
+ {
+ "bruteForceProtectionForAllLoginPages" : false,
+ "loginAttemptsFromTheSameIp" : {
+ "action" : "alarm",
+ "enabled" : true,
+ "threshold" : 20
+ },
+ "loginAttemptsFromTheSameUser" : {
+ "action" : "alarm",
+ "enabled" : true,
+ "threshold" : 3
+ },
+ "reEnableLoginAfter" : 3600,
+ "sourceBasedProtectionDetectionPeriod" : 3600,
+ "url": {
+ "method": "*",
+ "name": "/html_login",
+ "protocol": "http"
+ }
+ }
+ ],
+
+ }
+}
```
+{{< note >}} For further configuration details, see NGINX App Protect WAF Declarative Policy Guide [Declarative Policy guide]({{< relref "/nap-waf/v5/declarative-policy/policy/#policy/brute-force-attack-preventions" >}}). {{< /note >}}
## Custom Dimensions Log Entries