Dynamic Rules
Banning or monitoring traffic sources that violated defined limits
Last updated
Banning or monitoring traffic sources that violated defined limits
Last updated
The Dynamic Rules section defines security rulesets that evaluate various criteria over time. When traffic sources commit activities that exceed defined thresholds, those traffic sources can be banned, or merely reported on within the Dashboard and Events Log.
Note that Dynamic Rules do not block individual requests based on their content; they define actions to take against the sources of requests. Individual incoming requests are blocked elsewhere, e.g., in ACL Profiles or in processing stages that include Actions.
Dynamic Rules have similarities to Rate Limit Rules: both types of Rules include thresholds and time frames, and each Rule includes an allowable number of events that can occur within a defined period of time.
However, there is an important difference:
Rate Limit Rules are evaluated while an incoming request is being processed. A violation will result in an action being taken against that request.
Dynamic Rules are evaluated later, during periodic queries of the traffic logs. They are used to examine requests in the traffic log that have already been passed or blocked. A violation will result in an action being taken against future requests from the responsible traffic source.
Dynamic Rules have many potential uses. A common one arises from the nature of Rate Limit Rules, which can only block persistent attackers for short periods of time (as discussed here). Dynamic Rules can place violators into quarantine for extended periods of time, during which all requests from those traffic sources are blocked.
Lastly, although Dynamic Rules are commonly used with Rate Limit Rules, they can be used independently as well, and have many other potential applications.
Dynamic Rules work together with Global Filters and the Quarantine list.
When a Dynamic Rule is created, Reblaze auto-generates a corresponding dynamic Global Filter. Initially, the Global Filter will not have any effect on incoming traffic.
Dynamic Global Filters are managed automatically by Reblaze. They are not visible to, or editable by, admins. They are described here so that admins understand how the system operates.
As incoming requests are received and processed, Reblaze periodically queries the traffic logs, and uses the Dynamic Rules to evaluate the most recent requests.
The timing and frequency of these evaluations will depend on the Threshold parameters defined for the currently active Dynamic Rules. Reblaze selects the optimal frequency for promptly identifying Rule violators, while still minimizing the number of queries and amount of data that must be pulled from the traffic logs for analysis.
When a traffic source is found to have violated a Dynamic Rule, the following occurs:
A Security Alert will be sent (if any were configured for this Dynamic Rule and the relevant Server Group).
The Rule's Global Filter is updated automatically to include the offending traffic source.
The traffic source is added to the Quarantine list.
For all subsequent requests from that traffic source, the Global Filter will:
Attach the Dynamic Rule's Tags
And execute the Rule's Action.
This situation will continue until either of the following occurs:
The Rule's Quarantine time expires
Or an admin manually removes the traffic source from the Quarantine list (see more below about the effects of this).
At that point, the traffic source will no longer be on the Quarantine list, and will also be removed from the Global Filter.
In the discussion above, "traffic source" describes the source(s) that sent the requests which violated the Dynamic Rule. This might be a single entity, or multiple entities, depending on the admin's choice of the Target parameter. For example, an admin could choose to enforce a Dynamic Rule on each IP address separately, or on all requestors collectively within a country, or on all requestors collectively who submitted a certain header or argument, etc.
Appearing on the "Quarantine" list does not necessarily mean that a traffic source has been banned. It only means that a traffic source has violated a Dynamic Rule, and that currently, its requests will trigger the Rule's Action. Often, this will be a blocking action. However, admins might also choose to merely monitor the traffic source's behavior without banning it.
When the planet is deployed on a Link11 private cloud, and a Dynamic Rule is configured with an IP blocking action, admins have the ability to offload the IP blocking to Link11's Layer 3 protection. During DDoS attacks, these requests will be blocked before they reach Reblaze; therefore, this will increase performance, and reduce the scaling necessary for Reblaze to handle the attack. During this time, the traffic sources will still be listed on the Quarantined page, and will be designated there as having been offloaded.
Note that while offloaded blocking is occurring, the blocked requests will not be received by Reblaze; thus, they will not be counted toward violations of other Dynamic Rules or Rate Limit Rules.
Traffic sources can be exempted from Dynamic Rule enforcement by adding one of their tags to the Rule's Exclude list.
If a traffic source is being incorrectly quarantined, it should be manually deleted from the Quarantined list. The next time that Dynamic Rules are evaluated, the following will occur:
The quarantine will end.
The Dynamic Rule's corresponding Global Filter will be updated, so that requests from this traffic source will no longer receive the Rule's Tags and Action.
The Dynamic Rule will be automatically updated to allowlist the traffic source, by adding a tag for the traffic source's IP (or whatever identifier is being used as the Target) to the Exclude list.
Unlike some other types of security settings, Dynamic Rules are not assigned to paths in Security Policies.
Instead, each Policy has its applicable scope defined by the Active mode, Include, and Exclude parameters, as described below.
The main window (shown above) lists all current Dynamic Rules.
The administration (addition/deletion/editing/versioning) of Dynamic Rules follows the conventions described here.
A Dynamic Rule consists of the following:
Parameters defining its applicable scope [Active mode, Include, and Exclude]
The definition of an entity, i.e. how to combine incoming requests for counting purposes [Target]
The behavioral limits for each entity [Number of events, Time frame]
What the system should do when the behavioral limits are exceeded [Action], which part of the system should do it [Offload IP blocking], and how long it should be done [Quarantine time]
Tag(s) to attach to requests that are currently being quarantined
General parameters for administration [Name, Description]
A name for this Rule, to be used within the Reblaze interface.
When this is enabled, this Rule will be applied within the scope defined by the Include and Exclude lists. Otherwise, it will not be enforced.
When Active mode is changed to "off", admins should check the Security Alerts list, to see if any Alerts are based upon this Dynamic Rule. As long as the Rule remains inactive, it will not fire any Alerts.
Information about this Rule, for use within the interface.
The entity that will be evaluated for this Dynamic Rule, and that will be quarantined if the Rule is violated.
For example, selecting IP means that each IP address in the traffic logs will have its requests counted separately, and if a violator is found, that IP will be quarantined. On the other hand, selecting ASN will combine all requests from all IPs within each ASN, and a violation will result in all IPs from that ASN being quarantined.
Some values for Target also require an associated value for Target key, e.g. the name of a specific header, cookie, etc.
As described above, admins can choose to block Dynamic Rule violators with Link11's Layer 3 protection. This option will be available when all of the following apply:
The planet is deployed on a Link11 private cloud
An IP blocking action is selected
No Include or Exclude parameters are specified.
When this option is enabled, and the change is published, it will apply to new violations of the Dynamic Rule. In other words, traffic sources currently in quarantine will continue being blocked by Reblaze until the quarantine expires.
The number of permissible requests within the specified Time frame. Exceeding this number is a violation of the Rule and triggers the Action.
The period of time within which the Number of events is enforced.
The action to take when the Target exceeds the Number of events during the Time frame.
The period of time to keep the traffic source in quarantine, and execute the Action for its requests.
The tag(s) to include in the Global Filter that is constructed for this Dynamic Rule.
The Include and Exclude tag lists define the applicable scope of this Dynamic Rule. Their use is described on the UI Overview page.
Unlike Rate Limit Rules (which can be enforced against specific target URLs via Security Policies), Dynamic Rules are global by default.
However, they can still be limited to specific paths/targets by using a Global Filter to attach descriptive tag(s) to the appropriate requests, and then using the tag(s) in the Dynamic Rule's Include and Exclude lists.
Global Filters can be used to limit enforcement of a Dynamic Rule to certain types of requests (e.g., HTTP methods, non-static files, etc.).
For example, to enforce a Dynamic Rule only upon POST requests, a Global Filter could attach method-post to all incoming POST requests, and the Dynamic Rule would only Include method-post.
By using a cookie threshold, it is possible to quarantine hostile traffic originating from the same source, even if the attacker is changing IP addresses. This can be done by selecting a Target of cookie, with a Target key of rbzid(the cookie that Reblaze sets for all traffic sources).
