DDoS attack
A DDoS attack (distributed denial of service) overwhelms systems, networks or applications with floods of requests from many distributed sources, aiming to degrade or fully interrupt their availability for legitimate users.
In a distributed denial-of-service attack, large numbers of compromised machines, hijacked IoT devices or rented attack services send requests to a target at the same time until its bandwidth, connection tables or application resources are exhausted. Technically, three families are distinguished: volumetric attacks that flood the uplink and frequently exploit reflection and amplification via open DNS, NTP or Memcached services; protocol attacks such as SYN floods that fill the state tables of firewalls and load balancers; and application-layer attacks such as HTTP floods or Slowloris, which trigger expensive database and rendering operations with comparatively little traffic. Because the traffic originates from many sources that look partly legitimate, blocking individual IP addresses is not an effective defence. Ransom DDoS campaigns, in which a short demonstration attack is paired with an extortion demand, are common, as is the use of DDoS as a smokescreen for intrusion attempts running in parallel.
From a regulatory perspective, a DDoS attack is the textbook attack on the protection goal of availability. Article 21(2) of the NIS2 Directive (EU) 2022/2555 explicitly requires essential and important entities to implement measures for business continuity, backup management, network security and attack detection. Germany implements the directive through the NIS2 Implementation and Cybersecurity Strengthening Act (NIS2UmsuCG); entities in scope should verify the current status of its deadlines and registration duties rather than rely on earlier timelines. For significant incidents, Article 23 NIS2 sets out a staged reporting process: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. In addition, ISO/IEC 27001 covers capacity management, network security and ICT readiness for business continuity through its Annex A controls, and the German BSI IT-Grundschutz modules on network architecture address overload protection. Under German criminal law, DDoS attacks regularly constitute computer sabotage pursuant to section 303b of the Criminal Code (StGB).
Effective protection is layered. At network level, spare capacity, anycast distribution and content delivery networks disperse load geographically, while upstream filtering at the provider is essential because a saturated uplink can no longer be relieved inside the own data centre. For larger attacks, traffic is diverted via BGP or DNS to a scrubbing centre that separates attack traffic from genuine traffic and returns the cleaned stream through a tunnel. At application level, rate limiting, SYN cookies, web application firewalls, bot management and caching of static content take effect. Blackholing, which discards all traffic destined for a target IP address, is only a last resort because it takes the target offline itself. Organisationally, this requires a rehearsed incident plan with an escalation path to the provider, contractually agreed activation and response times with the mitigation provider, monitoring with defined alert thresholds, and clear ownership of communication and reporting duties. Paying ransom in ransom-DDoS cases is discouraged by the BSI and law enforcement, since it funds further attacks and offers no guarantee of relief.
Legal Basis
Art. 21(2) and Art. 23 NIS2 Directive (EU) 2022/2555; German NIS2UmsuCG; ISO/IEC 27001 (Annex A: capacity management, network security, ICT readiness for business continuity); BSI IT-Grundschutz; section 303b German Criminal Code (StGB)
Practical Example
On a Friday afternoon, a regional energy supplier receives an extortion email threatening a sustained attack unless payment is made; shortly afterwards the customer portal collapses under an HTTP flood, while the control room network remains fully reachable. The information security officer activates the documented DDoS response plan: the operations team switches over to the contractually agreed diversion into the provider's scrubbing centre, the web application firewall is moved to stricter rate limiting and bot verification, and the segmentation between the portal and the process network is verified. In parallel, the security officer and the legal team assess whether the event qualifies as a significant incident, prepare the early warning to the competent authority, and record timestamps, attack volumes and countermeasures in full for the later final report. No payment is made; instead the company files a criminal complaint and feeds the lessons learned into the next business continuity exercise.