Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
- Product Manual for v2.18 - Mobile SDK
Previously, adding a new site to Reblaze required the duplication of an existing site, then editing the duplicate. In addition to this option, v2.18 introduces a wizard for easily adding a new site. The admin need only specify:
Its security level (choosing from five possible levels)
Domain name
Backend service
And optionally, an SSL certificate to use.
The New Site Wizard uses various templated security policies to create a configuration, based on the admin's selection of the desired security level. These are also available to the admin for direct selection.
As part of its CDN management, Reblaze now supports AWS.
Admins can now purge CDN caches from the Reblaze UI.
The Mobile SDK now includes programmatic integration with Flutter.
When working with SSL certificates, full PEM information is now available.
A number of bugs were fixed in v2.18.
These release notes are for the Reblaze platform itself.
Release notes for Reblaze's Mobile SDK are maintained separately here.
Flow Control is a new feature that allows users to define a sequence (flow) of submitted requests which, if followed, will be permitted. In cases where the conditions of the sequence are violated, a user-defined Action is initiated.
Checkboxes were added to the Web Filter screen for activating or inactivating security types. They appear on the Web Proxy screen for each of a user’s sites. For example, below, a Default site is shown. Checkboxes at the top of the page can be checked to Activate a security feature or unchecked to switch the feature to Inactive mode. Redis configuration moved to global settings screen Redis configuration was moved from the Rate Limiting page to the Global page.
Dynamic trusted sources can now be configured from Tag Rules that are regularly updated from various lists and providers.
In View Log, when viewing extended event details, new up/down buttons were added at the top of the pop up to improve browsing through the events.
Tag Rules, multiple entries of type header/cookie/args with the same name can be added and matched
Negate ("!") in Tag Rules for attributes now works
Fixed Rate Limit to properly support protocol attribute
Rate limit can redirect based on relative path as well
Fixed user-agent missing verification
Added "max-dpi-length" tag on messages with oversized body
Error pages now work with utf-8
Masked input now inspected too; added masking to headers/cookies
Fixed Event Log issues filtering with special characters like "<" and "&"
A Landing page is now the first screen when logging into Reblaze. It provides a comprehensive summary of stats and activity in 13 areas, from Traffic Volume to Quarantined requests to active and expiring Certificates. You can drill down further into several areas by clicking on them.
Thumbnails of the Dashboard and the View Log appear on the page. Clicking them will open them.
The Dashboard function has changed slightly. Activity for the last 30 minutes is no longer automatically presented. You must now specify the timeframe you wish to see.
Include and Exclude rules can now only be specified using Tags – already existing ones or if needed, newly created ones. Enforcement of Tag rules follows the Origin Response Codes specified for rule.
The Flow Control feature, introduced in Version 2.20 is not available in Version 2.20.2.
Args Analysis – a reminder to Publish appears after a change to Args is saved
CDN Configuration tab – error message now appears when incorrect information is filled for “Add Provider”
Cloud functions – can now see full name for all name lengths. Web Proxy and Tag Rules one line with “…” at the end
Cloud functions – an error message is now received if a function name is not filled
Tag Rules – an error message is now received for a rule is saved with no tag
Tag Rules – ASN list updated
Tag Rules UI – changing an action from default to response no longer highlights the header field in red
View Log - extended attack information now appears in request details for blocked requests
Web Proxy – error message now appears when only a space char is entered at the path name/match
Improved log entry parsing via GraphQL. Individual arguments are now parsed and displayed, making it easier to use them for rule configuration.
Enhanced Arg Analysis engine. Arg Analysis engine now processes requests more quickly.
Mobile SDK now has enhanced abilities to detect emulators.
Rate limits. Fixed an issue where include/exclude values were only partially matched. Now they are exact matched.
UI Timeout has been increased, so that users won’t get timeout errors as quickly.
Dashboard challenge counter now displays correct values.
Redis configuration: Added GCP Israel region.
2020–07–20
- Product Manual for v2.14 - Mobile SDK
Version 2.14 introduces a new tag-based traffic flow for Reblaze. Some tag-based processing occurred within previous versions of Reblaze, but the new system is more powerful, more thorough, and more customizable than before.
Each incoming request receives a number of tags. There are different types of tags:
Automatically generated. Reblaze automatically assigns several tags to each request. Example: the originating ASN.
Externally sourced, based on lists selected by the admin. Example: the admin can instruct Reblaze to assign a tag of “blacklist” if the request is found on the Spamhaus DROP list.
Custom criteria, defined by the admin. Example: tags can be assigned if the request’s header, cookies, or arguments match specified regex patterns.
After tags have been assigned, Reblaze processes the request according to its tags.
The new system is administered through several pages of the UI: primarily Session Profiling, Rate Limiting, and ACL Policies.
Version 2.14 makes Reblaze’s rate limiting capabilities more flexible and powerful.
Attributes: Requests can be rate-limited based on several additional attributes, most notably including the tags discussed above. Multiple attributes can be combined into a single matching condition.
Paired Attribute: An optional “pair with” parameter can be specified, which limits the number of unique matching-condition values that are allowed per time period. More info is here. Example usage: A user is allowed to access a login form from no more than two separate ASNs within one hour.
Include/Exclude Filters: A simpler yet more powerful means of defining which segments of the incoming traffic stream will be monitored for rate-limiting purposes.
Actions: Admins can now specify a wider range of actions when a rate limit is violated.
Flag the request
Modify the request with a custom header for further evaluation by the backend
Block the request with a 503 error
Block the request with a custom response and error code
Block the request and redirect to a specified URL
Issue a challenge to verify that the user is a human
Ban the requestor and block all subsequent requests for a specified time
The new system incorporates and simplifies many capabilities (whitelisting, blacklisting, and more) that were previously configured across multiple pages of the UI. Other UI improvements have been made as well.
Admins can now supply Cloud Functions: custom Lua code that can be executed during request processing. Different functions can be assigned to different locations/URLs. A function can be configured to run at four possible times:
Upon receipt of a request, before Reblaze processes it
After Reblaze has finished processing the request, before it is sent to the backend
Immediately after Reblaze receives a response from the backend
As the last action before Reblaze sends the backend’s response to the client
Cloud functions are a powerful tool for extending Reblaze’s functionality. Future releases will include a variety of pre-written functions and templates.
The UI now provides the ability to specify ranges of IP addresses which are trusted for providing forwarded IP addresses in the X-Forwarded-For (XFF) header: for example, the load balancers in front of Reblaze, or a CDN.
Previously, the UI offered a variety of Cache Operation Modes for customizing Reblaze’s caching behavior and the instructions sent to the client. These capabilities have been moved to Cloud Functions.
Reblaze now offers more precise control over a number of capabilities. The list includes:
Active Mode vs Reporting Mode: Admins can separately enable/disable enforcement of ACL Policies, Rate Limiting, and WAF processing for individual URLs/locations.
Frontend Timeouts and Static Rate Limits: Previously, these were planet-wide settings; they are now configured on a per-application basis.
Backend Configuration:
“Backend services” (groups of origin/upstream servers) can now be defined. Their parameters (transport protocol, load balancing stickiness, etc.) are configured separately
Individual locations/URLs within an application can send traffic to different backend services.
Mobile SDK: The UI now provides the ability to customize various parameters for users of the Mobile SDK, including the secret key, verification variable, and more.
Admins can customize the content of pages returned to requestors when requests are rejected or blocked, for a variety of different error codes.
Some features (such as Dynamic Rules) have been deprecated, but are still being supported for now. It is recommended that admins implement all future configurations using the new tag-based system.
https://openresty.org/en/changelog-1015008.html
Args analysis: Fixed an Out of Memory error.
Dashboard: Fixed an issue that prevented the display from being filtered for unrecognized host headers.
Dashboard: Fixed an issue where the graphed time period did not match user-selected time frame.
DNS: When an app is deleted from Reblaze, its DNS record is now deleted as well.
Domains: Fixed an issue validating apex domains with suffixes longer than three characters.
Logs: Fixed an issue where headers/cookies/arguments were not being pushed to the logs.
Mobile: Fixed an issue where invalid cookies were not handled correctly when the user changes their IP address during a session.
Passive bot challenges: fixed an issue where error code 500 was being returned.
Publishing: Fixed an issue where success or failure of a Publish action was not being shown.
Redis: Optimized connection pools to eliminate latency in high-traffic situations.
Various: Long lists are now alphabetized (e.g., DNS records).
- Product Manual for v2.16 - Mobile SDK
Reblaze's tag-based traffic processing has several enhancements.
Additional external threat intelligence sources have been integrated into Reblaze's Tag Rules.
A Tag Rule includes a list of criteria; if a request matches them, the tag will be attached to it.
Previously, the criteria list had one comparison condition (AND or OR), applied throughout the list. For v2.16, admins can now group the criteria into sections. Each section can have its own internal comparison condition, and the sections have a separate condition applied between them.
Reblaze's tag-based traffic processing can now be configured globally.
Tags are defined in a UI page that was previously called Session Profiling. For v2.16, it has been renamed to Tag Rules.
In v2.14, the actions to enforce for each tag are defined via ACL Policies. In turn, ACL Policies are assigned to web application paths/locations via Security Profiles on the Web Proxy page.
This workflow is useful for granular processing of tags, and it is still available. However, it can be inconvenient in situations where granularity is not necessary, and an admin wants to define an action that will be enforced everywhere for that tag. For example, an admin might want to automatically reject all requests that came from an IP on the Spamhaus DROP list.
To support this, v2.16 adds an Action field to each Tag Rule. When an action is defined here, it is applied globally for that tag throughout the planet, to every site, web application, etc. Every incoming request which has that tag will have that action performed on it.
Reblaze has new capabilities for administering SSL certificates. SSL for cloud load balancers previously had to be managed outside of Reblaze; now the Reblaze UI provides the ability to attach/change/detach certificates to AWS and GCP load balancers.
Reblaze admins can now create user accounts with a variety of access levels. In ascending order of permissions, they are:
Viewer (can see the Traffic section, i.e. the Dashboard and View Log)
Editor (has Viewer permissions, and can also configure security rulesets and policies)
Organization Admin (has Editor permissions, and can also manage users)
Reblaze Admin (has Organization Admin permissions, and can also access some additional settings)
Also, Reblaze users can now receive OTPs (One Time Passwords) via email instead of SMS.
Reblaze now supports SSO.
A flexible UI is provided for integrating with various SAML2 providers.
Step-by-step instructions are provided for using Okta and Microsoft Azure SSO.
Previously, Rate Limits were linked to URLs via Security Profiles on the Web Proxy page. For v2.16, they can also be linked while editing the rule itself. When a new Rate Limit is created and the changes are saved, a Links to URLs section appears at the bottom of the UI.
The Rate Limiting UI now has a tab to provide Redis Management, which previously had to be done manually.
Various revisions were made to show more information on the screen, ease navigation, and reduce the number of clicks to perform operations.
A number of pages within the UI (including Tag Rules, Rate Limiting, and Cloud Functions) are now using a grid-based interface. A list of entries is presented in a consistent format, and users can drill down into individual entries for expanded details or editing. A walkthrough of the grid structure is here.
In many places within the UI, an admin must save changes, and then publish them. In v2.16, after changes are saved, a popup reminder will now appear as a reminder to publish the changes as well.
A number of legacy bugs were fixed in v2.16.