Skip to content
The DDoS Report

Mitigate DDoS attacks

The specifics of successfully mitigating DDoS attacks vary greatly depending on your resources, threat model, and the type of systems you are defending; nevertheless, in general, we advise that developers and operators use the following five-step process to mitigate attacks:

  1. Learn how DDoS attacks work.
  2. Define your threat model.
  3. Assess your organisation’s preparedness.
  4. Adopt the appropriate mitigation tactics.
  5. Define your response plan.

Because we’re only interested in DDoS attacks over the Internet, systems like intranet servers and mesh networks are outside the scope of this document.

Learn how DDoS attacks work

You can only protect yourself from DDoS attacks if you understand how they work, so if you aren’t already familiar with the topic, read our explanation.

Define your threat model

DDoS mitigation, like any security improvement initiative, should start with a threat model to make sure that the actions taken are suitable for the risks involved. Said model should include the assets you need to protect, the adversaries you want to defend against, and what they’re capable of.

If you’re the developer of a white-labelled app, consider the threat model of the individuals and organisations that you’re targeting.

Assess your organisation’s preparedness

Operators should assess their organisation’s preparedness against their own threat model using the DDoS Resiliency Score (DRS).

Note that elements of the DRS assume that the server is a website accessed from a browser, but the underlying principles are more broadly applicable. For example, it defines “HTTP Flood JavaScript Support” as an attack vector where headless browsers can circumvent cryptographic challenges, but the principle applies to any malicious client that supports such challenges.

As part of this exercise, operators should also stress-test their systems to ensure that they can handle the expected load.

Adopt the appropriate mitigation tactics

Adopting the appropriate tactics is the joint responsibility of developers and operators. We group the tactics below by system type because they differ widely depending on the system. Each system should fit within one or more categories, such as:

We aim to provide a comprehensive list of tactics, so some may be excessive for your specific threat model or not applicable to your system.

Static websites

The following mitigations should prove very effective against DDoS attacks on static websites that don’t require authentication:

API servers and dynamic websites

These are servers that provide an interface with which human and/or bot users interact. It includes, but isn’t limited to, Web-based APIs and websites with server-side rendering.

Developers should consider the following mitigations, most of which may involve breaking changes to the protocol:

On the other hand, operators can adopt the following mitigations:

Public goods

We refer to public goods as servers accessible to any device on the Internet without requiring users to create an account. These servers are essential in virtually all decentralised systems, ensuring that users aren’t priced out or forced to provide personally identifiable information (e.g. email address, phone number). Examples include:

  • DNS resolvers, like Cloudflare’s 1.1.1.1 or Google’s 8.8.8.8.
  • STUN servers, like stun.cloudflare.com:3478 or stun.l.google.com:19305.
  • Public time servers, like time.cloudflare.com or time.google.com.
  • Gateways used by Blockchain thin clients, like Cloudflare’s Ethereum endpoint https://cloudflare-eth.com.
  • BitTorrent trackers, like tracker.opentrackr.org.
  • PGP key servers, like pgp.mit.edu.
  • Guard relays in Tor.
  • Free geolocation APIs, like https://ipinfo.io/geo.

Developers should consider the following mitigations, most of which may require breaking changes to the protocol:

Operators, on the other hand, can use the following mitigations:

Peer-to-peer networks

A network is peer-to-peer (P2P) when nodes (or peers) directly share resources and communicate with each other, without central servers. In practice, however, they still depend on public goods (e.g. DNS resolvers, STUN servers), at least for bootstrapping and initial communication. Examples include BitTorrent and (P2P)SIP.

As the developer of a P2P protocol, you should consider the following mitigations:

The mitigations above work on the application layer, but since you can’t place proxies between peers, the P2P application itself should also be able to mitigate attacks on the transport layer (e.g. TCP), such as SYN floods. In lieu of a reverse proxy, you should consider using a P2P library that offers some DDoS defence, like libp2p.

Lastly, consider how the mitigations above can help address non-DDoS attacks specific to your P2P network. For example, in a network susceptible to Sybil attacks, both authentication and cryptographic challenges can play an important role in mitigating such attacks.

Define your response plan

With the help of mitigation tactics implemented by developers, operators should create a response plan outlining how they will detect, respond to, and recover from DDoS attacks.

The NETSCOUT DDoS Response Playbook is a good starting point for this exercise.

Conclusion

Successfully mitigating DDoS attacks requires a multi-layered approach and ongoing adaptation. Whilst no single tactic provides complete protection, the combination of thoughtful design, responsible development practices, and vigilant operations can dramatically enhance the resilience of your systems.

This document serves as a guide to inform your approach, but it’s vital to remember that the threat landscape is ever-evolving. Stay informed about new mitigation strategies, and regularly evaluate your chosen tactics to ensure they remain effective.