Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
What is the order when WAF and AGS are used together?
Short answer
If L7 DDoS & Threat Protection, AGS and WAF are on together in the same HTTP vService, the evaluation order is as follows: first the bot score is calculated, then the AGS session is validated, and last the WAF inspects the request (the difference from WAF and Bot/DDoS). Requests that start with the AGS Root Path (default /ags-portal), that is, the login, verification and helper pages of AGS, do not enter WAF inspection because they carry passwords and codes; they do not fall into WAF learning and attack records, and they are counted as Whitelisted in Live Stats. Requests that a user without a session sends to the application paths go through the WAF: if the WAF blocks the request, the client gets the blocking response (Blocking Page) without being redirected to the login page; if it does not block it, the request is redirected to the AGS login flow. The requests of a user whose session has been validated are also fully inspected in the WAF; being logged in does not provide a WAF exemption. The identity information that AGS adds for the Backend Service is added after the WAF, and the WAF does not see it. Since the AGS session information is ready before the WAF, the IF is an authenticated AGS user ready-made condition can be selected in the WAF's condition fields; if it is used in the Whitelist Condition, all the requests of logged-in users are taken out of WAF inspection.
How Does It Work?
In an HTTP vService on which WAF - WAAP, AGS - AAM and L7 DDoS & Threat Protection are on together, the request is processed in the following order:
| # | Stage | What happens |
|---|---|---|
| 1 | Bot score | Bot Protection gives the request a score. The score of a user whose AGS session has been validated gets a trust discount after the session is validated; the discount is applied on every vService with AGS on, without requiring a separate setting. |
| 2 | AGS session validation | Whether the client has an AGS session and whether it is valid is determined. At this stage, the request is not redirected yet; only the session status is determined. |
| 3 | WAF scan | If the request does not start with the AGS Root Path, it is scanned in the WAF; requests with and without a session are inspected in the same way. Requests that start with the AGS Root Path are not scanned. Independently of AGS, requests that match the Whitelist Condition and static content requests while Do Not WAF Static Contents is on are not scanned either. |
| 4 | Response | The L7 DDoS & Threat Protection enforcement, the Actions that end the request and the WAF blocking response (Blocking Page) are evaluated in this order. A request that the WAF blocks is responded to at this stage and does not reach the AGS login flow. |
| 5 | AGS redirect | A request that is not blocked and has no session is redirected to the AGS login flow; the user sees the login page. |
| 6 | Forwarding to the Backend Service | Identity information is added to a request with a valid session, the AGS cookies are removed from the request and the request goes to the Backend Service. Since this addition is made after the WAF scan, the WAF does not see this information. If there is a header that the client sent with the same name, the WAF sees it in the scanned request; then this header is deleted and the value of AGS is written in its place. |
All the stages: Which stages does a request go through inside TR7 before it reaches the backend?
WAF and AGS in TR7
- The path left outside the WAF: Among the paths of AGS, only the requests that start with the AGS Root Path do not enter WAF inspection. The value is set in the General Settings window on the Flowchart tab of the AGS-enabled vService and is applied with Save; since the match is made by text prefix, there must be no path on the Backend Service that starts with the same prefix (AGS Root Path). Requests left outside the AGS scope with the AGS Activation Condition are scanned normally in the WAF.
- Counting: The AGS Root Path traffic is written to the Whitelisted card in the WAF Inspection Distribution panel in WAF Live Stats; it does not enter the Clean, Blocked or Learning counts (What do the Whitelisted, Clean, Blocked, Monitor, Teacher and Learning categories in WAF Inspection Distribution mean?).
- WAF rule according to the AGS user: The IF is an authenticated AGS user ready-made condition can be selected in the condition fields in WAF Management (e.g. Conditional Blocking Pages); for example, a different blocking page can be shown to logged-in users. If the same condition is put in the Whitelist Condition, the requests of logged-in users are not scanned at all, and the malicious requests coming from these users also stay outside the inspection; AGS verifies the identity, it does not inspect the content.
- Turning on: How do I attach WAF, L7 DDoS & Threat Protection and AGS to a vService?
Common Misconceptions
- "The WAF does not inspect a user who is logged in to AGS." The requests of a validated user are also fully inspected; WAF and AGS do not replace each other.
- "The AGS login form can get caught by the WAF." Requests that start with the AGS Root Path do not enter WAF inspection; the password or code fields in the login form do not trigger WAF rules.
- "An attacker without a session goes to the login page first." The WAF blocking response returns before the AGS redirect; a request that the WAF blocks does not see the login page.
- "The WAF also scans the identity headers that AGS adds for the Backend Service." The identity information is added after the WAF scan; the WAF sees the request as it came from the client.
- "Putting the AGS condition in the Whitelist Condition is a safe performance setting." The malicious requests of logged-in users also stay outside the inspection; AGS does not inspect the content.
How it is done in the documentation
