Bot/DDoS Protection Mode

What Is Bot/DDoS Protection Mode?

Bot/DDoS Protection Mode is the strip at the very top of the Bot/DDoS Management screen and does two jobs at once: it summarizes the protection state of the vService in a single word, and below it gathers the challenge, quarantine, waiting room and notification settings that all the protections use in common.

There is no mode selected on this screen

Unlike the WAF Mode screen, there is no manually selected operating mode here. The Active, Monitoring or Not Active text on the strip is not a setting but a reading derived from the mode of the three protection columns. The modes are changed not from this strip but from their own bands: L7 DDoS Protection, IP Reputation Protection and Bot Protection.

Active

"Attack traffic is being blocked."

At least one of the three protections is blocking. The strip is displayed green. Even if the other two protections are in monitoring or off, the state is read as Active: there is a layer that actually intervenes in the traffic.

Monitoring

"No layer is blocking — the layers are only monitoring."

No protection is blocking, at least one is monitoring. The strip is displayed amber. The attacks are detected and reported, but no request is stopped.

Not active

"This pool has no active threat protection."

All three protections are off. The strip is displayed red: this state is consciously presented not as an off notification but as a warning.

The Mode Strip on Bot/DDoS Management

The strip is the first band of the screen. On its left side the icon, the name and the number of evaluated protections of the state; below it the definition sentence that describes what the module does; at its top right the protection distribution badges; at its bottom right the Export and Import buttons are located. In the body of the band there are four cards.

The Bot/DDoS Protection Mode Strip

Element	Meaning
The state icon and name	The reading derived from the mode of the three protections: Active with the shield icon, Monitoring with the eye icon, Not Active with the warning triangle.
The number	It is displayed in parentheses right next to the name of the state (Active(3)). It is the number of protection columns evaluated and is always 3. It shows not how many protections are on but from how many columns the state is calculated; it stays 3 on L7 TCP vServices as well.
The definition sentence	The fixed text that summarizes what the module does. It has two separate versions according to the vService type; the L7 TCP version speaks of the TCP layer and of connection floods and does not mention the challenge at all.
The state sentence	The single-line warning written in the body of the band only in the Monitoring and Not Active states. In the Active state it is not displayed at all: a second "everything is fine" line is not added under a green state word.
The distribution badges	The mode distribution of the protections: the Protecting (blocking), Monitoring (monitoring) and Off (off) numbers. A badge whose number is zero is not displayed at all; the total of the three badges is always equal to the number in the superscript.
Export / Import	It exports the whole Bot/DDoS configuration of the vService to a file and restores it. It is displayed only on the users that have edit permission; since exporting is also counted as a write operation, the configuration cannot be taken to a file with read-only permission.

The strip never fades

The cards fade when they are not used, but the strip itself is always at full visibility. In addition, the strip has no pencil icon of its own: there is no field to be edited from here.

Right below the strip comes the Smart Advisor strip, and after it the three protection columns. The operation that returns all the Bot/DDoS settings to their default values is located not on this strip but on the Smart Advisor strip.

How Is the State Calculated?

The state is derived from the mode of the three protection columns with a single rule:

Condition	Result
At least one of the protections is in the blocking (Active) mode	Active
None of them is blocking, at least one is in the monitoring (Monitor) mode	Monitoring
All three are off	Not Active

The rule is consciously generous: a single protection blocking is enough to carry the strip to Active. The meaning of this is that the word "Active" shows not that all the protections are working but that there is at least one layer that actually intervenes in the traffic. Which protection is in which mode is read from the distribution badges next to it.

The Default Modes

On a vService on which the Bot/DDoS protection has been newly enabled, no mode has been selected manually; every protection works with its own starting value:

Protection	Default mode
L7 DDoS Protection	Monitor
IP Reputation Protection	Active
Bot Protection	Monitor
Waiting Room	Off

