Can I use different modes for different domains on the same vService?

Short answer

Yes. Since the mode is assigned to the Virtual Host Group, the domain names are separated into different Virtual Host Groups and each group works with its own WAF Mode value; for example, while api.example.com is in Blocking mode, beta.example.com can stay in Learning mode. The group is added with the plus (+) icon of the Virtual Host Groups band on the WAF Management tab; domain name patterns that are compared exactly with the Host header of the request are entered in the Virtual Host Patterns field, and the mode in the WAF Mode field. Requests that match no pattern and requests that carry no Host header fall into the default group and use its mode. Each group has its own Page Types, and a new group does not inherit what the other groups have learned; the OWASP Protection Level, Whitelist & Blacklist, Blocking Page and Learning Methods settings, on the other hand, are common across the vService.

Problem: Domain Names on the Same vService Are at Different Levels of Maturity

While a domain name that is live on the same vService is protected in Blocking Mode, a new or changing domain name may still need to be learned. If the whole vService works in a single group, either the legitimate requests of the new domain name are blocked, or all the traffic is moved to Learning Mode for learning and is left unprotected.

Solution: Two Methods

A separate Virtual Host Group is added for the new domain name; the two methods give the same result.

Your situation	Suitable method
There is no group for the domain name yet; I want to add it from the interface	Method 1: Virtual Host Groups band
From the command line	Method 2: WEB-CLI
The group already exists, only the mode will change	It is changed from the mode card of the group: When should I move from Learning to Monitor and from Monitor to Blocking?

Method 1: Virtual Host Groups Band Recommended

• How it works A new Virtual Host Group with domain name patterns and its own mode is added; requests that match the pattern are processed with the mode and the Page Types of this group.
• Where it is opened Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → Virtual Host Groups band → plus (+) icon
• Requirement WAF being on for the vService (How do I enable WAF protection on a vService?) · modify permission in the WAF area
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the WAF Management tab of the vService

In the Left Monitor Panel, the WAF-Protected vServices category is selected, the vService is clicked and the WAF Management tab is opened (accessing the screen).

2

Adım 2 Open the group add window

In the Virtual Host Groups band at the bottom of the tab, the plus (+) icon is clicked; a window titled Add opens (adding a host group).

3

Adım 3 Enter the name of the group

The name of the group is written in the Virtual Host Group Name field (e.g. beta); the field is required.

4

Adım 4 Select the mode

Learning mode, Monitor mode or Blocking mode is selected in the WAF Mode field. The field comes preselected with the default mode in the WAF settings of the vService; when WAF is turned on, this value is Learning mode.

5

Adım 5 Enter the domain name patterns

At least one pattern is written in the Virtual Host Patterns field (e.g. beta.example.com); for another pattern, the + Add link below the field is used. The pattern is compared with the Host header of the request as it is: a difference in letter case or port breaks the match. * matches any character sequence (e.g. *.example.com). If a non-standard port is used, the port is also written in the pattern (e.g. beta.example.com:8443). A pattern field left empty is rejected with the Correct invalid inputs warning.

6

Adım 6 Save

The Add button in the window is clicked; there is no additional confirmation window and the change is applied without a separate deployment step. The new group is created with the default rule set (Any Paths) and the ready-made header inspections; the learned Page types of the other groups are not copied. In a cluster setup, it is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent to the peer device manually.

Verification

1Mode cardsTR7 side

On WAF Management, the separate mode card of each group and the summary sentence in the Virtual Host Groups band are examined.

ExpectedRequests are evaluated in 2 host groups, each with its own WAF mode — …

2Group matchTR7 side

If Learning mode was given to the new group, the requests made to the domain name that matches the pattern are counted in the Learning series of the WAF Inspection Distribution panel on the Dashboard; the requests of the other domain name continue to be counted according to the mode of their own group.

ExpectedThe Learning series increases

If the request falls into the default group, it is verified that the pattern matches the Host header (letters, port) exactly.

Method 2: WEB-CLI

• How it works The Virtual Host Group is added with a WEB-CLI command; its mode is changed later with the same command group.
• Where it is opened WEB-CLI → waf host-groups
• Requirement WEB-CLI access · modify permission in the WAF area
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Add the group

The name, the mode and the pattern are written together (optional fields). If --mode is not written, the group is created with the blocking mode. In WEB-CLI, the wildcard is valid only in the leading *. form and is written in single quotes ('*.example.com'):

waf host-groups add poolId <vService> name beta --mode learning --hosts.0 beta.example.com

The command gives no output when it succeeds.

2

Adım 2 Get the ID of the group

The group and its ID are seen in the list:

waf host-groups list poolId <vService>

3

Adım 3 Change the mode once learning is finished

In place of <id>, the ID from step 2 is written:

waf host-groups update poolId <vService> id <id> --mode blocking

Verification

1Group recordTR7 side

The record of the group is displayed.

Command: waf host-groups show poolId <vService> <id>

ExpectedThe entered values in the mode and hosts rows

A separate mode card of the group appears on WAF Management.

Common Mistakes

• Writing the pattern without a port and using a non-standard port. The port in the Host header is compared with the pattern; the beta.example.com pattern does not match the beta.example.com:8443 header and the request falls into the default group (Virtual Host Patterns).
• Defining overlapping patterns in two groups. The overlap is not prevented; the request falls into the first matching group in the order of definition, and the mode of the other group is never applied to that domain name.
• Assuming that the OWASP protection level is also set per group. OWASP Protection Level is vService-wide (Can I set the protection level separately for each domain / host group?).
• Assuming that the new group inherits the existing rules. The new group starts with the default rule set and goes through its own learning process; it is left in Learning mode and taught with Analysis & Learning.
• Adding a group in WEB-CLI without writing --mode. The group is created with the blocking mode, and legitimate requests of a domain name that has not been learned yet may be blocked.

How it is done in the documentation

• Virtual Host Groups · What Is Virtual Host Groups?
• Virtual Host Groups · Adding and Editing a Host Group
• Virtual Host Groups · Virtual Host Patterns
• WEB-CLI · Optional Fields

Related questions

• Can I set the protection level separately for each domain / host group?
• When should I move from Learning to Monitor and from Monitor to Blocking?
• How is a Host Group added; what goes into the Virtual Host Patterns field?