FAQ
Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform

English

Türkçe

English

Türkçe

Appearance

Intermediate

Can I verify humans with a CAPTCHA? ​

Short answer

Yes, in three places. The Advanced CAPTCHA action shows a CAPTCHA to the HTTP requests targeted with a condition; in Bot/DDoS protection, Show Captcha is selected as the action of a protection; in AGS, Captcha is selected as the action of the bot protection policy, and TR7 Captcha or a provider defined on the CAPTCHA Providers screen is used. In Advanced CAPTCHA, Captcha Type (Text, Math, Invisible; default Text), Difficulty (default Medium) and Captcha Valid for (default 24 hours) are set; a user who passes the verification is not asked again during this time.

Problem: Automated Requests Are Mixed Up with Human Users ​

Tools that send automated requests to sign-in, registration or form pages are to be told apart from real users. Asking the user for a short verification instead of blocking preserves the access of legitimate users.

Solution: Four Methods ​

The first three methods are independent of each other; Method 4 is the command line equivalent of Method 1.

Your situationSuitable method
CAPTCHA on specific pages (e.g. /login)Method 1: Advanced CAPTCHA
CAPTCHA when a request limit or the bot score is exceeded; Bot/DDoS protection is licensedMethod 2: Bot/DDoS → Show captcha
An AGS-enabled vService or a provider such as Google reCAPTCHA, hCaptcha, Cloudflare TurnstileMethod 3: AGS → Captcha action
Setting up Method 1 from the command lineMethod 4: WEB-CLI
  • How it works A request that matches the condition is met with the CAPTCHA page if it does not carry a valid verification cookie. When the verification succeeds, a signed cookie bound to the IP address and browser of the client is issued; the cookie is valid for the Captcha Valid for duration.
  • Where it is openedLoad Balancer → Actions → Advanced CAPTCHA
  • Requirement None
  • vService type HTTP (the action works only at the request stage)

Step-by-Step Configuration ​

1
Adım 1 Open the condition form

The condition form is opened with Load Balancer → Conditions → Add (how to add).

2
Adım 2 Define the condition

Condition Name = login-yolu, Criteria = Path is selected; Start is selected in the matching list, and /login is written in the Query field.

3
Adım 3 Save the condition

The condition is saved with Add.

4
Adım 4 Open the action form

The action form is opened with Load Balancer → Actions → Add (how to add).

5
Adım 5 Define Advanced CAPTCHA

Action Name = login-captcha, Action Type = Advanced CAPTCHA is selected. Captcha Type (Text, Math or Invisible), Difficulty (Very Easy … Very Hard) and Captcha Valid for (5 minutes – 30 days) are set. To block clients that fail consecutively for a while, Captcha Quarantine can be turned on (off by default; when it is turned on, the default threshold is 3 failed attempts / 5 minutes and the quarantine time is 30 minutes).

6
Adım 6 Bind the condition

In the Conditions field, login-yolu is selected. If the condition is left empty, the CAPTCHA is applied to all requests.

7
Adım 7 Save the action

The action is saved with Add.

8
Adım 8 Edit the vService

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

9
Adım 9 Add the action to the vService

In the Details → Actions field, login-captcha is selected. Unless the action is added to the vService, it does not work.

10
Adım 10 Save

The form is saved with Save. In a cluster, the change is transferred to the peer device automatically by default; if Manual Sync Mode is on, it is sent with Synchronize. Since the verification cookie is signed, a verified user is not asked for the CAPTCHA again on the peer device.

Verification ​

1CAPTCHA pageClient side

https://www.example.com/login is opened in the browser, the CAPTCHA is solved and the page is reloaded.

ExpectedCAPTCHA on the first request; the sign-in page after it is solved
If Captcha quarantine is on, the quarantine and tracking tables are seen in the Logs & Tracking tab of the vService (collected data).

Method 2: Bot/DDoS → Show Captcha ​

  • How it works When the action of a Bot/DDoS protection is Show Captcha, a CAPTCHA is shown to the client that exceeds the limit. The appearance and validity period of the CAPTCHA are managed from the Captcha card, of which there is one per vService; the L7 DDoS, IP Reputation and Bot protections share this card.
  • Where it is opened Left Monitor Panel → Bot/DDoS Protected vServices → vService → Bot/DDoS Management → Captcha card and the protection cards
  • Requirement Bot/DDoS protection license; at least one of the protections that direct to the CAPTCHA in Active mode
  • vService type HTTP

Step-by-Step Configuration ​

1
Adım 1 Turn on Bot/DDoS protection (if needed)

If the protection is not on in the vService, the vService is edited, the L7 DDoS & Threat Protection box under Details is checked and saved with Save (two ways). When the protection is turned on, IP Reputation Protection starts in Active mode (starting modes).

2
Adım 2 Open the Captcha card

In the Bot/DDoS Management tab, the Edit link of the Captcha card is clicked (Captcha Edit screen).

3
Adım 3 Configure the CAPTCHA

Captcha Type (default Text), Difficulty (default Medium) and Captcha Valid for (default 24 hours) are set; Quarantine failed captcha solvers can be turned on for those that fail consecutively.

4
Adım 4 Save the Captcha settings

The window is saved with the Edit button.

5
Adım 5 Open the edit window of the block

The pencil icon of the block in which the CAPTCHA will be shown is clicked: on the L7 DDoS Protection card, the pencil icon at the top right of the related block (e.g. Source IP Request Protection); on the Bot Protection card, the pencil icon of the Action Rules box.

6
Adım 6 Select the action

In the Limit Action field, Show Captcha is selected (in Bot Protection, the action of the related score rule). With the default values, Source IP Request Protection, Source IP Error Protection and Total Request Protection already apply Show captcha, and the Action Rules list of Bot Protection also applies Show captcha to a score of 75 and above.

