How Does LiveShield Detect a DDoS Attack?

LiveShield detects a DDoS attack by calculating concrete traffic thresholds in real time, namely packets per second and bandwidth, separately for each analyzed protocol, separately for individual IP addresses and separately for entire subnets. It is not an opaque "black box" mechanism described in general terms as "artificial intelligence". It is a set of openly configurable parameters that the operator sets and tunes to the characteristics of their own network.

This distinction has practical, not just marketing, significance: an operator who knows exactly what the system measures and what it bases its decisions on can predict its behavior, tune it to their own network and diagnose why a given rule was triggered. That is impossible with a system described only by the slogan "AI".

The system calculates thresholds separately for each of more than a dozen analyzed protocols and traffic types, including: total IP traffic, TCP, UDP, TCP-SYN traffic (connection establishment), ICMP, IP fragmentation (IPFRAG), small UDP packets (SMALL_UDP), and typical amplification vectors used in DNS, NTP, SSDP, CHARGEN, SNMP, CLDAP or Memcached attacks. For a single prefix, the system maintains the full set of these thresholds both at the level of an individual IP address and at the level of the entire subnet.

Separating thresholds per protocol has a direct effect on the precision of the response: instead of one general rule "too much traffic to this address", the system recognizes that the threshold for UDP amplification traffic, or for IP fragments, has been exceeded, and responds with a rule matched to the specific attack vector rather than blocking all traffic to that address.

LiveShield analyzes traffic at the level of individual IP addresses and entire subnets simultaneously, because an attack aimed at a single address and an attack spread across many addresses at once (carpet bombing) require different detection approaches.

Per-IP detection works for a classic attack on a single target: the threshold is clearly exceeded on one address, and the rule can go down to a single address (a /32 mask). An attack spread across many addresses at once, by contrast, is by definition designed to bypass per-IP thresholds: each individual address receives a relatively small volume of traffic, not enough to exceed the threshold, even though the total traffic to the entire subnet is already an attack. That is why per-subnet thresholds must be configured separately, independently of the per-IP thresholds. One does not replace the other.

When the system detects a pattern indicating an attack spread across many addresses, only the per-subnet rules are triggered, and the system automatically looks for the largest possible mask that covers the attacked addresses as precisely as possible. The mechanism first tries the narrowest possible mask (e.g. /32), and if that does not work, as is typical of genuine carpet bombing where the attack actually covers many different addresses, the system gradually widens the rule, e.g. to /29, /28, up to the entire attacked subnet, depending on how widely the attacked addresses are spread.

This mechanism is also a safeguard against overloading the detection system itself: without aggregation into broader rules, an attack on hundreds or thousands of addresses at once would have to generate just as many separate /32 rules, which would burden both the system and the rule tables on the edge routers.

LiveShield offers two filtering modes for individual protocols: prefiltering, which relies solely on a traffic threshold being exceeded (packets per second and/or bandwidth) with no additional analysis of packet contents, and advanced filtering, which additionally analyzes more detailed traffic characteristics, such as destination ports or TCP flags, to generate a narrower rule better matched to the specific attack.

The choice between these modes is a trade-off between precision and risk: prefiltering reacts faster and more simply, but with carelessly chosen thresholds it may also cut off some legitimate traffic with similar characteristics. Advanced filtering allows the rule to be narrowed more precisely, but requires that the additional criteria (e.g. a specific port) actually match the nature of the traffic on a given type of address. In practice, this means that different filtering profiles are chosen for different groups of addresses in the network (e.g. ordinary customers versus servers that listen on many ports), rather than one universal rule for the whole network.

There is no single universal set of thresholds suitable for every network, because the nature of normal traffic differs significantly between segments of the same infrastructure: traffic typical of address pools behind NAT differs from that on addresses assigned directly to customers, and differs again from that on server addresses, which by nature receive large, varied traffic from many sources at once.

That is why a LiveShield deployment in practice includes a stage of observing production traffic and iteratively tuning thresholds to the specific network, rather than a one-time configuration treated as final. This applies both to the per-protocol thresholds and to the threshold that decides escalation from FlowSpec to RTBH (based on the percentage of traffic the system managed to filter out). The configuration is fully accessible to the operator and can be changed as data from real traffic accumulates, without vendor intervention.

Attack detection in LiveShield is based on an open, configurable set of traffic thresholds calculated separately for each of more than a dozen protocols and attack vectors, simultaneously at the level of individual IP addresses and entire subnets. Attacks spread across many addresses are detected by a separate aggregation mechanism that automatically selects the narrowest effective subnet mask, and the operator chooses the level of filtering detail (prefiltering or advanced filtering) individually to match the nature of traffic in a given network segment. It is this transparency and configurability, not the general slogan "artificial intelligence", that is responsible for the system's effectiveness and predictability in practice.

How does LiveShield detect a carpet bombing attack? When the traffic pattern indicates an attack spread across many addresses at once, the per-subnet rules are triggered, and the system automatically selects the narrowest possible subnet mask covering the attacked addresses, gradually widening it if a narrower mask is not enough.

What is the difference between prefiltering and advanced filtering? Prefiltering reacts solely to a traffic threshold being exceeded, without analyzing additional packet characteristics. Advanced filtering additionally analyzes details such as the destination port or TCP flags to generate a narrower, more precise filtering rule.

Do detection thresholds need to be tuned manually after deployment? Yes. The nature of normal traffic differs between network segments (e.g. addresses behind NAT, customer addresses, server addresses), so deployment includes a stage of observation and iterative tuning of thresholds to the specific infrastructure.