DDoS means Distributed Denial-of-Service, a cyberattack that makes a website, application, server, or network unavailable by overwhelming its bandwidth, connection capacity, or computing resources. Unlike a traditional DoS attack from one source, a DDoS attack uses many coordinated systems, rented infrastructure, or reflection services to exhaust resources and prevent legitimate users from connecting.
Key facts at a glance
A DDoS attack targets availability, although attackers may use it alongside intrusion, extortion, or distraction.
DDoS traffic can exhaust bandwidth, packets-per-second capacity, connection tables, CPU, memory, or application workers.
Volumetric attacks mainly saturate network capacity; protocol attacks exhaust network devices; Layer 7 attacks consume application resources.
A web application firewall can filter malicious requests, but it cannot protect an exposed origin when the upstream internet link is already saturated.
Effective protection combines monitoring, upstream filtering, rate controls, origin hiding, tested runbooks, and suitable mitigation capacity.
The correct response depends on attack symptoms, not simply on the number of packets or the apparent source country.
What Does DDoS Mean in Cybersecurity?
DDoS means Distributed Denial-of-Service, the coordinated use of multiple traffic sources to deny normal access to a target. The target may be a public website, API, DNS service, game server, corporate VPN, cloud workload, or an entire network range. The attack succeeds when legitimate requests cannot receive timely service.
“Distributed” describes the attack’s sources, not necessarily the attacker’s location. A botnet may contain infected routers, cameras, virtual machines, home computers, or cloud hosts, while a reflection attack causes legitimate third-party servers to send traffic toward the victim. Some attacks use no traditional botnet at all and rely on rented infrastructure or automated request networks.
DDoS is primarily an availability threat. Attackers can use it to demand ransom, damage reputation, disrupt competitors, distract defenders from a breach, or pressure an organization during a politically motivated campaign. A DDoS event does not prove that data was stolen, and an intrusion does not need to occur for the outage to be severe.
DDoS Versus DoS: What Is the Difference?
A DoS attack generally uses one originating system or one attack path, while a DDoS attack coordinates traffic from many distributed sources. Distribution makes filtering harder because blocking one address rarely stops the event.
| Attribute | DoS | DDoS |
|---|---|---|
| Typical source count | 1 system or connection path | Hundreds to millions of sources |
| Coordination | Single host or simple script | Botnet, C2 system, peer-to-peer network, or rented platform |
| Traffic diversity | Often narrow and easier to identify | Multiple networks, countries, protocols, and addresses |
| Main defense challenge | Block or rate-limit the source | Separate malicious patterns from distributed legitimate traffic |
| Common scale | Kilobits to several gigabits per second | Gigabits per second, millions of packets per second, or huge request rates |
| Attribution | Sometimes easier from one source | Often obscured by compromised devices and spoofing |
| Typical mitigation | Local filtering may work | Upstream, CDN, or scrubbing capacity is often required |
How Does a DDoS Attack Work?
A DDoS attack usually follows four operational stages: preparation, coordination, traffic delivery, and resource exhaustion. The sequence varies when an attacker rents a stress service, uses reflection, or sends requests directly from a distributed network.
- Preparation: The attacker acquires a botnet, compromised accounts, cloud instances, or a reflection method.
- Targeting: The attacker selects an IP address, hostname, API endpoint, DNS service, game server, or network port.
- Coordination: A command-and-control system, web panel, script, or peer-to-peer mechanism distributes instructions.
- Traffic delivery: Sources send packets, connection attempts, DNS queries, or application requests.
- Exhaustion: Bandwidth, packet-processing capacity, connection state, CPU, memory, database workers, or application threads become unavailable.
- Service impact: Legitimate traffic experiences delay, errors, timeouts, failed handshakes, or complete loss of connectivity.
Attackers do not always need to compromise millions of devices. A small number of systems can create a serious Layer 7 event if each request triggers an expensive search, login, report, image transformation, or database query.
What Is a Botnet and What Is Command and Control?
A botnet is a group of compromised or controlled devices that can receive instructions from an operator. Command and control, often abbreviated C2, is the mechanism used to coordinate those devices, although decentralized botnets can reduce dependence on one server.
Device owners commonly remain unaware because malware may consume modest resources between attacks. Weak administrative passwords, unpatched firmware, exposed management interfaces, and reused credentials are common entry points. Internet of Things devices are attractive because many run continuously and receive limited security maintenance.
A reflection attack differs from direct botnet traffic. The attacker sends a request to an exposed service with the victim’s spoofed source address, causing the service to reply to the victim. Amplification occurs when the response is larger than the request. Proper anti-spoofing controls and closed or restricted services reduce this abuse.
What Are the Main Types of DDoS Attacks?
The three practical categories are volumetric, protocol, and application-layer attacks. Categories can overlap, and one campaign may combine UDP floods, SYN floods, and HTTP requests to test different controls.
| Attack category | Primary target | Typical indicator | Common examples | Effective control |
|---|---|---|---|---|
| Volumetric | Internet bandwidth and transit capacity | Link utilization near 100% | UDP flood, DNS reflection, NTP reflection | Upstream filtering or cloud scrubbing |
| Protocol | Firewalls, load balancers, routers, connection state | SYN backlog or state table exhaustion | SYN flood, fragmented-packet abuse | SYN cookies, stateless filtering, provider controls |
| Application layer | Web, API, database, or game application | CPU, workers, latency, or errors rise | HTTP flood, Slowloris, expensive search requests | WAF, authentication, caching, endpoint rate limits |
| Mixed campaign | Multiple infrastructure layers | Simultaneous network and application anomalies | UDP plus HTTP flood | Layered detection and coordinated mitigation |
What Is a Volumetric DDoS Attack?
A volumetric DDoS attack attempts to consume the target’s available bandwidth or packet-processing capacity. The important measurements are not only gigabits per second, but also packets per second and the number of flows, because small packets can exhaust network equipment before the link reaches its advertised bandwidth.
A UDP flood sends large quantities of UDP packets, sometimes to random ports. The target may spend resources checking ports or generating unreachable responses. DNS and NTP reflection attacks abuse exposed servers, although modern amplification factors vary by request, server configuration, protocol, and filtering; fixed claims such as “70 times” or “550 times” should not be treated as universal values.
What Is a Protocol DDoS Attack?
A protocol attack consumes the processing state of network devices or exploits behavior in IP and TCP. A SYN flood sends TCP connection-start packets without completing the handshake, filling pending connection structures when defenses are poorly configured.
SYN cookies, connection limits, edge filtering, and provider support can reduce exposure. The historical Ping of Death involved oversized or malformed ICMP packets that could crash vulnerable systems; current operating systems generally resist the original flaw, but malformed-fragment filtering remains relevant for protocol hygiene.
What Is a Layer 7 DDoS Attack?
A Layer 7 DDoS attack targets the application rather than merely filling the network pipe. HTTP floods can request pages, searches, logins, or API operations that require disproportionate server work. Slowloris-style behavior holds connections open with incomplete requests, consuming concurrency.
Layer 7 events can look like legitimate popularity. A request rate of 500 per second may be harmless for cached static content but damaging for an uncached database search. TLS encryption also moves inspection cost to the edge, so mitigation must account for handshake rates, HTTP versions, authenticated sessions, and endpoint behavior.
| Vector | Resource consumed | Useful detection signal | Defensive response |
|---|---|---|---|
| SYN flood | TCP pending connections | SYN-to-ACK completion ratio | SYN cookies and edge filtering |
| UDP flood | Bandwidth and packet processing | Packets per second by protocol and port | Provider filtering and ACLs |
| HTTP GET flood | Web workers and cache misses | Requests per endpoint and status code | CDN caching and WAF rules |
| Expensive API flood | CPU, database, and queue capacity | Cost per endpoint and user identity | Authentication and quotas |
| Slow connection attack | Concurrent sockets and timeouts | Long-lived incomplete requests | Header and idle time limits |
| DNS reflection | Transit bandwidth | Unexpected DNS response volume | Upstream anti-spoofing and filtering |
How Can You Tell Whether a DDoS Attack Is Happening?
A DDoS attack is likely when traffic, connection behavior, or application demand changes sharply while legitimate users report timeouts or errors. No single symptom proves DDoS, because a flash crowd, software failure, routing issue, or overloaded database can produce similar effects.
Compare several signals:
- Bandwidth saturation: inbound traffic approaches the provider’s port capacity.
- Packet-rate increase: packets per second rises sharply, even when bandwidth remains moderate.
- Connection-state pressure: SYN backlog, firewall sessions, or load-balancer tables fill.
- Application stress: CPU, memory, worker utilization, database connections, or queue depth increases.
- Traffic quality change: repeated paths, unusual methods, abnormal headers, or impossible user-agent patterns appear.
- Geographic mismatch: demand comes from networks unrelated to the customer base, although geography alone is weak evidence.
- Error change: 502, 503, timeout, reset, and TLS-handshake failures rise together.
A flash crowd usually shows coherent navigation, successful sessions, recognizable referrers, and varied content access. A DDoS campaign may show high repetition, low session completion, abnormal source-network concentration, or a request cost that exceeds normal user behavior. Automated traffic can also be legitimate, so blocking by country or user-agent alone creates false positives.
How Large, Long, and Expensive Are DDoS Attacks?
DDoS size and duration vary too widely for one universal “typical” figure. Short attacks may last minutes, while repeated campaigns can continue intermittently for days; the relevant planning question is whether defenses can absorb the event continuously and recover without manual delay.
The figures below are planning ranges, not guarantees or current criminal-market price quotes.
| Dimension | Typical planning range | What changes the number | Operational meaning |
|---|---|---|---|
| Short event duration | 5-30 minutes | Botnet availability and defender response | Automated mitigation should activate quickly |
| Sustained event | 1-24 hours | Extortion, activism, and target value | Human escalation and provider coordination matter |
| High-volume traffic | 10-100+ Gbps | Reflection, botnet size, and provider access | A small internet circuit can saturate immediately |
| Extreme reported events | 1 Tbps or more | Campaign design and measurement method | Local appliances cannot absorb traffic alone |
| Layer 7 request rate | Hundreds to millions per second | Endpoint cost and caching | Requests per second matters more than Gbps |
| Small-business downtime | Hundreds to tens of thousands of dollars per hour | Revenue, staffing, SLA, and recovery | Calculate business impact before selecting controls |
| Enterprise downtime | Tens of thousands to over $1 million per hour | Transactions, penalties, and global reach | Resilience planning can outweigh appliance cost |
A low-bandwidth attack can be more damaging than a larger one when it targets an expensive endpoint. Conversely, a multi-terabit event may look dramatic while a well-configured global CDN absorbs it without an outage.
Ransom DDoS adds a social-engineering component. Preserve messages, headers, payment instructions, and timestamps, but do not treat payment as a reliable mitigation strategy. Report extortion and criminal activity through appropriate legal and law-enforcement channels.
Which DDoS Protection Strategy Fits the Situation?
Cloud scrubbing is generally the strongest choice for internet-scale volumetric attacks because filtering occurs before traffic reaches the victim’s access link. On-premise appliances remain useful for local protocol and application controls, while hybrid designs combine local low-latency handling with provider-scale failover.
| Strategy | Absorption position | Typical latency effect | Cost model | Main limitation |
|---|---|---|---|---|
| On-premise appliance | Inside the organization’s network | Often under 1 millisecond locally | Capital purchase plus support | Cannot exceed the ISP link |
| CDN or reverse proxy | At distributed edge locations | Often a few to tens of milliseconds | Monthly or usage-based | Requires correct DNS and origin protection |
| Cloud scrubbing | Provider network before origin | Routing-dependent, commonly milliseconds to seconds during diversion | Contract, capacity, or event fees | Requires routing, contracts, and runbooks |
| Hybrid architecture | Local appliance plus upstream failover | Low during normal traffic; higher during diversion | Highest operational complexity | Configuration and failover must be tested |
| ISP blackholing | Provider edge discards destination traffic | No useful application availability | Often included, but destructive | Stops the attack by taking the service offline |
Is a Firewall Enough to Stop DDoS?
A standard firewall is not sufficient against a bandwidth-saturating DDoS attack because malicious traffic can exhaust the connection before the firewall receives enough processing opportunity to filter it. Firewalls remain valuable for access control, but they are one layer rather than the complete mitigation architecture.
Stateful firewalls can also become a target when connection tables fill. Stateless edge controls, SYN cookies, provider filtering, anycast distribution, connection limits, and application controls address different failure points. The design must match the resource under attack.
Can a CDN Stop a DDoS Attack?
A CDN or reverse proxy can absorb and filter many web-layer and volumetric attacks when the protected hostname resolves to the proxy and the origin address is not publicly reachable. A CDN cannot protect an exposed direct IP, arbitrary non-web protocols, or an undersized private link when attackers bypass the proxy.
Use origin firewall rules that permit only the provider’s published egress ranges where practical. Rotate previously exposed origin addresses, remove direct DNS records, restrict administrative services, and verify that mail, APIs, staging systems, and certificate records do not reveal the backend.
How Do You Prevent and Mitigate DDoS Attacks?
DDoS prevention reduces attack surface, limits resource consumption, and shortens the time between detection and filtering. No control prevents every DDoS event; the goal is to keep critical services available or fail them in a controlled way.
Use this layered baseline:
- Map public assets: Record domains, IP ranges, APIs, DNS providers, game ports, VPN gateways, and origin hosts.
- Move public web traffic behind an edge provider: Proxy HTTP and HTTPS traffic, then restrict origin access.
- Set endpoint-specific limits: Apply separate quotas to login, search, checkout, upload, and anonymous API operations.
- Cache safe content: Cache static files and eligible GET responses to reduce origin computation.
- Harden network protocols: Enable SYN protection, reject unnecessary UDP services, restrict ICMP where operationally safe, and patch exposed systems.
- Monitor baselines: Track bandwidth, packets per second, concurrent connections, latency, status codes, cache ratio, and database saturation.
- Prepare provider escalation: Keep account identifiers, emergency contacts, prefixes, DNS access, and authorization procedures current.
- Test failover: Conduct authorized tabletop exercises and controlled resilience tests with providers.
- Protect DNS and certificates: Use resilient DNS hosting and ensure emergency routing does not create certificate or hostname failures.
- Preserve evidence: Export flow logs, packet summaries, application logs, provider tickets, and timestamps before changing filters.
Rate limiting should use multiple dimensions, such as IP, account, token, ASN, path, and device behavior. A single-IP threshold can block offices, mobile carriers, universities, or customers behind carrier-grade NAT.
What Should You Do During an Active DDoS Attack?
During an active DDoS attack, confirm the failure mode, contact the upstream provider, activate the prepared mitigation profile, and preserve evidence. Do not spend the first hour manually blocking thousands of addresses when the access circuit is already saturated.
- Confirm scope: Compare current bandwidth, packet rate, connection count, CPU, database load, and application errors with a normal baseline.
- Identify the bottleneck: Determine whether the failure is transit saturation, state exhaustion, TLS pressure, or an expensive endpoint.
- Capture evidence: Save timestamps, flow summaries, representative headers, request paths, source ASNs, and error rates.
- Engage the provider: Request upstream filtering, cloud scrubbing, BGP diversion, or Flowspec where supported.
- Protect priority services: Keep DNS, authentication, status pages, payment dependencies, and administrative access available through separate protected paths.
- Apply narrow controls: Block clear protocol abuse and impose endpoint-specific challenges or quotas.
- Communicate accurately: Publish service status and avoid claiming data theft unless forensic evidence supports it.
- Validate recovery: Check latency, successful transactions, cache behavior, origin load, and false-positive rates after mitigation.
Null routing, also called blackholing, can protect the provider’s network by discarding all traffic to a destination. It is an emergency availability trade-off, not a successful application defense.
Common DDoS Defense Mistakes
Relying on a Firewall Alone
A firewall that sits behind a saturated ISP circuit cannot restore access. Pair local filtering with upstream capacity when the threat can exceed the circuit.
Leaving the Origin IP Exposed
A reverse proxy is bypassed when attackers discover the backend address through old DNS records, mail headers, certificates, staging systems, or application responses. Treat origin discovery as an architecture problem, not merely a DNS problem.
Using One Global Rate Limit
One threshold ignores endpoint cost and shared networks. A login request, cached image, and database report should not consume the same budget.
Blocking by Country as the Primary Rule
Geographic filters can reduce obvious noise, but distributed attacks frequently use domestic providers and compromised local devices. Country blocking also harms legitimate travelers, mobile users, and international operations.
Ignoring Non-HTTP Services
A web CDN does not automatically protect DNS, SMTP, VPN, SSH, game protocols, or custom TCP and UDP services. Inventory every exposed protocol.
Failing to Test the Runbook
An emergency plan that depends on an expired provider contract, unavailable DNS credentials, or an untrained approver is not an operational control. Test the decision path at least annually and after major architecture changes.
DDoS Guidance by Organization Type
| Organization | Main exposure | Recommended baseline | Escalation trigger |
|---|---|---|---|
| Personal site | Web traffic and origin discovery | Reverse proxy, caching, managed rules, backups | Repeated outages or exposed origin |
| Small business | Web, DNS, VPN, customer APIs | CDN, provider support plan, endpoint limits, monitoring | Link saturation or revenue impact |
| SaaS company | APIs, authentication, tenant isolation | Always-on edge, per-tenant quotas, WAF, autoscaling | API latency, queue growth, or multi-region demand |
| Online game | UDP or custom TCP sessions | Game-aware provider, session limits, protected address ranges | Match disruption or repeated targeting |
| Enterprise | Multiple regions and critical services | Hybrid controls, scrubbing contract, redundant DNS, drills | Regional outage or SLA exposure |
| Critical infrastructure | Operational technology and public services | Segmentation, upstream coordination, tested crisis governance | Safety, continuity, or public-service impact |
Frequently Asked Questions
Is a DDoS attack the same as being hacked?
No. A DDoS attack attempts to disrupt availability, while hacking usually refers to unauthorized access, code execution, or data compromise. Attackers can combine both activities, so an outage should trigger availability triage and a separate review of authentication logs, privileged actions, persistence, and data access.
Can DDoS attacks steal passwords?
A DDoS attack by itself does not steal passwords because its direct objective is service exhaustion. Attackers may use the outage as a distraction for phishing, credential theft, or intrusion, so organizations should inspect identity-provider alerts and privileged-account activity while mitigation proceeds.
How long does DDoS protection take to activate?
Always-on CDN protection can filter eligible traffic immediately after correct configuration, while reactive scrubbing commonly takes minutes to activate after detection and provider approval. DNS changes, BGP diversion, contract checks, and origin cleanup can extend recovery time when no runbook exists.
Does changing an IP address stop a DDoS attack?
Changing an IP address can help only when the attacker targets the old address and the new address remains private and protected. DNS propagation, leaked infrastructure records, direct-origin access, and attacks against the entire prefix can make an address change ineffective or temporary.
Can a small business afford DDoS protection?
Yes. Small businesses can begin with a reverse proxy, caching, managed WAF rules, restricted origin access, monitoring, and a documented provider contact process. Costs rise when protection must cover non-web protocols, dedicated capacity, multiple regions, contractual response times, or forensic support.
Is DDoS testing legal?
DDoS testing requires written authorization from the asset owner, the hosting provider, the transit provider, and any third party whose systems could receive test traffic. Unauthorized stress traffic can disrupt other customers and may violate computer-crime, contract, or telecommunications laws.
The Bottom Line
DDoS meaning in cybersecurity is distributed denial of service: coordinated traffic or connection activity that prevents legitimate users from reaching a system. The right defense depends on the exhausted resource, whether bandwidth, packets, connection state, CPU, database capacity, or application workers. Use upstream mitigation for large network attacks, application controls for Layer 7 abuse, origin protection for proxied services, and a tested incident runbook for every public service.