A distributed denial-of-service attack, commonly known as a DDoS attack, is an attempt to overwhelm a website, application, server, or network with artificial traffic. The attacker’s goal is to consume the available bandwidth, connections, processing power, memory, or application resources until legitimate users can no longer access the service.
During an attack, a website may become slow, return server errors, stop processing payments, or go completely offline. Even a short disruption can lead to lost sales, wasted advertising spend, customer complaints, and reputational damage.
Effective DDoS protection is not limited to installing a firewall or moving a website to a more powerful server. It requires a layered system that filters traffic before it reaches the hosting infrastructure, identifies malicious automation, limits abusive requests, and keeps the origin server hidden.
What Is a DDoS Attack?
DDoS stands for Distributed Denial of Service. The word “distributed” means that malicious traffic comes from many different devices rather than a single computer.
Attackers often control a botnet consisting of compromised computers, servers, routers, smartphones, security cameras, and other internet-connected devices. The owners of these devices may not know that their equipment has been infected.
When the attacker sends a command, thousands of devices begin transmitting requests to the same target. Blocking one IP address does not stop the attack because the remaining devices continue generating traffic.
A traditional DoS attack usually comes from one source. A DDoS attack is more difficult to mitigate because its traffic may originate from thousands of IP addresses, countries, providers, and network types.
How a DDoS Attack Works
Every website has limited resources. These include:
-
network bandwidth;
-
simultaneous connections;
-
processor capacity;
-
server memory;
-
database connections;
-
application workers;
-
file system operations;
-
third-party API limits.
Under normal conditions, these resources are sufficient to process real visitors. During a DDoS attack, the server receives more traffic or more expensive requests than it can handle.
A simple analogy is a small shop with two checkout counters. Normal customers enter, choose products, pay, and leave. During a denial-of-service attack, thousands of people enter the shop, occupy all available space, ask endless questions, and never purchase anything. Real customers cannot reach the checkout counters.
The same happens to a website. It spends its resources processing artificial requests while legitimate users wait, receive errors, or leave.
Why Attackers Launch DDoS Attacks
DDoS attacks can have several motives. In some cases, attackers demand payment in exchange for stopping the attack. In others, the objective is to disrupt a competitor during an important sales period or advertising campaign.
Common motives include:
-
financial extortion;
-
unfair competition;
-
political or ideological pressure;
-
revenge against a company or individual;
-
disruption of an event or online broadcast;
-
testing or advertising a botnet;
-
cybercrime experimentation;
-
distracting security teams during another attack.
The distraction scenario is particularly dangerous. While administrators are focused on restoring availability, attackers may attempt credential stuffing, exploit a vulnerability, or gain unauthorized access. For this reason, security logs should be reviewed after every serious DDoS incident.
Main Types of DDoS Attacks
DDoS attacks use different methods and target different layers of infrastructure. They can generally be divided into volumetric attacks, protocol attacks, and application-layer attacks.
Volumetric Attacks
A volumetric attack attempts to saturate the target’s network connection with a massive amount of traffic. The server may still be operational, but legitimate requests cannot reach it because the connection is full.
Examples include:
-
UDP flood;
-
ICMP flood;
-
DNS amplification;
-
NTP amplification;
-
other reflection and amplification attacks.
In an amplification attack, the attacker sends small requests to misconfigured third-party systems and spoofs the victim’s IP address. Those systems then send much larger responses to the victim. This allows the attacker to generate a large amount of traffic using relatively few resources.
A local firewall cannot effectively stop an attack that has already saturated the network link. Filtering must happen upstream, through a hosting provider, scrubbing center, or distributed protection network with sufficient capacity.
Protocol Attacks
Protocol attacks exploit weaknesses or resource limits in network protocols and infrastructure equipment.
A common example is a SYN flood. The attacker sends many requests to begin TCP connections but does not complete the handshake. The server keeps information about each incomplete connection until its connection table or memory is exhausted.
Protocol attacks may target:
-
web servers;
-
routers;
-
load balancers;
-
firewalls;
-
connection tracking systems;
-
other network appliances.
Increasing server capacity may provide temporary relief, but it does not solve the underlying problem. Without filtering, an attacker can simply increase the number of malicious connections.
Application-Layer Attacks
Application-layer attacks, also called Layer 7 or L7 attacks, target specific website or API functions. Instead of generating an enormous volume of raw traffic, the attacker sends requests that are expensive for the application to process.
Bots may repeatedly:
-
open dynamic pages;
-
use website search;
-
change catalog filters;
-
submit forms;
-
access login pages;
-
request password resets;
-
add products to a cart;
-
generate reports;
-
upload files;
-
call API endpoints.
A single HTTP request can trigger several database queries, external API calls, calculations, and file operations. A few hundred expensive requests per second may be enough to overload an application.
L7 attacks are difficult to detect because they use normal HTTP and HTTPS protocols. Advanced bots can execute JavaScript, store cookies, rotate IP addresses, and imitate human browsing behavior.
Multi-Vector Attacks
Real-world attacks often combine several techniques. An attacker may begin with a UDP flood, switch to a SYN flood, and then target a login page or API endpoint.
The attack vector may change whenever the current method is blocked. A protection system must therefore cover the network, transport, and application layers rather than relying on a single filter.
How to Recognize a DDoS Attack
A slow website does not always indicate an attack. Performance problems may also be caused by a software update, database error, insufficient hosting resources, or a successful marketing campaign.
Possible signs of a DDoS attack include:
-
a sudden increase in requests or bandwidth;
-
unusually high CPU or memory usage;
-
a large number of simultaneous connections;
-
repeated requests to the same URL;
-
traffic from unexpected countries or networks;
-
many visitors with identical technical characteristics;
-
an increase in HTTP 429, 502, 503, or 504 errors;
-
high traffic without a corresponding increase in sales;
-
excessive requests to login, search, or API endpoints;
-
an unexpected increase in cloud infrastructure costs.
No single sign proves that an attack is taking place. Administrators should compare traffic patterns, server metrics, access logs, error rates, and user behavior.
DDoS Traffic Versus Real Visitors
A legitimate traffic spike may occur after a product launch, news publication, advertising campaign, or social media mention. Blocking such users would turn a successful event into an outage.
Real visitors normally display varied behavior. They open different pages, read content, download assets, pause between actions, and complete meaningful tasks.
Basic bots often send repetitive requests at unnatural speeds. However, advanced bots can imitate normal browsers and distribute requests across residential or mobile IP addresses.
Accurate detection therefore requires several signals:
-
IP reputation;
-
geographic location;
-
autonomous system number;
-
hosting, residential, or mobile network type;
-
HTTP headers;
-
browser fingerprint;
-
TLS fingerprint;
-
cookie support;
-
JavaScript execution;
-
request frequency;
-
navigation sequence;
-
session behavior.
The decision should be based on the combined risk profile rather than one IP address or User-Agent string.
How to Protect a Website from DDoS Attacks
Reliable protection requires multiple defensive layers. Each layer handles a different part of the problem.
Use a Protected Reverse Proxy
A reverse proxy stands between the internet and the origin server. Visitors connect to the proxy, which inspects each request before forwarding approved traffic to the website.
The traffic path becomes:
Visitor → DDoS protection network → Origin server
A distributed reverse proxy can absorb more traffic than a single hosting server. It can block malicious requests, apply a web application firewall, challenge suspicious clients, and serve cached content without reaching the origin.
For volumetric attacks, the provider must have enough network capacity to receive and clean the traffic. For L7 attacks, it must also analyze application behavior and distinguish automated requests from real users.
Hide the Origin Server
A reverse proxy is ineffective if attackers know the real IP address of the origin server. They can send traffic directly to it and bypass the protection layer.
After enabling proxy protection, administrators should:
-
remove public DNS records that expose the origin;
-
review historical and forgotten subdomains;
-
check mail server and third-party service records;
-
restrict origin access with firewall rules;
-
allow web traffic only from trusted proxy networks;
-
change the origin IP if it has already been exposed.
Administrative access, monitoring systems, payment callbacks, and trusted integrations may require separate allowlists.
Configure Rate Limiting
Rate limiting controls how many requests a client can send during a specific period. Different website functions should have different limits.
Sensitive endpoints include:
-
login and registration;
-
password reset;
-
search and catalog filters;
-
checkout;
-
contact forms;
-
file uploads;
-
public and private APIs;
-
report generation.
A normal visitor is unlikely to submit dozens of login attempts within a few seconds. Such activity may indicate brute force or credential stuffing.
Limits should be based on real usage data. If they are too strict, legitimate customers, corporate networks, or search engines may be blocked. If they are too permissive, automated traffic will continue to consume resources.
Deploy a Web Application Firewall
A Web Application Firewall, or WAF, inspects HTTP and HTTPS requests. It can block known attack patterns, suspicious parameters, malicious payloads, and access to sensitive paths.
A WAF helps stop:
-
SQL injection;
-
cross-site scripting;
-
path traversal;
-
malicious file uploads;
-
exploitation of known vulnerabilities;
-
scanning of configuration files;
-
access to backup files;
-
abuse of administrative endpoints.
During an L7 DDoS attack, custom WAF rules can temporarily restrict the targeted URL, request method, country, network, or client characteristic.
A WAF does not replace secure development, patching, or server hardening. It provides an additional filtering layer in front of the application.
Use Behavioral Bot Detection
IP blocklists are useful against known malicious sources, but they are not enough for distributed attacks. Modern bots rotate addresses and use residential proxies to appear legitimate.
Behavioral bot detection examines how a client interacts with the website. It may consider browsing speed, navigation patterns, browser capabilities, TLS characteristics, cookies, JavaScript results, and inconsistencies between claimed and observed software.
Suspicious clients can be:
-
blocked immediately;
-
temporarily rate-limited;
-
required to pass a JavaScript challenge;
-
redirected to CAPTCHA;
-
logged for additional analysis.
The system should verify useful bots rather than trusting the User-Agent alone. Any attacker can claim to be Googlebot or another recognized crawler.
Apply GeoIP and ASN Filtering
If a website serves only specific markets, traffic from unrelated regions can be restricted during an attack. Filtering can also be applied by autonomous system number, network provider, or data center classification.
ASN filtering is useful when malicious requests come from many IP addresses that belong to the same hosting provider. Instead of blocking every address separately, administrators can create a rule for the network.
Broad blocking must be used carefully. Large cloud and telecom networks may contain legitimate customers, search engine crawlers, payment systems, and business integrations.
Cache Website Content
Caching reduces the number of requests that reach the origin server. Images, scripts, stylesheets, fonts, downloads, and public HTML pages can be served from edge nodes.
Even when a page is requested thousands of times, the origin may only need to generate it once. This reduces processor usage, database queries, and network traffic.
Personalized content should not be placed in a shared cache. Accounts, shopping carts, dashboards, and pages containing private data require carefully configured cache bypass rules.
Optimize the Application
A protected website should also be designed to handle abnormal traffic efficiently.
Useful measures include:
-
optimizing slow database queries;
-
indexing frequently searched columns;
-
setting connection and execution timeouts;
-
using queues for expensive tasks;
-
limiting upload sizes;
-
restricting complex search filters;
-
caching repeated database results;
-
protecting third-party API calls;
-
disabling unnecessary endpoints;
-
separating static and dynamic content.
Optimization does not stop DDoS attacks, but it increases the amount of traffic the application can survive.
Use Load Balancing and Redundancy
A load balancer distributes requests across multiple servers. If one origin becomes unhealthy, traffic can be redirected to another.
Redundancy reduces the risk of a single server failure, but it should not be treated as a replacement for filtering. Without DDoS protection, attackers can overload every available origin.
Scaling also creates financial risk in cloud environments. Automatic scaling may keep a service online while producing a large bill for malicious traffic.
What to Do During a DDoS Attack
When an attack begins, the first objective is to identify the overloaded resource and keep essential services available.
A practical response plan includes the following steps:
-
Confirm that the incident is caused by external traffic.
-
Record the start time and baseline metrics.
-
Identify targeted IP addresses, domains, URLs, and services.
-
Determine whether the attack is volumetric, protocol-based, or L7.
-
Contact the hosting and DDoS protection providers.
-
Enable stricter filtering or an emergency protection mode.
-
Apply temporary limits to targeted endpoints.
-
Disable nonessential resource-intensive features.
-
Monitor changes in the attack vector.
-
Preserve logs for later investigation.
Avoid blocking all foreign traffic unless the business genuinely has no international audience. Emergency restrictions can reduce malicious traffic, but they can also exclude customers, search crawlers, remote employees, and external services.
After the website is stable, review login activity, administrative actions, file changes, API requests, and WAF events. This helps determine whether the DDoS attack was used as cover for another intrusion attempt.
Common DDoS Protection Mistakes
Waiting Until the Website Is Down
DNS changes and traffic migration take time. Protection should be enabled before an incident rather than after the origin becomes unreachable.
Relying Only on a Bigger Server
Additional resources can handle a small traffic spike, but an attacker can increase the load. A large volumetric attack may saturate the network regardless of server capacity.
Blocking Individual IP Addresses
Manual IP blocking is ineffective against a large distributed botnet. Attackers can rotate addresses faster than administrators can add firewall rules.
Using CAPTCHA as the Only Defense
CAPTCHA may stop basic automation, but it cannot protect network bandwidth. It can also reduce conversions and create accessibility problems for legitimate users.
Leaving the Origin IP Exposed
If the origin remains publicly accessible, attackers can bypass the reverse proxy. Origin lockdown is one of the most important steps in a protected architecture.
Using Identical Limits Everywhere
A static page, login form, search function, and API have different usage patterns. Applying one global limit may either block legitimate traffic or fail to protect expensive endpoints.
Ignoring False Positives
Aggressive filtering can block payment services, monitoring systems, mobile applications, search engines, and real customers. Logs and allowlists must be reviewed regularly.
Preparing for an Attack in Advance
DDoS protection works best when normal traffic patterns are already understood. A company should know its usual request volume, geographic distribution, peak hours, critical endpoints, and origin capacity.
Preparation should include:
-
continuous traffic and uptime monitoring;
-
centralized access and security logs;
-
tested alerting rules;
-
documented provider contacts;
-
an incident response checklist;
-
backups of DNS configuration;
-
verified origin firewall rules;
-
protection for administrative interfaces;
-
tested failover procedures;
-
regular review of WAF and rate-limiting rules.
Emergency changes are safer when they have already been tested. A rule created under pressure can block real customers or interrupt payments.
Can DDoS Attacks Be Prevented Completely?
It is impossible to prevent attackers from sending traffic. The purpose of DDoS protection is to prevent that traffic from disrupting the protected service.
A strong architecture absorbs the load, identifies malicious activity, and filters it before it reaches the origin. Legitimate users should continue accessing the website even while hostile traffic is being blocked.
For most websites, the practical solution is a cloud-based protection service combining reverse proxy, DDoS mitigation, WAF, bot detection, rate limiting, caching, and real-time analytics.
Frequently Asked Questions
Can a standard antivirus stop a DDoS attack?
No. Antivirus software searches for malicious code on a device. DDoS attacks create external network or application load and require traffic filtering.
Does a CDN provide DDoS protection?
A CDN can absorb traffic and reduce origin load through caching, but protection levels vary. A basic CDN may not detect advanced L7 bots or protect dynamic endpoints and APIs.
Will moving to a larger server solve the problem?
It may help with small traffic spikes, but it is not a complete solution. Attackers can scale their traffic, and network capacity may be exhausted before server resources.
Should all traffic from other countries be blocked?
Only if the website has no legitimate international users or integrations. Geographic filtering is useful, but it should be based on business requirements and traffic analysis.
How can the real origin IP be protected?
Route public traffic through a reverse proxy, remove records that expose the origin, restrict server access to proxy IP ranges, and change the origin address if it is already known.
What is the most important DDoS protection measure?
Traffic should be filtered before it reaches the hosting infrastructure. A protected reverse proxy combined with origin lockdown is the foundation of an effective defense.
Conclusion
DDoS attacks range from massive network floods to carefully designed application requests that imitate real users. A website can be disrupted not only by enormous traffic volumes but also by repeated calls to an expensive search function, login form, checkout process, or API endpoint.
Reliable DDoS protection requires a layered approach. A protected reverse proxy absorbs incoming traffic, a WAF filters malicious requests, behavioral analysis identifies bots, and rate limiting controls abuse of sensitive functions. Caching, application optimization, load balancing, monitoring, and a tested response plan provide additional resilience.
The most important step is preparation. Once an attack has saturated the network or exposed the origin server, recovery becomes more difficult. When protection is deployed in advance and configured around normal user behavior, a website can remain accessible even while malicious traffic is actively being filtered.
