Using the deception action
IMPORTANT:
This guide only applies to Next-Gen WAF customers with access to the Next-Gen WAF control panel.
To help defend your web applications from Account Takeover (ATO) attacks (e.g., credential stuffing), you can add rules that use the Deception action type. When the Next-Gen WAF identifies POST requests to login forms that match these rules, the WAF prevents the requests from accessing your origin and returns an invalid credentials page. This response tricks attackers into believing their attack failed due to incorrect credentials, when in reality the WAF actually blocked them. The deception response discourages attackers from continuing their account takeover attempts to save resources and time.
Prerequisites
To use the deception action, be sure you have the following prerequisites in place:
- You must be on the Premier platform. The deception action is not included as part of the Professional or Essential platforms.
- You must have an Edge WAF deployment. The other deployment types do not support the deception action.
- Dynamic backends must be enabled. If they are not enabled, ask customer support to enable them for you.
Limitations and considerations
When working with the deception action, keep in mind the following:
- Advanced rate limiting rules and request rules support the deception action at the site-level (workspace-level) only. Other rule types don't support the deception action.
- Deception rules only take action on POST requests to login forms where the password field is named
password,passwd,pass, orpw.
How it works
Let's say you have a deception rule protecting your web application's login page from POST requests that use known compromised credentials. When the Next-Gen WAF identifies a request that meets the rule's conditions, the WAF:
- tags the request with the
Deception Responsesignal. - obtains the invalid credentials page from your web application.
- forwards the invalid credentials page to the attacker. This tricks the attacker into thinking that their login attempt failed and that the WAF did not block them.
Examples
The following examples demonstrate how to configure deception rules to prevent ATO attacks. Be aware that values (e.g., paths) used in these examples may not be the same as those used by your particular web application.
Example request rule
This example demonstrates how to configure a request rule that will deceive attackers attempting to use suspected bad bots to log in to a web application.
The request rule requires two conditions:
- The request must be tagged with the
Suspected Bad Botsignal. - The path of the request needs to be
/login.
HINT: A condition requiring the HTTP method to be POST is not required. The Next-Gen WAF won't take action on matching requests unless the HTTP method is POST.
The rule must have an Action type of Deception and a Deception type of Invalid Login Response.
Example advanced rate limiting rule
This example demonstrates how to configure an advanced rate limiting rule that will deceive attackers attempting to use known compromised credentials to log in to a web application after they exceed a threshold.
The advanced rate limiting rule requires two conditions:
- The request must be tagged with the
Compromised Passwordsignal. - The path of the request needs to be
/login.
HINT: A condition requiring the HTTP method to be POST is not required. The Next-Gen WAF won't take action on matching requests unless the HTTP method is POST.
The rule must also:
- set the Client key to IP address (default). Client key specifies how the WAF should identify an individual client.
- define threshold tracking behavior by setting Threshold signal to the Rate Limit ATO custom signal and leaving the default Threshold and Interval values.
- define rate limiting behavior by setting Action type to Deception and Deception type to Invalid Login Response.
