Security Profiles
Location-based security settings, and Report Only mode
Last updated
Location-based security settings, and Report Only mode
Last updated
In this section, you can:
Define different locations and/or resources within your planet. For each one, you can:
Assign a security Profile. Profiles are defined elsewhere in the interface: this section is where you assign them and make them active for different locations within your planet.
Configure rate limiting (optional).
Configure content filtering (optional).
Set a site/application into Report Only mode (usually used only for testing).
The top right part of the screen shows the site that is currently being displayed for editing.
On the main part of this page, the various defined sections of the selected site are listed. The Default entry is always present.
Each entry is defined as follows:
Item | Description |
Name | A descriptive label that you choose. |
Matching Path | Defines a Location, i.e. everything within the planet that matches this Path. This entry uses Pattern Matching Syntax. |
Profile | The Security Profile assigned to this Location. |
More | Configures rate limiting for this location, explained below. |
To add a new Location, fill out the blank entry at the bottom and click Add. To delete a Location, click the Remove link next to its name.
Once you have defined a Location, you can assign a Security Profile to it.
Within each Location entry, the Profile field is autocomplete. Typing the first few characters of a Profile name will populate the list appropriately, then select the desired Profile.
Once you have defined a Location and assigned a Profile to it, you can also (if desired) configure rate limits and content filtering for it.
This is synchronized protection: you can limit the request rate, according to any desired parameter, per URL or section, across the entire cluster, while keeping all the proxy servers in sync.
If you need to whitelist an IP, Country, or ASN from being subject to this rate limiting, see Whitelisting and Creating Exemptions from Rate Limits.
At the end of the Location's entry, click on "More" to open the Location Settings dialog.
This displays whatever limits have been defined for this location, and another line to add a new limit.
Settings you make in this dialog will only apply to the location associated with the "More" button that opened the dialog.
Each limit defines the number of requests allowed for a specific time period, defined in the TTL field. When a request is received that matches one or more Keys, an internal TTL timer starts, and Reblaze begins counting. If the Rate Limit is reached before the TTL period has ended, subsequent requests are blocked until the current TTL period ends.
Here are the possible attributes:
Field | Description |
Name | A name that will describe the limit. (This will be shown in the View Logs for any requests that are blocked by this limit.) |
Rate Limit | Sets the threshold for the requests. This is the number of requests allowed per the time period defined in the TTL field. |
Key Composition | The value for which Reblaze searches in a request. Explained in Key Composition Values below. |
TTL | The time period in seconds until the request count will be reset. |
When counting the number of requests, Reblaze searches for the value of a Key. Each value has its own cumulative count.
Combining Keys into one rate limit (by entering their names together, separated by a space) allows for more granularity. Examples:
remote_addr : Each IP will have its incoming requests counted, and evaluated separately against the Rate Limit.
remote_addr uri Each combination of IP and URI will be counted, and evaluated separately against the Rate Limit. In other words, Reblaze will count the requests from each IP for each URI, maintaining separate cumulative counts for each combination. So, if a specific IP asks for multiple pages within a site, it will be allowed; but if it asks for the same page too many times, it will be blocked.
Here are the possible values for Key Composition.
Value | Description |
remote_addr | The request's source IP address. |
request_uri | The request URI. |
http_HeaderName | Arbitrary request header field; the last part of a variable name is the field name converted to lowercase with dashes replaced by underscores. |
arg_ArgName | The name of an argument in the request. (See warning below.) |
cookie_CookieName | The name of a cookie. |
request | The full original request line (including the query string). |
Custom | See below for explanation: Advanced String Manipulation in the Key Composition. |
When using an argument in a rate limit (as mentioned in the arg_ArgName description above), the argument becomes mandatory. Any request received without the argument will be blocked.
You can use Lua to manipulate strings in the Key Composition field. Use the tostring() function to return a string into the field.
Usually there will also be a substring operation. This should come after the tostring(). Example: tostring():sub(1, 20)
Inside the tostring(), there must be a valid NGINX variable, usually from ngx.var or ngx.ctx. The full variables list can be found here.
Examples:
Substring - Suffix last 5 char :
tostring(ngx.ctx.args_table['foo']):sub(-,5)
Substring - Prefix from 1st char to 5th char: tostring(ngx.ctx.args_table['foo']):sub(1,5)
If you need assistance with this feature, please feel free to contact support.
For each Location, along with defining rate limits, you can also set up content filtering.
This is a powerful feature that allows you to require, or deny, exact values for specific headers, cookies, and arguments, based on regex matching.
Content filter example
The Filters do not have user-assigned descriptions or names (the Name field has a different meaning, described below) When a request is blocked based on the Content Filter, the request appears in the logs with a custom description constructed from the Filter's parameters.
Parameter | Comments |
Action | Required to block if a match from the specified Pattern is not found. Deny to block if a match is found. |
Data Item | The source of content to examine. Options: Argument, Header, Cookie. |
Name | The name of the Data Item from which to get the content. |
Pattern | The matching conditions, specified as regex. |
To add a new Filter, enter values into the empty row in the list and click Add. Existing Filters can be deleted by clicking Remove.
When you are finished configuring rate limits and content filtering for a location, click Done. After you have edited all Locations, Save Changes and Publish Changes.
At the bottom of the screen, the Report Only switch allows you to test your Reblaze configuration. Enabling this setting means that Reblaze will not block any traffic for this site/application; it will merely report on what it would have blocked otherwise. This is useful during a new deployment, since you can fine-tune and optimize your settings while avoiding false positives.
This setting applies to the site/application currently being displayed. It is the same setting that is available for this site/application on the Planet Overview page. See the warning there about this setting.