For this reason, on a vService that has not been touched at all, the strip reads directly Active and the badges show Protecting: 1 and Monitoring: 2: the IP reputation protection blocks from the first moment on, and the other two protections monitor first.

A setting that has not been touched is not considered off

The mode of a protection is considered off only when it has been explicitly switched off. A mode field that is not present at all in the record means that it works with its default mode. The waiting room is outside this rule: unlike the protection columns, its default is not monitoring but off.

"Not active" is red, not gray

When all three protections are switched off, the strip is displayed not as a gray "off" notification but as a red warning. This is a conscious choice so that a vService without protection does not appear silently on the screen.

Export and Import

The two buttons at the bottom right of the strip carry the Bot/DDoS configuration of the vService as a file.

The scope is not only this strip

Both operations cover the whole Bot/DDoS configuration of the vService: the three protection columns, all the limit blocks, the country and network type rules, the exemption lists, the four cards on the strip, the notification and learning settings. Not only the cards on the strip but the whole of the screen is transferred.

There are two exceptions: the record identity and the protection priority fields that have no equivalent in the interface are not written to the file and are also ignored in the import. The priority fields are values that have remained only in old records and are not shown on any screen; since the import changes the whole of the record, if they have a value on the target, it drops after the transfer.

Operation	Behavior
Export	After confirmation is obtained, it downloads the configuration as a single JSON file. The file name consists of the vService name, the _threat suffix and the date-time stamp.
Import	After confirmation is obtained, it loads the selected file and completely replaces the configuration of the target vService. No merging is done. In the file picker the .json filter is applied by default; no extension check is made on the server side.

At the moment the file is selected or the Export is confirmed, both buttons become passive and the icon of the working button turns into a spinning symbol. Both operations are written to the user log; the import record carries a change summary together with its before and after.

Since the import passes through the same line as every edit, it takes effect immediately: after the record is written, the regeneration and application of the configuration runs in the background, and no separate confirmation or reload step is required. If the file is not a valid JSON object, a corrupt file error is returned, and if the target vService has no Bot/DDoS record, a record not found error.

The import is not lossless

Of the keys in the file, only the ones that the target device recognizes are taken; the unrecognized keys are dropped silently and the user is not informed which ones have dropped. For this reason a file taken from a device of a different version may not give exactly the same result. A valid file that contains no recognized key is also accepted and returns the configuration to the default behavior.

The Cards on the Strip

The four cards in the body of the band show the surfaces that the protections use in common. These are not a protection layer; the three of them take effect in three different ways:

• Captcha and Quarantine are each a direction target: a protection sends the request to one of them, and the settings on these cards determine what will be done.
• Waiting Room triggers itself: not the action of a protection but its own operating mode and capacity thresholds put it into effect.
• Notifications is not a target but the common notification surface of the three protections.

Card	Its content	Scope
Captcha	The type of the challenge, its validity period and the failure behavior.	Only HTTP
Quarantine	The tracking key of the penalty box, its period and the action applied.	HTTP and L7 TCP
Waiting Room	The simultaneous visitor capacity and the entry rate limit.	Only HTTP
Notifications	The notification channels, the state band notification and the advanced triggers.	HTTP and L7 TCP

The cards are always lined up in this order. Since the challenge and the waiting room cannot be defined on the vServices of the L7 TCP type, these two cards are not displayed at all; only Quarantine and Notifications remain on the strip.

Every card fades with its own criterion

The fading condition changes per card:

• Captcha and Quarantine when no protection that directs to them remains,
• Waiting Room when its own operating mode is Off,
• Notifications when there is no open notification channel, are displayed faded.

Fading does not mean that the settings have been lost: the pencil icon of the card continues to work and the defined values stay in place.

At the top right of every card there is a pencil icon; it opens the edit window of the related settings and is displayed only on the users that have edit permission. The Table → link below the cards opens the live table of the card as a closable tab on the same screen.

Captcha

