A fundamental part of traffic evaluation
Version 2.14 has introduced a significantly changed workflow for Reblaze's traffic processing. Some of the features in this section of the UI are included mostly for backwards compatibility. Specific information is noted in the discussion of each feature.
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.
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.
In previous versions of Reblaze, a Profile would include one WAF/IPS Policy. Now, a WAF Policy is assigned directly to each resource/location in the Security Profiles section of the Web Proxy page.
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.
Access Control List Policies
The ACL Policies section allows you to define Policies and Rules 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 Web Proxy 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:
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 have been deprecated. Session Profiling 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.
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:
Administration of built-in Security Policy 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.
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:
For creating custom matching conditions
Starting with version 2.14, this feature is being replaced with , which is more flexible and has 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 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.
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).
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.
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 instead.
Before discussing each tab, it will be useful to discuss .
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 .
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 section within the tab.
An explanation and some examples are here: .
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
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 |
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 |
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.) |
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.
