Flow Control Policies
Tagging valid or invalid session flow patterns
Last updated
Was this helpful?
Tagging valid or invalid session flow patterns
Last updated
Was this helpful?
Flow Control Policies allow admins to define "flow" sequences of submitted requests. As incoming traffic is received, the requests are evaluated against the active Policies. If a defined sequence is completed--in other words, if the listed requests are received in the specified order--the Policy will attach one or more tags to the final request in the sequence. The tags can subsequently trigger an action (allow, block, challenge, etc.)
Reblaze includes several types of behavioral profiling and control. Flow Control Policies are one type of behavioral control that are defined by admins. They can allow, or disallow, traffic sources that display specific patterns of behavior.
Use case example: A web application has a login page. A legitimate user session will begin with a GET request, followed by a POST. However, threat actors who are waging brute-force login attacks will typically just send a series of POSTs. A Flow Control Policy can be the basis for blocking every POST request that was not preceded by a GET.
A Flow Control Policy's purpose is to assign its defined Tags to the last request in defined flow sequences. The Tags can then be used in Rate Limit Rules or ACL Profiles to trigger specific actions. Usually, a Global Filter is involved in the process as well (see the implementation example below).
Unlike some other types of security settings, Flow Control Policies are not assigned to paths in Security Policies, because a Flow Control Policy can incorporate multiple paths within an application or API.
Instead, each Policy has its applicable scope defined by the Active, Include, and Exclude parameters, as described below.
To implement the GET/POST example mentioned above, an admin would create the following configuration:
A Global Filter would assign a tag (e.g., method-post) to all POST requests sent to /login.
A Flow Control Policy would assign a tag (e.g., login-flow) to each POST that was preceded by a GET.
An ACL Profile would Block/Skip all requests tagged with login-flow, and Block/Apply all requests tagged with method-post.
The main page (shown above) lists all current Flow Control Policies.
The administration (addition/deletion/editing/versioning) of Policies follows the conventions described here.
Each Flow Control Policy consists of:
A flow sequence: A list of two or requests that are expected to be received in the sequence shown, within the specified Time frame.
Tag(s) to assign to the final request in the defined flow sequence.
Include/Exclude: Tags to define the scope within which this Policy is enforced.
Count by parameters for identifying distinct flow sequences within incoming traffic. In other words, these settings tell the system how to separate incoming requests into distinct groups, each of which will be evaluated separately for flow sequence analysis. Usually, admins will want to enforce flow sequences on individual users (for example, according to IP address).
General parameters for administrative purposes.
Each of these is described in depth below.
A name for this Policy, to be used within the Reblaze interface. A system tag (shown below the Tags field) will include it as well.
When this toggle is selected, the Policy will be enforced within its defined scope.
This defines the time available for the flow sequence to be completed. When the first request in the sequence is received, an internal timer begins. The final request must be received within the Time Frame in order for the Tags to be assigned.
At any given time, an application might receive a variety of incoming requests from different users simultaneously, each of which might be at a different stage of a flow sequence. For Flow Control Policies to work successfully, the system must be able to differentiate among all the various streams of incoming traffic, and perform stateful evaluations of each one separately.
The Count by parameter allows admins to define how this differentiation is done. For example, a common configuration is Attribute / IP Address. When the application is receiving requests from multiple IP addresses simultaneously, the requests from each IP will be considered as a separate and distinct set for Flow Control purposes. On the other hand, if it is possible that users will sometimes share IP addresses, then a better choice might be Attribute / Session ID.
Admins have a variety of configuration options for this parameter. Incoming requests can be processed according to specific headers, cookies, arguments, or attributes.
Multifactorial Count by definitions can be set up by selecting "New entry" and editing the controls that appear. When incoming requests are evaluated, the Count by definitions are combined with a logical AND.
Enter one or more unique tags, separated by spaces. When a series of incoming requests matches the flow control sequence, the tags listed here will be attached to the final request.
In addition to these admin-defined tags, the system also shows some system tags that will be attached as well.
Information about this Policy, for use within the interface.
These are lists of tags that can limit the applicable scope for this Policy. Their use is described on the UI Overview page.
This is an admin-defined sequence of at least two steps.
The system maintains stateful histories of each traffic stream defined by the Count by parameter. When a series of incoming requests matches the Flow Control Sequence exactly, the final request has the defined Tags attached.
Each step in the sequence is defined by a Method, Host, and Path, along with any optional parameters added by an admin.
A new Flow Control Policy includes a two-step sequence by default. To add additional steps, select the "Add Step" button.
