How do I tell that a legitimate request was blocked by the WAF?

Short answer

A request blocked by WAF receives the built-in blocking page (Blocking Page) with the 418 status code by default; on the default page, the time of the request is at the top right, and the Request ID and IP Address rows are below the title in the middle. Since the blocking page can be customized from the Blocking Page window, this information may not be on a custom page. When the Request ID is written in the Request Unique ID field of the server filter on the WAF Event Logs screen of the vService and Save & Get Logs is clicked, the record is found directly; if Attack blocked is written when the Action icon is hovered over and in the preview title, WAF has blocked the request. The Attacks tab of the preview shows which signature or rule was triggered and which part of the request matched. If it is not known which vService the request came to, the same search is done on the Global WAF Event Log screen. If there is no record in Event Logs, Debug is turned on in the vService and the Security Action column of the Debug Mode Logs record is examined: a request that was blocked in Blocking mode because its scan could not be completed within the time limit is not written to Event Logs; it appears only here as Attack blocked — scan timed out. If there is no WAF decision in the Debug record either, the block came not from WAF but from the Bot/DDoS Protection layer or from a Load Balancer action.

Problem: A User Reports Being Blocked

A user reports that the page does not open or that they see a blocking page with the 418 code. It must be found whether the block came from WAF and, if it did, which signature or rule was triggered.

Solution: 3 Methods

Your situation	Suitable method
The vService is known; there is a Request ID, the client IP or time information	Method 1: Event Logs
It is not known which vService the request came to	Method 2: Global WAF Event Log
There is no record in Event Logs or it is not known which layer gave the block	Method 3: Debug Mode Logs

Method 1: Event Logs Recommended

• How it works WAF writes a log row for every request it blocks or monitors; the row is found with the unique ID of the request, the client IP address or the time range.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → Event Logs tab
• Requirement WAF permission; the host group the request falls into is in Monitor or Blocking mode (in Learning mode, no Event Logs record is created)
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Get the Request ID

The Request ID value on the blocking page and the approximate time of the request are requested from the user. The built-in page shows the ID with the %UID variable (Which Smart Variables can I use on the blocking page (%UID, %SRCIP, %WAFSCORE, %WAFINFO …); is it safe to show attack details?); if the blocking page has been customized with Manual Content or with another content profile, the ID may not be on the page. If there is no ID, the user's IP address is taken.

2

Adım 2 Open the Event Logs screen

The Left Monitor Panel → WAF-Protected vServices → vService → Event Logs tab is opened.

3

Adım 3 Fill in the server filter

In the server filter tab at the beginning of the filter strip, Date Range is selected so as to cover the time of the request (default Last 7 day(s)), and the ID taken from the user is written in the Request Unique ID field.

4

Adım 4 Pull the logs

Save & Get Logs is clicked; the fields are not applied without this button being clicked. If there is no ID, the field is left empty, and after the logs are pulled, the user's address is selected from the Client IP tab in the filter strip (filterable information).

5

Adım 5 Read the decision

The icon in the Action column of the row is hovered over. Attack blocked shows that the request was blocked by WAF; in the Not blocked — Monitor mode, Not blocked — Below the blocking threshold and Not blocked — Teacher IP matched (Teacher cookie / Teacher header if the Teacher identity was recognized with a cookie or a header) decisions, the request was let through.

6

Adım 6 Examine the triggered rule

The row is clicked; on the Attacks tab of the preview that opens on the right, the triggered signatures and rules are listed. When an attack is selected, Description highlights the matched part of the request, and Corresponding Rule shows the matched page type rule. If the matched part is the application's own data, the record is a false positive (How do I allow a request that was blocked by mistake?).

Verification

1Preview titleTR7 side

The preview title of the selected row and the request ID below the title are checked.

ExpectedAttack blocked · the user's Request ID value

In a cluster, the list shows the logs of the two devices together; the device the row comes from is written in the Source column.

Method 2: Global WAF Event Log

• How it works The logs of all WAF-protected vServices on the device are scanned in a single table; it is not necessary to know which vService the request came to.
• Where it is opened The TR7 logo at the bottom left → Configuration Menu → WAF → Global WAF Event Log
• Requirement WAF permission and an unrestricted vService scope (how to access)
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the screen

The Configuration Menu is opened with the TR7 logo at the bottom left; WAF → Global WAF Event Log is selected.

2

Adım 2 Fill in the server filter

In the server filter tab, Date Range is selected and the ID is written in the Request Unique ID field.

3

Adım 3 Pull the logs

