What is a DDoS attack and how to protect your website?

Sajjad
Security
02 Sep, 2026

A DDoS (distributed denial of service) attack is an attempt to make a website or online service unavailable by overwhelming it with traffic or requests sent from many different machines at once. The best way to protect your website is to put it behind a CDN or DDoS protection service that can absorb large floods, combine that with caching and rate limiting to reduce the cost of each request, and have a plan for what to do when an attack happens.

DDoS attacks range from huge floods that saturate entire networks to small, targeted bursts of expensive requests that can take down a modest server. The good news is that effective protection is now widely available and often affordable. This article explains how DDoS attacks work, the main types, the warning signs, and the practical steps you can take to keep your site online.

What Is a DDoS Attack?

A denial of service (DoS) attack tries to exhaust a resource your site depends on, such as bandwidth, CPU, memory, database connections, or PHP workers, so that legitimate visitors can't be served. When the attack comes from a single source, it's relatively easy to block that source.

A distributed denial of service attack uses many sources, often thousands or even millions of devices. These are usually part of a botnet: a network of compromised computers, servers, routers, cameras, and other internet-connected devices that an attacker controls remotely. Because the traffic comes from so many addresses, often spread across the world, simply blocking IPs one by one doesn't work.

Why Do People Launch DDoS Attacks?

Motivations vary:

Extortion: "Pay us or we'll keep your site offline."
Competition: Knocking a rival's store offline during a busy sales period.
Activism: Protesting against an organization's views or actions.
Distraction: Keeping security teams busy while another attack happens.
Mischief or testing: Some attacks are launched simply because DDoS-for-hire services make it easy.

Sometimes your site isn't even the real target. It might share infrastructure with a target and suffer collateral damage.

Types of DDoS Attacks

DDoS attacks are generally grouped by which layer of the network they target.

Volumetric Attacks

Volumetric attacks try to saturate the bandwidth between your server and the internet. They're measured in gigabits or terabits per second. Common techniques include:

UDP floods: Massive amounts of UDP packets sent to random ports.
Amplification and reflection attacks: The attacker sends small requests to public services, such as misconfigured DNS, NTP, or memcached servers, with your IP spoofed as the source. Those services send much larger responses to you, multiplying the attacker's traffic.

You can't defend against a large volumetric attack on your own server; the flood fills your connection before any firewall rule helps. It has to be absorbed upstream by a network with far more capacity.

Protocol Attacks

Protocol attacks exploit how network protocols work to exhaust server or network equipment resources, like connection tables in firewalls and load balancers. They're measured in packets per second.

SYN floods: The attacker sends many TCP connection requests without completing the handshake, leaving the server waiting on half-open connections.
Ping of death and fragmented packet attacks: Malformed or oversized packets that some systems handle poorly.

Application-Layer (Layer 7) Attacks

Application-layer attacks target your website software directly with requests that look legitimate but are expensive to process. They're measured in requests per second, and they don't need huge bandwidth to be effective.

HTTP floods: Large numbers of GET or POST requests to pages that can't be cached, such as search results, login pages, or cart pages.
Slow attacks: Techniques like "Slowloris" open many connections and send data extremely slowly, tying up server workers.
Targeted endpoint abuse: Hammering endpoints like xmlrpc.php, wp-login.php, or a REST API route that triggers heavy database queries.

For WordPress sites, layer 7 attacks are the most common kind you'll feel directly, because a small server with a limited number of PHP workers can be overwhelmed by a relatively modest number of uncached requests.

Signs Your Website Is Under a DDoS Attack

A traffic spike isn't always an attack. A viral post or marketing campaign can look similar at first. Warning signs of an attack include:

A sudden, sustained spike in traffic that doesn't match any campaign or referral source.
Huge numbers of requests to a single URL, especially an uncached one.
Traffic from unusual countries, networks, or user agents all at once.
Server metrics showing CPU, memory, or PHP worker saturation.
Your host reporting network-level issues or null-routing your IP.
502, 503, or 504 errors for legitimate visitors.

On a server you manage, you can quickly see which IPs are making the most requests in your access log:

sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

And which URLs are being hit the most:

sudo awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

If you're behind a CDN, your logs may show the CDN's IPs instead of the visitor's. Configure your web server to log the real client IP header your provider sends.

How to Protect Your Website from DDoS Attacks

1. Use a CDN or DDoS Protection Service

This is the most important step. Services like Cloudflare, Akamai, Fastly, Sucuri, AWS Shield (with CloudFront), and Google Cloud Armor operate large global networks designed to absorb volumetric attacks. Traffic reaches their edge first, where attacks are filtered and only clean traffic is forwarded to your server.

Many providers include basic DDoS protection on free or entry-level plans, with more advanced features and guarantees on paid tiers. Pricing varies widely, so compare what each plan actually includes.

2. Hide and Protect Your Origin IP

A CDN only helps if attackers can't bypass it. If your server's real IP is known, attackers can target it directly.