It defines the type of the challenge, for how long a successful solution will be considered valid and whether the visitor that continuously cannot pass the challenge will be taken into quarantine. While taking into quarantine is on, the card summarizes the threshold in a single sentence: after a certain number of failed attempts within a certain period, the visitor is taken into quarantine.

The Used by row below the card lists which protections use the challenge. The protections are written here with their short names: L7 DDoS, IP Reputation and Bot. If no protection directs to it, a sentence indicating that the settings are waiting ready is written instead.

Detail: Captcha.

Quarantine

It defines according to what the penalty box is applied, how long it will last and what will be done throughout that period. If all three settings are defined, the card combines them in a single sentence; in the sentence the period is emphasized in bold and the action in color: red if the action is Silent Drop, amber in the others. If even one of the settings is missing, the sentence is not formed and the values are listed as separate rows.

In the Used by row, besides the protections, Captcha can also appear: if taking the ones that cannot pass the challenge into quarantine is on, the challenge is also one of the parties that fill the box. Since the challenge is not present on L7 TCP, this row does not appear at all on that type.

The hard ceilings defined per source address also use the quarantine; the action of these ceilings is fixed and cannot be changed. The total ceilings across the vService, on the other hand, go not to the quarantine but directly to the silent drop.

Detail: Quarantine.

Waiting Room

It puts the visitors in a queue in a sudden intensity. On the card the simultaneous visitor capacity, the sudden entry threshold and the number of conditional waiting pages appear; each of these rows is displayed only if the related setting is defined. The sudden entry threshold is not an admission quota: even if the capacity is not full, when the number of new visitors per minute exceeds this threshold, the queueing starts.

Unlike the other three cards, this card carries its own operating mode in its header: Active, Monitor or Off.

This card also carries the only learning badge on the strip: when the learning engine produces an evaluation for the capacity and the entry rate, a second badge appears in the header (Learning, Suggestion, Advice, Attention or Verified) and when it is clicked, the detail of the evaluation opens.

Its capacity being defined is not enough

The waiting room is off by default; on a vService that has not been touched at all, the card comes with the Off badge and faded. Even if the capacity value is defined, the waiting room does not work.

Detail: Waiting Room.

Notifications

It shows through which channels the Bot/DDoS notifications will go (UI Notification, E-mail, SMS and SNMP Notification), at which band the threat state a notification will be produced when it reaches, and the number of the advanced triggers defined. The advanced trigger row is displayed only if at least one trigger is defined.

If there is no open channel, the card is displayed faded and Disabled is written in the Channels row. The state band notification is a setting independent of this; if it is not defined, Disabled is written in its own row.

The Notification log → link below the card opens the notification log narrowed down to this vService as a closable tab.

Detail: Notifications.

Scope and Limits

INFO

• The strip is not a setting but a reading. The state text and the badges are derived from the mode of the protection columns; they cannot be changed from the strip. The modes are edited from their own bands.
• The number in the superscript is fixed. It is always 3 and shows the number of protection columns evaluated; it has nothing to do with the number of cards on the strip or with the number of protections that are on.
• Seeing the strip is possible with monitoring permission. The state, the badges, the cards and all the rows appear with read-only permission. The Export and Import buttons and the pencil icons of the cards are displayed only on the users that have edit permission; on a user without permission these controls are not created at all. Since exporting is also counted as a write operation, it requires the same permission.
• The Table → and Notification log → links do not depend on the edit permission and work on a read-only user as well. The listing of the live table sources, on the other hand, requires Load Balancer monitoring permission.
• The live tables are filled conditionally. Although the Table → link always appears, the live source on the tab that opens depends on a separate condition for every card. The Quarantine table depends not on the protection that fills the box being defined but on its being in the Active mode: a protection in the monitoring mode does not produce a live source even if it appears in the Used by row. The Captcha table is created only while taking into quarantine on challenge failure is on. The Waiting Room tables, on the other hand, are not created at all as long as its own mode is Off.
• Two cards are not present on L7 TCP vServices. The challenge and the waiting room cannot be defined on this type; the strip is displayed with two cards.