Traffic Filtering Process
Last updated
Last updated
Reblaze subjects incoming requests to a multi-stage filtering process.
Below is a high-level description of the overall process. For a more in-depth review of the various stages and how to configure them, see their detailed discussion in the Console UI Walkthrough section of this manual, as linked to below in each description.
When processing an incoming request, Reblaze enforces the applicable security rulesets. As shown above, some types of rulesets are applicable to all requests, while others will vary depending on each request's destination URL and/or the tags attached to the request. To see how Reblaze decides which rulesets are applicable to a request, see the Policy Mapping page.
Reblaze acts as a proxy for the backend that it protects. It receives incoming requests, and examines them for potential threats. Requests that pass inspection are passed through to the backend. Those that do not pass inspection trigger an Action, which often is either a blocking action or a bot challenge. Along the way, Reblaze logs the request and the actions that occur, which are available to admins via analytics and dashboards.
The diagram above shows the progression of incoming requests through this process, shown from left to right. When a request successfully passes a stage, it proceeds to the next stage, as designated by a green arrow. When it does not, it follows the red arrow instead. Black arrows show activities that occur independent of a request's evaluation.
Before any other processing occurs, Reblaze can execute one or more Edge Functions. An Edge Function consists of custom Lua code; it allows admins to extend Reblaze's capabilities as desired.
Each Edge Function contains a Phase parameter. When this is set to Request, the Function is executed immediately when processing of the request begins.
Reblaze uses a tag-based system when processing and evaluating requests. At various points during processing, tags are attached to a request based on its source, content, and other characteristics.
Subsequently, the attached tags can be the basis for decisions about the disposition of the request.
In this stage of processing, each request receives a specific set of system tags. For example, every request will be tagged with all, along with tags for the geolocation of the traffic source.
This stage is also when Reblaze performs policy mapping: determining which security rulesets should be enforced upon the request.
The Global Filters stage has two primary purposes:
Attaching tags when the request matches specified criteria.
Executing an Action depending on the tags that were attached. In some situations, admins will decide to stop Reblaze's processing at the Global Filter stage. For example, an admin can decide that if the traffic source is found on a Spamhaus DROP list, there is no point in analyzing it further; it should just be blocked.
In this stage, Flow Control Policies are evaluated. Flow Control allows admins to define and enforce sequences (flows) of requests submitted by traffic sources.
Example: a web application has a login page. A legitimate user will submit a GET request to access the page, followed by a POST request with login credentials. Conversely, a threat actor waging a brute-force attack might conserve resources by submitting a series of POSTS, without any GETs. A Flow Control Policy can allow the legitimate user to access the page, while excluding the threat actor.
Rate limiting restricts the rate at which the system will accept requests from traffic sources. When a limit is exceeded, an action can be taken.
In this stage, rate limiting is enforced upon incoming requests, regardless of their destination URLs. The limits are defined in Rate Limit Rules with Global mode enabled.
In this stage, path-specific rate limiting is enforced. Admins can define different parameters for the limits, depending on the request's destination URL.
Path-specific rate limiting can be configured in two places within the system:
Rate Limit Rules that do not have Global mode enabled.
Proxy Templates, which allow for IP-based rate limiting to be defined for all applications based upon them.
An ACL Profile defines what will happen to a request, based on the tags that it contains. Admins can assign a variety of available actions that will be performed.
As shown in the diagram above, three outcomes are possible:
The request triggers an Action.
The request is passed, and then subjected to content filtering.
The request is passed, but is exempted from content filtering.
In this stage, the applicable Content Filter Profile is used to evaluate the request. Each Profile defines the applicability of various Content Filter Rules.
This stage fulfills the traditional role of a WAF, which is to examine the content of a request for threat signatures and take action when a match is found.
However, Content Filtering within Reblaze is much more powerful than this. Admins can configure Content Filter Profiles to allow or block requests if they do have specific characteristics, or if they don't.
When Edge Functions have a Phase setting of Response, Reblaze will execute them as the final step in its filtering.
When a request has passed all of Reblaze's traffic filtering, it is forwarded to the backend. The backend's response is then obtained, and returned to the client. Reblaze's interaction with the backend is configured in Proxy Templates and Backend Services.
Various stages of processing can result in an Action being executed. Often, this is a blocking action, but other actions are possible as well, including the acceptance of the request and bypassing the remainder of the filtering process.
Reblaze stores all requests and their details, and makes them accessible in the Events Log.
The Dashboard and Events Log provide customizable displays of traffic and events.
Reblaze periodically reviews the most recent tranche of incoming requests and evaluates them using Dynamic Rules. Unlike the other stages of analysis described above, this is done after the requests have been processed, and the resulting responses have been returned to the user.
Dynamic Rules are not meant to pass or block specific requests. Instead, they are used to analyze the overall behavior of traffic sources, as shown in the requests they have recently submitted.
When a traffic source violates a Dynamic Rule, the traffic source is quarantined. Until the quarantine expires, two things occur:
The traffic source is added to the Quarantine list, where admins can monitor it.
The traffic source can also be banned, which means that future requests will be blocked. (As shown in the diagram above, this is done by adding the traffic source to an internal system-maintained Global Filter, automatically.)
