Why DDoS protection lets behavioral attacks through
The attack does not arrive as a spike but as a steady background: tens of thousands of addresses, each sending one or two requests per minute. The per-address threshold is not exceeded, so basic DDoS protection sees the load as normal.
In aggregate, the flow keeps the application at the edge of its capacity — and the service begins to degrade.
Static rules and rate thresholds catch crude attacks, but a low-intensity attack is invisible to them. Behavioral attacks on a website are spread across addresses and time, while the session looks alive: full handshake, session tokens, referrer header, pauses between actions.
The filter sensitivity cannot be increased — false positives will increase during a campaign or sale spike, and we will cut off real buyers.
Service degradation under load follows a chain. First, response time increases for expensive operations — search, authorization, catalog rendering. Then the database connection pool is exhausted, and all sections fail.
Monitoring shows a formally normal request flow because it counts their number, not the cost of servicing them.
We explain how this is addressed: a behavioral profile instead of a per-address threshold, adaptive thresholds for each entry point, and mitigation based on session attributes rather than a single frequency attribute.
What adaptive traffic mitigation provides
Adaptive mitigation relies on a behavioral traffic model: daily request rhythm, ratio of anonymous to authorized sessions, source spread, and browsing depth.
Traffic anomaly detection is based on deviation from a baseline, not on a static signature list, so a change in the attack vector does not require manual reconfiguration of rules.
Triggering is automatic: filtering turns on at the edge, and the rest of the traffic flows without delays.
Detection time and automatic triggering
Static thresholds become visible only when the attack is already reflected in monitoring — usually after user complaints. The model notices a deviation within tens of seconds: a rise in identical requests, a spike in authorization failures, an atypical spread of addresses.
Rules are applied to the entire flow, so attack response time does not depend on whether an engineer is on shift, and metrics and triggers are collected via Prometheus — the picture is visible in dynamics.
False blocking of real users
The main risk of strict filtering is cutting off live customers: corporate networks with a shared address, mobile operators, search engine bots.
The model evaluates session behavior, not just the address, so the restriction catches flows with anomalous attributes, while an ordinary buyer passes the check without a CAPTCHA. Disputed sessions go to a soft check instead of blocking.
| Metric | Before | After |
|---|---|---|
| Anomaly detection time | minutes, based on complaints | tens of seconds |
| False blocks | a few percent of sessions | fractions of a percent |
| Availability at peak | degradation and failures | target load |
Service resilience under load no longer depends on manual actions of the on-call shift: the model maintains the baseline and updates it as the product grows.
DDoS protection modes: always-on, on-demand, hybrid
The modes differ not in the level of filtering, but in when traffic enters the protection perimeter.
Always-on channel protection keeps the flow through the filter at all times, on-demand protection activation only after a signal that an attack has begun, and a hybrid filtering scheme distributes services between these approaches. The difference shows up in response delay and in the amount of operational effort.
Always-on mode and on-demand mode
Always-on mode gives zero activation delay: traffic filtering modes are already applied when an attack begins, so short spikes do not reach the service.
The trade-off is that the entire inbound flow goes through the protection perimeter, including legitimate peaks, and application debugging requires accounting for this layer.
| Option | When it fits | Limitations |
|---|---|---|
| Always-on channel protection | Round-the-clock flow, regular attacks, strict latency requirements | All traffic goes through the filter, diagnostics of your own services is more difficult |
| On-demand activation | Rare spikes, predictable load profile | Window between signal and activation, short attacks manage to pass through |
| Hybrid filtering scheme | Different service criticality, seasonal peaks | Requires a switching procedure and control of rule consistency |
When a hybrid scheme is justified
The hybrid is divided by criticality: the payment circuit and authorization are kept under always-on filtering, while the storefront and static content are on-demand. This option is chosen when peaks are seasonal and systems have different sensitivity to latency.
There is one limitation: the two perimeters require consistent rules and regular switching checks — otherwise protection exists on paper, not at the moment of an attack.
Perimeters of this class, such as Cloudflare, support both modes, so the choice is determined by the load profile, not by the provider's capabilities.
Stages of implementing behavioral traffic analysis
The implementation of behavioral analysis proceeds in steps, where each next step relies on data from the previous one: first we look at what actually arrives at the perimeter, and only then do we turn on the response. Below is how the work is structured from audit to handover of the protection system into operation.
Traffic audit and baseline building
A traffic audit answers two questions: what to consider normal and where the critical boundary lies.
Based on the history of requests, seasonal peaks, and past incidents, a behavioral baseline is built — a profile of sources, request types, and their ratio at different times of day.
- Traffic audit — inventory of entry points, analysis of request and incident history, identification of services where downtime is unacceptable.
- Activation scheme — first a monitoring mode with traffic mirroring; blocking is turned on as a separate step, after verification.
- Model training on your own traffic — profiles are built on the customer's data, including promotions and seasonal spikes, not only on typical attack patterns.
- Threshold tuning — we select sensitivity so that a spike is caught quickly, while legitimate customers are not blocked.
- Protection testing under load — we reproduce scenarios on a test flow, measure the false positive rate and response time.
- Handover — on-call procedures, monitoring dashboards, incident analysis, and shift training.
Threshold tuning and testing under real load
Thresholds are not set once: they are refined based on actual operation, when it is clear how the system behaves at a live peak. A mandatory part of acceptance is rolling back to monitoring with one command if the response turned out to be excessive.
Filtering schemes, procedures, and handover to the team
We consider the work complete not at the moment protection is turned on, but when your team maintains it on its own.
Therefore, along with the configured rules, we hand over descriptions that let the on-call engineer act without us — from reading the traffic scheme to rolling back a change.
What is included in the handover document package
- Traffic flow scheme — all points where a request is inspected, filtered, or sent to shadow, with notes on which segment is managed by what and where traffic goes if a node fails.
- Filtering rule configurations — exception lists, trigger thresholds, monitoring mode for new rules, so that enabling protection does not break legitimate sessions.
- Management access matrix — permission levels: view, change thresholds, enable active mode, full access. Roles are separated, and every change is logged.
- Incident response procedure — criticality levels, who makes the decision, within what time, at what point we get involved, and when the on-call shift handles it.
- Instructions for the on-call shift — step-by-step actions for typical situations: growth of suspicious traffic, a false trigger, a complaint about service unavailability.
- Verification and rollback procedure — how to make sure a new rule does not cut off anything extra, and how to return to the previous configuration with a single operation.
- List of metrics and where to view them — what the system logs automatically, and by which deviations to understand that escalation is needed.
We keep the documents in your perimeter and in your language of description — after handover, nothing remains "in the contractor's head." We separately conduct handover of settings to the team: we go over real triggers on your data, show how a rule is changed and how the result is verified.
Case study: reducing false blocks during peak attacks
A service with sharp demand peaks — evening hours and sale launches — kept protection on strict trigger thresholds based on the request rate from a single address.
Such rules could not distinguish an attack masked as a spike of legitimate traffic from real buyers: live sessions were blocked, and the on-call engineer removed restrictions manually, analyzing each incident from logs.
We added behavioral analysis on the flow: the model looks not only at request frequency, but also at the sequence of actions, depth of progression through pages, and the typicality of the "search — product card — cart" chain.
When the share of disputed decisions in a specific segment rises above a set level, thresholds are automatically relaxed, and the reasons for each trigger are written to a common log.
The metrics dashboard is built in Grafana, so the on-call engineer sees which rule triggered, by what attribute, and how many requests were affected.
Metrics before and after implementation
Removing blocks is no longer a separate shift task: automation handles typical peaks on its own, and manual intervention remains for non-standard scenarios.
The freed-up time is spent by on-call engineers on analyzing attempts to bypass protection, rather than on restoring access for buyers.
How does behavioral analysis differ from signature-based analysis?
Signature-based filtering compares a request against a database of pre-described patterns: if a set of attributes matches, the flow is cut off at the edge.
Behavioral traffic analysis does not look for matches: it builds a profile of normal behavior for the service — distribution of requests across addresses, ratio of dynamic and static content, source connectivity, and rate of load growth.
Hence the first difference — trigger conditions. A signature needs an exact attribute: as soon as the field order or set of requests changes, the rule stops seeing the flow.
The behavioral perimeter triggers on deviation from the profile, so it raises protection for a pattern that is not yet in the database.
Second — adaptation to new attack patterns. A signature must be noticed, described, and rolled out, and all that time the flow goes to the service.
The behavioral model reacts to an anomaly immediately, but it needs an accumulated profile: until it is collected, signatures work, and thresholds have to be calibrated so that legitimate spikes do not fall under the filter.
Third — manual rule maintenance. A signature set becomes overgrown with exceptions for legitimate scenarios: partner exports, monitoring, search engine bots. Each exception needs an owner and review, otherwise protection starts blocking its own. In a behavioral perimeter, you adjust thresholds and weights, not the pattern list.
In practice, comparison of filtering approaches ends in a combination: signatures are a cheap cutoff for the known volume, behavioral analysis for the remainder.
The share of automatically cut-off traffic grows, response to a new pattern speeds up, and there are fewer manual rules.
Technical doubts before implementation
Engineering teams ask the same questions before starting: will the model coexist with existing filtering, how much data is needed, will response latency increase. Below are direct answers, without promises of "complete invisibility."
We already have filtering in place — will the new solution conflict with it?
The model becomes a second perimeter after existing rules, not instead of them. We pass the current protection's verdicts (triggered thresholds, lists, denials) as attributes — the rule remains a fast filter, and the behavioral model analyzes what passed it.
How much data is needed for the model to learn?
Logs of normal traffic for several weeks of a typical profile are enough — with seasonality, peaks, and releases.
At the start, a generalized behavior profile works; then the model is further trained on your traffic; with a short history, we supplement the sample with synthetic scenarios.
Will service response time increase?
Attributes are collected asynchronously, outside business logic processing, so the application response time does not change.
If the telemetry channel is overloaded, the verdict is taken from the latest calculated profiles rather than blocking the request while waiting for recalculation.
What will have to be changed in the architecture?
The activation points are the load balancer and the network boundary; there is no need to go into the application or database.
We deploy in shadow mode: the solution calculates verdicts but blocks nothing until we compare them with the current protection and agree on trigger thresholds.
How do you decommission protection without downtime?
Switching is done in traffic shares: first a small portion of requests, then the entire load. Rollback means returning the share to the previous perimeter; configuration is stored in a repository, so any state is reproducible, and old rules can be left disabled as a reserve.
What to discuss at the first task review
Preparing for the task review takes the customer an hour or two but saves weeks of back-and-forth. We need facts about the service: how it looks from the outside, what is critical in it, how you have already responded to attacks.
With this data set, we will more quickly propose a filtering mode, trigger thresholds, and rules that will not affect live users.
- Description of past attacks: when it started, how long it lasted, what failed first — login, payment, search, or data exchange with partners.
- Traffic flow scheme: where the load balancer is located, which nodes accept external connections, whether there are third-party intermediaries and external services on the request path.
- Service availability requirements: which scenarios must always work, and which may be limited during an attack in favor of resilience.
- Decision-making procedure for blocking: who has the right to enable strict mode, by what attribute, how the decision is recorded and how it is removed.
- On-call shift mode: who is on call, during what hours, how context is handed over between shifts, which notifications are considered urgent.
- Infrastructure constraints: what cannot be changed — partner integrations, fixed addresses, payment provider requirements — and what measures you have already tried.
Send what you have, even in draft form: we will complete the scheme together. After the review, we will return with an estimate and work plan — stages, timelines, responsibility areas, and metrics by which we will verify the result.
