The most common mistake in traditional DDoS protection is applying the same fixed threshold to every service. A simple rule like "block above 100 requests per second" may react too slowly for a low-traffic service and produce false blocks for an e-commerce site during a campaign. Every application has its own normal traffic volume, path distribution, client profile and connection behaviour.
L7 DDoS attacks do not always arrive with high packet counts or high request rates. Slowloris-style attacks — low rate but many open connections — as well as SSL connection floods, rising error rates, bot behaviour and load concentrated on specific endpoints can all defeat classic rate-limit logic. Making decisions from a single counter is therefore not sufficient.
A further problem is that protection actions are often one-size-fits-all. If every suspicious request is immediately dropped, legitimate users are affected; if a captcha is shown in every case, the user experience degrades. Silent drop is correct in some scenarios, redirect in others, an informational page in others, and a self-hosted captcha in others still.
The right approach is to learn per-service traffic behaviour, evaluate L4 and L7 signals together and choose the action based on conditions. Whitelist rules, path behaviour, connection count, request rate, bot score and IP reputation should all participate in the same decision pipeline.
TR7 Adaptive DDoS Learning delivers this model: it monitors service traffic, converts learned behaviour into policy recommendations and applies controlled protection actions with operator approval.
TR7 applies DDoS decisions through counter collection, combined conditions, learned baselines and a graduated action model.
TR7 tracks connection, request, error and SSL behaviour using global and per-tracking-key counters. These figures form the core signals for per-service DDoS conditions.
`ddosCond` lets multiple ACL conditions be combined with AND, OR and NOT logic. Decisions can therefore be based not only on request rate but also on SSL connection count, error rate, bot score, IP reputation or path behaviour.
Service, path and request behaviour is analysed from historical traffic and log data. Learned values are presented to the operator as recommendations and become an enforceable policy once approved.
TR7 supports deny, redirect, showContent and showCaptcha actions. Depending on service sensitivity, the operator can choose silent drop, redirect, a custom response page or a self-hosted captcha.
Adaptive DDoS Learning combines per-service traffic signals with learned behaviour to deliver more precise L4/L7 protection.
TR7 uses a flag model that can mark DDoS status at the global level. When a service or tracking condition triggers an attack state, that information can be used as a signal in other protection decisions. DDoS is therefore treated as part of system-wide behaviour, not just an isolated request event. Operations teams get a clearer view of the overall protection mode during an incident.
Alongside the global signal, a per-request DDoS flag is also available. Whether a request has been caught by a DDoS condition can be determined at the transaction level. Action is therefore applied only to the relevant flow — there is no need to place all traffic in the same bucket unnecessarily. Fine-grained behaviour reduces the risk of false positives.
TR7 can track different keys such as HTTP request rate, HTTP error rate, connection rate, active connection count and SSL connection count. L7 behaviour is prominent for HTTP services; connection-based signals lead for TCP services. This distinction enables selecting the right DDoS indicator for each service type, so decisions are based on the appropriate signal set rather than a single counter.
A shorter tracking window catches fast attack bursts more quickly; a longer window makes slow, sustained behaviour visible. TR7 makes this duration configurable per service need. Short default windows are suitable for a quick start, but production policy should be shaped to the service profile. This flexibility helps distinguish sudden campaign traffic spikes from slow DDoS behaviour.
`ddosWhitelistCond` can exempt specific IPs, ASNs, paths or trusted traffic sources from DDoS actions. This is especially important for search engine bots, enterprise integrations, monitoring systems or partner API traffic. The whitelist does not have to be a static list; it can be written with condition logic for finer control. Business-critical flows remain protected even when protection becomes more aggressive.
TR7 supports deny, redirect, showContent and showCaptcha actions. deny is the most aggressive silent-drop approach; redirect moves traffic to another location; showContent returns a custom page with a specific status code; showCaptcha initiates user verification. This variety means not every attack is met with the same level of force. The operator selects the right response based on service value and false-positive risk.
TR7 can serve multi-language verification pages in DDoS challenge scenarios. These pages present the control flow to users without relying on an external third-party service. The self-hosted challenge approach is an advantage in sectors with data-sharing and compliance sensitivity. Instead of simply showing an error, users receive a controlled verification experience.
TR7 can derive a per-service normal profile from historical log and traffic data. Expected traffic per path, typical error rate or load behaviour can be presented to the operator as recommendations. The operator reviews and approves these to convert them into DDoS conditions. This approach makes it easier to build policy from observed real traffic rather than writing thresholds blindly.
Bot protection scores can be used as auxiliary signals in DDoS decisions. Factors such as datacenter IP, Tor exit, poor IP reputation, user agent analysis, header fingerprint and TLS fingerprint can all affect the risk score. When the bot score exceeds a configured threshold, deny, redirect or captcha action can be triggered. DDoS protection therefore looks not only at volume but also at client quality.
TR7 can use 13 IP reputation categories as decision signals: open proxy, bad bot, brute force, web application attack, SQL injection, hacking, DDoS attack, exploited host, port scan, web spam, email spam, blog spam and VPN IP. These categories do not need to be definitive on their own — they contribute additional risk weight inside a combined condition. Known bad sources are therefore separated from normal user traffic more quickly, making protection policy more context-aware.
TR7 can derive per-service recommendations from signals such as connection rate, active connections, request rate, error rate and path behaviour. These recommendations are reviewed by the operator rather than applied blindly. Approved values are converted into DDoS conditions and action policies. This model keeps automation under control — learning, human approval and enforceable policy work together.
The operations team can also activate DDoS status manually during an attack. This is useful for taking fast protective action without waiting for automatic learning or condition triggers to fire. Manual mode provides a temporary defence layer especially during the incident response process. Conditions identified post-incident can be formalised into permanent policy.
Adaptive DDoS protection is operated alongside thresholds, condition composition, action selection, whitelist rules, bot score and challenge behaviour.
When the bot protection score reaches a configured threshold, actions such as deny, redirect or captcha can be triggered. This threshold must be applied carefully based on service sensitivity. Evaluating it together with request behaviour and whitelist conditions — rather than relying on the bot score alone — produces more reliable results.
The global DDoS tracking model can maintain a counter for single-system state. This structure helps understand the system-wide attack state alongside per-service conditions. During an incident, operations teams monitor not just a single request but also the aggregate behaviour signal.
When the DDoS flag is active, the selected protection action is applied. deny provides silent drop; redirect performs redirection; showContent serves custom content; showCaptcha initiates the challenge flow. Action selection should be made according to service value, user experience and attack severity.
In the showContent action, the status code, content-type and content profile are all customisable. This allows the organisation's own message to be shown to users instead of a generic error. The feature is valuable for maintenance windows, incident communication and compliance messaging.
The showCaptcha action can invoke TR7's own CAPTCHA module, reducing dependency on an external third-party verification service. This approach delivers a more controlled verification flow for organisations with data protection and regulatory sensitivity.
Multiple signals can be combined inside `ddosCond` using AND, OR and NOT logic. For example, a high request rate can be evaluated together with a specific path concentration and an IP reputation category rather than in isolation. This reduces false positives while enabling more targeted action.
E-commerce teams can use per-service DDoS conditions to separate a traffic surge during a campaign from an actual attack. Trusted crawlers or partner sources are whitelisted while abnormal path and request behaviour is mapped to protective actions.
Banking applications can jointly monitor HTTP request rate, SSL connection count and error rate on login traffic. When thresholds are exceeded, redirect, captcha or deny actions are applied according to service policy.
Public portals can use their own TR7 challenge pages without sending data to an external verification service. Multi-language content keeps the user verification flow under institutional control.
Attacks that generate a high number of open connections despite a low request rate can be monitored through connection count and duration behaviour. TR7 makes connection-exhausting slow attack patterns visible — not just high PPS floods.
Walk through baseline learning, combined conditions and the graduated action model on your own services.