We're sorry but this app doesn't work properly without JavaScript enabled. Please enable it to continue.

This lesson's interactive features are locked, please to keep using them

DDoS

A Distributed Denial-of-Service (DDoS) attack is much harder to deal with than a regular DoS, because traffic comes from many different sources, often thousands or millions of IP addresses. You can't just block them all, and even if you could, new ones pop up immediately. Typical signals of a DDoS are:

  • Sudden traffic from unrelated IPs – no geographic or referral pattern consistent with a real event
  • Repeated hits to the same expensive endpoint – report generation, search, or export endpoints called at high frequency
  • Low session completion – high request rate but almost no follow-through actions
  • Requests that skip normal user flow – hitting authenticated endpoints without a prior login sequence

Many DDoS attacks use botnets, which are networks of compromised devices controlled remotely. Others use reflection and amplification to make public servers flood the victim.

Once an attack saturates your origin's network connection, application code can't help: legitimate traffic can't reach it either. The flood needs to be filtered before it consumes your bandwidth.

Assignment

Per-client limits are not enough when a distributed flood consumes all available request capacity.

Add global in-flight request load shedding.

This is graceful degradation, not complete DDoS protection. A large volumetric attack must be filtered before it reaches the application.

With Bearly Secure still running, run and submit the CLI tests from the project root.