Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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
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
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.
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.
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.
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 .
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.
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.
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.
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.
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.
| Field | Value |
|---|---|
| Level | Included protection |
|---|---|
| Component | Description |
|---|---|
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 page.
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.
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 |
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:
Viewer: can see the Traffic section, i.e. the Dashboard and View Log.
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 Azure accounts.
Configuration options will vary depending on the type of account.
Please note: In setting up an SSO account with Okta or Microsoft Azure, the screens you encounter on those sites may differ slightly from those appearing here. However, the information you will be required to provide for SSO set up and configuration will be the same as shown below.
Go to Okta. At the top of the page, click "Try Okta", register and create an application:
Go to https://{YOUR ACCOUNT}-admin.okta.com/admin/apps/active
Click Add Application → Create New App
Choose Platform: Web and Sign on method: SAML 2.0
Give your app a name and click Next:
Now, configure the SAML integration, as shown in the screen below.
In the Single sign-on URL field, enter the URL in the following format:
https://{REBLAZE_CONSOLE_DOMAIN}/sso/saml20/signon
In the Audience URI field, enter the URI in the following format:
https://{REBLAZE_CONSOLE_DOMAIN}/sso/saml20/audience
[Obtain Reblaze Console Domain URL from the Reblaze Log In.]
Next, scroll down to the Attribute Statements (optional) section.
In the Name column, write emailaddress; in the Value column, write user.email
Click Add Another.
In the Name column, write displayname; in the Value column, write user.firstName + " " + user.lastName
Click Add Another.
In the Name column, write groups; in the Value column, write appuser.rbzgroups
Scroll down, click Preview the SAML Assertion, then click Next.
The screen shown below will appear. Select I'm an Okta customer adding an internal app, then click Finish at the bottom of the screen.
Next, the Reblaze Admin group ID must be configured.
On the left side of the Okta screen, under Directory, go to Profile Editor . The screen below will appear.
In the Users tab, select Apps.
Scroll down and in the list of Profiles, locate and then click {$APP_NAME} User, where {$APP_NAME} is the name you assigned to your app earlier.
The following screen will appear. Under Attributes, click + Add Attribute.
An Add Attribute window will appear. Complete the fields as shown below, then click Save.
The next step is mapping. Return to the Profile Editor screen, and click on the Mappings tab.
The window below will appear.
Fill in the top field with appuser.rbzgroups. Click the arrow to the right of the field, and select the first option.
At the bottom of the window, click Save Mappings, then click Apply updates now.
Create user groups for two possible access levels: Admin and Read-Only access.
On the Okta menu on the left side of the screen:
Under Directory, select Groups.
A Groups screen appears; go to Add Group. Add a group named reblazeadmin.
From the left-hand menu, under Applications, select Applications.
An Applications screen will appear. Click your app's name. The screen shown below will open.
In the Assignments tab, click the Assign dropdown and select Assign to Groups, as below.
The following window will open. Select reblazeadmin, and click Assign.
The following window will open. Fill in the field as below, then click Save and Go Back. This will bring you back to the previous window (above), where you click Done.
Next, back at the app window, select the Sign On tab. In the window that appears, scroll down until the SAML Signing Certificates section. On the right hand side, click View SAML setup instructions.
This leads to the How to Configure SAML 2.0 for {$APP_NAME} Application page. You will use the information here in the next step.
At this point, you must log into the Reblaze console. Go to your Reblaze Log In screen and complete all the fields, including the MFA PIN you will receive. Click Log In.
This will bring you to the Reblaze console.
From the menu on the left, under Settings select Account. Your Account page will open. Click the Single sign on configuration tab.
In the window that appears, select Enabled.
To obtain the URL for the Provider URL field, return to the Okta How to Configure SAML 2.0 for {$APP_NAME} Application page.
Copy the url from the Identity Provider Single Sign-On URL, and paste it into the Reblaze Provider URL field.
The following revisions must be made to the URL:
Now, add the suffix metadata to the end of the URL (after the segment ending: saml/).
4. Fill in the name of the Admin Group (i.e., reblazeadmin).
5. Fill in the URL for the IDP Issuer field. To obtain the URL:
6. Return to the How to Configure SAML 2.0 for {$APP_NAME} Application page.
7. Copy the URL from the Identity Provider Issuer field.
8. Paste it into the Reblaze IDP Issuer field.
9. Ignore the Audience URL and Assertion URL fields (they should be disabled automatically).
10. Click Save. This will restart the console service.
On the Reblaze Log In page there will now be an additional button: SSO Login. Click to log into the Reblaze console.
Go to this MS Azure page to sign in.
You will be redirected to the Default Directory page. From the side menu, select Enterprise applications.
Choose + New Application , as shown below.
In the screen below, choose + Create your own application .
Then, from the drop-down that appears, give your app a name and choose Integrate any other application you don't find in the gallery (Non-gallery). Click Create.
On the next screen that appears, from the left menu, select Single sign-on, then choose SAML:
The screen below will appear. Click Edit in the first block (Basic SAML Configuration) on the left.
On the right, enter values for the Identifier (Entity ID) and Reply URL (Assertion Consumer Service URL) fields:
The Identifier (Entity ID) should be provided by the customer. It must be unique for the customer’s SSO applications. The best option is to use something like: customer_domain.com?sso=123. Note that this should not contain the "https://" prefix. Also note that this value will be entered into the IDP Issuer field in the Reblaze console.
The Reply URL (Assertion Consumer Service URL) should be: https://{REBLAZE_CONSOLE_DOMAIN}/sso/saml20/signon, where the {REBLAZE_CONSOLE_DOMAIN} can be obtained from the Reblaze Log In.
Click Save (at the top).
Copy the App Federation Metadata URL and save it for later. This will be used as the Provider URL value in the Reblaze console.
user.groups in Attributes & Claims.In the second block of the screen below, click Edit.
The screen below will appear. Select + Add a group claim.
From the drop down that appears on the right:
Choose All groups
Choose Source attribute:Group ID
Click Save
The following screen will appear.
Return to the Enterprise Application screen. From the left menu, click Users and Groups.
Click the + Add users/groups tab. Add users to the application by searching for a display name or through application registration.
Go to Azure Active Directory → Groups, and create a group by clicking on the New Group tab.
Copy the Object ID and save it for later use. It will be the value for the Admin Group field in the Reblaze console.
Click on the hyperlinked group name (ReblazeAdmin); the screen below will appear. Select Members from the left menu.
Assign a user to the group:
Go to the Reblaze console and sign in.
In the left menu, under Settings, select Account. When the screen below appears, click on the Single sign on configuration tab; set the Enabled checkbox.
For the remaining fields:
Set Provider to Microsoft.
Set the Provider URL to the value obtained in Step 4 (the App Federation Metadata URL).
Set the Admin Group to the value obtained in Step 7 (the Object ID).
Ignore the remaining fields. (IDP Issuer should have been set automatically, while Audience URL and Assertion URL should have been disabled.)
After the fields are filled in, click Save.
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.
To avoid an app getting a new signature when uploaded to the AppStore or Google Play, a new feature was added to the protocol between the SDK and the Backend. It negotiates the signature remotely, and updates the system with a new signature, if such was generated.
Communication between the components takes place under the /74d8-ffc3-0f63-4b3c-c5c9-5699-6d5b-3a1f endpoint.
When a new signature is introduced, it will be provided as a value for the header named sig (see screenshot below). This new sig will then be added to the list under the Mobile SDK tab in the Reblaze Console. View log filter: url:/74d8-ffc3-0f63-4b3c-c5c9-5699-6d5b-3a1f
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.
If the same threshold is assigned to two Rate Limit rules, the rule added first to the Web Proxy page will be the rule whose action will be activated first. Changing the order in which the rules are added will change the order of the first rule to be activated.
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.
This field is populated when this certificate is chosen for use in the section.
Delete the following segment, highlighted in blue, from the URL you copied: [dev-7889665_mynewapp_1/]
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, Cloud Functions and Flow Control), 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.
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 |
FC |
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 number of rules assigned to this resource. Its name will be displayed in green if it is active; if displayed in red, it is currently disabled.
The name of the header that carries the user authentication token. It can not be empty. For more information, see .