Save & Get Logs is clicked. Since the scan reads the files of all vServices, the result comes faster if the Date Range is kept narrow (the working of the scanning).

4

Adım 4 Read the vService and the decision

The vService column of the row shows the vService the request came to, and the Action icon shows the decision. The Attacks tab of the preview is examined as in step 6 of Method 1.

Verification

1ListTR7 side

The vService column of the found row and the sentence of the Action icon are checked.

ExpectedvService name · Attack blocked

Method 3: Debug Mode Logs

• How it works The Debug record keeps every request that comes to the vService; the Security Action column shows the security feature that terminated the request and its decision, and the WAF box in the preview shows WAF's decision and the triggered rules. A request that was blocked in Blocking mode because its scan could not be completed within the time limit is not written to Event Logs; the WAF decision appears only here.
• Where it is opened vService Edit → Details → Debug · Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking → Debug Mode Logs
• Requirement Modify permission in the Load Balancer area (the Debug Mode Logs screen does not open with the WAF permission alone); Debug must have been turned on before the problematic request is repeated; the record is created only for the requests after it is turned on
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the condition form (if needed)

If the Debug record is to be limited to the user's requests only and there is not yet a condition for the user's address, the Configuration Menu is opened with the TR7 logo at the bottom left; on the Load Balancer → Conditions screen, Add is clicked.

2

Adım 2 Define the user's address

Criteria = Source IP and Source IP Type = Manual are selected and the user's address is entered.

3

Adım 3 Save the condition

The condition is saved with Add.

4

Adım 4 Edit the vService

On the Load Balancer → Load Balancer vService List screen, the vService is selected and the edit form is opened with Edit.

5

Adım 5 Turn on Debug

Debug is checked under Details; if the record is to be limited to the user, the condition from step 3 is selected in the Select Conditions field (conditional debug). If no condition is selected, all requests are recorded.

6

Adım 6 Save

The form is saved with Save; the Status value of the vService becomes Debug Mode. The user is asked to repeat the request.

7

Adım 7 Open the Debug records

In the Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking tab, the Debug Mode Logs source is selected.

8

Adım 8 Turn on the Security Action column

With Columns, the Security Action column, which is hidden by default, is turned on.

9

Adım 9 Examine the record

The user's request is selected; in the WAF box on the Summary tab of the preview, Verdict, Attacks and Triggered Rules are read. The Attack blocked — scan timed out decision shows that the request was blocked in Blocking mode because its scan could not be completed within the time limit; if these blocks affect the service, Fail-open in the Request Body Limits window can be turned on, and while it is on, these requests are let through without being scanned (What happens to a request if the scan exceeds a certain time (2-second scan limit)?). If there is no WAF box, WAF did not give a decision for this request; which layer the block came from is distinguished as on the Legitimate users are being blocked; how do I find which rule is blocking them? page.

10

Adım 10 Edit the vService again

When the examination is finished, the vService is opened again with Edit.

11

Adım 11 Turn off Debug

The Debug check under Details is removed; Debug that stays on uses disk and CPU.

12

Adım 12 Save

The form is saved with Save.

Verification

1Summary tabTR7 side

In the user's record, the Security Action column and the WAF box on the Summary tab are read.

ExpectedVerdict: Attack blocked or Attack blocked — scan timed out

Common Mistakes

• Ruling out WAF if there is no record in Event Logs. A request that was blocked in Blocking mode because its scan could not be completed within the time limit is not written to Event Logs; it appears in the Debug Mode Logs record (Why does a request that received 418 not appear in Event Logs?).
• Searching for a record in a host group in Learning mode. In Learning mode, WAF does not block the request and no Event Logs record is created (log production).
• Attributing every block to WAF. A CAPTCHA page points to bot protection, a silent drop of the connection to Quarantine Action, and a response that returns with a code such as 403 and has no WAF record to a Load Balancer action (Legitimate users are being blocked; how do I find which rule is blocking them?).
• Forgetting the log suppression condition. If a suppression condition is defined on the Log Settings screen, the rows that match the condition are not shown in the Event Logs list (log production).
• Leaving the Date Range narrow. Even if the ID is correct, the record does not come if the time of the request is outside the selected range.

How it is done in the documentation

• Event Logs · Request Unique ID
• Event Logs · The Action Values
• Debug Logs · Summary Tab
• Blocking Page · What Is Blocking Page?

Related questions

• How do I allow a request that was blocked by mistake?
• I am blocking legitimate users by mistake; how do I find out?
• How do I find a specific request by its Request Unique ID?