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.
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.
An HTTP/S request which passes all security tests will be forwarded to the Backend Service defined for the requested resource.
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 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.
To delete a definition, expand its listing. In the window that appears, select the Delete button.
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.
Check boxes - available for path level and site level
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.
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 extract this fingerprint from the ipa bundle.
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.
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.
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).
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.