A distributed denial-of-service attack, usually called a DDoS attack, is designed to make a website, application, or network service unavailable. Instead of stealing data directly, the attacker tries to overwhelm capacity so real users cannot get through.
This page explains how DDoS attacks work at a safe, defensive level. It does not provide instructions for launching attacks. The goal is to help site owners, administrators, and security teams recognize risk, prepare controls, and respond calmly.
What a DDoS attack does
Every online service has limits. Servers, networks, databases, application code, and third-party dependencies can only handle so much traffic at once. A DDoS attack abuses those limits by sending more traffic or requests than the service can process.
The “distributed” part means traffic comes from many sources. Those sources may include compromised devices, rented infrastructure, proxies, or other abused systems. Because the traffic is spread out, blocking one address rarely solves the whole problem.
CISA’s DDoS guidance describes DDoS as a denial-of-service attack that targets a specific application or service and can make websites or services inaccessible. That is the practical business impact: customers cannot log in, checkout pages fail, support portals slow down, and teams lose visibility during the incident.
Common DDoS categories at a high level
Volumetric attacks try to consume bandwidth. The service may be healthy, but the pipe leading to it becomes congested.
Protocol attacks target network or transport-layer behavior. They can exhaust connection tracking, firewall capacity, or load balancer resources.
Application-layer attacks target expensive actions inside the application, such as search, login, checkout, or dynamic pages. These can be harder to distinguish from real user activity because the requests may look normal at first glance.
Many real incidents mix categories. A site might see a bandwidth flood while also receiving application requests that stress the database.
Warning signs to watch
A DDoS incident may begin with sudden traffic spikes, unusual geography, high request rates, increased 5xx errors, slower page loads, overloaded CPU or memory, database saturation, or complaints from users who cannot reach the site.
Monitoring matters because the same symptom can have different causes. A marketing campaign, search crawler, broken integration, plugin error, or database issue can also create traffic spikes or slow pages. Good baselines help you tell normal busy periods from an attack.
For WordPress and WooCommerce sites, watch login endpoints, search pages, cart and checkout paths, XML-RPC, REST API endpoints, and uncached dynamic pages. These are often more expensive than static assets.
Practical defenses before an incident
Use a reputable CDN or DDoS protection provider in front of the site. Make sure DNS, hosting, and firewall settings are configured so attackers cannot easily bypass the protective layer and hit the origin server directly.
Cache aggressively where safe. Static assets, public pages, and anonymous traffic should be served without forcing the origin to do unnecessary work. Keep dynamic actions such as login and checkout protected with rate limits and bot filtering.
Harden the origin. Disable unused services, restrict administrative paths, use strong authentication, and keep the CMS, theme, plugins, server packages, and WAF rules current.
Create an incident runbook. It should list contacts for hosting, DNS, CDN, developers, security providers, legal, communications, and executives. It should also define who can make emergency changes.
What to do during a suspected DDoS attack
Do not start with random changes. Activate the incident plan, confirm symptoms, preserve logs, and contact your provider. Share timestamps, affected URLs, traffic patterns, error rates, and any recent changes.
If you have a CDN or WAF, use managed challenge modes, rate limiting, cache rules, and provider support. Avoid blocking entire countries or networks unless you understand the business impact.
Communicate clearly. Internal teams need to know what is affected, what is being done, and where updates will be posted. Customers may need a status page or temporary support channel.
After service stabilizes, review logs, identify what worked, update rate limits, tune caching, and revise the runbook.
Where ethical hacking fits
Ethical security work can help before an incident by reviewing architecture, finding exposed origin infrastructure, testing rate limits, and validating monitoring. It should not involve live attacks against third-party systems or uncontrolled stress testing.
If you need structured help, start with Digital Forensic Investigation Retainer for urgent response or Splunk for Security Monitoring for detection and visibility training.
The bottom line
DDoS defense is about preparation, visibility, capacity, and coordination. You cannot control every hostile request on the internet, but you can reduce exposure, put protection in front of the origin, monitor what matters, and respond with a calm plan.
For broader security planning, read How to Hire a Hacker Safely and Legally and keep all testing authorized, documented, and defensive.
Frequently asked questions
What is a DDoS attack?
A DDoS attack floods a service with traffic or requests from many sources so legitimate users cannot reach it reliably.
Is this guide a DDoS tutorial?
No. It explains the concept at a defensive level and focuses on preparation, detection, mitigation, and recovery.
What are common signs of a DDoS attack?
Sudden traffic spikes, high error rates, slow pages, unreachable services, unusual geographic traffic, and overloaded network or application resources can be warning signs.
What should a business do first during a DDoS attack?
Activate the incident plan, contact the hosting or DDoS protection provider, preserve logs, communicate with stakeholders, and avoid making untested emergency changes.