Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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 publish your changes.
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. These tend to be parameters that once set up, usually will not change during your use of Reblaze.
There are five 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.
SSL Management is where SSL Certificates are uploaded and managed.
DNS is where DNS records are configured.
Planet Overview shows you information relevant to your entire planet: the active domains and applications, what notifications are issued in response to events, and the ability to Publish changes that were made elsewhere in the interface.
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'.
Related video: SSL Training
The SSL Certificate Management interface displays certificates according to the load balancer to which they are attached. Those stored in the Reblaze cloud are listed as "None."
Displayed parameters are:
Choosing a different load-balancer option will filter the certificates and display only the ones attached to that LB.
Reblaze provides the capability to generate an SSL Certificate for free using the Let's Encrypt service. This is not done in this section of the interface; it is done using the "Gen Cert" 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 "New" button. This dialog will appear:
To upload a PFX file, select "Choose File." Otherwise, enter the Cert Key and Cert Body values into their respective text boxes.
On the upper right, select the load balancer to which this certificate will be attached. If "None" is selected, the certificate will be uploaded and stored on Reblaze's cloud.
In the example screenshot above, a specific load balancer IP has been selected. This enables the options shown at the bottom of the screenshot:
Attach to Application: Specifies the application/site to which this certificate will be attached.
Replace existing certificate: Replaces an existing certificate with this new one. All web applications that were attached to the specified certificate will now be attached to the new one.
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 blue edit icon to the right of its entry in the list. This dialog will appear:
Under "What would you like to do?", the following options are offered.
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.
Attach to application - Select an application/site and attach it to this certificate.
Copy to another load balancer (available only when this certificate is attached to a LB, and more than one LB exists) - Allows you to copy the certificate and upload it directly to another load balancer.
Auto Let's Encrypt Renewal/Replacement: 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, then the following process occurs:
If the Auto Let's Encrypt Renewal option for that certificate is enabled, Reblaze will generate a new certificate using Let's Encrypt.
If the Auto 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.
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.
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:
After making edits to this section, Save Changes and Publish 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.
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 Security Section Concepts.
This section is where security rulesets are assigned to resources within your site, application, API, etc.
Some rulesets are defined within the Security section of the interface: the ACL Profiles, WAF Policies, Rate Limiting, and Cloud Functions. Others are defined farther down on this page, such as the Request Rate Limits discussed below.
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.
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 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 configuring security for mobile applications.
The parameters on the left are for applications which use Reblaze's Mobile SDK. The parameters on the right (the "Grace" parameters) are meant for applications which do not use the SDK. It is recommended to use the SDK if possible, since this provides much more robust security and the ability to authenticate client requests.
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.
Changing user settings
The Account Settings allows you to review and modify your Reblaze user account.
From this page, you can reset your password. Before this can be accomplished, you will need to enter an OTP (One Time Password) code that will be sent to you via SMS text message.
Alternatively, you can scan the QR code shown on this page, using an app like Google Authenticator (available for both and ).
This will generate an OTP without requiring you to wait for an SMS message.
To remove a Service from Reblaze, click on the Delete Service button at the bottom of the window.
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.
Parameter
Description
Name
A unique identifier for use elsewhere in the interface.
Common name
The domain name for which the certificate was created. It can be a single domain (“www.example.com”) or a wildcard expression. For example, “*.example.com” will match “example.com” and all its subdomains.
Expiration
When the certificate expires.
Issuer
The source of the certificate.
Linked To
This field is populated when this certificate is chosen for use in the Proxy Settings section.
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.
Field
Value
Name
A descriptive label that you choose, for use within the Reblaze interface.
Match
An expression for the resource's location, expressed as PCRE (Perl Compatible Regular Expressions). This entry uses Pattern Matching Syntax.
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
The WAF Policy applied to this resource. Its name will be displayed in green if it is active; if displayed in red, it is currently disabled.
ACL
The ACL Profile applied to this resource. Its name will be displayed in green if it is active; if displayed in red, it is currently disabled.
RL
The number of Rate Limits assigned to this resource.
Fn
The number of Cloud Functions assigned to this resource.
expand
A button to expand this definition and display it for editing.
Field
Value
Domain Names
The list of domains that Reblaze will protect.
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.
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
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
The value included in requests in the header_name field. In other words, this is the string referred to in the documentation as <YOUR-USER-KEY-NAME>. For more information, see SDK Method Arguments.
Hashing mechanism
To be edited only with the help of support.
Grace
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.
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.
Configuring Notifications and Alerts.
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 by duplicating an existing one, and then editing the one that is created.
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 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.
At the bottom of the Planet Overview are the Notification Settings.
When a Dynamic Rule is violated, Reblaze can send immediate alerts to a list of one or more email addresses, SMS numbers, 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.
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, hooks, and mobile numbers for SMS messages.
Reports
Email addresses for the recipients of cumulative weekly reports.
