A distributed denial of service (DDoS) attack tries to make a website, application, or network service unavailable to legitimate users. It does this by exhausting a resource the service depends on: network capacity, connection state, or application and server capacity.
The traffic often comes from many compromised devices, sometimes called a botnet. Other attacks use reflection and amplification, or a mix of different techniques. In each case, the defender has to distinguish harmful traffic from the ordinary requests the service is designed to handle.
Think of a busy road with limited capacity. If enough traffic arrives at once, legitimate users can be delayed or blocked. The analogy is useful, but a DDoS attack can target several points along the request path, from the network edge to a costly application endpoint.
Why do attackers launch DDoS attacks?
Motivations vary. Some attackers use the threat of disruption to demand money. Others aim to interrupt a service for political, ideological, or personal reasons. An attack can also draw responders’ attention while someone probes or targets other systems. That possibility makes it important to keep monitoring beyond the visibly affected service.
Not every outage or sudden traffic increase is an attack. A release, a popular event, a broken integration, or an infrastructure fault can produce similar symptoms. Compare what you see with normal traffic patterns and check with your hosting, network, or mitigation provider before settling on a cause.
How DDoS attacks affect services
It helps to think about attacks by the resource they consume:
- Volumetric attacks send enough traffic to saturate available bandwidth. Reflection and amplification techniques can make a smaller volume of requests generate a larger volume of traffic toward a victim.
- Protocol and state-exhaustion attacks consume connection or processing capacity in network equipment and servers.
- Application-layer attacks send requests to web applications or APIs. The requests may resemble normal user activity while consuming disproportionate application resources.
An incident may combine more than one type. A network-layer filter may help with some unwanted traffic but will not, by itself, address every expensive application request. The response should match the affected resource and the architecture in front of it.
How to prepare
Understand what matters
List the public services your organization depends on, their owners, upstream providers, and business priorities. Identify which services can tolerate reduced functionality and which need to remain available. Know how to reach your internet service provider, cloud provider, and DDoS mitigation provider before an incident.
Establish a baseline and useful signals
Monitor traffic, service health, and application behavior so that responders can compare an incident with normal activity. Useful signals can include request rates, connection counts, latency, error rates, and the health of critical dependencies. Alerts should help an on-call person decide what to investigate, not merely announce that traffic is high.
Put layered controls in the right places
Use protections suited to the services and risks you have identified. Depending on the architecture, these may include upstream DDoS mitigation, a content delivery network, network controls, a web application firewall, rate limits, and application changes that reduce the cost of expensive requests. Confirm which traffic reaches the origin and which protections your providers can apply during an attack.
No single product or control covers every attack path. Review the design with the teams and providers who would operate it, including how legitimate users will continue to reach the service while mitigations are active.
Agree on an incident plan
Document who can declare an incident, who contacts providers, who approves mitigation changes, and how service owners communicate with customers and leadership. Record provider escalation paths and rehearse the plan. Keep recovery priorities and any business continuity steps clear.
What to do during an attack
- Confirm and scope the impact. Compare current network and application signals with your baseline. Check for maintenance, application changes, provider incidents, or other explanations. Identify the services and users affected.
- Engage the right providers early. Contact your ISP, hosting or cloud provider, and DDoS mitigation provider. They may have visibility and upstream controls that are not available to your team alone.
- Apply targeted mitigations. Use the controls in your response plan and match them to the traffic and resource affected. Broad blocking can also block legitimate users, so monitor service health and the effect of each change.
- Keep looking for other activity. Continue monitoring other systems and preserve relevant logs and timelines. A DDoS incident can coincide with other suspicious activity.
- Recover and review. Confirm that service has returned to normal, check for remaining impact, and update the response plan with what the incident revealed.
The Canadian Centre for Cyber Security recommends preparation that includes traffic baselines, monitoring, provider coordination, and a response plan. Its DDoS prevention and preparation guidance and incident response advice are useful starting points. CISA also provides a DDoS Quick Guide.
The takeaway
DDoS resilience is a combination of preparation, provider coordination, monitoring, and controls placed along the service path. A tested plan helps responders identify what is affected, choose proportionate mitigations, and restore service while staying alert to other activity.