Traffic Filtering Process
Last updated
Was this helpful?
Last updated
Was this helpful?
Link11 WAAP 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.
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.
Subsequently, the attached tags can be the basis for decisions about the disposition of the request.
Attaching tags when the request matches specified criteria.
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, 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:
As shown in the diagram above, three outcomes are possible:
The request is passed, and then subjected to content filtering.
The request is passed, but is exempted from content filtering.
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 L11WAAP 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.
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 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.)
When processing an incoming request, L11WAAP 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 L11WAAP decides which rulesets are applicable to a request, see the page.
Link11 WAAP 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 , which often is either a blocking action or a . Along the way, L11WAAP logs the request and the actions that occur, which are available to admins via analytics and dashboards.
Before any other processing occurs, L11WAAP can execute one or more . An Edge Function consists of custom Lua code; it allows admins to extend the system's capabilities as desired.
Each Edge Function contains a parameter. When this is set to Request, the Function is executed immediately when processing of the request begins.
L11WAAP uses a when processing and evaluating requests. At various points during processing, tags are attached to a request based on its source, content, and other characteristics.
In this stage of processing, each request receives a . For example, every request will be tagged with all, along with tags for the geolocation of the traffic source.
This stage is also when L11WAAP performs : determining which security rulesets should be enforced upon the request.
The stage has two primary purposes:
Executing an depending on the tags that were attached. In some situations, admins will decide to stop ths system's processing at the Global Filter stage. For example, an admin can decide that if the traffic source is found on a hostile IP list, there is no point in analyzing it further; it should just be blocked.
In this stage, are evaluated. Flow Control allows admins to define and enforce sequences (flows) of requests submitted by traffic sources.
In this stage, rate limiting is enforced upon incoming requests, regardless of their destination URLs. The limits are defined in with enabled.
that do not have enabled.
, which allow for IP-based rate limiting to be defined for all applications based upon them.
An 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.
The request triggers an .
In this stage, the applicable is used to evaluate the request. Each Profile defines the applicability of various .
When have a setting of Response, L11WAAP will execute them as the final step in its filtering.
When a request has passed all of the system's traffic filtering, it is forwarded to the backend. The backend's response is then obtained, and returned to the client. L11WAAP's interaction with the backend is configured in and .
Various stages of processing can result in an being executed. Often, this is a blocking action, but as well, including the acceptance of the request and bypassing the remainder of the filtering process.
L11WAAP stores all requests and their details, and makes them accessible in the .
The and provide customizable displays of traffic and events.
L11WAAP periodically reviews the most recent tranche of incoming requests and evaluates them using . 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.
The traffic source is added to the list, where admins can monitor it.
