Bot and abuse traffic rarely announces itself as a spike. A source may generate 30–50 requests per minute — not catastrophic in isolation, but after ten minutes of sustained activity it looks exactly like scraping, automation or credential stuffing. An instant rate-limit decision is made per request; it does not capture the cumulative character of behavior spread across time.
WAAP signatures answer a different question: does this request match a known attack pattern? SQL injection, XSS and command injection can be caught by signature. But scraping, price harvesting, account enumeration or aggressive API consumption — traffic that looks legitimate per request — escapes signature-based protection because the WAAP asks "how bad is the content" rather than "how sustained is the behavior."
A temporary isolation model is needed in between. If a source has exhibited above-threshold behavior in the last N minutes, it should be isolated for M minutes without being permanently banned. During that window its traffic can be blocked, diverted to an explanation page or redirected to a different flow. When the window expires, the source is released automatically.
Implementing this model requires two distinct mechanisms: a tracking window that measures behavior over time, and a quarantine window that enforces isolation. They can run with different durations — short observation, longer penalty — or reversed to match application sensitivity. The action also should not be one-size-fits-all: a silent block suits confirmed automation, an explanation page suits borderline cases, and a redirect suits flow management.
TR7 Traffic Quarantine delivers this model in full: two separate time windows for tracking and quarantine, four key types, three action modes, quarantine status usable as a condition in other rules, and live visibility plus manual intervention from the vService monitor.
TR7 Traffic Quarantine combines behavior tracking and temporary isolation inside the same policy engine.
Every quarantine rule defines a tracking window and a quarantine window as independent parameters. The tracking window measures source behavior; the quarantine window determines how long the action is enforced after the threshold is crossed.
A source does not have to be identified by IP alone. The four options — IP, IP + user agent, Host + IP, and Host + IP + user agent — allow accurate differentiation across multi-domain, NAT and multi-tenant environments.
While in quarantine, traffic can be blocked silently, redirected to another URL, or served a custom content page. This allows a silent drop for confirmed bots, an explanatory message for real users who may have hit a limit, and a workflow-aligned redirect where needed.
A quarantined source generates a system-wide status signal. Other traffic, routing and content rules can reference this signal as a condition, enabling composite policies that react to an active quarantine without duplicating logic.
Traffic Quarantine brings behavior tracking, temporary isolation and operator control into a single operating model.
Each rule sets a tracking duration and a quarantine duration independently. Within the tracking window, source behavior is counted; when the threshold is exceeded, the source is held in a separate list for the quarantine window. When the quarantine window expires, the entry is dropped automatically. This design delivers controlled, time-bound isolation rather than a permanent ban.
The `ip` option provides classic source-IP tracking. `ipUa` distinguishes between different user agents behind the same IP, separating bot sessions from human sessions on shared addresses. `hostIp` counts traffic to each domain independently in multi-domain environments. `hostIpUa` provides the finest-grained separation for multi-tenant and multi-client deployments.
Operators define a threshold against a count within the tracking window. A rule such as "more than 100 requests in the last 10 minutes" triggers behavior-based quarantine. The decision is based on aggregate behavior across the window, not on a single request — this is the fundamental distinction from rate limiting, which is observation-driven rather than per-request.
The `block` action silently drops requests from a quarantined source. For bot and automation traffic this is often the most effective response: the attacker receives no application feedback and typically stops. This action suits high-risk abuse scenarios where no explanation is appropriate. Impact on real users can be monitored through the vService monitor.
`showContent` returns a custom HTTP status code and content body to a quarantined source. For example, a page explaining that the source has been temporarily limited due to excessive requests can be shown. This model is softer than a block and is appropriate when false-positive risk exists or when user experience matters. The message content can be prepared in the organization's support language and branding.
`redirect` sends a quarantined source to a different URL. Targets can include a CAPTCHA page, an explanation portal, a subscription upgrade page or a support page. Quarantine becomes not just a barrier but a mechanism to move users to the correct workflow. This option is especially valuable in multi-tenant and SaaS environments.
Whether a source is currently in quarantine can be used as a condition in other rules. Quarantined sources can be routed to a different backend, assigned custom response headers, served different content, or placed under a second, stricter rule. This turns a single quarantine rule into a system-wide behavioral signal — one of TR7's most important differentiators.
Traffic Quarantine is available for both HTTP and TCP services. On the HTTP side, request-level behavior is tracked; on the TCP side, the decision is made at the connection level. The technical outcome of the action differs by protocol, but the fundamental model is the same: observe, isolate sources that exceed the threshold, release them when the window expires.
Active quarantined sources are listed in the vService live monitoring view. Operators can see which key is in quarantine, which rule triggered it and how long it has been held. Manual release is supported — a legitimate power user or false positive can be freed immediately. Expired entries are cleaned up automatically, so manual intervention is optional.
More than one quarantine rule can run simultaneously under the same vService. For example, a first rule can show a warning page for excessive requests while a second rule blocks sources that are still generating traffic while already in quarantine. Up to 5 parallel quarantine rules per vService are supported. This structure builds enforcement that escalates from soft to hard.
Traffic Quarantine is managed operationally through its table lifecycle, cluster behavior, reload impact, monitoring view and audit records.
Each quarantine rule uses two separate live tracking areas — one for the tracking window and one for the quarantine window. Entries are held with a TTL and cleaned up automatically when it expires. Incoming requests continuously update the tracking window behavior. This keeps quarantine as time-bound behavioral control rather than a permanent ban.
For every incoming request, the key formula is computed, the tracked value is updated, and the quarantine condition is evaluated. If the source is already in quarantine, the defined action is applied. If not, the request proceeds through the normal traffic path. The decision happens in the data path at low cost.
In dual-node deployments, quarantine tables can be kept local or run in synchronized mode. When synchronization is not enabled, a new active node after failover rebuilds its quarantine history from scratch. When synchronization is enabled, quarantine state is preserved across failover. The right choice depends on operational requirements and the deployment model.
Quarantine tables are held in memory and do not behave as a persistent blacklist. After a soft reload or table reset, active quarantine state may be cleared. This is acceptable behavior: quarantine is a temporary isolation mechanism, not a permanent ban. When long-term banning is required, it should be used together with IP reputation feeds.
Active quarantine entries are visible in the vService monitor, and an operator can release a specific source from quarantine. The table entry is deleted and the next request from that source is evaluated in the normal traffic path. This provides a fast response for VIP users, false positives or support requests.
Quarantine and release events can be written to the audit log. When SIEM log streaming is enabled, events are forwarded to an external collector. Which key was quarantined, by which rule, with which action and for how long can all be reviewed after the fact.
Active key count and key type affect memory consumption. IP-based keys are compact; combined keys such as Host + IP + user agent consume more space. Because up to 5 parallel quarantine rules per vService are supported, capacity planning should be aligned with the traffic profile.
An e-commerce site can track price-scraping sources with the `ipUa` key. Any IP + user agent combination that exceeds 100 requests in 5 minutes is blocked for 30 minutes, while legitimate human traffic from the same IP using a different user agent is tracked as a separate key and is unaffected.
A banking portal can track repeated login attempts on the login endpoint by IP or IP + user agent. When the threshold is crossed, the source is served an explanatory page for 60 minutes, informing the real user of the temporary restriction.
A SaaS platform hosting multiple domains can track each tenant's traffic independently using the `hostIp` key. One tenant's aggressive usage can be placed under a redirect or temporary block without affecting traffic from any other tenant.
A first rule redirects excessive-request sources to a warning page for 10 minutes. If the source continues generating traffic while already in quarantine, a second rule applies a 60-minute block. Using quarantine status as a condition in another rule is what makes this escalation model possible.
Behavior-based temporary isolation, composite rule design and live operator visibility. Let's walk through how it works in your own environment.