Restrict access: Configure your server firewall to accept web traffic only from your CDN's published IP ranges.
Check for leaks: Old DNS records, mail servers on the same IP, and historical DNS data can reveal your origin. Consider changing your server IP after moving behind a CDN.
Send email separately: Use a transactional email service instead of sending directly from your web server, so email headers don't reveal the IP.

3. Cache Aggressively

The cheaper each request is to serve, the harder it is to exhaust your server. Serve as much as possible from cache:

Use full-page caching through your host, a CDN, or a plugin like WP Rocket, W3 Total Cache, or LiteSpeed Cache.
Cache static assets at the CDN edge with long cache lifetimes.
Use object caching (Redis or Memcached) to reduce database load for dynamic pages.

4. Rate Limit Expensive Endpoints

Limit how many requests a single client can make to costly URLs. With Nginx, you can define zones and apply them to specific locations:

# In the http block
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
limit_conn_zone $binary_remote_addr zone=conn_perip:10m;

# In the server block
limit_conn conn_perip 20;

location / {
    limit_req zone=perip burst=20 nodelay;
    try_files $uri $uri/ /index.php?$args;
}

location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Tune the rates to your real traffic, test on staging, and adjust the PHP-FPM socket to your version. If you're behind a CDN, make sure Nginx sees the real client IP (via the real_ip module), otherwise you'll rate-limit the CDN itself.

5. Block Endpoints You Don't Use

If you don't use XML-RPC (most modern WordPress sites don't), block it at the server so requests never reach PHP:

location = /xmlrpc.php {
    deny all;
    access_log off;
}

On Apache, you can do the same in .htaccess:

<Files "xmlrpc.php">
    Require all denied
</Files>

6. Tune Server Timeouts Against Slow Attacks

Short timeouts for reading request headers and bodies help defend against slow connection attacks. In Nginx:

client_header_timeout 10s;
client_body_timeout 10s;
keepalive_timeout 15s;
send_timeout 10s;

On Apache, the mod_reqtimeout module serves a similar purpose and is enabled by default on many distributions.

7. Enable Under Attack or Challenge Modes

Most CDNs have an emergency mode. Cloudflare's "I'm Under Attack Mode," for example, presents a browser challenge to every visitor, stopping many bots while letting real users through. You can also create rules that challenge traffic to specific paths or from specific regions during an attack.

8. Choose Hosting with Headroom

Hosting with more resources, auto-scaling, or built-in DDoS mitigation gives you a buffer. Managed hosts often include network-level protection and can help during an incident.

Creating a DDoS Response Plan

When an attack hits, you don't want to be figuring things out from scratch. Prepare a short plan:

Know your contacts: Your host's support channel, your CDN's support, and your developer.
Document how to enable emergency modes: Under Attack mode, stricter WAF rules, or geo-blocking.
Have access to logs and metrics: Know where to see traffic, errors, and resource usage.
Prepare a status page or social account: Let customers know you're aware of the issue.
Don't pay ransom demands: Paying encourages further attacks and doesn't guarantee they'll stop. Report extortion to the appropriate authorities.
Review afterwards: Identify what worked, what was slow, and what to improve.

Is DDoS Protection Worth It for Small Sites?

Yes, and it's often free or inexpensive. A small site on shared hosting can be knocked offline by a surprisingly modest flood of uncached requests. Putting it behind a CDN with basic DDoS protection and enabling page caching dramatically raises the bar for attackers and usually improves your site's speed at the same time.

FAQ: DDoS Attacks

A DoS attack comes from a single source, so it can usually be blocked by filtering that source. A DDoS attack comes from many sources at once, often a botnet, which makes simple IP blocking ineffective.

A DDoS attack aims to make your site unavailable rather than to break in or steal data. However, attackers sometimes use a DDoS as a distraction while attempting other attacks, so keep monitoring during an incident.

Not a large one. A plugin runs on your server, so traffic has already reached you before it can act. Plugins can help with small application-level floods, but real DDoS protection needs a CDN or network-level service.

It varies widely. Many last minutes to hours, while persistent campaigns can come and go over days. Having protection in place before an attack is far more effective than reacting during one.

For many small and medium sites, Cloudflare's free plan provides meaningful DDoS protection. Businesses with higher risk or strict uptime needs may want paid plans with advanced rules, support, and guarantees.

Legitimate spikes usually have a clear source, like a social post or campaign, and visitors browse many pages. Attacks often hammer a few URLs, come from unusual sources, and show no normal browsing behaviour.

Geo-blocking or challenging traffic from regions you don't serve can help during an attack, but it can also block legitimate visitors and is easy for attackers to work around. Use it as a temporary measure.

Conclusion

A DDoS attack uses many machines to overwhelm your website's bandwidth, network equipment, or application resources until legitimate visitors can't get through. Volumetric and protocol attacks need to be absorbed upstream by a large network, while application-layer attacks can be blunted with caching, rate limiting, and blocking unused endpoints.

The most effective protection is to put your site behind a CDN or DDoS protection service, lock your origin server so it can't be reached directly, cache as much as possible, and rate-limit expensive URLs. Add a simple response plan so you know exactly what to do when an attack happens, and you'll turn a potentially site-ending event into a manageable inconvenience.