Preventing DDoS Attacks on Your Website

What a DDoS attack is

A distributed denial-of-service (DDoS) attack tries to make a website or service unavailable by overwhelming it with traffic or requests from many sources at once. Unlike a break-in, the goal is not usually to steal data but to stop legitimate users from reaching you. The sources are often compromised devices or rented infrastructure, which is why simply blocking one IP address rarely helps.

This guide is about defense: understanding the main categories of attack so you can choose sensible protections, configure your stack and respond calmly if it happens. No website can be made completely immune, but good preparation dramatically reduces the chance that an attack turns into a long outage.

The main categories of DDoS attack

Attacks are commonly grouped by which resource they try to exhaust. Understanding the category tells you where the defense must sit.

The key point: volumetric attacks are usually far beyond what a single server or small hosting connection can absorb, so filtering on the server itself is too late. Application-layer attacks, on the other hand, can be small in bandwidth but expensive in CPU, and tuning your own application matters a lot.

Put a protection layer in front of your site

For most websites, the single most effective step is to route traffic through a provider with large, distributed capacity: a CDN with DDoS protection, a dedicated mitigation service or a cloud load balancer with built-in filtering. These networks absorb volumetric floods across many locations and filter malicious traffic before it reaches you.

When comparing options, ask practical questions rather than relying on marketing claims:

• Which layers are covered (network, protocol, application) and are any of them paid add-ons?
• Is mitigation always on, or does it activate only after detection?
• Are there bandwidth or request caps, and are you billed for attack traffic?
• What does the support process look like during an active incident?
• Can you set custom rules, rate limits and challenges for specific paths?

Pricing and limits change frequently and differ between plans, so check your provider’s current documentation rather than assuming coverage.

Hide and lock down your origin

A protection layer only helps if attackers cannot go around it. If your origin server’s IP address is known, an attacker can send traffic straight to it and bypass the CDN entirely.

1. Avoid leaking the origin IP. Old DNS records, unprotected subdomains such as mail or FTP hostnames, email headers and historical DNS data can reveal it. Consider moving to a new IP after enabling protection.
2. Allow web traffic only from the provider. Configure the firewall to accept ports 80 and 443 solely from your CDN’s published IP ranges, or use an authenticated tunnel or origin certificate if your provider supports one.
3. Restrict administrative access. SSH, control panels and database ports should not be open to the whole internet; limit them to VPNs or known addresses.

The TLDix hosting lookup is a quick way to see what the public can learn about where a hostname resolves, which helps when auditing subdomains for leaks.

Harden the application layer

Application-layer floods mimic real visitors, so defense focuses on making each request cheap and limiting abusive patterns.

Cache aggressively

Pages served from a CDN cache never touch your origin. Cache static assets for long periods and consider short caching even for dynamic but non-personal pages. Every cached response is one your server does not have to compute.

Rate limit sensibly

Limit requests per client on expensive endpoints such as login, search, checkout and APIs. An example for Nginx:

http {
    limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
    limit_conn_zone $binary_remote_addr zone=connperip:10m;

    server {
        location /search {
            limit_req zone=perip burst=20 nodelay;
            limit_conn connperip 20;
        }

        client_body_timeout 10s;
        client_header_timeout 10s;
    }
}

The numbers here are placeholders. Base real limits on your own traffic logs, and remember that many users can share one IP behind corporate or mobile networks. When traffic arrives through a CDN, configure the real client IP header correctly so you do not rate limit the CDN itself.

Reduce expensive work

• Optimize slow database queries and add indexes for common lookups.
• Move heavy tasks such as report generation or image processing into background queues.
• Use challenges or CAPTCHAs selectively on sensitive forms rather than everywhere.
• Set timeouts so slow connections cannot hold resources open indefinitely.

Plan capacity and graceful degradation

Resilience is not only about filtering. Think about what your site should do when it is under strain. Can the homepage and key landing pages be served as static files from the CDN if the application is down? Can non-essential features, such as recommendations, live search or heavy widgets, be switched off with a feature flag to save resources? Autoscaling in cloud environments can absorb moderate application-layer surges, but set spending limits and alerts, because scaling to meet attack traffic can become expensive quickly.

Separating components also helps. Hosting the API, admin area and public site on different hostnames or services means a flood against one does not automatically take down the others, and lets you apply stricter rules where they matter most.

Don’t forget DNS and the domain itself

If your authoritative DNS goes down, your site is unreachable even if the web servers are fine. Use a DNS provider with anycast infrastructure and redundancy; see how anycast DNS works for background. Some organizations use two independent DNS providers for extra resilience, which requires keeping zones in sync.

Also protect the registration itself. During an incident you may need to change name servers quickly, so make sure registrar access is secure and the domain is not close to expiry. Track renewal dates in TLDix domain monitoring so a lapsed registration never compounds an attack.

Monitoring and early warning

The earlier you notice an attack, the faster you can respond. Useful signals include:

• Uptime checks from multiple external locations.
• Sudden spikes in requests per second, bandwidth or error rates (especially 5xx responses).
• Unusual concentration of traffic on one URL, user agent or region.
• Rising server CPU, memory, connection counts or database load without a matching business reason.

Keep monitoring independent of the infrastructure it watches; an alerting service hosted on the same server will go silent exactly when you need it.

Establish a baseline of normal traffic so that anomalies are obvious. Alerts should reach a person who can act, not just an unattended inbox.

An incident response checklist

Write your plan before you need it. A simple version:

1. Confirm it is an attack, not a legitimate traffic surge, a bad deployment or an upstream outage.
2. Contact your hosting and protection provider using the escalation path you prepared in advance.
3. Enable stricter modes: higher security levels, challenges on targeted paths, temporary geographic or rate rules where justified.
4. Serve a cached or static version of key pages if the application is struggling.
5. Communicate with users through a status page or social channel hosted separately from the main site.
6. Afterwards, review logs, adjust rules and update the plan.

Prepare the people, not just the systems

During an incident, time is lost hunting for logins and phone numbers. Keep an up-to-date contact sheet with provider support channels, account IDs and who is authorized to change DNS or protection settings. Store it somewhere reachable even if your main site and email are affected. Running a short tabletop exercise once or twice a year, walking through the checklist above, reveals gaps such as expired credentials or unclear ownership long before a real attack does.

If an attack is accompanied by an extortion demand, involve your provider and report it to the appropriate authorities. This is not legal advice; check local requirements.