Loading...
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.
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.
Stage
Comments
Pre-Processing Cloud Functions
Quarantines & Dynamic Rules
Static Rules & Rate Limits
Session Profiling
ACL Policies
Rate Limits
Challenges
Argument Analysis
WAF/IPS
Post-Processing Cloud Functions
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 Dynamic Rules and Rate Limiting 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:
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).
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".
Defining how Reblaze processes your traffic
This section defines the parameters with which Reblaze scrubs traffic.
The user interface is divided into these sections:
Dynamic Rules: Thresholds for banning sources of hostile traffic.
Quarantined: The "warehouse" of traffic sources that are currently banned. This contains blacklists and whitelists, allowing you to manually control quarantines when necessary.
Profiles: Creation of security rule sets for assignment to specific resources, locations, and applications.
Args Analysis: Settings for allowing requests based on their arguments, in a procedure that occurs before normal WAF inspection and filtering.
Session Profiling: Settings for assigning tags to incoming requests.
Rate Limiting: Settings for rate limits and the actions that will be performed when a rate limit is violated.
Cloud Functions: 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 "Security Concepts" 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.
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.
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.
For creating custom matching conditions
This feature is being replaced with , 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.
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.
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).
Access Control List Policies
The ACL Policies section allows you to define by which Reblaze will process your incoming traffic. Once an ACL Policy has been defined, it is available to be part of a . 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 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.
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