Will LiveShield Respond to a DDoS Attack Within 1 Second?
How Long Does It Take LiveShield to Detect and Stop a DDoS Attack?
LiveShield detects a DDoS attack and deploys the first filtering rule almost immediately: in a controlled test on a live attack, the system detected the threat and installed the first rule in the same second in which the attack started. This is the result of an architecture based on real-time, in-memory traffic analysis, with no database on the critical detection path.
In DDoS protection, time translates directly into the impact of an attack: the longer detection and deployment of filtering take, the longer attack traffic reaches the customer's infrastructure, loading links, routers and edge devices. That is why, instead of relying solely on the claim "we react instantly", we show a real test on a comparable attack, run in parallel with another popular market solution.
How the test was run
On 21 November, a test was carried out on a live attack with parameters of 700 kpps / 6.5 Gb/s, made up of three simultaneous vectors: IP fragmentation (IP Fragments), DNS amplification and UDP flood. The traffic was analyzed in parallel by LiveShield and by another anti-DDoS solution widely used in the industry, on the same infrastructure and at the same moment of the attack, which made it possible to directly compare the response time of both systems to identical traffic.
The test deliberately involved a multi-vector attack rather than a single, simple flood. In practice DDoS attacks rarely limit themselves to one type of traffic, so checking how a system copes with several overlapping patterns at once gives a more credible picture.
Results: detection and first rule in the same second
LiveShield detected the attack and deployed the first filtering rule (for DNS traffic) in the same second. The compared solution detected the attack with a 4-second delay relative to LiveShield, and its first filtering rule (also for DNS traffic) was deployed 18 seconds after the moment at which LiveShield was already filtering that traffic.
For the second attack vector (IP fragmentation), the difference was 8 seconds in favor of LiveShield. The third vector (UDP to a specific destination port) LiveShield handled with another, separate rule. The compared solution, despite having a rule configured for this traffic pattern, did not deploy it at all during the test.
Why a difference of seconds matters in practice
A difference of several seconds in deploying the first filtering rule may seem like a small margin, but with an attack on the order of several gigabits per second, that is tens to hundreds of gigabytes of traffic freely reaching the customer's infrastructure in that time instead of being filtered at the network edge. For devices with limited resources, such as BRAS or lower-end edge routers, it is precisely these first seconds of an attack that decide whether the device manages to become overloaded before protection actually kicks in.
Even more significant is the case of the third rule from the test: a situation in which a system has a rule correctly configured, yet still does not deploy it during a real attack. This shows that merely declared functionality (the system "supports" a given type of attack) is not the same as confirmed, practical operation of that function under load on live traffic.
Where the difference in response time comes from
The difference in response time follows directly from the data-processing architecture. LiveShield analyzes traffic packet by packet, in memory, and communication between the analysis module and the rule-generating module runs over a dedicated, fast, TCP-based protocol designed specifically to minimize latency. Most operations critical to detection time do not go through the database. The database is used to store historical data and statistics, not to make current filtering decisions.
Solutions that rely more heavily on database queries for detection and filtering logic inherently introduce additional delay at every stage, from anomaly detection, through classification, to generating and sending the rule. For a single attack, a difference of several to a dozen or so seconds may seem minor, but it grows with scale and the number of simultaneous incidents in the network.
Summary
In a controlled test on a multi-vector attack with parameters of 700 kpps / 6.5 Gb/s (IP Fragments, DNS amplification, UDP flood), LiveShield detected the attack and deployed the first filtering rule in the same second in which the attack started, staying several to a dozen or so seconds ahead of the compared market solution on the subsequent attack vectors, and the competing system did not deploy one of the rules at all despite correct configuration. This is the result of an architecture based on in-memory traffic analysis and inter-module communication designed for minimum response time, not merely a claimed speed.
Frequently Asked Questions
How fast does LiveShield detect a DDoS attack? In tests on live traffic, LiveShield detected the attack and deployed the first filtering rule in the same second in which the attack began, thanks to real-time, in-memory traffic analysis with no database on the critical detection path.
What parameters did the attack used in the comparison test have? The test was carried out on an attack with an intensity of 700 kpps and 6.5 Gb/s, made up of three simultaneous vectors: IP fragmentation, DNS amplification and UDP flood.
Do all anti-DDoS systems respond in a similar time? No. In the test carried out, the compared market solution detected the same attack with a delay of several seconds relative to LiveShield, and did not deploy one of its configured filtering rules at all during the attack.
