Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
Location-based security settings, and Report Only mode
In this section, you can:
Define different locations and/or resources within your planet. For each one, you can:
Assign a security Profile. Profiles are defined elsewhere in the interface: this section is where you assign them and make them active for different locations within your planet.
Configure rate limiting (optional).
Configure content filtering (optional).
Set a site/application into Report Only mode (usually used only for testing).
The top right part of the screen shows the site that is currently being displayed for editing.
On the main part of this page, the various defined sections of the selected site are listed. The Default entry is always present.
Each entry is defined as follows:
To add a new Location, fill out the blank entry at the bottom and click Add. To delete a Location, click the Remove link next to its name.
Once you have defined a Location, you can assign a Security Profile to it.
Within each Location entry, the Profile field is autocomplete. Typing the first few characters of a Profile name will populate the list appropriately, then select the desired Profile.
Once you have defined a Location and assigned a Profile to it, you can also (if desired) configure rate limits and content filtering for it.
This is synchronized protection: you can limit the request rate, according to any desired parameter, per URL or section, across the entire cluster, while keeping all the proxy servers in sync.
If you need to whitelist an IP, Country, or ASN from being subject to this rate limiting, see Whitelisting and Creating Exemptions from Rate Limits.
At the end of the Location's entry, click on "More" to open the Location Settings dialog.
This displays whatever limits have been defined for this location, and another line to add a new limit.
Settings you make in this dialog will only apply to the location associated with the "More" button that opened the dialog.
Each limit defines the number of requests allowed for a specific time period, defined in the TTL field. When a request is received that matches one or more Keys, an internal TTL timer starts, and Reblaze begins counting. If the Rate Limit is reached before the TTL period has ended, subsequent requests are blocked until the current TTL period ends.
Here are the possible attributes:
When counting the number of requests, Reblaze searches for the value of a Key. Each value has its own cumulative count.
Combining Keys into one rate limit (by entering their names together, separated by a space) allows for more granularity. Examples:
remote_addr : Each IP will have its incoming requests counted, and evaluated separately against the Rate Limit.
remote_addr uri Each combination of IP and URI will be counted, and evaluated separately against the Rate Limit. In other words, Reblaze will count the requests from each IP for each URI, maintaining separate cumulative counts for each combination. So, if a specific IP asks for multiple pages within a site, it will be allowed; but if it asks for the same page too many times, it will be blocked.
Here are the possible values for Key Composition.
When using an argument in a rate limit (as mentioned in the arg_ArgName description above), the argument becomes mandatory. Any request received without the argument will be blocked.
You can use Lua to manipulate strings in the Key Composition field. Use the tostring() function to return a string into the field.
Usually there will also be a substring operation. This should come after the tostring(). Example: tostring():sub(1, 20)
Inside the tostring(), there must be a valid NGINX variable, usually from ngx.var or ngx.ctx. The full variables list can be found here.
Examples:
Substring - Suffix last 5 char :
tostring(ngx.ctx.args_table['foo']):sub(-,5)
Substring - Prefix from 1st char to 5th char: tostring(ngx.ctx.args_table['foo']):sub(1,5)
If you need assistance with this feature, please feel free to contact support.
For each Location, along with defining rate limits, you can also set up content filtering.
This is a powerful feature that allows you to require, or deny, exact values for specific headers, cookies, and arguments, based on regex matching.
Content filter example
The Filters do not have user-assigned descriptions or names (the Name field has a different meaning, described below) When a request is blocked based on the Content Filter, the request appears in the logs with a custom description constructed from the Filter's parameters.
To add a new Filter, enter values into the empty row in the list and click Add. Existing Filters can be deleted by clicking Remove.
When you are finished configuring rate limits and content filtering for a location, click Done. After you have edited all Locations, Save Changes and Publish Changes.
At the bottom of the screen, the Report Only switch allows you to test your Reblaze configuration. Enabling this setting means that Reblaze will not block any traffic for this site/application; it will merely report on what it would have blocked otherwise. This is useful during a new deployment, since you can fine-tune and optimize your settings while avoiding false positives.
This setting applies to the site/application currently being displayed. It is the same setting that is available for this site/application on the Planet Overview page. See the warning there about this setting.
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:
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.
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.
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 page.
Item
Description
Name
A descriptive label that you choose.
Matching Path
Defines a Location, i.e. everything within the planet that matches this Path. This entry uses Pattern Matching Syntax.
Profile
The Security Profile assigned to this Location.
More
Configures rate limiting for this location, explained below.
Field
Description
Name
A name that will describe the limit. (This will be shown in the View Logs for any requests that are blocked by this limit.)
Rate Limit
Sets the threshold for the requests. This is the number of requests allowed per the time period defined in the TTL field.
Key Composition
The value for which Reblaze searches in a request. Explained in Key Composition Values below.
TTL
The time period in seconds until the request count will be reset.
Value
Description
remote_addr
The request's source IP address.
request_uri
The request URI.
http_HeaderName
Arbitrary request header field; the last part of a variable name is the field name converted to lowercase with dashes replaced by underscores.
arg_ArgName
The name of an argument in the request. (See warning below.)
cookie_CookieName
The name of a cookie.
request
The full original request line (including the query string).
Custom
See below for explanation: Advanced String Manipulation in the Key Composition.
Parameter
Comments
Action
Required to block if a match from the specified Pattern is not found. Deny to block if a match is found.
Data Item
The source of content to examine. Options: Argument, Header, Cookie.
Name
The name of the Data Item from which to get the content.
Pattern
The matching conditions, specified as regex.
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 |
Settings for security behaviors
The Application Profiles tab allows you to set appropriate security behaviors for your web applications.
Before configuring, ensure that the correct site is selected via the dropdown list at the upper right.
To add an entry to the list, click on the "+" button. To delete an entry, click on the "Remove" link next to its name.
As shown in the above screenshot, the default (“/”) profile will always be present. It applies to the entire site, except for those parts of the site that have specific profiles assigned to them.
Here are the fields for each Application Profile.
If you'd like to clear cache on one of your websites on the platform, you can click the "Purge" button. Usually, the action takes around 5 minutes.
When you deploy Reblaze to protect your web assets, it acts as a proxy, receiving requests from clients (web visitors, mobile/native app users, etc.), blocking hostile traffic, and passing legitimate requests to your servers.
The Web Proxy section defines how Reblaze behaves in this role. It consists of three tabs:
Proxy settings are configured per site/application. To switch between them, click on the drop down menu on the right side.
After making edits to this section, don't forget to Save Changes and Publish them to the cloud.
Web Proxy - General Settings overview.
This part of the interface allows administration of three categories of settings, for the site that is currently selected at the top of the screen:
At the bottom, it also provides the ability to delete the selected site from the planet.
This section defines the servers that Reblaze will protect. In other words, these are the servers to which Reblaze will send the (legitimate) traffic it receives.
Within these settings, you can:
Enable and configure load balancing, weighting and distributing traffic across your primary servers.
Define backup servers, to which Reblaze will failover your traffic when your primary servers aren’t available.
Take servers offline for maintenance by ticking a single box in the interface.
Instruct Reblaze to keep individual users connected to the same server throughout their sessions.
Adding and deleting servers from this list is straightforward. To add a server, enter its IP in the “New Server” box and click Add, then fill out the rest of the information in the new entry. To delete an existing entry, click on the Delete link next to that entry.
The settings for each server in the list are as follows.
In addition to the features described above, Reblaze also has a stickiness capability that is not exposed in this version of the interface. Sometimes an application requires a user to be connected to the same server throughout the session. Reblaze can ensure that this occurs, and can do so using a variety of methods (tracking the user by IP address, session cookies, geographic location, and more).
The stickiness feature will be added to the Reblaze interface in a future version. Meanwhile, if you need this capability for your deployment, contact Reblaze support to set it up for you.
The Proxy Settings parameters define Reblaze’s behavior as a proxy, i.e. how Reblaze passes information back and forth between client and server.
The Client’s IP Header Name (Upstream Side) setting defines how Reblaze passes the client's IP address to the upstream server. In addition to the IP, Reblaze also sends the client's geographic information (if it is available). The field names are:
The Log Files Parameters enables you to control the contents of the Reblaze-generated traffic logs.
When you wish to remove a site from Reblaze, select it in the pulldown list in the upper right of the page. Then, at the bottom of the page, you will find a (disabled) Delete Site button.
To enable the button, check all three boxes next to it. (This is a safety measure to prevent accidental site deletions.) Once the button is enabled, clicking it will remove the specified site from Reblaze. Note that 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 along to your server.
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. 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, .
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 far 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 if you need assistance for your particular situation.
Related video:
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.prod2.reblaze.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.
As shown in the example screenshot, this page is divided into two sections. The upper section is blue, and lists two special resource recordsets: SOA (Start Of Authority) and NS (Name Server). These are at the Zone level, and once created, these cannot be modified. They also will not be filtered (hidden from view) by the "search" feature.
The "search" feature is based upon the text box at the upper left.
This will control the DNS entries being displayed, by filtering them according to the search value and selected record type. Note that filtering does not apply to the entries in the blue section; these will always be displayed.
To add a new DNS entry, click on the "New" button on the right hand side. 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
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.
Administering your entire planet
The Planet Overview page enables the following actions:
Managing your planet's sites/applications.
Configuring a site/application's health monitoring.
Making a site/domain active, or inactive (in "Report Only" mode).
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.
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.
On the far right part of the screen, click on its "Duplicate" button.
This will clone the site and create a new one with identical settings, which you can then edit.
Each web application has two possible Security modes:
By clicking on the "Gen Cert" 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.
In a typical deployment, incoming traffic is load-balanced, processed by Reblaze, and then (if it is legitimate) passed through to the upstream origin.
Load-balancing includes more than just equal distribution of loads; it also includes failover. To perform this correctly, the health of the upstream origin must be monitored.
In this section of the interface, you can define a URL within your site that can be queried by the load balancer. If the URL is accessed successfully, the site is assumed to be healthy and capable of handling a continuing load. If the URL is not accessed successfully, the site is deemed to be unhealthy; depending on the configuration, a failover process might then begin.
Here are the available settings. Check marks at the end of certain fields indicate that the entries are valid.
This button resets the health statuses that are displayed in the interface. It does not trigger a health check; it merely resets the status displayed to the user.
For example, a user has disabled health monitoring for a particular upstream server. (Perhaps it has been intermittently failing its health check.) However, its most recent status was "failed," and so its IP address is appearing as red in the interface. To remove this distraction, the user clicks on Reset States. The IP address will now be showed normally.
At the bottom of the Planet Overview are the Notification Settings.
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.
This field is populated when this certificate is chosen for use in the section.
Deleting a web application is done in the General Settings on the page.
Clicking on a site name will open it in the page, where those settings can be edited.
Please note that the security mode applies only to the WAF & ACL. Regardless of its setting, Static Rules are still enforced, and challenges will also occur (except for those locations/resources which have had a "no challenge" profile assigned to them in the section).
Reblaze integrates with to provide free SSL Certificates.
To set up health monitoring for a site, click on its "[Health] Monitor" button: . Doing so will open this dialog:
When a is violated, Reblaze can send immediate alerts to a list of one or more email addresses, SMS numbers, and hooks (e.g., Slack).
Field Name
Description
Label
The name you have assigned to this particular entry. In the example screenshot, the labels are “Static Content” , “Default,” and “JS CSS".
Pattern
The list of extensions to which this profile will be applied, expressed as PCRE (Perl Compatible Regular Expressions). An explanation and some examples are here: Pattern Matching Syntax.
Protect
When enabled, this tells Reblaze to inspect all requests for the specified destination. This should always be enabled, unless there is a specific reason not to do so.
WebSocket
Enables support for the WebSocket protocol for this resource.
Cache Mode
Defines Reblaze’s cache behavior for the resources specified in this profile. Modes are explained here: Controlling Caching Behavior.
Client TTL
Custom expiration time for the Client Side cache, in TTL Expression Syntax. (Entries will show as strikethroughs when the Cache Mode is set to an option where the TTL values are ignored.)
CDN TTL
Custom expiration time for the CDN Side cache, in TTL Expression Syntax. (Entries will show as strikethroughs when the Cache Mode is set to an option where the TTL values are ignored.)
Purge Content
Purges the cache and removes its content. See explanation below.
Attribute
Description
Host
The IP address for each server 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 seen in the next field.
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.
Is Backup
When this box is checked, Reblaze will treat this server as a backup. In other words, Reblaze will not attempt to communicate with it unless all the primary servers (i.e., those for which this box is not checked) are unavailable.
HTTP Port
The HTTP port for the server.
HTTPS Port
The HTTPS port for the server.
Setting
Description
Host Header
Defines whether or not Reblaze will alter the Host field in the request header. The default value (“$host”) means that Reblaze will not change it; the server will receive the Host field that the client sent. A different string will replace the Host field in the header. For example, if you have multiple domains in your Reblaze planet, you might mandate that all incoming requests have a certain domain in the header, regardless of which domain the client is actually accessing.
Client’s IP Header Name (Upstream Side)
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 Client’s IP Header Name (Upstream Side) entry allows you to define the name of the field within which this information is passed.
Client's IP Header Name (Client Side)
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 for Client's IP Header Name (Client Side). 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.
Domain Names
The list of domains that Reblaze will protect.
SSL Offload
Reblaze can send web traffic via HTTP instead of HTTPS. This improves server performance, because the server no longer needs to decrypt the traffic. Obviously, this decreases security, and so this setting should usually be disabled. However, under certain circumstances (e.g., when a VPN is established between Reblaze and the servers), it can make sense to enable this.
Connect Timeout
The time (in seconds) for Reblaze to wait, before treating a connection with the upstream server as having failed.
Send Timeouts
The time (in seconds) for Reblaze to wait, before treating an upstream data transfer attempt as having failed.
Read Timeout
The time (in seconds) for Reblaze to wait, before treating a downstream (toward Reblaze) data transfer attempt as having failed.
Mask Headers
Defines the response headers that Reblaze will mask (i.e., remove from the response), preventing them from being exposed to the client.
For example: a default response header might include information about the server software (e.g. “Server: Microsoft-IIS/8.5”). This tells an attacker exactly which platform he is targeting, and so he can know which vulnerabilities to exploit. The Mask Headers entry defines all the headers to remove. It can contain multiple values, connected by pipes, with asterisks as wildcards.
HTTP/HTTPS redirect lines
Used to redirect all requests coming into these ports.
Field name
Description
RBZ-GEO-Country
Client's country
RBZ-GEO-CountryCode
Abbreviation of client's country
RBZ-ORG
Client's organization
RBZ-REGION
Client's region
Log file Parameter
Description
Challenge 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.
Private 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.
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. |
Security Mode | Description |
Active | The WAF will log all traffic, and actively block traffic deemed to be hostile. |
Report | The WAF will log all traffic, including reasons that requests are deemed to be hostile, but will not block anything. |
Setting | Description |
Protocol | Options are Do Not Monitor, HTTP, and HTTPS. HTTP is offered as a faster option (compared to HTTPS) for a static resource where an insecure connection would have no potential consequences. If HTTP is selected for health monitoring, it will not be overridden by any specification elsewhere within the Reblaze interface to use HTTPS. |
Notify Only | Enabled (displaying as blue) by default. When enabled, an unsuccessful health check only results in a notification being sent (and another notification will be sent when the first subsequent health check succeeds); traffic is not failed over to other servers. This is the default setting, because many customers do not have more than one upstream. Even when more than one upstream exists, disabling this setting can mean that upstreams get taken offline as the result of network issues. |
Host Header | The header for the request. Default is $Host. |
URL | The URL of the resource that should be requested to verify health. |
Expected Status | HTTP status code to use in the response to the request. |
Server | The server where the resource's URL is located. |
Setting | Description |
Group Name | A name you choose for display in the Group listing. |
Sites | The site(s) for which alerts will be sent. To include multiple sites, select them one by one from the dropdown list. |
Rules | The Dynamic Rules which, when violated, will trigger alerts. To include multiple Dynamic Rules, select them one by one from the dropdown list. 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. |
