Web Proxy
Last updated
Last updated
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, 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.
The Web Proxy page allows you to edit an existing web application. To define a new web application within Reblaze, navigate to the Planet Overview page.
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.
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. |
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.
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. |
This section (shown above in the previous screenshot) configures Reblaze's communication with the backend.
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. |
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.
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 here.
When uploading the fingerprint to the Reblaze Console, the spaces and colons will be removed for you, and the hexadecimal characters will be converted to lowercase. Other symbols are not allowed.
Any number of signatures may be 'Active' at given time. During testing, you may allow running the app on Simulator (iOS) or Android Emulator. These generate a special signature: "abadbabe". Make sure that this is disabled on Production.
Profiles is a list of remote configurations, which contain settings 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. The profile is stored as a JSON string. Correct JSON syntax is enforced, all strings must be "quoted". For further discussion of remote configurations, please consult your Mobile SDK Developer's Guide.
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.
Token Header Name determines the name of the header that contains session or user authentication token. With the new versions of Mobile SDK, it can be empty. This name should match the tokenHeaderName configuration parameter.
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:
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 name of the header that carries the user authentication token. It can not be empty. For more information, see SDK Method Arguments. |
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. |
Documentation for the old versions of Mobile SDK is available here. Note that the Grace Period field is read-only; it only reflects the global setting above.
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.
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. |
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.
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. |
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.
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. |
Reblaze can track a session by using a header, argument, or cookie. This parameter allows you to specify which one to use.
Size | Functionality |
Session Key | Specified as header_YOURHEADERNAME, arg_YOURARGUMENTNAME, or cookie_YOURCOOKIENAME. |
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.
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.
