Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This section defines the Services that Reblaze will protect. In other words, these are the destinations to which Reblaze will send the (legitimate) traffic it receives.
Each Service can receive traffic for multiple web applications, and for multiple resources/locations within each web application. These assignments are made on the Web Proxy page.
At the top of the window, the title on the left displays the Service currently being displayed for editing. The pulldown on the right allows the selection of a different Service.
To add a Service, click on the "Add" button (the plus sign).
When editing is complete, click on the Save button and then publish your changes.
For a single Service, you can define multiple endpoints. Within them you can:
Enable and configure load balancing, weighting and distributing traffic across your primary endpoints.
Define backups hosts, to which Reblaze will failover your traffic when your primary hosts aren’t available.
Take hosts offline for maintenance by ticking a single box in the interface.
Adding and deleting endpoints from this list is straightforward. To add an endpoint, click on the Add button (the plus sign) and fill out the new entry. To delete an existing entry, click on the delete link next to that entry.
The settings for each endpoint in the list are as follows.
The Name field defines the description for this Service within Reblaze.
Use HTTP/1.1: selecting this can speed up communication, via the use of connection pooling.
Transport Protocol: this configures the communication between Reblaze and the backend.
Sometimes an application requires a user to be connected to the same Reblaze instance and backend endpoint throughout the session. Reblaze can ensure that this occurs, and can do so using a variety of methods.
To remove a Service from Reblaze, click on the button at the top of the window.
Attribute
Description
Host
The name or IP address for each endpoint that Reblaze protects. This can be a normal web server, or it can be a load-balancer. Note that Reblaze also provides load-balancing capabilities in its own right, as discussed below.
HTTP Port
The HTTP port for the server.
HTTPS Port
The HTTPS port for the server.
Weight
The relative weight of each server for load-balancing purposes. Reblaze distributes traffic with a round-robin sequence, according to these weights. For example, if two servers are both set to 'weight=1', they will receive equal amounts of traffic. If the first is set to 'weight=3' while the second is set to 'weight=1', the first server will receive three visitors for every single visitor that the second server receives.
Max Fails
The maximum number of failed communication attempts that are allowed for this server. Once this number of failures occurs, Reblaze will consider the server to be inactive. If other servers are available, Reblaze will failover the traffic to them. If this was the only server available, Reblaze will return an error to the client (either 504 Timeout, or 502 Bad Gateway).
Fail Timeout
When a server fails, this is the length of time that Reblaze will wait before trying to send traffic to it again. Example: "10s" indicates a fail timeout of 10 seconds. This field uses TTL Expression Syntax.
Is Down
When this box is checked, Reblaze will not attempt to communicate with this server. This allows you to easily take a server offline for temporary maintenance or some other purpose.
Option
Value
Per Request
This is the default mode. Incoming HTTP requests will go over HTTP, and incoming HTTPS requests will go over HTTPS.
HTTP Always
All communication between Reblaze and the backend will be over HTTP. (This mode should not be used unless Reblaze runs within the same cloud as the backend.)
HTTPS Always
All communication between Reblaze and the backend will be over HTTPS.
Port Bridge Mode
Reblaze will use the same port as the incoming request. This is not limited to ports 80 and 443; Reblaze will use whatever port was specified. Note: this mode is not available when more than one host is defined.
Stickiness Model
Action
None
This is the default. Requests will be distributed across the endpoints in a round-robin fashion, according to the Weights assigned to them (described above in the Endpoint Definitions).
Auto Cookie
Reblaze will automatically generate a cookie to maintain the session on the same endpoint.
Custom Cookie
You can provide the name of the cookie that Reblaze will use to track the session, e.g. one generated by an AWS or GCP load balancer.
IP Hash
Routing will be determined from a hash of the client and destination IP addresses.
Least Connection
Requests will be sent to the endpoint with the fewest number of connections.
Planet configuration and other parameters
The Settings section has an extensive number of configuration values for Reblaze. Many of these are parameters that once set up, usually will not change during your use of Reblaze.
There are several sections in this part of the interface.
Web Proxy contains parameters for the overall architecture of Reblaze and its interaction with the downstream clients and the upstream network. It includes settings for proxy behavior, load balancing, failover, and more. It is also where you assign Security Profiles to specific areas of your website.
Backend Services is for managing the services that Reblaze is protecting.
Error Pages is for defining the error pages served to traffic sources.
SSL Management is where SSL Certificates are uploaded and managed.
DNS is where DNS records are configured.
CDN allows you to purge CDN caches.
Planet Overview provides the abilities to add/manage sites to your planet, generate SSL certificates, and publish changes that were made elsewhere in the interface.
Global is for managing planet-wide settings.
Account is where your user account settings are managed.
Administration of certificates
This section allows you to manage your SSL Certificates. You can create, edit, attach, and remove certificates. The certificates themselves can be uploaded and stored into Reblaze's cloud, or a cloud load balancer.
If you are reading this Manual as part of an initial evaluation of Reblaze, and if you have large numbers of certificates to manage, you should know that Reblaze treats certificates differently than most other security solutions.
It's not unusual for some companies (especially SaaS platforms) to have dozens or even hundreds of certificates to manage. Unfortunately, most security solutions treat each SSL Certificate as a separate "site," and they charge their customers on a per-site basis. Thus, these solutions can be extremely expensive.
Contrary to this, Reblaze does not treat certificates as sites. A certificate is merely a certificate. For customers with tens or hundreds of certificates to manage, Reblaze's monthly pricing can be one or two orders of magnitude less than its competitors'.
The SSL Management interface is split into 2 tabs: Load balancers and Certificate store.
The Load balancers list shows the load balancers for the current site, and the certificates that are attached to them. Certificate store is where certificates are managed.
For each load balancer shown in the list, the displayed parameters are:
Table 1: Max number of certificates depending on the load balancer type
Table 2: Cloud vendor regions
The Filter by name input control at the top accepts regular expressions, and quickly filters the list to show matching entries.
Selecting an entry in the list expands it to show that load balancer's details: a default certificate, and a list of any additional attached certificates.
The expanded list provides several buttons to perform administrative actions.dnnd
To change the default certificate for the load balancer, select the Set default button next to the name of the desired certificate.
To remove a certificate from the list, select the Detach button next to its name.
To attach a certificate from the certificate store, select Attach certificate. See discussion below.
Additional certificates can be attached to a load balancer until it reaches its full capacity, i.e. the maximum number of certificates shown in Table 1. (Full capacity is indicated when the "# Of Certs" column contains two similar numbers, e.g., "15 / 15". Also, the Attach certificate button will change to the message "You have reached the max certificates quota for the load balancer.")
To attach a certificate, select the Attach certificate button. This will open a modal window with a list of unattached certificates from the certificate store:
The Filter by name input control at the top accepts regular expressions, and quickly filters the list to show matching entries.
To attach a certificate, press the Attach button next to its name. The certificate will disappear from this list ail appear in the list of the certificates attached to the load balancer (see Figure 2).
This tab displays certificates according to the site to which they are attached.
The Filter by name input control at the top accepts regular expressions, and quickly filters the list to show matching entries.
For each entry, the displayed parameters are:
Certificates are loaded console. After that they can be loaded to a cloud provider. The AWS/GCP columns indicate which provider has the certificate. It can be none, one, or both.
Reblaze provides the capability to generate an SSL Certificate for free using the Let's Encrypt service. This can be done using the "Generate Certificate" button on the Planet Overview page.
SSL certificates can be added to Reblaze in two ways:
Uploading a PFX file.
Manually entering the certificate information.
In both cases, begin by clicking the "+" button. This dialog will appear:
To upload a PFX file, select "Extract pfx file." Otherwise, enter the Private Key, Certificate body and Intermediate chain values into their respective text boxes.
To remove an existing certificate, click on its trash icon to the right of its entry in the list. You can delete a certificate if it's not linked to a site. However, you cannot remove the last certificate on a load balancer.
To edit a certificate, click on its edit icon to the right of its entry in the list. This dialog will appear:
The following options are offered:
Attach to application - Select an application/site and attach it to this certificate.
Replace existing certificates - When this is chosen, a "Select Certificate" dropdown list will appear. Selecting one and then clicking "Save" will result in all sites/applications being transferred from the selected certificate over to the certificate you're currently editing.
Auto Replacement by Let's Encrypt: See discussion below.
Download PFX: Download the certificate information as a file in PFX format.
When managing certificates through one of these options (except for "Download PFX"), you must click the Save button to preserve your changes.
Let's Encrypt is a free certificate authority service. Reblaze integrates with it, and offers this service by default.
Once a day, Reblaze will check each application it protects. If that application's certificate is going to expire in the coming week, and itsAuto Let's Encrypt Replacement option for that certificate is enabled, Reblaze will generate a new certificate using Let's Encrypt, and will attach all of its sites to the new certificate.
Parameter
Description
Name
A unique identifier for use elsewhere in the interface.
#Of Certs
Number of certificates attached to the load balancer / Max number of certificates can be attached to a load balancer of this type (as shown in Table 1 below)
Cloud Provider
AWS, Azure, GCP or a custom cloud provider.
DNS Name
The balancer's dns name.
Region
The cloud vendor region name (from Table 2 below)
Type
Load balancer type (from Table 1 below)
Load balancer type
Max number of certificates
gcp
15
application
25
classic
1
GCP
AWS
Azure
Digital Ocean
asia-east1 asia-east2 asia-northeast1 asia-northeast2 asia-northeast3 asia-south1 asia-southeast1 asia-southeast2 australia-southeast1 europe-north1 europe-west1 europe-west2 europe-west3 europe-west4 europe-west6 northamerica-northeast1 southamerica-east1 us-central1 us-east1 us-east4 us-west1 us-west2 us-west3 us-west4
us-east-2 us-east-1 us-west-1 us-west-2 af-south-1 ap-east-1 ap-south-1 ap-northeast-3 ap-northeast-2 ap-southeast-1 ap-southeast-2 ap-northeast-1 ca-central-1 eu-central-1 eu-west-1 eu-west-2 eu-south-1 eu-west-3 eu-north-1 me-south-1 sa-east-1
eastasia southeastasia centralus eastus eastus2 westus northcentralus southcentralus northeurope westeurope japanwest japaneast brazilsouth australiaeast australiasoutheast southindia centralindia westindia canadacentral canadaeast uksouth ukwest westcentralus westus2 koreacentral koreasouth francecentral francesouth australiacentral australiacentral2 uaecentral uaenorth southafricanorth southafricawest switzerlandnorth switzerlandwest germanynorth germanywestcentral norwaywest norwayeast
NYC1 NYC2 NYC3 AMS2 AMS3 SFO1 SFO2 SFO3 SGP1 LON1 FRA1 TOR1 BLR1
Parameter
Description
Name
A unique identifier for use elsewhere in the interface.
AWS
Whether the certificate is loaded to AWS (see explanation below).
GCP
Whether the certificate is loaded to GCP (see explanation below).
Expiration Date
When the certificate expires.
Linked To
This field is populated when this certificate is chosen for use in the Proxy Settings section.
Administering your entire planet
The Planet Overview page enables the following actions:
Add and manage a site/application.
Generate an SSL certificate for a site/application using the Let's Encrypt service.
Note that in the discussion below, "site" and "web application" are synonymous.
This section allows you to add and modify web applications. It does not provide the ability to delete them.
Deleting a web application is done at the bottom of the Web Proxy page.
Creating a new web application is done in one of two methods:
Via the Create New Site Wizard
Duplicating an existing one, and then editing the one that is created.
Click the button on the right top corner of the table so the popup will appear.
The Create New Site Wizard helps to create a new site with predefined settings. It will have predefined ACLs, Security Profiles, and Rate Limits embedded into the new site and paths, depending on the chosen security level.
Security levels:
The available protection components are:
After the site is created the page will be redirected to a Web Proxy editing form.
Select an existing site that is the most similar to the one you want to add.
Select its "Duplicate Application" button.
This will clone the site and create a new one with identical settings, which you can then edit.
Clicking on a site's name will open it in the Web Proxy page, where it can be edited.
Reblaze integrates with Let's Encrypt to provide free SSL Certificates.
By clicking on the "Generate Certificate" button at the end of an entry in the site list, you can:
Generate a new certificate without attaching it to a site
Generate a new certificate and immediately attach it to a site. If the site has an existing certificate, it will be replaced by the new one.
In either case, this is the dialog you will see:
Just choose the button for the activity you want.
Purging of caches
Sometimes it is beneficial to purge a Content Delivery Network (CDN) cache. Reblaze provides this ability on this page.
You can purge a single cache or multiple caches, across one CDN or multiple CDNs simultaneously. Both AWS and GCP CDNs are supported.
Initial configuration of the CDN provider(s) within your planet is done by Reblaze personnel. Please contact support for assistance with this.
Once initial configuration is complete, purging becomes available on this page.
The top part of the window shows a list of caches to purge.
To add an entry:
Select the + button.
In the Host field, enter the domain. If you leave this field empty, all hosts (i.e., all sites/applications shown in the Planet Overview) will be purged.
In the Path field, enter a relative path (such as /*) or a fixed path (such as /static/image.png). If you leave this field empty, all caches will be purged.
Select the add button at the end of the entry.
When the cache list has at least one item, the Purge button becomes available.
When there is more one CDN provider configured, by default Reblaze will purge all of them.
If instead you wish to select a certain CDN provider, check the Select CDN manually checkbox. A dropdown list will appear where you can select the provider.
Selecting the Purge button will send purge commands to the selected provider(s). The cache list will be moved to the PURGE STATUS list at the bottom of the window, and the status for each purge will be shown.
The completion time will vary by the provider. To update the statuses in the list, select the Refresh control at the top right of the list.
Once you have launched a purge, you can exit this page. The purge(s) will run in the background; you do not need to wait here for them to complete.
The entries in the status list will be retained for one week.
Whole planet settings
The Global parameters are planet-wide settings. This page has two sections: Site Settings and Notifications and Alerts.
There are global settings that will be applied to all Sites.
Trusted Sources
The ranges of IP addresses which are trusted for providing forwarded IP addresses: for example, the load balancers in front of Reblaze, or the CDN.
When a Dynamic Rule is violated, Reblaze can send immediate alerts to a list of one or more email addresses and hooks (e.g., Slack).
In addition, a cumulative report of the previous week's violations can be sent to one or more email addresses.
This section defines one or more Notification Groups for these notifications. Clicking on the "+" button on the right will display this dialog:
The settings for a Notification Group are as follows.
An existing Notification Group can be edited by clicking on its listing, or deleted by clicking on the trash button at the right end of its listing.
An optional but recommended capability
DNS Management is an optional capability. Your DNS management does not need to be done within Reblaze, but it can be.
Reblaze provide a full DNS service, based on AWS Route 53. Reblaze also supports DNS on other cloud platforms, but they are not yet supported natively within the Reblaze interface. If you need this capability within your deployment, contact support for assistance.
Many site administrators use their domain registrars as their DNS providers, but this is often a poor choice. In general, domain registrars do not place a high priority on DNS security (since DNS management is not a primary part of their business model), and attackers frequently target their DNS servers. A successful DNS poisoning attack can result in your site getting hijacked.
Managing your DNS through a secure platform like Reblaze is a better choice. This ensures your full stack is protected—even the DNS layer.
A full explanation of DNS setup is beyond the scope of this Manual. The discussion below is an overview of Reblaze's capabilities and interface. Please contact support if you need assistance for your particular situation.
Related video: DNS Training
You can manage millions of DNS zones and records using the Reblaze interface.
The DNS Management feature of Reblaze is for both external and internal DNS administration. Internally, Reblaze maintains a special name for every planet (planetname.d1.rbzdns.com), and every domain protected by Reblaze is mapped to an entry in this domain. This system can also be used for domains accessible externally.
To display existing records, a "search" feature is provided at the upper left.
This will control the DNS entries being displayed, by filtering them according to the search value and selected record type.
To add a new DNS entry, click on the "New" button. The following dialog is displayed:
Once a record has been created, it can be deleted (via the trash icon shown to the right of its entry in the list) or edited (via the blue edit icon shown to the right of its entry in the list).
Reblaze supports the following types of DNS records:
Expected formats for the respective values are given below.
The value for an A record is an IPv4 address in dotted decimal notation.
Example:
example: 192.150.2.1
The value represents an IPv6 (128bit) address in a colon separated notation.
Example:
20541:0da8:85a3:0:0:8a2e:0370:7334
A CNAME value is a domain name.
Example:
www.sample.com
Each record includes a priority (integer) and an email server domain name. It is possible to add multiple records.
Example:
10 mail1.sample.com
20 mail2.sample.com
Delegates a DNS zone to use the given authoritative name servers. (It is possible to include multiple name servers.)
Example:
ns1.amazon.com
ns2.amazon.org
ns3.amazon.net
ns4.amazon.co.uk
Includes a text record. (Enclose the text in quotation marks. Multiple entries are allowed.)
Example:
"test1"
"test2"
SPF records were formerly used to verify the identity of the sender of email messages. It's now deprecated, and a TXT record should be used instead.
Example:
"v=spf1 ip4:192.168.0.1/16-all"
A generalized service location record, used for newer protocols instead of creating protocol-specific records such as MX.
The syntax is based on the following: [Priority][Weight][Port][Domain Name]
Example:
2 12 5050 sip-server.example.com
3 15 5060 network.example.com
Pointer to a canonical name. Unlike a CNAME, DNS processing stops and the name is returned.
Example:
www.example.com
This section allows you to customize the error messages that are displayed to users. There are separate tabs for the most common types of errors, with the HTTP status code for each one. The defaults can be used, or you can customize the content and/or contact details as needed.
A straightforward use of this feature is to enter text into the fields. More advanced usage (for example, iframes) is also possible.
Select the web application to edit by using the pulldown on the upper right. When you have completed your edits, select the Save Changes button on the upper right, and then .
Changing user settings
The Account Settings page allows you to manage your Reblaze user accounts.
From this tab, you can reset your password, name, and phone number.
Reblaze uses 2FA (two factor authentication). There are several options for sending an OTP when you login:
If only an email address is provided, the OTP will be sent via email.
If a phone number is provided, the OTP will be sent over SMS message.
This tab also offers a personal API key, to be used in all requests to the Reblaze API.
This tab allows you to manage users that are attached to your organization. It is only available to users with administrator permissions.
An admin can:
Create a new user
Edit an existing user
Reset a user's password
Delete a user
When a user account is being edited, this will appear:
The available Access Levels are:
Organization Admin: has all Editor permissions, and can also manage users via the Users Management page.
Reblaze Admin: has all Organization Admin permissions, and can also edit and view the Notes, Init and Run pages.
This tab allows SSO to be configured so that users have the ability to log into Reblaze with their Okta or Microsoft accounts.
Configuration options will vary depending on the type of account.
Go to https://{YOUR ACCOUNT}-admin.okta.com/admin/apps/active
Click Add Application → Create New App
Choose Platform: Web, Sign on method: SAML 2.0
Single sign on URL:
RBZ_SSO_ASSERTION_URL env var. Value should look like: https://{CUSTOMER_DOMAIN}/sso/saml20/signon.
Audience URI (SP Entity ID):
RBZ_SSO_AUDIENCE_URL env var. Value should look like: https://{CUSTOMER_DOMAIN}/sso/saml20/audience
Attribute Statements:
emailaddress: user.email
displayname: user.firstName + " " + user.lastName
groups: appuser.rbzgroups
In order to pass Admin group ID we need to add custom attribute to the user groups. Directory > Profile Editor > Apps > Click on Profile
Next step will be to map it.
Directory > Profile Editor > Apps > Click on Mappings
4. Assign the application to users
Create user groups for two possible access levels: Admin and Read-Only access.
Assign users to it. Group name is the string you need for RBZSSOSAML2_ADMINGROUP or place the group name into the Reblaze console SSO settings.
And in your just-created Application settings:
On the assignment step, a value will be required for the custom attribute which we configured before. For the admin group the value will be same as on RBZSSOSAML2_ADMINGROUP, while for the read-only group value it can be anything else.
RBZ_SSO_IDP_ISSUER:Go to Applications, choose yours, Sign On tab, click on View Setup Instructions
There you'll find Identity Provider Issuer:
2. Choose + New Application → + Create your own application:
3. Choose option Integrate any other application you don't find in the gallery (Non-gallery) (this option will create SSO app):
4. Go to Single sign-on section and choose SAML:
5. Set up appropriate links:
RBZ_SSO_IDP_ISSUER should be provided by a customer and have to be unique for the customer’s SSO applications. The best option is to just use something like: https://customer_domain.com?sso=123. (the IDP Issuer field (in the console) should be identical to the Identifier field (in Azure))
6. Get Metadata XML link and add to RBZ_SSO_META_URL environment variable:
7. Setup user.groups in User Attributes & Claims, so it send all groups related to the user:
Click on “+ Add a group claim”, choose:
All groups
Source attribute: Group ID
8. Add a user as a member of the application:
9. Get admin group ID from Azure and put it into RBZ_SSO_ADMIN_GROUP environment variable:
Go to Azure Active Directory → Groups, create a group.
Object ID is the string you need for RBZ_SSO_ADMIN_GROUP or place the group ID into the Reblaze console SSO settings:
And assign a user to the group:
When you deploy Reblaze to protect your web assets, it acts as a proxy; it receives requests from clients (web visitors, mobile/native app users, etc.), blocks hostile traffic, and passes legitimate requests to your servers.
The Web Proxy page defines how Reblaze behaves in this role. It contains these sections, from top to bottom:
For a cleaner interface, the lower sections are collapsed by default. They can be expanded using the ⌵ control to the right of each section heading.
After making edits to this section, them to the cloud.
At the top of the page, the title shows the web application currently being displayed below for editing.
The pulldown on the right selects the web applications to edit. The save button on the far right saves the edits that have been made to the current application.
This section shows a list of URLs/resources within the application, and defines Reblaze's behavior for them.
Every incoming HTTP/S request targets a specific URL. Reblaze finds the best match for that resource in this list, and applies the security configuration defined for it.
The "best match" is determined by regex evaluation. (The order in which the Match strings are listed in the interface does not matter.) If no matching resource definition is found, Reblaze applies the rulesets from the default resource definition (shown in the screenshot above as the fourth entry).
An HTTP/S request which passes all security tests will be forwarded to the Backend Service defined for the requested resource.
This section is where security rulesets are assigned to resources within your site, application, API, etc.
To edit a definition, click on the "expand" button at the end of its listing. The following window will appear.
The entries in this window correspond directly to the various fields discussed earlier in the definition listing.
Checkboxes for activating or inactivating security types 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.
Inactive/Active – Site Level
The table titled Path Level Security Profiles is seen in the above screen. Note the five checkboxes to the right of each of the column titles relating to a security feature.
Checking the box indicates that on this site, the feature is Active for all the rules associated with the paths of the feature in question.
Unchecking the box indicates that on this site, all the rules associated with the paths of the feature in question are now Inactive.
Use case: Among others, a user may wish to temporarily disable a security feature while system behaviors are examined.
The rules of a feature that has been made Inactive will still be checked but no action will be initiated even if rules have been violated. Only a Tag action will be initiated, enabling the user to see, in the logs, which requests would trigger an action.
Inactive/Active – Path Level
Similarly, specific paths associated with a security feature can be inactivated.
To inactivate or activate a security profile on the Path level, click on the rule that appears in the Path Level Security Profiles table. This will expand the rule so its settings are visible. Any of the five security features can then be inactivated or activated by checking the Active Mode checkbox that appears in the security feature’s section. A checked box is Active. An unchecked box is Inactive.
If the security feature for a particular path has been made inactive, the relevant column in the Path Level Security Profiles table, will display text in red.
Rules associated with a specific Path that is Inactive will still be checked but no action will be initiated if rules have been violated. Only a Tag action will be initiated, enabling the user to see, in the logs, which requests would trigger an action.
This section configures Reblaze's behavior as the frontend for traffic.
This section (shown above in the previous screenshot) configures Reblaze's communication with the backend.
This section lists the signatures of recognized applications and available remote profiles.
App Signatures lists the SHA-256 digests of recognized certificates.
When uploading the fingerprint to the Reblaze Console, make sure that it contains hexadecimal characters only, in lowercase, without spaces.
Any number of signatures may be 'Active' at given time. While debugging the app on emulator, it will present a special signature "abadbabe": make sure it is not activated on production.
Profiles lists the remote profiles that can override the parameters of the SDK on all mobile clients. The Default profile is always empty, and when it is active, the SDK parameters are fully determined by the app local configuration. Only one remote profile may be active at given time.
Grace period defines the allowable time between the timestamp of a request and the time that Reblaze receives the request from the application. Requests with a longer delay will be rejected.
UID Header Name determines the name of the header that contains the user authentication token. With the new versions of Mobile SDK, it can be empty.
Support for old versions of Mobile SDK is disabled by default, but if your app has not fully migrated to Mobile SDK v2.0, you can enable backwards compatibility:
This section defines several types of limits: Timeouts, Size Limits, and Request Rate Limits.
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.
You can 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.
These settings allow you to limit the amount of resources consumed by an IP address. Reblaze can limit consumption by the average number of requests per second, while also allowing temporary bursts at a higher rate.
When a requestor exceeds any of these thresholds, subsequent requests will be answered with error code 503 (Service Unavailable).
Note that this rate limiting is a global metric; it applies across the entire application. For example, if one IP address is submitting requests to multiple URLs within a web application, all the requests are combined when determining if rate limits have been violated.
Request Rate Limits are active even when the domain is in Report-only mode.
Reblaze can track a session by using a header, argument, or cookie. This parameter allows you to specify which one to use.
This section is for advanced configurations only. To use it, please contact support.
To delete the current site or application being displayed on the page, enter its name into the textbox and click on the Delete site button. Note: this action cannot be undone.
Before deleting a site from Reblaze, you should change your DNS settings to reroute your traffic, and then wait for the changes to propagate. Otherwise, Reblaze will still be receiving traffic, but the traffic will no longer be passed upstream to your server.
| Field | Value |
|---|---|
| Level | Included protection |
|---|---|
| Component | Description |
|---|---|
As an alternative, you can also get a QR code for use in apps such as Google Authenticator (available for both and ).
Viewer: can see the section, i.e. the Dashboard and View Log.
Editor: has all Viewer permissions, and can also configure security rulesets and policies in the and sections.
Add the URL to the XML metadata file to the RBZ_SSO_META_URL env var (and/or for Provider URL field in admin)
The URL example:
1. Go to → Enterprise applications
The Web Proxy page allows you to edit an existing web application. To define a new web application within Reblaze, navigate to the .
Reblaze evaluates incoming traffic in a multi-stage process. The stages include the tests defined here for each resource (WAF Policy, ACL Profile, Rate Limits, and Cloud Functions), and other tests as well (Dynamic Rules, Static Rules, etc.) The complete list of tests and their order of evaluation are described in .
Some rulesets are defined within the Security section of the interface: the , , , and . Others are defined farther down on this page, such as the Request Rate Limits discussed below.
To add a resource definition, click on the "expand" button in an existing definition. Within the window that appears, click on the Fork Profile button.A new definition will be created for editing.
To delete a definition, expand its listing. In the window that appears, select the Delete button.
To find the signature for an iOS app, you can open the Apple Development Certificate in the Keychain app, and copy the SHA-256 fingerprint. Alternatively, you can this fingerprint from the ipa bundle.
For Android app, you can get the SHA-256 fingerprint from the keystore or extract it from a signed APK with the apksigner tool (part of the Android SDK). See detailed instructions .
Documentation for the old versions of Mobile SDK is available . Note that the Grace Period field is read-only; it only reflects the global setting above.
Security Level
Preset of settings (ACLs, Profiles, Rate Limits) to protect a new site. See the list of available settings below.
Domain Name
The list of domains that Reblaze will protect. The first domain in the field will be taken as a canonical name for the new site.
Backend Service
Backend Service will be embedded to all default Paths of the new site.
Certificate
An optional specification for an SSL certificate to use for the site. If selected, the certificate must be embedded into a Load Balancer so it will be used as a source for IP to create a DNS record for the new site.
Off
All protection is disabled
Low
DDoS Protection
Medium
DDoS Protection
Injection Proof
High
DDoS Protection
Injection Proof
Session hijacking
Credentials stuffing
Brute force
Enumeration (mapping)
Paranoid
DDoS Protection
Injection Proof
Session hijacking
Credentials stuffing
Brute force
Enumeration (mapping)
Bot mitigation
DDoS Protection
Volumetric distributed denial of service protection
Injection Proof
Malicious code injection, signatures filter protection
Session hijack
Control sessions (cookie/header/key) from unauthorized access
Credentials stuffing
Automated login requests, usually based on a list of stolen account credentials
Brute force
Attempts to guess an account and password/passphrase
Enumeration (mapping)
An attempt to guess and map valid user accounts
Bot mitigation
Detect and mitigate bot activity
Setting
Description
Group Name
A name you choose for display in the Group listing.
Sites
The site(s) for which alerts will be sent.
Rules
The Dynamic Rules which, when violated, will trigger alerts. When more than one rule is included, a violation of one or more will trigger the notification.
Alerts
Information for the recipients of alerts: their email addresses and hooks.
Reports
Email addresses for the recipients of cumulative weekly reports.
Record Type
Description
A
Address record
AAAA
IPv6 address record
CNAME
Canonical name record
MX
Mail exchange record
NS
Name server record
PTR
PTR resource record
SOA
Start of [a zone of] authority record
SPF
Sender policy framework (now discontinued, as of RFC 7208)
SRV
Service locator
TXT
Text record
ALIAS CNAME
Alternative to CNAME that can coexist with other records on that name.
ALIAS A
Alternative for an A record
Field | Value |
Domain Names | The list of domains that Reblaze will protect. |
Client IP Header Name | Defines one or more header fields within which Reblaze can find the client's IP address. When Reblaze receives an incoming request from a client, the request will have passed through a load balancer on its way to Reblaze. This means that the header will contain the client's IP and the load-balancer IP. These two IPs are usually found within the X-Forwarded-For field (which is the default entry here). In this situation, Reblaze knows how to extract the client IP from this field. In other situations, a different field name might be necessary. For example, if the Reblaze customer is using Akamai CDN, the incoming request will have the client IP in a field named True-Client-IP instead. |
Challenge Content-type | The Content-Type entity header of the response when a challenge is executed. |
Challenge's cookie domain | Defines the domain you want Reblaze to use when setting a challenge cookie. The default value (“$host”) tells Reblaze to use the domain being accessed by the user. |
Mask Post Args | Defines the argument names which contain sensitive data, and therefore will not be saved in log files. Common examples of this are payment details and credit card numbers. |
Field | Value |
Proxy Connect Timeout | The time (in seconds) for Reblaze to wait, before treating a connection with the backend as having failed. |
Proxy Send Timeout | The time (in seconds) for Reblaze to wait, before treating a data transfer attempt to the backend as having failed. |
Proxy Read Timeout | The time (in seconds) for Reblaze to wait, before treating a downstream (toward Reblaze) data transfer attempt as having failed. |
Backend Service Host Header | Defines the value of the Host header passed to the backend. The default value (“$host”) sets it equal to the Host header in the incoming request. |
Real IP Header Name | Defines the field name that contains the client's IP address. Reblaze is a proxy, and it passes incoming client requests to the upstream server. This means that the server will receive request headers which contain Reblaze's cloud IP address as the "client" IP. This is not useful; almost always, the server will need the IP of the actual client instead. To facilitate server logging, analytics, and so on, Reblaze adds the IP address of the originating client to the headers that it sends to the server. The Real IP Header Name defines the name of the field within which this information is passed. |
Parameter | Timeout |
Client 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)'. |
Client Header Timeout | How long to wait for the client to send a request header. |
Keepalive 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 Max Body Size | Specifies the maximum accepted body size of a client request, as indicated by the request header Content-Length. Size in MBs. |
IP Parameter | Functionality |
Global Limit - Requests per second per IP address | Sets the allowable request rate per IP, per second: i.e., 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). Example: This is set to 100. 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.) |
Global Limit - Burst for request per second per IP address | Sets the allowable additional burst rate per IP, per second. Example: Let's say that the previous field (Global Limit - Requests per second per IP address) is set to 100. Without burst limits—i.e., if this field were set to zero—the system will reject every request that was received less than 10ms after the previous one. However, the burst limit is set to 20 instead. 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. |
Size | Functionality |
Session Key | Specified as header_YOURHEADERNAME, arg_YOURARGUMENTNAME, or cookie_YOURCOOKIENAME. |
Field | Value |
Name | A descriptive label that you choose, for use within the Reblaze interface. |
Match |
Backend Service | An HTTP/S request which passes all tests (as defined in the assigned rulesets, plus other applicable tests such as dynamic rules) will be forwarded to this service. |
WAF |
ACL |
RL |
Fn |
expand | A button to expand this definition and display it for editing. |
Field | Value |
Secret | When a mobile application sends requests into Reblaze, it includes a secret value in each call that will be used as part of the client authentication process, to verify that the requestor is a legitimate human user. This field allows you to specify that value. |
Variable Name |
Hashing mechanism | To be edited only with the help of support. |
Grace Period | Defines the allowable time between the timestamp of a request (provided in the Grace variable name, below), and the time that Reblaze receives the request from the application. Requests with a longer delay will be rejected. This will prevent replay attacks. |
Grace variable name | The name of the header, cookie, or argument used to transmit the request's timestamp. |
An expression for the resource's location, expressed as PCRE (Perl Compatible Regular Expressions). This entry uses .
The applied to this resource. Its name will be displayed in green if it is active; if displayed in red, it is currently disabled.
The applied to this resource. Its name will be displayed in green if it is active; if displayed in red, it is currently disabled.
The number of assigned to this resource.
The number of assigned to this resource.
The name of the header that carries the user authentication token. It can not be empty. For more information, see .
