Reblaze Setup Checklists

Easy-to-use checklists for starting and testing Reblaze

Overview

Please go through these checklists, and verify that their actions have been completed, both before and after your traffic is routed through Reblaze.

There are three checklists below: two for setup, and one for testing.

Prerequisite

Before going through the checklists below, you should already have performed the actions listed in Getting Started.

Configuring your environment

Item	Action	More Information
Web Server Firewall & Hosting Firewall	Verify that Reblaze IPs are whitelisted in the firewall.	Also, please ensure that only Reblaze IPs are able to access your web server, i.e. block access for all non-Reblaze IPs. This can be done via a set of rules for your firewall, or via .htaccess files.
Rate Limits	Verify that you're not using any Rate Limit/QOS rules that apply to Reblaze IPs.	This avoids potential blacklisting of Reblaze, and other availability issues. (If Rate Limits are applied, Reblaze can be misidentified as a DDoS source.)
Website Cache Settings	Ensure that each site/application returns the correct caching instructions.	You can also control caching behavior through Reblaze, as mentioned below.

Setting up Reblaze

Item	Action	More Information
Upstream Server	Verify that the Web Proxy settings for each domain/site are correct. (These settings define where and how Reblaze forwards incoming traffic.)	Defined via Upstream Servers and also Proxy Settings.
SSL	Verify that your SSL setup (which should have been performed already, as described in Getting Started) is complete before routing traffic to Reblaze. (Note that if you want Reblaze to generate Let's Encrypt certificates for you, the traffic must be routed to Reblaze before the certificate can be generated.)	You can use pre-existing certificates, or generate new ones via Reblaze. More info.
Non- Browser Applications	If your application serves bots or other non-browser clients (e.g., monitoring services, mobile/native applications using an API, etc.), you will need to exempt them from Reblaze's browser challenges.	Mobile/native applications are exempted by using the Mobile SDK. For other non-browser clients, you should disable Active Challenges. It is highly recommended that you enable Passive Challenges to replace them. More info on the overall challenge process is here.
HTTPS	Enable traffic via HTTPS.	Make sure that the Proxy Settings are configured properly.
Block Known Sources	Define ACL Policies to reject traffic from sources known to be hostile (e.g., IPs, countries, etc.)	This is done with Security Profiles that include ACL Policies with an operation of "Deny".
Whitelist Known Sources	Exempt specific traffic sources from inspection and filtering.	This is done with Security Profiles that include ACL Policies with an operation of "Allow" or "Bypass".
Web Application Firewall (WAF)	Review the default ACL Policies and WAF/IPS Policy, to ensure they meet your needs. Define new ones if necessary.	The Policies are included in one or more Security Profiles, which are then assigned to appropriate locations within your site as explained here.
DDoS Settings (Rate Limits)	Review the global rate limits to ensure they match your site's capacity. For most use cases, the default settings should work well.	In addition to the general rate limits, it's also possible to define limits for specific site locations and/or traffic sources. More info about this.
Cache Settings	Review the applications' cache settings in their Application Profiles.	Reblaze has a variety of caching options. Its settings are explained here.
Alerts	Review and customize alerts and notifications according to your needs.	More info about this.
Account	Review your account settings to ensure they are correct.	Sometimes new customers enter placeholder values at first. Ideally, correct values would be in place by the time Reblaze is active.

Testing your setup

When the following checklist has been completed, you'll be ready to go.

Note: by default, Reblaze is deployed in Report mode for all applications. In this mode, it will not block traffic; it merely reports on the traffic it would have blocked, if that application had been set to Active mode.

Item	What to verify	More Information
Check DNS	Run a DNS query for the website, and validate that the DNS records of the HTTP/S services are pointing to Reblaze CNAME /IPs only.	You can use tools such as https://dnschecker.org/.
Test Traffic	Generate traffic to your site, and verify that it is being displayed in the Dashboard. For more in-depth traffic inspection, you can use the View Log. If SSL traffic is used, use your web browser to validate that the right certificate is being used.	Both the Dashboard and View Log include a Query box to filter their displays. Here's how to use the Reblaze Query Box.
Test Non-Browser Clients	If applicable, generate and test traffic from non-browser clients, and verify via the Dashboard that the requests are not blocked/reported.	This is to validate the (optional) settings configured for non-browser clients, as described in the checklist above.
Monitor and Optimize Settings	As traffic is processed by Reblaze, review the Dashboard (and ideally, the View Log) to see the decisions that are being made. Optimize Reblaze until it is performing as expected. Once you are satisfied with Reblaze's traffic scrubbing, move your application(s) from Report mode to Active mode.	Reblaze's logs are a rich source of insights into incoming traffic. Highly recommended reading: Understanding and Diagnosing Traffic Issues.