Dynamic Rules
Banning or monitoring traffic sources that violated defined limits
Last updated
Was this helpful?
Banning or monitoring traffic sources that violated defined limits
Last updated
Was this helpful?
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, Link11 WAAP auto-generates a corresponding dynamic Global Filter. Initially, the Global Filter will not have any effect on incoming traffic.
As incoming requests are received and processed, L11WAAP periodically queries the traffic logs, and uses the Dynamic Rules to evaluate the most recent requests.
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.
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 L11WAAP; therefore, this will increase performance, and reduce the scaling necessary for the system 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 L11WAAP; 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 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.
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 L11WAAP 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 L11WAAP sets for all traffic sources).
