Dynamic Rules
Security rules with time-based thresholds
Overview
The Dynamic Rules section defines security rulesets that evaluate various criteria over time. When requestors commit activities that exceed defined thresholds, they can be banned, or merely reported on within the interface.
Note that Dynamic Rules do not block requests; they ban the sources of requests. Individual incoming requests are blocked for reasons defined elsewhere, e.g., in ACL Policies.
When requests are blocked, or display other hostile characteristics, Dynamic Rules are used to monitor their sources. If the sources continue their hostile activities, they can be banned. A ban means that all subsequent requests from that source will be blocked for a configured length of time.
In some situations, either Rate Limiting Rules or Dynamic Rules could be used. Rate Limiting Rules are the preferable option. They are more powerful, more flexible, and in a future release, they will fully replace Dynamic Rules.
The interface displays the Dynamic Rules that are currently defined. At the top are the default rules supplied by Reblaze, marked with the Reblaze icon.
The default rules from Reblaze are useful for most customer deployments. If you wish to edit them, one approach is to preserve the originals by duplicating them, deactivating them, and then editing and using the copies.
Dynamic Rules Administration
To edit a rule, click on its name, and its parameters will appear below.
Dynamic Rules section menu
It provides these abilities:
The interface also provides a search box, which can be used to find a rule according to a string within its name.
Creating Dynamic Rules
To create a Dynamic Rule, click on "Add new rule" in the Dynamic Rules section menu and provide the Rule Name.
Newly-created Rules are always disabled, and must be enabled before they will be active.
Dynamic Rule settings
Each Dynamic Rule contains the following parameters:
Note that it is theoretically possible to construct a Dynamic Rule so that a specific request can match both the Monitor and Ignored conditions simultaneously. (This usually indicates a mistake in constructing the rule.) If a request ever matches both condition sets at the same time, nothing happens.
Matching Conditions for Dynamic Rules
The monitor list includes many useful arguments for identifying relevant traffic.
Some of the matches rely on the results of ACL Policies. For example, an Anonymizer value of "true" will match a request that was denied by the "Deny Anonymous Proxies" ACL Policy.
Scrolling down the list will reveal additional fields. These tend to be used by more advanced users.
The video below sums it all up:
Defining Block Reasons
The Block Reason field allows you to construct a Dynamic Rule that will be triggered when requests are blocked for specific reasons. When this is included in a Rule, Reblaze will compare its value to the reasons that a request was blocked.
The comparison is based on a "contains" substring search, and is case-insensitive. Therefore, when a request is blocked for Over-capacity, Block Reason values of capacity, over-capacity, and Over-capacity will all match.
There can be multiple Block Reasons OR'd together, e.g.: autoban|over-capacity.
There are several ways to obtain values for constructing Block Reasons. The first is the list of standard Reblaze WAF signatures (example: Autoban/etc.). Other possible values are custom, created dynamically by Reblaze as the result of user configuration. Example: Rate limit 2/1s .
In both cases, recent values can be obtained from individual events in the View Log, or from the Signatures tab on the Dashboard page.
How to Test Dynamic Rules
After creating or modifying Dynamic Rules, it is recommended that you test them to ensure that they are behaving as expected.
You can safely test Dynamic Rules against actual traffic data, without actually banning any traffic sources. This is done by running the rules in Simulated Ban mode.
There are two ways to do this: testing all rules globally (most useful when setting up a new planet), or testing individual rules (useful in daily operation).
Testing all rules globally
Select Activate global simulation mode from the section menu, which will change all Dynamic Rules that were set to Ban to Simulated Ban.
This means that requestors who violate Dynamic Rules will not be banned; instead, they will appear within the Simulation Ban List in the Quarantined section. You can observe the requestors who appear there, and evaluate if the Dynamic Rules are identifying the requestors you expected.
Note that during this process, all Dynamic Rule traffic scrubbing will be disabled. Therefore, it is most useful during the initial setup of a new planet.
Testing individual rules
To test individual rules, set each one to Simulated Ban mode. Save and Publish your changes. Then from the section menu, choose Test All Rules.
This will evaluate the current set of Dynamic Rules against the most recent traffic data. Example: a rule with a Period of five minutes will be evaluated against the requests that were received in the last five minutes.
You can compare each rule's performance with what you expected. Once you are satisfied with a rule's performance, you can make it active by changing its mode to Ban.
Note that you can accomplish a similar result by observing the Simulated Ban list in the Quarantined section. However, testing is faster using Test All Rules: you get the results immediately, instead of having to wait for a full Period to see how a Rule performed.
Examples of Dynamic Rules
Rate-limiting access to a specific URL
In the example below, this Dynamic Rule limits the number of requests that are sent to /login from a specific IP.
Limiting could also be done globally for all IPs by changing the Target to "Planet."
Using cookies to ban an attacker who is switching IPs
By using a cookie threshold, it is possible to eliminate Denial Of Service attacks originating from the same session, even if the attacker is changing IP addresses. In the screenshot below, requests are counted toward the threshold if they have the same value for the "rbzid" cookie. Requests are not counted toward the threshold if they were Bypassed by an ACL, or if the requestor has already been banned.
Rate-limiting specific HTTP requests
This rule blocks HTTP GET requests from a specific IP for 10 hours, under these conditions:
The IP has submitted more than 3600 GET requests in the previous three minutes.
The requests were not for a static file (.png , .jpg, .ico, .gif).
The requests were not already blocked
The requests were not from IP 1.2.3.4.
