Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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 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.
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.
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:
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.
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.
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.
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.
Profile: A re-usable collection of security policies
In a typical deployment, Reblaze performs much of its traffic evaluation according to security Profiles.
Within the Reblaze user interface, there are four sections for defining Profiles:
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 , 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 Dynamic 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. For example, even if they violate a rate limit, they will not be banned.
Requestors are added to the Banlist and Simulation Banlist automatically when they violate a Dynamic 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".
Administration of built-in Security Policy modules
Along with its , Reblaze includes WAF/IPS Policies. This section allows you to administer them.
Just like ACL Policies, WAF/IPS Policies are included in . Unlike ACL Policies, a Profile cannot contain more than one WAF/IPS Policy.
Existing WAF/IPS Policies are listed on the left side; selecting one will display its contents on the right for editing.
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:
Below the modules is the list of Allowed HTTP Methods. In general, you should enable as few of these as possible, and then disable the rest.
Sometimes there are methods that are used only by a few specific users. A possible approach for this situation is to disable those methods here, and then define ACL Policies or Signatures by which those specific users are Bypassed from being blocked by this module. This strategy works, but it should only be done in deployments where the specific users can be reliably identified.
Defining how Reblaze processes your traffic
This section defines the parameters with which Reblaze scrubs traffic.
The user interface is divided into five sections:
: Security settings that apply to your entire planet.
: 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.
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.
Constant settings that apply to the entire planet
This section defines security ruleset parameters that apply to your entire Reblaze planet. They are "static" because they are simple settings, and do not vary according to context or circumstance.
The settings in this section are global. They apply to all configured sites on the platform, even if the domain is set to .
The main page for this section has three tabs:
Timeouts
Sizing
Speed & Rate
Each tab is discussed in-depth below.
At the upper right corner of this screen, there is a choice of two different sets of settings: Default and DDoS. Please ignore the DDoS settings: this mode has been deprecated, and will be removed from a future version of the interface. You should only work with the Default settings, since only these settings will be used by Reblaze.
After working in this section, remember to click on "Save Changes."
The Timeout settings allow the system to monitor the time required to serve resources to each client. Any connection that exceeds the specific limits will be dropped.
Why timeouts are important
Some DDoS tools (e.g., R-U-Dead-Yet, or RUDY) send a relatively small quantity of traffic requests, but do so as slowly as possible (often with each byte sent separately). While a legitimate request can be resolved in milliseconds, a single RUDY machine can tie up server resources for several minutes. Even a few hundred of these machines attacking your server can be very destructive.
The Timeout settings allow Reblaze to block unresponsive requestors, whether their unresponsiveness is malicious or not. For most Reblaze deployments, the default timeout settings work very well. They are sufficient to filter out hostile traffic, while still accommodating even those users with low bandwidth.
All times are specified in seconds, as shown in the example below.
This tab allows you to place limits on the amount of data that users can upload to the system. The defaults usually work well; however, if your application accepts user-generated content or other large files, then changes to these settings might be necessary.
Please note that if you increase these settings within Reblaze, then the upstream server should also be configured to accept and store the quantity of data that Reblaze will (potentially) pass through.
This tab allows you to limit the amount of resources consumed by an IP or individual user.
Reblaze can limit consumption by the average number of requests per second (the "IP Requests" and "User Requests" settings), while also allowing temporary bursts at a higher rate ("IP Maximum Burst" and "User Maximum Burst").
Note that this rate limiting is a global metric across all sites. For example, if one IP address is submitting requests to multiple web applications within a Reblaze planet, all the requests are combined when determining if rate limits have been violated.
Here's an example screenshot:
When a requestor exceeds any of these thresholds, subsequent requests will be answered with error code 503 (Service Unavailable).
For most use cases, the two most important Speed & Rate parameters are IP Requests and IP Maximum Burst.
In the Speed & Rate section, the rate limiting settings can be nonintuitive. Here is an explanation of how they work.
IP/User Requests sets the allowable per-second average of incoming requests, enforced on an incremental basis (where "increment" refers to the number of milliseconds allowed for one request). IP/User Maximum Burst sets a higher per-increment ceiling.
Example: IP Requests is set to 100 r/s. Thus, 100 requests are allowed per second. However, the system does not enforce rate limits on a per-second basis; it used a granularity of milliseconds. Therefore, it will allow one request every 10 milliseconds. (100 r/s, divided by 1000 ms/s, equals 1r/10ms.)
Without burst limits—i.e., if IP Maximum Burst is set to zero—the system will reject every request that was received less than 10ms after the previous one.
Now the Reblaze admin sets IP Maximum Burst to 20. This means that Reblaze will accept 21 requests (1 original plus 20 additional) per 10 milliseconds. In other words, when a request is received, up to 20 more can be received and accepted within the following 10 ms. If instead 25 total requests are received during that time, the last four requests will be denied with a 503 error.
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:
Before discussing each tab, it will be useful to discuss .
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 ().
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 .
The average and burst limits are more nuanced than is possible to explain in the field labels in the user interface. Please see "" at the bottom of this page for a full explanation.
Name
Description
Add new rule
Creates a new Dynamic Rule.
Activate global simulation mode
The rules currently set to "Ban" will be changed to “Simulated Ban”. This is useful for testing. See also How to Test Dynamic Rules, below.
Test All Rules
Explained in How to Test Dynamic Rules, below.
Set new TTL globally
Sets TTL (described below in Dynamic Rules settings) for all Dynamic Rules.
Help
Brings up a help screen describing the settings for a rule. See also Dynamic Rules settings, below.
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.
Ban will block the violator (available for IP, Cookie, Request Body, Request Header, Country, and ASN), and will add the violator to the Quarantined Banlist.
Simulated Ban does not actively ban the violator; it only adds the violator to the Quarantined Simulation Banlist.
Report Only does not actively ban the violator. If this rule has been included within a Notification Group, then the defined notifications will be sent.
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.
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.
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). |
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 enforces the Allowed HTTP Methods that are defined in the list farther down the page. |
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. |
Parameter | Functionality |
Bad Robots | Identifies and blocks malevolent bots, based on their user agents. This works differently than the default Deny Bot ACL Policy, which uses active challenges to identify bots. Therefore, when active challenges are disabled, this WAF capability can still be used. |
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.) |
Parameter | Timeout |
Header Timeout | How long to wait for the client to send a request header. |
Body Timeout | If the body is not obtained in one read-step, this timeout begins. If the timeout expires and the client has still sent nothing, the Reblaze Gateway returns error 'Request time out (408)'. |
Keep Alive Timeout | The timeout for keep-alive connections with the client. The Reblaze Gateway will close connections after this time. This setting increases server efficiency; it allows the server to re-use browser connections and save resources. When changing this value, special care should be taken; in some cases, it depends on specific cloud vendor and load balancer settings. |
Send Timeout | Specifies the response timeout to the client. This timeout does not apply to the entire transfer but, rather, only between two subsequent client-read operations. Thus, if the client has not read any data for this amount of time, the Reblaze Gateway shuts down the connection. |
Size | Functionality |
Client’s Body Max Size | Specifies the maximum accepted body size of a client request, as indicated by the request header Content-Length. Size in MBs. |
Large Client Headers | Allows additional buffers to be used for large client headers. |
IP Parameter | Functionality |
IP Requests | Sets the allowable average request rate per IP, per second. |
IP Maximum Burst | Sets the allowable additional burst rate per IP, per second. See "Average and Burst Rate Limiting" below, for a full explanation. |
IP Concurrent Sessions | The maximum number of simultaneous sessions per IP. (An HTTP Session ends upon a completion of the response sent.) |
Downstream Bandwidth | Downstream bandwidth limitation per response. Note: The limit is metered in kilobytes, ie. 1250 KB is equal to 10Mbps. |
User Requests | Sets the allowable average request rate per user, per second. |
User Maximum Burst | Sets the allowable additional burst rate per user, per second. See "Average and Burst Rate Limiting" below, for a full explanation. |
User Concurrent Sessions | The maximum number of simultaneous sessions per user. |
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 Web Proxy -> Security Profiles section.
A page for administration of security Profiles
Within the Security section, this tab provides an interface for administering Profiles.
Existing Profiles are shown on the left.
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, 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.
Note that every Profile must include one, and only one, WAF/IPS Policy.
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.
For creating custom matching conditions
Custom signatures are custom matching conditions that you can use in Rules and 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.
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.
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.
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.
How Reblaze scrubs incoming traffic
When Reblaze receives an incoming request, it decides whether to pass the request through to the upstream server, or block it.
This decision-making is done in several stages.
Some of the criteria for the decisions are global. In other words, they apply throughout your entire planet. For example, the settings in the Static Rules section are globally applicable, and do not change depending on the context of the request. They will be applied to all traffic for all resources within your planet.
Conversely, some criteria are non-global, and they do depend on the context. For example, you can assign different security rulesets for different resources or locations within your planet. In other words, you can assign different rules to specific domains, subdomains, folders, filetypes, etc.
These non-global criteria are primarily defined within the Profiles section. They have their own structure, explained in more detail in that section of this Manual (see especially the Profile Concepts page).
Once Profiles are defined, they are available to be assigned to specific resources/locations within your planet. Those assignments are done in the Settings->Web Proxy->Security Profiles section.
Analyzing the values of arguments within incoming requests
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.
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.
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.
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).
Access Control List Policies
The ACL Policies section allows you to define by which Reblaze will scrub your incoming traffic. Once the Policies have been defined, they are assigned to specific resources (e.g., a section of your website) in the section.
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.
To create a new ACL, click the "Create New" button toward the top of the screen, then "ACL Policy." Or, duplicate an existing ACL and then edit the newly-created copy.
As shown above, Reblaze comes with a default set of ACL Policies. (They are designated with the Reblaze logo.)
These Policies are not editable, because they are managed and maintained by Reblaze. 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.)
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:
Class
Company
Country
IP Address
Custom Signature
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 Class, enter one of these strings as the Match Argument:
anon-proxy
bot
cloud
tor
vpn
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).
By adding the following characters as a suffix to the ACL's name, the ACL will behave as follows:
This can have some important and potentially nonintuitive consequences. See the warning below in the discussion of .
In the top right menu you will see this button: . Clicking on it will open the main menu:
if the request is not passed, further processing occurs. See , below.
Learning Resources - Displays the list of all defined in your planet, except for the default ones supplied by Reblaze. Example:
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 feature.
Enter the first few characters of a Signature that you created previously in the 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.)
For an example of using the OC suffix, see .
For an example of using XDeny, see .
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 |
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 | Loadtest OC |
XDeny | "God Mode": bypass the Rule Operation hierarchy. | Global DR XDeny |
Stage
Comments
Quarantines and 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 and Rate Limits
Requests that do not conform to specified size, time, and rate limits are blocked. More information: Static Rules
ACLs
Filtering based on Access Control Lists, including Custom Signatures.
Rate Limits
Enforces rate limits defined for specific locations/resources within the planet. More information: Setting Rate Limits for a Location.
Challenges
Verifies that requests are coming from humans. More information: The Challenge Process.
Content Filtering
Blocks requests that do not conform to specified rulesets for required or disallowed content. This is the location-based filtering described in Filtering on Content.
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 Policies
Blocks requests that do not conform to the WAF/IPS Policy settings.
Over-capacity override: ignore rate limits.
