Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
A fundamental part of traffic evaluation
As mentioned earlier in Security Section Concepts, Reblaze's decision-making can vary depending on the context. In a typical Reblaze deployment, much of the traffic evaluation is done using Profiles. When Reblaze receives a request for web resources, it first determines the Profile that is in effect for the resource that was requested.
Reblaze's Profiles are hierarchical structures, so that you can set up your security framework in a modular fashion. Rules and collections of rules can be set up once, and re-used throughout your planet as needed.
The hierarchy has several levels:
Profile
Policy
Rule
Condition and Operation
A Profile contains one or more Policies. A Policy contains one or more Rules. A Rule is a combination of a condition and an operation. Let's illustrate these with examples, from the bottom of the hierarchy upward.
Example conditions:
Is the request coming from a specific country? Or ASN?
Is the request coming from a specific IP address?
Is the request coming from a proxy? Or a VPN? Or a Tor network?
Is the request for a specific URI?
Is the request originating from an allowed (or a disallowed) HTTP referer?
Does the request contain (or not contain) specific arguments?
Is the request using (or not using) a specific method or protocol?
Does the request contain (or not contain) a query string in a specific format?
Does the requesting client have (or not have) specific cookies, or a specific cookie structure?
Possible operations:
Deny
Allow
Bypass (similar to "Allow", but the request will not be subject to further evaluation or filtering by other rules)
Example Rules:
If the requestor IP is within 131.253.24.0/22 [a known range of Bing crawlers], Allow.
If the requestor IP is within 157.55.39.0/24 [a known range of Bing crawlers], Allow.
If the requestor IP is within 1.10.16.0/20 [a range within the Spamhaus DROP list], Deny.
If the requestor IP is within 1.32.128.0/18 [a range within the Spamhaus DROP list], Deny.
If the requestor is a bot, Deny.
If the requestor is using a proxy anonymizer, Deny.
If the requestor's Company is [our company], Bypass.
If the requestor submitted an HTTP/S request, Deny.
Example Policies:
Allow Bing Crawlers [contains example Rules 1-2 above]
Deny requestors on Spamhaus DROP list [contains example Rules 3-4]
Deny bots [contains example Rule 5]
Deny proxy users [contains example Rule 6]
Allow users from our company [contains example rule 7]
Deny all requests [contains example rule 8]
Example Profiles:
Default:
Allow Bing Crawlers
Deny requestors on Spamhaus DROP list
Deny bots
Deny proxy users
Private area of our website, for internal use only:
Allow users from our company
Deny all requests**
** "Allow" Policies are evaluated before "Deny" Policies. When a match is found, no further evaluation is performed. In this example, company users will be Allowed, which exempts them from the Policy which Denies all requests.
Note that while Profiles are defined in this section of the Reblaze UI, they are assigned to specific resources/locations in the Security Profiles section of the Web Proxy page.
Profile: A re-usable collection of security policies
In a typical deployment, Reblaze performs much of its traffic evaluation according to security Profiles. There are four tabs within the interface:
The Custom Signature feature is being deprecated, and will be phased out in a future release of Reblaze. It is recommended that instead of constructing new Custom Signatures, use Tag Rules instead.
Before discussing each tab, it will be useful to discuss Profile Concepts.
How Reblaze scrubs incoming traffic
Reblaze evaluates incoming traffic in a multi-stage filtering process. An HTTP/S request which passes all security tests will be forwarded to the backend.
This decision-making is done in several stages.
Access Control List Policies
The ACL Policies section allows you to define Policies and Rules by which Reblaze will process your incoming traffic. Once an ACL Policy has been defined, it is available to be part of a Security Profile. Once a Security Profile has been defined, it is available to be assigned to specific resources (e.g., a section of your website) in the Web Proxy page.
In the discussion below, "ACL" and "ACL Policy" refer to the same thing: the Policies that can be administered in this section.
Existing ACLs are listed on the left. Selecting one will display it in the middle of the screen for editing.
Admins can create new ACL Policies, as discussed below. Admins can also edit many of the ACLs that are included out of the box in a new deployment.
Out of the box, many of the included ACLs are named with a prefix of ACL. This naming convention is recommended when creating/editing new ACLs, but it is not mandatory.
Several of the Reblaze-maintained ACL Policies are templates (designated by the prefix ACLT). If you do not wish to see them on this page, they can be hidden by selecting the Hide Templates checkbox on the upper right. These templates are used by the Create New Site wizard, and can also be assigned to other sites/applications by admins in the Security Profiles section of the Web Proxy page.
To create a new ACL, select the Create New button toward the top of the screen, then choose "ACL Policy." Or, duplicate an existing ACL and then edit the newly-created copy.
Each ACL contains one or more Rules. These are listed in the middle of the screen. To create a new Rule and add it to the current ACL, use the settings on the right part of the screen. (See below for more on this.) When you are finished with the Rule setup, click on the Add button. The Rule will be added to the Policy that you are currently defining or editing.
To remove a Rule from a Policy, click on the "X" to the right of its name.
Each of these fields is explained further below.
The Operation field has three possible values:
Bypass: the requestor will be granted access to the requested resource, without further evaluation or filtering of the request. However, although a Bypassed request will not be subject to further filtering, it will still show up in the logs (as “reason:bypassed”).
Allow: the requestor will not be presented with a challenge, but will still be evaluated by the WAF.
Deny: the requestor will not be allowed to access to the requested resource
When constructing an ACL Policy from multiple Rules, the Rules are arranged in the hierarchy shown above (Bypass, then Allow, then Deny). Rules are evaluated in order from top to bottom. When a Rule resolves to an action, that action is implemented, and further evaluation ceases.
There are five available options for Match:
Tag
Company
Country
IP Address
Custom Signature
The first four of these are common matching conditions that are always available. The fifth choice allows you to select custom matching conditions that you constructed by using the Custom Signature feature (however, note that Custom Signatures are being deprecated. Tag Rules should be used instead).
This is the third, unlabeled field in the New Rule dialog. The correct entry will depend on the option that was selected for Match.
If you selected Tag, enter one or more tags as the Match Argument.
If you selected either of these, enter the first few characters of the company name or country, and then choose the full name from the list that appears. (If the text box does not populate itself appropriately as you type the first few characters, check your spelling.)
Enter the specific IP or range of IPs (e.g., 178.184.0.0/16).
Enter the first few characters of a Signature that you created previously in the Custom Signature tab, and then choose the one you want from the list that appears. (If the text box does not populate itself with matching Signatures, check your spelling.)
By adding the following characters as a suffix to the ACL's name, the ACL will behave as follows:
For an example of using the OC suffix, see Bypassing Rate Limits for Loadtesting.
For an example of using XDeny, see Quickly Blocking an Attacker.
For creating custom matching conditions
This feature is being replaced with Tag Rules, which are more flexible and have more capabilities. For now, Custom Signatures are still being supported. However, it is recommended that you do not create any new Custom Signatures, as they will be deprecated in the future.
Custom signatures are custom matching conditions that you can use in ACL Policies to evaluate client requests.
These allow the administrator to "catch" traffic based on any parameter in the request or the response. They can be used in a number of situations. Some examples:
"Virtual patching": Identifying an incoming exploit attempt for a newly-discovered vulnerability in the upstream network.
Identifying logged-in admin users, so that their requests can be Bypassed.
Identifying specific patterns of traffic that are suspected to be malicious, so they can be blocked.
Identifying specific types of requests (e.g., XMLHttpRequest), so they can be blocked from specific sections of a website.
Signatures that have already been defined are listed in the left column, while you can edit and create new ones on the right. Once a Signature has been created, it will be available in the New Rule section within the ACL Policies tab.
Admins can create new Custom Signatures, as discussed below. Admins can also edit the Signatures that are included out of the box in a new deployment.
Out of the box, Reblaze's Custom Signatures are named with a prefix of CS. This naming convention is recommended when creating/editing new Signatures, but it is not mandatory.
There are several Reblaze-maintained Custom Signatures which are templates (designated by the prefix CST). If you do not wish to see them on this page, they can be hidden by selecting the Hide Templates checkbox on the upper right. These templates are used by the Create New Site wizard, and can also be assigned to ACL Policies.
To create a Custom Signature, click the Create New button toward the top of the screen, and then choose Custom Signature. Or select an existing one and choose Duplicate, then edit the newly-created copy.
Custom Signatures give you tremendous power and flexibility for evaluating your traffic. They are composed of one or more matching conditions, which can be combined using Boolean AND/OR operators.
When you first create a Signature, one condition appears for editing. If you wish to create more than one, click on the Append Condition button at the bottom. This will add another condition for editing.
You can continue for as many conditions as you want. The conditions will be evaluated according to the Boolean operator specified by the Condition Type selector.
Each matching condition combines the entries in Either one of the following fields and Is matching with.
This text box accepts strings or PCRE (Perl Compatible Regular Expressions).
An explanation and some examples are here: Pattern Matching Syntax.
Analyzing the values of arguments within incoming requests
This feature is still available within the UI. However, in the future it will be deprecated. It is recommended that customers switch to using Session Profiling instead, which is more powerful and more intuitive.
The Arguments Analysis feature has two primary functions:
Examining incoming requests for specific whitelisted characters in specific arguments (i.e., parameters in the URL query string or within the request body). Alphanumeric characters are allowed by default; all others must be allowed via a whitelist. When all characters in all arguments are found in the respective whitelists, the request is allowed, and no further inspection or filtering by the WAF is performed. If one or more characters are encountered that are not whitelisted, the request is either forwarded to the WAF for further inspection (when Inspect Unknown mode is enabled), or the request is denied (when Strict Whitelist mode is enabled).
Automatically updating the whitelists: As non-whitelisted characters are encountered, they can be added to the argument whitelists, depending on the Adaptive Mode selected.
The first function is often used in complicated sites; it offers a positive-security approach for analyzing traffic. Arg Analysis makes it easy to whitelist values that should be allowed in various request parameters. Another possible use is to bypass specific parameters that are too long for the WAF to efficiently process, or where WAF inspection is not relevant.
The second function (i.e., automatically updating whitelists) is less applicable for most deployments, and in most situations, is not encouraged. If Args Analysis is used incorrectly, large whitelists can be inadvertently built that will match most or all incoming requests. Thus, most or all incoming requests will bypass the WAF's traffic inspection and be sent directly upstream. In effect, this will disable Reblaze's traffic scrubbing. Therefore, we discourage the use of this function unless you are sure you need it, and you fully understand how it works.
For both functions, an argument list must be built.
Initially, this section will look like this:
Note the pulldown list on the right, which specifies the domain that you are currently administering.
Each time the system performs an analysis, arguments that were not previously known will be learned and added to the argument list, automatically (even in Supervised mode). The new character whitelists will consist of those characters that were encountered with each argument.
This can have some important and potentially nonintuitive consequences. See the warning below in the discussion of conflicted arguments.
Upload arguments file: The system allows you to upload a HAR file (that can be recorded using the browser’s dev tool). From the HAR file, the system will learn all the arguments and their values.
Creating an argument manually: You can also create individual arguments by selecting "New Argument," after which this dialog will appear:
When an argument is encountered in a query string or request body, its Argument Name is sought within the Args list for the relevant domain. If not found, it is added to the list, as noted previously.
If found, its value is analyzed. If each character within it is found in its corresponding Argument Characters, then this argument is passed.
If every argument in a query string or request body is passed, then the entire request is passed. It is sent to the origin (the upstream server), without being subjected to further inspection or filtering by Reblaze.
if the request is not passed, further processing occurs. See Handling Requests with Unmatched Characters, below.
In addition to the "New Argument" and "Upload Arguments File" options, the pulldown menu also offers additional capabilities.
Download as JSON - When this option is selected, the system will start a browser download of a JSON file that contains all the arguments and their values.
Delete App Args - Removes all the arguments in the current domain.
Analyze Now - Manually triggers the analysis process (described below), starting from the previous day.
Learning Resources - Displays the list of all ACL Policies defined in your planet, except for the default ones supplied by Reblaze. Example:
By default, Args Analysis learns from every request. The Learning Resources feature allows you to filter this, so that it only learns from specific requests.
When you select an ACL Policy from this list, Args Analysis will be limited to the requests which match that Policy. (If the ACL Policy happens to be empty, then the most recent 100,000 requests will be analyzed, or the most recent 24 hours' worth of data, whichever limit is reached first.)
If the selected ACL Policy has an Operation of Allow, then Args Analysis will analyze all the requests that were not blocked by the WAF or other ACL Policies. If the Policy is instead set to Bypass, then Args Analysis will also learn from blocked requests. (This can be useful when in Report-Only mode).
Show Regex/Characters - Toggle the display of all values on this page in regex, and then back into characters. Note when showing regex, alphanumeric characters are also explicitly included in the whitelist. In character mode, the Reblaze interface does not display these; the user should understand that all alphanumerics are whitelisted by default.
Refresh and Discard Changes - This allows you to discard all the changes you made to the arguments table.
Save Changes - When making any changes to the arguments table, you must save them afterward. This includes any modified or accepted conflicts in the system (more on these below).
In daily operation, Reblaze analyzes arguments in incoming requests. When they match the character whitelists, the requests are allowed, as described above.
Additionally, Reblaze goes through the traffic logs, analyzing and mapping all arguments received since the last analysis. This occurs every night around 3am UTC.
The system creates a list of argument characters that were encountered in requests, but were not in the whitelists.
Then in this Args Analysis section of the interface, Reblaze displays the current whitelists as follows:
Unchanged Arguments: This is at the bottom of the screen. It shows all the arguments for which Reblaze did not encounter any new (i.e., non-whitelisted) characters.
Conflicted Arguments: This shows the results of the most recent analysis: all the arguments for which Reblaze encountered characters that were not in the whitelists.
Here you have the opportunity to update the whitelists, accepting some or all of the proposed updates listed in the Conflicted Arguments section.
The manner in which these updates are accepted or rejected will depend on the New Args Adaptive Mode.
There are four possible modes: Automatic, Supervised, Locked, and Preview.
The system will discover and deploy new args without any human intervention. Everything occurs automatically.
The system will discover new args, but it will not deploy them. Instead, it will present them as Conflicted Arguments, and await approval or rejection by a human admin.
The system will not discover any new args. All configuration changes must be done manually.
The system will discover new args, but this is for informative purposes only. Traffic processing is not affected.
In the interface, there is a help section that lists the first mode as Automatic (Recommended). This is deprecated; we no longer recommend Automatic mode for most customers. As mentioned previously, this introduces the risk that erroneously large whitelists will be built. For most customer deployments, we now recommend Supervised or Locked mode.
For each of the first 3 operation modes (Automatic, Supervised, and Locked), another setting is available:
This defines Reblaze's behavior when non-whitelisted characters are encountered for known args.
A request that contains an argument that contains one or more non-whitelisted characters will be forwarded to the WAF for inspection and potential filtering.
A request that contains an argument that contains one or more non-whitelisted characters will be blocked.
After the request is processed, this argument is added to the list of Conflicted Arguments.
When new (non-whitelisted) characters are encountered, the arguments in which they were found are listed in the interface as Conflicted Arguments. Reblaze suggests updates (the New Values) for each argument's whitelist, and awaits the user's decisions.
Every time an analysis is performed, the previous list of Conflicted Arguments is discarded, and a new one generated. Thus, the interface displays only the Conflicted Arguments that were found in the most recent analysis.
Sometimes, argument names contain a designation for an ampersand ("amp;"), while others do not. This results from differences in decoding URLs versus arguments found in the body. It doesn't affect anything within the interface or its usage.
Each Conflicted Argument contains a set of New Values. These are updates that Reblaze is proposing to make. There are three available actions:
Deleting
Modifying
Accepting
Deleting - selecting the Trash icon will remove the Conflicted Argument from the list. This can produce unintended consequences: see warning below.
Modifying - You can edit the New Values. For the character field, only valid regex will be accepted.
Accepting - Clicking on the green Accept Conflicts button will accept all the Conflicted Arguments, updating the args list to the New Values.
It might appear that the "Delete" command (the trash can button) is merely a method of resolving the Conflict by rejecting the New Values and retaining the Current Values. This is incorrect.
When an argument is deleted from the list of Conflicted Arguments, this does not remove the conflict, it removes the argument. This has two consequences, both of which might not be intended by the user:
Until the next analysis is run, this argument will be unknown to Reblaze. Therefore, every incoming request that contains it will either be sent to the WAF for further inspection (when Inspect Unknown mode is enabled), or it will be denied (when Strict Whitelist mode is enabled).
When the next analysis is performed, Reblaze will learn the "new" argument, and create a new whitelist containing whatever characters were encountered within it. It's possible that this whitelist will contain some or all of the characters that previously caused that argument to appear as Conflicted.
The second point is especially important. If the user thinks that "Delete" will reject the New Values, the opposite can actually occur. When the argument is deleted and subsequently re-added, its character whitelist might automatically contain the same characters that the user was trying to reject previously.
The correct way of resolving a Conflict while retaining the same whitelist is to edit the New Values to match the Current Values, before selecting Accept Conflicts.
Or, the user can do nothing, and merely leave the Conflict unresolved in the interface. This will leave the argument's whitelist unchanged.
At the bottom of the screen is a list of Unchanged Arguments.
This shows the arguments for which Reblaze has not encountered any non-whitelisted characters.
You can edit these arguments if desired, or even delete them (by clicking on the trash icon to the right—but see the warning above about the potential consequences of deleting arguments).
Defining how Reblaze processes your traffic
This section defines the parameters with which Reblaze scrubs traffic.
The user interface is divided into these sections:
: Thresholds for banning sources of hostile traffic.
: The "warehouse" of traffic sources that are currently banned. This contains blacklists and whitelists, allowing you to manually control quarantines when necessary.
: Creation of security rule sets for assignment to specific resources, locations, and applications.
: Settings for allowing requests based on their arguments, in a procedure that occurs before normal WAF inspection and filtering.
: Settings for assigning to incoming requests.
: Settings for rate limits and the actions that will be performed when a rate limit is violated.
: Custom code that can be executed at specified times during traffic processing.
The Security section is where you define the "under the hood" settings for Reblaze. When defining or editing the information in this section, careful consideration is necessary.
Before investigating each section of the interface, it's recommended to read the "" discussion on the next page of this Manual.
Some security entities (Profiles, Rate Limits, etc.) are marked with icons. That means it is a Reblaze-managed default entity, and it cannot be edited or deleted. If you do not wish to see these in the interface, you can hide them with the checkbox at the top of a page.
Security rules with time-based thresholds
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 .
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 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.
To edit a rule, click on its name, and its parameters will appear below.
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.
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.
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.
The monitor list includes many useful arguments for identifying relevant traffic.
Scrolling down the list will reveal additional fields. These tend to be used by more advanced users.
The video below sums it all up:
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.
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).
Select Activate global simulation mode from the section menu, which will change all Dynamic Rules that were set to Ban to Simulated Ban.
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.
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.
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."
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.
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.
Early in the (immediately after evaluation of Quarantines and Dynamic Rules), Reblaze can assign one or more Tags to an incoming request. Subsequently, the Tags can be used to make decisions about how the request is processed. After processing, a request's Tags remain associated with it, and they are available for display in the .
This page allows you to administer Tag Rules, which are combinations of Tags and the criteria for assigning them to requests.
Each Tag Rule consists of:
Match conditions: A description of possible characteristics that a request can match (e.g., a list of IP addresses that it might originate from).
One or more Tags to assign when a match occurs.
An Active toggle to enable the Rule.
An Action to take immediately when a match occurs. Other Actions might be taken later as well; more on this below.
For each request, Reblaze will evaluate all active Tag Rules. A single request will receive Tags from all Rules which match it.
Tag Rules can be either Reblaze-managed or self-managed.
Reblaze-managed Rules are maintained by Reblaze. Most of these are based upon online data feeds (e.g., Spamhaus DROP lists), and are updated frequently and automatically. The match conditions for these rules are not editable in the interface, although the remaining parameters (Active, Tags, Action, etc.) still are.
Self-managed Rules are created and managed by admins. These Rules are fully editable within the interface.
The main window (shown above) lists all current Tag Rules.
To edit an existing Rule, select the Edit icon at the end of its entry in the list. To delete a Rule, select the Edit icon, and then within the window that appears, select the Trash icon.
To add a new Rule, select the + button in the main window, or edit an existing one and choose the Duplicate button at the top right.
The discussion below will focus on self-managed Rules. For Reblaze-managed Rules, the parameters that are editable will work the same as discussed below.
Name. A description that will be displayed within the Reblaze interface.
Active. By default, this Rule will be evaluated for all incoming requests. To prevent this, unselect the checkbox.
Tags. One or more Tags (separated by spaces) that will be assigned to all requests that fulfill the match conditions. Example: internal team-devops
Notes: An optional field for including information about this Tag Rule.
The Action that is selected here will be applied globally to all requests that match the Match Conditions.
To apply an Action to only some of the matching requests instead:
Choose the Tag Only Action and an appropriate Tag
Match conditions consist of two parts:
A list of one or more criteria to match.
If the criteria are organized into multiple sections, the Entries Relation specifies the logical condition to apply (either OR or AND) among the sections.
Some Tag Rules are based on external data feeds. (Many of the Reblaze-managed Tag Rules fall into this category.)
Enter the URL of the data feed into the Source field, then select the update now button that appears. Reblaze will then populate the criteria list automatically.
(Note that this example is for illustration only. An out-of-the-box deployment should contain the ASN DROP list already as a Reblaze-managed list.)
A self-managed Tag Rule based on an external data feed should be refreshed frequently, to re-query the data source. This can be done by opening the Rule for editing, then selecting the update now button next to the Source field. For convenience, you can also do this directly from the list of Rules in the main window; in the entry for the self-managed Rule, an Update now button will appear before the Edit icon.
If the criteria are organized into multiple sections--which is unlikely for a feed-based Tag Rule, but not impossible--also choose the appropriate value for Entries Relation, as discussed below.
Many Tag Rules will be based on specific criteria for a use case--criteria that are not found in an external feed.
To add match criteria, select the Create new section button. (If this button is not available, verify that the Source field is set to self-managed.)
A new section of criteria will be available, and the following dialog will appear.
For most of the criteria categories, the dialog will appear as it is above. Multiple entries can be made at once, with each entry on a separate line. Each line contains the value, plus a pound sign (#) followed by an annotation (a label for display within the Reblaze interface). Example:
For some categories, one entry can be made at a time, with each entry requiring multiple fields. Annotations are not preceded by a pound sign.
Match criteria are case-sensitive. The exception is Header keys, where match criteria are case-insensitive.
Here are some sample entries for the various categories. Notice that the logical operators are available.
Once created, these entries cannot be edited. If one needs to be modified, remove it and re-create it.
The first criterion added to a Tag Rule will be in one section. If additional criteria are added, they are all evaluated with an OR. (For a request x and list of criteria a, b, c , the evaluation will be (x==a) OR (x==b) OR (x==c) ).
You can add additional sections by selecting the Create new section button. Each section will similarly use OR internally.
However, when there is more than one section, an additional evaluation must occur among the results of the individual sections. The Entries Relation selector specifies the logical operation used here.
Example: there are two sections. The first section has criteria a, b, c and the second has i, j, k . The Entries Relation is set to AND. For a request x, the evaluation will be ((x==a) OR (x==b) OR (x==c)) AND ((x==i) OR (x==j) OR (x==k)).
Administration of built-in modules
This section allows you to administer WAF/IPS Policies, which define the sets of defined behaviors for the WAF. The Policies are assigned to paths/URLs in the .
Existing WAF/IPS Policies are listed on the left side; selecting one will display its contents on the right for editing. A default Policy must always exist. Additional Policies for specific situations can be defined if needed.
Admins can create new WAF/IPS Policies, as discussed below. Admins can also edit many of the Policies that are included out of the box in a new deployment.
Out of the box, many of the included Policies are named with a prefix of WAF. This naming convention is recommended when creating/editing new Policies, but it is not mandatory.
To create a WAF/IPS Policy, select an existing one and choose Duplicate, then edit the newly-created copy.
When viewing or editing a WAF/IPS Policy, the Active Modules section allows you to enable/disable some of the modules. The four on the left are always active and cannot be turned off. (However, an ACL Policy that resolves to an action of Bypass will exempt a requestor from them.) These four modules are:
The next three modules are optional, but are recommended in most situations:
Administer the lists of which requestors are banned and/or permitted access
The quarantined section will show requestors that have been banned for violation of the and rules, requestors that have been blacklisted, and requestors that have been whitelisted. You can add and remove requestors, and transfer them among the various lists.
There are four lists of requestors in this section:
Banlist
Simulation Banlist
Blacklist
Whitelist
Each is described in more detail below.
For each entry, it's possible to see the following: IP address, origin country, AS number, the violation that was triggered, "CNT/Limit" (the number of violations compared to the allowable limit), when the ban began, and when the ban will expire.
All requests from these requestors are currently being rejected. These requestors violated a rule that was set to “Ban” mode.
These requestors are NOT having all their requests rejected. These requestors violated a rule that was set to “Simulated Ban” mode. Simulated Bans are used mainly for testing new rules and seeing how they function, before converting those rules to Ban mode.
All requests from these requestors are currently being rejected. These requestors were placed here by a Reblaze admin.
These requestors are exempted from the Dynamic Rules. Even if they violate a Dynamic Rule, they will not be banned.
Requestors are added to the Banlist and Simulation Banlist automatically when they violate a Dynamic Rule or Rate Limiting Rule.
You can add a requestor manually to the Whitelist or Blacklist using the "Add New Entry" option in the section menu. This is demonstrated in the following video:
The fields are:
Requestors can be transferred among the various lists with this procedure:
Select the requestor(s) by checking the box at the left of each entry.
Open the section menu.
Choose the desired "Move to" command (e.g., "Move to Whitelist").
Moving an item to the Banlist can only be done from the Simulation Banlist.
Requestors on the Banlist, Simulation Banlist, or Blacklist will be automatically removed when their expiration time is reached. (The Whitelist has no expiration time.)
Requestors can be manually removed from the list they are currently on:
Select the requestor(s) by checking the box at the left of each entry.
Choose "Delete".
A Cloud Function (CF) allow you to extend Reblaze's tools and functionality. Each CF consists of Lua code that can be run at different points in Reblaze's traffic processing.
Cloud Functions are defined here. They are assigned to URLs within the web application in the .
When creating a Cloud Function, do not rely on Reblaze to validate the code. Please ensure that the code is valid and, ideally, tested before adding it. If the code has errors, undefined behavior can occur when Reblaze attempts to execute it.
The top right of the screen provides a pulldown for selecting a CF for editing, an Add button to create a new CF, and a Save button for saving edits that were made on the currently-displayed CF.
The CF itself consists of a name (for display within the Reblaze interface), an automatically-generated ID, the Code itself, and a specified Phase. The Phases pulldown allows you to specify when the CF will execute:
Request Pre Reblaze: Execute immediately when Reblaze receives an incoming request, before any other processing occurs.
Request Post Reblaze: Execute after Reblaze has finished processing the request, and before it accesses the backend server.
Response Pre Reblaze: Execute when Reblaze receives the response from the backend.
Response Post Reblaze: Execute as the last action before Reblaze sends the response to the client.
A page for administration of security Profiles
Within the Security section, this tab provides an interface for administering Security Profiles.
Existing Profiles are shown on the left.
Admins can create new Security Profiles, as discussed below. Admins can also edit the Profiles that are included out of the box (e.g., SP Default) in a new deployment.
Out of the box, Reblaze's Security Profiles are named with a prefix of SP. This naming convention is recommended when creating/editing new Profiles, but it is not mandatory.
To create a profile, click the Create New button toward the top of the screen, and then choose Profile. Or select an existing one and choose Duplicate, then edit the newly-created copy.
To edit a profile, select it from the list on the left. Its contents will appear in the middle part of the screen.
To add a new Policy to the Profile, select the desired Policy from the Link More Policies list on the right, and click the Add button. To remove an existing Policy from the Profile, click on the X to the right of its name.
Within a Profile, the order of Policies does not matter. When evaluating an incoming request, Reblaze combines the Bypass, Allow, and Deny Rules from all the ACL Policies in the Profile. It evaluates all the Bypass Rules first, then all the Allow Rules, then the Deny Rules.
Most Profile administration will not be possible until the appropriate Policies have been created. Similarly, complete Policy administration will not be possible until there are Rules to add to them.
Controlling the rates of incoming requests
Rate limiting restricts the rates at which traffic sources can send requests. When a limit is exceeded, the defined action is enforced.
Admins can create new Rate Limit rules, as discussed below. Admins can also edit the rules that are included out of the box in a new deployment.
Out of the box, Reblaze's Rate Limit rules are named with a prefix of RL (for Rate Limit) or RLP (a Rate Limit using the "Pair with" attribute, discussed below). This naming convention is recommended when creating/editing new rules, but it is not mandatory.
It is also recommended that Rule names are descriptive of their contents. For example, a Rule that limits 50 requests per username, per 60 seconds, could be named "RL 50/60s username". This makes administration straightforward, and also clarifies events in the traffic logs.
Existing rules are listed on the page shown above. To edit or delete a rule, select the "edit" button at the end of its listing.
To add a new rule, select the + button. The following window will appear.
After defining a new Rate Limit, select the Save button at the top of the window. An additional section (Links to URLs) will then appear at the bottom of the window. This will be discussed later.
Each Rate Limit Rule consists of the following types of parameters:
Each is discussed further below.
Event criteria have two components:
Key(s). These define the events that are being counted. See "Composing Keys," below.
Include/exclude filters constrain the requests whose Keys are being counted. In other words, they define the segment of the incoming traffic stream that is being evaluated for possible events. See "Including/Excluding Requests," below.
A Key consists of a field and a value. Within a Rate Limit Rule, they play a role like this:
"More than <LIMIT> requests with the same <KEY-VALUE> <KEY-FIELD> sent to <ASSIGNED-LOCATION> within <TIME-PERIOD> will cause <ACTION>."
Example: "More than three requests with the same username argument sent to the login form within one hour will cause the requestor to be banned for six hours."
A Key can be built upon any one of these four fields:
Multiple Keys can be defined within the same Rule. To create a new Key and open it for editing, select the "+" button next to the Key label.
If multiple Keys are defined, they are evaluated by combining them together with a logical AND. In other words, the cumulative count toward the Limit will be incremented whenever a request is seen that matches all of the Keys simultaneously. Different combinations of Keys will have separate Limit counts maintained for them.
Example. A Rule contains two Keys: "Attribute / Remote Address" and "Argument / Username". When the first request is received, an internal counter is created (set to a value of one) for this unique combination of Remote Address and Username. A second request is then received, originating from the same Remote Address and for the same Username; this causes the internal counter to be incremented up to two. A third request is then received from the same Remote Address but with a different Username; this causes a new internal counter to be created (and set to a value of one) for this combination.
Below the list of Key(s), there is a checkbox labeled "Pair with." If this is checked, then a different type of Key can be added below it.
In the following discussion, "Key" will refer to the Key (or combination of Keys) defined above the "Pair with" checkbox.
"Paired Key" will refer to an optional, additional Key that is defined below the checkbox.
Adding a Paired Key changes the evaluation process. A Paired Key is not logically combined with the preceding Key; it is always evaluated separately.
Also, adding a Paired Key changes the meaning of the Rate Limit.
If a Paired Key is not defined, an internal counter is maintained for each Key value, and incremented each time that value is encountered in a request.
If a Paired Key is defined, an internal counter is maintained for each Key Value, and incremented each time a new, previously unobserved Paired Key value is encountered in a request.
Therefore, if a Paired Key is defined, the Rate Limit constrains the number of allowable Paired Key values for any given Key value.
So, the evaluation becomes something like this:
"More than <LIMIT> <PAIRED-KEY-VALUE> <PAIRED-KEY-FIELD>s per any one <KEY-VALUE><KEY-FIELD> sent to <ASSIGNED-LOCATION> within <TIME-PERIOD> will cause <ACTION>."
Note that the number of Key values is not being limited here. The limit is on the number of Paired Key values that each Key value is allowed.
Example: Let's say we want to allow an individual user to login from a maximum of two ASNs within one hour. (Perhaps the user is accessing our web application from a coffee shop's WiFi, and then a few minutes later, leaves the coffee shop and begins using the cell network instead.) We want to allow this possibility; however, if we receive requests from the same user originating from three or more ASNs within an hour, we want to treat this traffic more suspiciously. This is not possible merely by specifying two Keys, as described earlier in the "Multiple Keys" section. If we set up two Keys ("Argument / Username" and "Attribute / Organization") with a limit of 2, and assign it to our login form, then this will merely limit the number of times that the user can login from each ASN within an hour. Instead, we can set up one Key ("Argument / Username"), check the "Pair with" checkbox, and then set up the Paired Key ("Attribute / Organization"). Now the Limit will apply to the number of combinations of Username and Organization that are received for each specific Username.
The Include and Exclude filters allow you to constrain the requests against which this Rate Limit Rule will be evaluated.
By default, an active Rate Limit Rule will be enforced upon all incoming requests. Specifying an Include and/or an Exclude filter will set limits to this enforcement.
Include and Exclude Tags
The Include filter will limit enforcement to the Tags specified in the Tags field under Include.
In the autofill field of the Include section, enter the name of an already existing Tag from Tag Rules. If more than one Tag is needed, click the "+" sign to the right of the field to add another Tag.
If there is a need to add a Tag which does not exist yet, create a new rule in Tag Rules. It will then be included in the list of Tags available for rate limiting.
All other requests in the traffic stream that do not have the Tags specified will not have the Rate Limit Rule enforced upon them.
Selecting Tags in the Exclude filter works in the identical manner as Include. Tags specified in the Exclude filter will exempt requests from enforcement that otherwise would have been evaluated. Exclude requests, which otherwise match the Include filter's parameters, will not have the Rate Limit Rule applied to them.
Note that the same Tags cannot be specified for Include as for Exclude.
2. Include and Exclude Origin Response Codes
For both Include and Exclude: In this field, specify the code(s) returned by the origin server which will be counted for this rule. This can be either a single three-digit code or a range of two three-digit codes separated by a hyphen, for example, 300-700.
Note that the same Origin Response Codes cannot be specified for Include as for Exclude.
If you wish the Limit to be set to zero, leave the Origin Response Codes field blank for both Include and Exclude.
When a Rate Limit is triggered, the specified Action will occur.
The Ban action is a unique option for Rate Limiting, and is described in detail below.
Most of the available Actions will not fully exclude an attacker that continues pressing the attack.
Example: Access to a login form is rate-limited to three requests per minute. An attacker tries to brute-force the login, and sends 60 requests per minute. The Rate Limit allows the first three requests, but then blocks the next 57 requests with a 503 error. However, after the minute has passed, the Rate Limit resets. The attacker is allowed another three attempts before being temporarily blocked again. This cycle can continue for as long as the attacker wishes. In effect, the Rate Limit is not preventing the attack; it is merely slowing it from 60 attempts per minute down to three attempts per minute.
The Ban action can be used to block (or take some other Action in response to) a Rate Limit violator for an extended period of time.
Example: As described above, a Rate Limit is created to allow three requests per minute, with an Action of 503 Service Unavailable. However, an additional Rate Limit rule is also defined: nine requests per three minutes, with an Action of Ban. The Ban has an Action of 503 Service Unavailable, and a duration of one hour. Reblaze allows multiple Rate Limits to be assigned to a single URL. Thus, both of the above rules can be assigned to the login form. Now an attacker tries to brute-force the login form, sending 60 requests per minute. The first three requests are allowed. The next six requests are blocked by the first Rate Limit. The tenth request triggers the second Rate Limit, and the Ban occurs. For the next hour, the attacker's requests will be blocked with a 503 error.
Note that when setting up a Ban, the most common choices for its Action are to deny the violator's requests (via 503 Service Unavailable, Response, or Redirect). However, you can also choose Tag Only (to observe the violator's actions during the ban period), Challenge (to verify that the violating activity is not being done by bots), or Request Header (to mark the requests for further scrutiny by the backend).
In the main window, each Rule listing has a number for Linked URLs.
The number represents the number of URLs to which this Rule is currently assigned. URLs are linked after a new Rule is created, or they can be added later when editing an existing Rule.
URL linking is done at the bottom of the rule editing window:
When creating a new Rate Limit rule, the Links to URLs section does not appear until after the new rule is saved.
Select a location from the pulldown
Select the "+" button to add it to the list of assignments.
Select the Save button at the upper right of the window.
More than one assignment can be performed at once. After adding the first assignment to the list, simply add additional ones as needed. When the list is complete, select the Save button.
Some ACLs are provided and maintained by Reblaze, and are read-only. These are designated by the Reblaze icon. They are updated as necessary with no action required on your part. (Typically these include dynamic elements that need frequent updating—for example, a list of IP addresses with a recent history of malicious activity.)
Some Custom Signatures are provided and maintained by Reblaze, and are read-only. These are designated by the Reblaze icon.
In the top right menu you will see this button: . Clicking on it will open the main menu:
To disable or enable a rule, click on the Activation trigger:
To delete a rule, click on the small button at the end of its listing: That button will display options to Delete this rule, or to Duplicate it. (Sometimes, it is faster to Duplicate a rule and edit the copy than to create a new one from scratch.)
At the top right screen, this larger button is shown : . Clicking on it will cause the section menu to appear:
Some of the matches rely on the results of . For example, an Anonymizer value of "true" will match a request that was denied by the "Deny Anonymous Proxies" ACL Policy.
There are several ways to obtain values for constructing Block Reasons. The first is the list of standard (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 , or from the Signatures tab on the page.
This means that requestors who violate Dynamic Rules will not be banned; instead, they will appear within the in the section. You can observe the requestors who appear there, and evaluate if the Dynamic Rules are identifying the requestors you expected.
When working in this window, when all edits are completed be sure to select the Save buttonon the upper right part of the page, to save the new Rule.
The choices for this parameter are described in .
Create an for that Tag
Assign the ACL Policy to a
Assign the Security Profile to the relevant section(s) within application(s) in the page.
As an example, to create a list based on the Spamhaus ASN DROP list, you would enter , and then select the "update now" button.
There will be at least one Policy that is designated by the Reblaze icon. It is provided and maintained by Reblaze, and is read-only.
A prefix of WAFT indicates a Reblaze-maintained WAF/IPS Policy template. If you do not wish to see any templates on this page, select the Hide Templates checkbox on the upper right. Templates are used by the , and can also be assigned to other sites/applications by admins in the .
At the bottom of the page are the Request Arguments Limitations, Whitelist Argument Names, and Whitelist Rule IDs. These allow you to permit or deny requests based on the arguments contained in the request. For assistance with these entries, please .
On the right part of the screen is the section menu, invoked via the button with three vertical dots:. Depending on context, the section menu will offer the management abilities described below.
Open the section menu by clicking on its button ().
Cloud Functions are a very powerful tool. If you need assistance with this feature, please feel free to .
Some Security Profiles are provided and maintained by Reblaze, and are read-only. These are designated by the Reblaze icon.
Several of the Reblaze-maintained Security Profiles are templates (designated by the prefix SPT). If you do not wish to see them on this page, they can be hidden by selecting the Hide Templates checkbox on the upper right. These templates are used by the , and can also be assigned to other sites/applications by admins in the .
In previous versions of Reblaze, a Profile would include one . Now, a WAF Policy is assigned directly to each resource/location in the .
Some rules are provided and maintained by Reblaze, and are read-only. These are designated by the Reblaze icon.
Some of the Reblaze-maintained Rate Limit rules are templates (designated by the prefix RLT or RLPT). If you do not wish to see them on this page, they can be hidden by selecting the Hide Templates checkbox on the upper right. These templates are used by the , and can also be assigned to Linked URLs by admins.
In all cases except one, the Limit can be zero. If so, the specified Action will occur immediately when an incoming request matches the Event Criteria. For Include/Exclude criteria, the Limit must be set to at least one. If you wish to specify a Limit of zero, then the Origin Response Codes fields must be left empty. More about this in the section.
There are various Actions available for selection here: 503 Service Unavailable, Challenge, Tag Only, and more. They are described in the documentation for the dropdown.
Second example: A hostile bot receives a , which it fails. Reblaze will block the request. If the bot keeps re-submitting its request, it will continue to fail the challenges. However, each time the bot tries again, Reblaze has to issue a new challenge . To solve this problem, a second Rate Limit is created with a Ban action. Now a persistent bot will simply be Banned, saving the overhead of issuing continuous challenges.
The Site dropdown contains a list of web applications that are currently defined in the .
After selecting a web application, a pulldown list will appear. It will contain the locations defined for this web application within the . To assign the current Rule to this location:
Fields
Description
Operation
The action that will result when the Rule’s Match condition occurs.
Match
The type of parameter that will be tested to see if a Match occurs.
(unlabeled)
The value for the Match condition.
Suffix
Description
Examples
OC
Over-capacity override: ignore rate limits.
Loadtest OC
XDeny
"God Mode": bypass the Rule Operation hierarchy.
Global DR XDeny
Field Name
Description
Args
Arguments in the request’s header
Arg Names
Argument names in the request’s header
Autonomous System Number (ASN)
The ASN for a specific entity
Country Name / City
Geolocation
Host Name
Destination Hostname
Query String
Regex value inside the query string
Referer
Referer / Via values
Remote Address
Client Address in the request
Request Cookies
Cookie in the request’s header
Request Cookies Names
Cookie names in the request’s header
Request Filename
The GET request resource
Request Headers
Specific headers inside the requests
Request Headers Names
Scan the request for specific header values
Request Method
An HTTP method: PUT, POST, GET, etc.
Request Protocol
HTTP / HTTPS
Request URI
The URI of the resource being requested
User Agent
The User-Agent of the requestor
Field Name
Description
Argument Name
The parameter in the query string or request body
Argument Characters
A regex pattern to match against the values specified for the Argument Name. This is a whitelist of allowable characters.
Max Length
Maximum allowed length of the argument, in characters
Field Name | Description |
Block Reason | The reason for the traffic being blocked. See Defining Block Reasons below for a full explanation. |
Blocked | True if the request was blocked, otherwise False. |
Cookie | An exact match of the cookie name and value. |
Domain Name | Which domain names should be monitored. |
File Extension | Which file extensions should be monitored. Example: (exe|jpg|tar) |
City | The abbreviation of the country. Example: "US" for "United States." |
Country | Country name. |
Host Name | Any name that was configured as Host. |
Reblazer ID | ID of the Reblaze proxy |
Anonymizer | Boolean value (True/False) |
Cloud | Boolean value (True/False) |
Human | Boolean value (True/False) |
Proxy | Boolean value (True/False). [This is different than the Anonymizer field above. It uses an internal value of Reblaze that is not otherwise exposed in the interface.] |
TOR | Boolean value (True/False) |
VPN | Boolean Value (True/False) |
Method | HTTP method type (e.g., GET, POST, etc.). |
ASN | The ASN Value. |
Referer | The Referer value. |
IP | The IP Address. |
Complete URL | URL with the query string. |
URI | URI |
Request Body | Text boxes will appear for "Name" and "Value" parameters. Both can be regex. |
Request Headers | Text boxes will appear for "Name" and "Value" parameters. Both can be regex. |
Response Status | HTTP response code (200, 404 etc.). |
User Agent | The request's user agent name. |
Parameter | Functionality |
Essential Headers Checkup | A request without a header is illegitimate (and generally is an indication of a bot). This module blocks these requests. |
HTTP Methods | This module defines the HTTP Methods that are allowed in requests. |
Argument Limitations | This module enforces the Request Arguments Limitations that are specified below the list of Allowed HTTP Methods. |
RFC Compliance | This module ensures that every request is RFC compliant. Most penetration tools are non-compliant (often deliberately so)—thus, this module alone defeats and excludes a high amount of hostile traffic. |
Field Name | Description |
Type | Cookie, Country, ASN, IP, Request Body, Request Header. |
Name | Will appear for specific types: Cookie (Name), Headers, etc. |
Value | The value which will activate the blacklisting. For example, when Type is "IP", the blacklistable IP address would be entered here. |
Reason | User description of the reason for adding this entry. |
Expiration | The expiration of the entry, in Hours or Minutes (only relevant for blacklists). |
Type | Values |
Meta | A name and description for the Rule. |
Rate Limit | Defines the maximum allowable number of events within a certain time period. |
Event Criteria | Specifies which events will be counted toward the Rate Limit. |
Action | Specifies what will happen when the Rate Limit is exceeded. |
Assignments | The resources/locations/URLs within the web application where the Rate Limit Rule will be enforced. |
Field | Value |
Name | A name for this Rule. It will be used within the Reblaze interface, and will also be used to create a Tag that will be assigned to requests which trigger the Rate Limit. |
Description | A description of this Rule which will be used within the Reblaze interface. |
Field | Value |
Limit | The maximum number of allowable events within the specified Time Frame. Subsequent events within the Time Frame will trigger the Action. |
Time Frame | The time period within which the Limit is enforced, specified in seconds. |
Field | Result |
Header | All requests with the same value for the specified header will be counted together toward the Limit. |
Cookie | All requests with the same value for the specified cookie will be counted together toward the Limit. |
Argument | All requests with the same value for the specified argument will be counted together toward the Limit. |
Attribute | All requests with the same value for the specified attribute will be counted together toward the Limit. |
Name | Description |
Add new rule | Creates a new Dynamic Rule. |
Activate global simulation mode |
Test All Rules |
Set new TTL globally |
Help |
Refresh and discard changes | Discards all changes that you have made, and refreshes the display to show the current settings within the system. |
Save Changes | Saves all changes that have been made. Note that this makes your changes go live immediately. Unlike other administrative activities within Reblaze, when editing Dynamic Rules it is not necessary to Publish Changes after saving them. |
Field Name | Description |
Description | Your description of the rule. This is useful for internal purposes, e.g., noting why a particular rule is necessary. |
Target | Defines the source of aggregated requests which will be evaluated, and the recipient of the specified action if a violation occurs. The most commonly-used target is IP. Other options are Cookies, Country, ASN, Planet, Request Body, Request Header, or User Agent. ("Planet" means "all requests." This is used in the Global Request Count default rule.) |
Alert | If a notification should be sent when a violation of this rule occurs. |
Mode | Defines the action that will happen when a requestor exceeds the specified Threshold during the Period. |
Threshold | The maximum allowable number of http/s requests by the Target in the specified Period. |
Period | The time period within which requests will be counted, and if the Threshold is exceeded, will trigger the defined action. Note that each Period should be 3 minutes or longer. (A few example screenshots in this Manual have shorter periods. These were taken from a demo site, and are for illustration only. Periods in a production deployment should be 3 minutes or more.) |
TTL | Time To Live: If the violator is banned, this is the length of the ban. If the violation is merely reported (as in Report Only mode), this is the amount of time before a new report can be issued on this violation. |
Monitor | A list of matching conditions. If a request matches all the conditions in this list, it will be included in the aggregated count toward a potential violation. Multiple conditions are ANDed together. See further discussion below. |
Ignore | A list of matching conditions. If a request matches any of the conditions on this list, it will be ignored, and will not be included in the count toward a potential violation. Multiple conditions are ORed together. See further discussion below. |
Parameter | Functionality |
Bad Robots |
Dual Encoding | A common penetration technique is to encode a hostile request multiple times, in an attempt to evade detection and filtering. For example, an injection attack might be encoded in binary, and then sent as if it were plain text. Or, different types of encoding might be mixed together in the same request. This module detects and defeats these attempted attacks. |
* Injection Proof | This module detects and defeats different kinds of injection attacks: SQL, XSS, and OSC. (The "*" is a wildcard.) |
Stage
Comments
Pre-Processing Cloud Functions
The Cloud Functions marked "Request Pre Reblaze" are executed.
Quarantines & Dynamic Rules
Traffic from requestors that are currently on the Banlist or Blacklist is blocked. Other requestors are evaluated for potential addition to the Banlist using Dynamic Rules.
Static Rules & Rate Limits
Requests that do not conform to specified size, time, and per-IP rate limits are blocked, according to the Advanced Frontend Settings for the application.
Session Profiling
Reblaze assigns automatically-generated tags, and user-defined tags (configured in Tag Rules) to the requests.
ACL Policies
ACL Policies are enforced.
Rate Limits
Rate Limit Rules are enforced.
Challenges
Verifies that requests are coming from humans. More information: The Challenge Process.
Argument Analysis
Examination of characters in arguments. Possible results are to exempt a request from WAF filtering, to send the request to the WAF for inspection, or to block the request. More info: Args Analysis.
WAF/IPS
The active WAF Policy is enforced, assuming that the request was not previously Bypassed in the ACL Policy.
Post-Processing Cloud Functions
The Cloud Functions marked "Request Post Reblaze" are executed.
The rules currently set to "Ban" will be changed to “Simulated Ban”. This is useful for testing. See also , below.
Explained in , below.
Sets TTL (described below in ) for all Dynamic Rules.
Brings up a help screen describing the settings for a rule. See also , below.
Ban will block the violator (available for IP, Cookie, Request Body, Request Header, Country, and ASN), and will add the violator to the .
Simulated Ban does not actively ban the violator; it only adds the violator to the .
Report Only does not actively ban the violator. If this rule has been included within a , then the defined notifications will be sent.
Identifies and blocks malevolent bots, based on their user agents. This works differently than the process to identify bots. Therefore, when active challenges are disabled, this WAF capability can still be used.
|
|
