Skip to content

Update policy.html #127

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jan 28, 2025
Merged

Update policy.html #127

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
7691429
Update policy.html
ohad-perets Jan 28, 2025
e14b8d9
Update policy.html
ohad-perets Jan 28, 2025
0e82d92
Update policy.html
ohad-perets Jan 28, 2025
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
234 changes: 0 additions & 234 deletions content/includes/nap-waf/policy.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -803,36 +803,12 @@ <h2 id="policy/brute-force-attack-preventions">brute-force-attack-preventions</h
<td></td>
</tr>
<tr class="even">
<td><a href="#policy/brute-force-attack-preventions/captchaBypassCriteria">captchaBypassCriteria</a></td>
<td>object</td>
<td>Specifies configuration for CAPTCHA Bypass Mitigation.</td>
<td></td>
</tr>
<tr class="odd">
<td><a href="#policy/brute-force-attack-preventions/clientSideIntegrityBypassCriteria">clientSideIntegrityBypassCriteria</a></td>
<td>object</td>
<td>Specifies configuration for Client Side Integrity Bypass Mitigation.</td>
<td></td>
</tr>
<tr class="even">
<td><a href="#policy/brute-force-attack-preventions/detectionCriteria">detectionCriteria</a></td>
<td>object</td>
<td>Specifies configuration for detecting distributed brute force attacks.</td>
<td></td>
</tr>
<tr class="odd">
<td><a href="#policy/brute-force-attack-preventions/leakedCredentialsCriteria">leakedCredentialsCriteria</a></td>
<td>object</td>
<td>Specifies configuration for Leaked Credentials Detection.</td>
<td></td>
</tr>
<tr class="even">
<td><a href="#policy/brute-force-attack-preventions/loginAttemptsFromTheSameDeviceId">loginAttemptsFromTheSameDeviceId</a></td>
<td>object</td>
<td>Specifies configuration for detecting brute force attacks for Device ID.</td>
<td></td>
</tr>
<tr class="odd">
<td><a href="#policy/brute-force-attack-preventions/loginAttemptsFromTheSameIp">loginAttemptsFromTheSameIp</a></td>
<td>object</td>
<td>Specifies configuration for detecting brute force attacks from IP Address.</td>
Expand Down Expand Up @@ -882,98 +858,6 @@ <h2 id="policy/brute-force-attack-preventions">brute-force-attack-preventions</h
</tr>
</tbody>
</table>
<h3 id="policy/brute-force-attack-preventions/captchaBypassCriteria">captchaBypassCriteria</h3>
<table>
<colgroup>
<col style="width: 29%" />
<col style="width: 5%" />
<col style="width: 47%" />
<col style="width: 17%" />
</colgroup>
<thead>
<tr class="header">
<th>Field Name</th>
<th>Type</th>
<th>Description</th>
<th>Allowed Values</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><p><code>action</code></p></td>
<td><p>string</p></td>
<td><p>Specifies action that is applied when defined threshold is reached.</p>
<blockquote>
<ul>
<li><strong>alarm-and-blocking-page</strong>: The system will log the login attempt, block the request and send the Blocking page.</li>
<li><strong>alarm-and-drop</strong>: The system will log the login attempt and reset the TCP connection.</li>
<li><strong>alarm-and-honeypot-page</strong>: 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.</li>
</ul>
</blockquote></td>
<td><ul>
<li>alarm-and-blocking-page</li>
<li>alarm-and-drop</li>
<li>alarm-and-honeypot-page</li>
</ul></td>
</tr>
<tr class="even">
<td><code>enabled</code></td>
<td>boolean</td>
<td>When enabled, the system counts successful CAPTCHA challenges with failed logins from IP Address / Device ID.</td>
<td></td>
</tr>
<tr class="odd">
<td><code>threshold</code></td>
<td>integer minimum: 1 maximum: 100</td>
<td>After configured threshold (number of successful CAPTCHA challenges with failed logins from IP Address / Device ID) defined action will be applied for the next login attempt</td>
<td></td>
</tr>
</tbody>
</table>
<h3 id="policy/brute-force-attack-preventions/clientSideIntegrityBypassCriteria">clientSideIntegrityBypassCriteria</h3>
<table>
<colgroup>
<col style="width: 29%" />
<col style="width: 5%" />
<col style="width: 47%" />
<col style="width: 17%" />
</colgroup>
<thead>
<tr class="header">
<th>Field Name</th>
<th>Type</th>
<th>Description</th>
<th>Allowed Values</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><p><code>action</code></p></td>
<td><p>string</p></td>
<td><p>Specifies action that is applied when defined threshold is reached.</p>
<blockquote>
<ul>
<li><strong>alarm-and-captcha</strong>: The system determines whether the client is a legal browser operated by a human user by sending a CAPTCHA challenge. A login attempt is logged if the client successfully passes the CAPTCHA challenge.</li>
</ul>
</blockquote></td>
<td><ul>
<li>alarm-and-captcha</li>
</ul></td>
</tr>
<tr class="even">
<td><code>enabled</code></td>
<td>boolean</td>
<td>When enabled, the system counts successful challenges with failed logins from IP Address / Device ID / Username. Legitimate users who have disabled JavaScripting on their browsers for security reasons will fail a client side integrity challenge.</td>
<td></td>
</tr>
<tr class="odd">
<td><code>threshold</code></td>
<td>integer minimum: 1 maximum: 100</td>
<td>After configured threshold (number of successful challenges with failed logins from IP Address / Device ID / Username) defined action will be applied for the next login attempt</td>
<td></td>
</tr>
</tbody>
</table>
<h3 id="policy/brute-force-attack-preventions/detectionCriteria">detectionCriteria</h3>
<table>
<colgroup>
Expand All @@ -998,16 +882,12 @@ <h3 id="policy/brute-force-attack-preventions/detectionCriteria">detectionCriter
<blockquote>
<ul>
<li><strong>alarm</strong>: The system will log the login attempt.</li>
<li><strong>alarm-and-captcha</strong>: The system determines whether the client is a legal browser operated by a human user by sending a CAPTCHA challenge. A login attempt is logged if the client successfully passes the CAPTCHA challenge.</li>
<li><strong>alarm-and-client-side-integrity</strong>: 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.</li>
<li><strong>alarm-and-client-side-integrity-captcha</strong>: The system sends a Client Side Integrity challenge upon the first failed login attempt from a source and a CAPTCHA challenge upon second and all subsequent failed login attempts. A login attempt is logged if client successfully passes the challenge. This enforcement action should be chosen if CAPTCHA is considered intrusive. Benign users who mistype their password will likely get only the Client Side Integrity challenge, while an attacker will eventually get the CAPTCHA challenge.</li>
</ul>
</blockquote></td>
<td><ul>
<li>alarm</li>
<li>alarm-and-captcha</li>
<li>alarm-and-client-side-integrity</li>
<li>alarm-and-client-side-integrity-captcha</li>
</ul></td>
</tr>
<tr class="even">
Expand All @@ -1017,123 +897,13 @@ <h3 id="policy/brute-force-attack-preventions/detectionCriteria">detectionCriter
<td></td>
</tr>
<tr class="odd">
<td><code>detectCredentialsStuffingAttack</code></td>
<td>boolean</td>
<td>When enabled, the system detects login attempts that match known leaked credentials library.</td>
<td></td>
</tr>
<tr class="even">
<td><code>detectDistributedBruteForceAttack</code></td>
<td>boolean</td>
<td>When enabled, the system detects distributed brute force attacks.</td>
<td></td>
</tr>
<tr class="odd">
<td><code>failedLoginAttemptsRateReached</code></td>
<td>integer minimum: 1 maximum: 10000</td>
<td>After configured threshold (number of failed login attempts within measurementPeriod) defined action will be applied for the next login attempt.</td>
<td></td>
</tr>
</tbody>
</table>
<h3 id="policy/brute-force-attack-preventions/leakedCredentialsCriteria">leakedCredentialsCriteria</h3>
<table>
<colgroup>
<col style="width: 29%" />
<col style="width: 5%" />
<col style="width: 47%" />
<col style="width: 17%" />
</colgroup>
<thead>
<tr class="header">
<th>Field Name</th>
<th>Type</th>
<th>Description</th>
<th>Allowed Values</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><p><code>action</code></p></td>
<td><p>string</p></td>
<td><p>Specifies action when leaked credentials detected.</p>
<blockquote>
<ul>
<li><strong>alarm</strong>: The system will log the login attempt.</li>
<li><strong>alarm-and-blocking-page</strong>: The system will log the login attempt, block the request and send the Blocking page.</li>
<li><strong>alarm-and-honeypot-page</strong>: 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.</li>
<li><strong>alarm-and-leaked-credentials-response-page</strong>: The default response page warns the user that the username and password have been leaked and the password should be changed.</li>
</ul>
</blockquote></td>
<td><ul>
<li>alarm</li>
<li>alarm-and-blocking-page</li>
<li>alarm-and-honeypot-page</li>
<li>alarm-and-leaked-credentials-response-page</li>
</ul></td>
</tr>
<tr class="even">
<td><code>enabled</code></td>
<td>boolean</td>
<td>When enabled, the system can match presented credentials to those in the credentials dictionary to detect leaked credentials.</td>
<td></td>
</tr>
</tbody>
</table>
<h3 id="policy/brute-force-attack-preventions/loginAttemptsFromTheSameDeviceId">loginAttemptsFromTheSameDeviceId</h3>
<table>
<colgroup>
<col style="width: 29%" />
<col style="width: 5%" />
<col style="width: 47%" />
<col style="width: 17%" />
</colgroup>
<thead>
<tr class="header">
<th>Field Name</th>
<th>Type</th>
<th>Description</th>
<th>Allowed Values</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><p><code>action</code></p></td>
<td><p>string</p></td>
<td><p>Specifies action that is applied when defined threshold is reached.</p>
<blockquote>
<ul>
<li><strong>alarm</strong>: The system will log the login attempt.</li>
<li><strong>alarm-and-blocking-page</strong>: The system will log the login attempt, block the request and send the Blocking page.</li>
<li><strong>alarm-and-captcha</strong>: The system determines whether the client is a legal browser operated by a human user by sending a CAPTCHA challenge. A login attempt is logged if the client successfully passes the CAPTCHA challenge.</li>
<li><strong>alarm-and-client-side-integrity</strong>: 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.</li>
<li><strong>alarm-and-drop</strong>: The system will log the login attempt and reset the TCP connection.</li>
<li><strong>alarm-and-honeypot-page</strong>: 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.</li>
</ul>
</blockquote></td>
<td><ul>
<li>alarm</li>
<li>alarm-and-blocking-page</li>
<li>alarm-and-captcha</li>
<li>alarm-and-client-side-integrity</li>
<li>alarm-and-drop</li>
<li>alarm-and-honeypot-page</li>
</ul></td>
</tr>
<tr class="even">
<td><code>enabled</code></td>
<td>boolean</td>
<td>When enabled, the system counts failed login attempts for Device ID.</td>
<td></td>
</tr>
<tr class="odd">
<td><code>threshold</code></td>
<td>integer minimum: 1 maximum: 100</td>
<td>After configured threshold (number of failed login attempts for Device ID) defined action will be applied for the next login attempt.</td>
<td></td>
</tr>
</tbody>
</table>
<h3 id="policy/brute-force-attack-preventions/loginAttemptsFromTheSameIp">loginAttemptsFromTheSameIp</h3>
<table>
<colgroup>
Expand All @@ -1159,7 +929,6 @@ <h3 id="policy/brute-force-attack-preventions/loginAttemptsFromTheSameIp">loginA
<ul>
<li><strong>alarm</strong>: The system will log the login attempt.</li>
<li><strong>alarm-and-blocking-page</strong>: The system will log the login attempt, block the request and send the Blocking page.</li>
<li><strong>alarm-and-captcha</strong>: The system determines whether the client is a legal browser operated by a human user by sending a CAPTCHA challenge. A login attempt is logged if the client successfully passes the CAPTCHA challenge.</li>
<li><strong>alarm-and-client-side-integrity</strong>: 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.</li>
<li><strong>alarm-and-drop</strong>: The system will log the login attempt and reset the TCP connection.</li>
<li><strong>alarm-and-honeypot-page</strong>: 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.</li>
Expand All @@ -1168,7 +937,6 @@ <h3 id="policy/brute-force-attack-preventions/loginAttemptsFromTheSameIp">loginA
<td><ul>
<li>alarm</li>
<li>alarm-and-blocking-page</li>
<li>alarm-and-captcha</li>
<li>alarm-and-client-side-integrity</li>
<li>alarm-and-drop</li>
<li>alarm-and-honeypot-page</li>
Expand Down Expand Up @@ -1212,13 +980,11 @@ <h3 id="policy/brute-force-attack-preventions/loginAttemptsFromTheSameUser">logi
<blockquote>
<ul>
<li><strong>alarm</strong>: The system will log the login attempt.</li>
<li><strong>alarm-and-captcha</strong>: The system determines whether the client is a legal browser operated by a human user by sending a CAPTCHA challenge. A login attempt is logged if the client successfully passes the CAPTCHA challenge.</li>
<li><strong>alarm-and-client-side-integrity</strong>: 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.</li>
</ul>
</blockquote></td>
<td><ul>
<li>alarm</li>
<li>alarm-and-captcha</li>
<li>alarm-and-client-side-integrity</li>
</ul></td>
</tr>
Expand Down