7
Adım 7 Save the block

The window is saved with the Edit button.

8
Adım 8 Open the mode window

The Edit link below the mode badge at the top right of the same card is clicked.

9
Adım 9 Set the mode to Active

In the mode field (DDoS Protection in L7 DDoS Protection, Bot Protection in Bot Protection), Active is selected. In Monitor mode, the CAPTCHA is not shown; only the action that would be applied is written to the event record.

10
Adım 10 Save

The window is saved with the Edit button; there is no separate deployment step.

Verification ​

1Event recordTR7 side

On the Bot/DDoS Event Logs screen, the tab of the related protection is checked.

ExpectedShow captcha record for the client that exceeds the limit
The Table → link on the Captcha card shows the tracking table of the failed attempts only while Quarantine Failed Captcha Solvers is on.

Method 3: AGS → Captcha Action ​

  • How it works When the AGS bot protection policy is triggered, if the action is Captcha, the verification of the provider selected in the Captcha Provider field (TR7 Captcha, Google reCAPTCHA, hCaptcha or Cloudflare Turnstile) is shown to the client.
  • Where it is openedAGS → Protection Policies → Bot Protection Policies
  • Requirement AGS license; an AGS-enabled vService. For an external provider, a CAPTCHA Providers record first.
  • vService type HTTP

Step-by-Step Configuration ​

1
Adım 1 Enable AGS (if needed)

If AGS is not on in the vService, it is turned on (two ways); since the default flow denies users when AGS is turned on, the flow is prepared first: How do I attach WAF, L7 DDoS & Threat Protection and AGS to a vService?

2
Adım 2 Define the provider (if necessary)

If Google reCAPTCHA, hCaptcha or Cloudflare Turnstile will be used, a provider record is created with AGS → Protection Policies → CAPTCHA Providers → Add (CAPTCHA Providers). This step is not required for TR7 Captcha.

3
Adım 3 Open the policy form

The policy form is opened with AGS → Protection Policies → Bot Protection Policies → Add.

4
Adım 4 Define the policy

Bot Protection Policy Name is entered, Trigger Type is selected (e.g. Requests: when a specific request threshold is exceeded, Static: on every request); Action = Captcha and Captcha Provider are selected.

5
Adım 5 Save the policy

The policy is saved with Add.

6
Adım 6 Open the Protection section

In the Left Monitor Panel → AGS-Enabled vServices → vService → AGS Management tab, the Edit link of the Protection section is clicked.

7
Adım 7 Select the policy

In the Edit / Protection window that opens, the policy is selected in the Bot Protection Policies field.

8
Adım 8 Save

Accept is clicked; the policy is listed in the Bot Protection box in the AGS Management tab.

Verification ​

1Live StatsTR7 side

On the Live Stats screen of the AGS vService, the Captcha section is checked.

ExpectedNumbers of CAPTCHAs shown and solved

Method 4: WEB-CLI ​

  • How it works The condition and the Advanced CAPTCHA action in Method 1 are created with lb condition / lb action, and the action is added to the vService with lb service.
  • Where it is opened TR7 WEB-CLI → lb condition · lb action · lb service
  • Requirement WEB-CLI access. The Captcha Quarantine fields do not exist in WEB-CLI; if necessary, they are turned on from the interface after the action is created.
  • vService type HTTP

Step-by-Step Configuration ​

WEB-CLI runs each line as a separate command; commands are written on a single line.

1
Adım 1 Create the condition
text
lb condition add criteria path query /login --content_placement start --name login-yolu
2
Adım 2 Get the condition ID

The --cond field of the action requires the ID of the condition, not its name. lb condition add gives no output when it succeeds; the ID is seen in the id column of the list below (it starts with lbConditions-).

text
lb condition list
3
Adım 3 Create the Advanced CAPTCHA action

For --captchaType, text, math, invisible is written; for --captchaDifficulty, 1 (Very Easy) – 5 (Very Hard). The duration is given with --captchaVerifiedTtl.val and --captchaVerifiedTtl.unit (m, h, d) (blocking and verification actions).

text
lb action add type advancedCaptcha name login-captcha --captchaType math --captchaDifficulty 3 --captchaVerifiedTtl.val 24 --captchaVerifiedTtl.unit h --cond <login-path-id>
4
Adım 4 See the existing actions

The rules.0, rules.1… lines show the actions bound to the vService.

text
lb service show <vService>
5
Adım 5 Add the action to the vService

The new action is written to the first empty index, that is, to the number of existing actions. In the example, since the vService has two actions (rules.0, rules.1), --rules.2 is used; writing to a filled index replaces the action there.

text
lb service update id <vService> --rules.2 login-captcha

Verification ​

1ConfigurationTR7 side

Command: lb action show login-captcha

ExpectedcaptchaType and cond fields filled in
The CAPTCHA page itself is tested with the browser attempt in Method 1.

Common Mistakes ​

  • Applying Advanced CAPTCHA to the whole site without a condition. Every visitor sees the verification; only risky pages are targeted with a condition.
  • Showing a CAPTCHA to API clients. Clients that are not browsers cannot solve a CAPTCHA; API paths are excluded with a condition.
  • Expecting a Hit Counter. There is no Hit Counter in the Advanced CAPTCHA action; the verification traffic is monitored from the browser, and if Captcha quarantine is on, from the Logs & Tracking tables.
  • Leaving Bot/DDoS in Monitor mode. In Monitor mode, Show captcha is not applied, and the CAPTCHA page is never produced.
  • Writing the condition name in the --cond field. In WEB-CLI, --cond expects the condition ID; if the name is written, the action is bound to a condition that does not exist.

How it is done in the documentation

Related questions