How to Prevent a DDoS Attack: A Practical Guide for Websites and Businesses

What Is a DDoS Attack?

A distributed denial-of-service (DDoS) attack occurs when an attacker uses many devices or systems to overwhelm a website, server, application, or network with traffic or requests.

VPN

Proton VPN

3.5

3.5

Proton VPN combines Swiss privacy law, open source audited apps, and Secure Core routing with strong speeds and a genuinely usable free tier.

• Genuinely unlimited free VPN plan
• Fully open source client apps

• Monthly pricing sits above rivals
• Free plan limited to few countries

Read review View Plans Affiliate Link

The objective is to exhaust resources and prevent legitimate users from accessing the service.

Unlike a basic denial-of-service attack that originates from a single source, a DDoS attack can distribute malicious traffic across many devices, making it harder to distinguish harmful requests from legitimate visitors.

Some attacks rely on compromised devices controlled as a botnet, while others exploit weaknesses in network protocols or overwhelm resource-intensive application endpoints.

The FBI’s Internet Crime Complaint Center identifies traffic from many sources as a defining challenge in DDoS mitigation.

A website experiencing a DDoS attack may load slowly, return errors, become temporarily unavailable, or lose access to the network services it depends on.

An attack can target different parts of the infrastructure, so the right defense depends on where the traffic is overwhelming resources.

The three broad categories are:

• Network-layer attacks: Attempt to overwhelm network capacity or infrastructure with excessive traffic.

• Transport-layer attacks: Target network connections and protocol handling, potentially exhausting connection state or related resources.

• Application-layer attacks: Send large numbers of requests to websites or APIs, sometimes targeting operations that require significant processing power or database activity.

These categories can overlap.

A robust defense must account for the network, transport, and application layers rather than relying on a single firewall rule.

1. Use a Dedicated DDoS Protection Service

For most public-facing websites and online services, a managed DDoS protection service is one of the most important defenses.

These services monitor traffic patterns and use network capacity and filtering systems to absorb or block attack traffic before it overwhelms the protected service.

A suitable provider should offer protection that matches your infrastructure, including network-layer and application-layer mitigation when needed.

Ask whether the service can handle volumetric attacks, protocol abuse, and HTTP request floods, and how it responds when traffic exceeds your normal capacity.

Common options include the following.

Cloudflare DDoS Protection provides automatic mitigation for multiple categories of DDoS traffic, including network-layer and HTTP attacks.

Its documentation also recommends combining managed protection with custom firewall and rate-limiting rules.

AWS Shield provides DDoS protection for supported Amazon Web Services infrastructure.

AWS Shield Standard is automatically available for eligible services, while more advanced protection options provide additional capabilities for certain architectures and workloads.

Organizations should verify the coverage and requirements for their specific deployment.

Google Cloud offers infrastructure and application protection capabilities for workloads hosted on its platform.

The appropriate configuration depends on the services in use, traffic architecture, and protection requirements.

Before selecting a provider, check which services and protocols it protects, whether traffic must pass through its network, how alerts and incident support work, and what costs may apply during sustained high traffic.

A service that protects a website’s HTTP traffic may not automatically protect every exposed IP address, mail server, game server, or other internet-facing endpoint.

2. Put a Content Delivery Network in Front of Your Website

A content delivery network, or CDN, distributes website content across a network of servers.

When a visitor requests a cached image, stylesheet, script, or other supported resource, the CDN may serve it without sending the request all the way to the origin server.

This reduces the load on the origin and can help a website remain responsive during traffic surges.

A CDN with integrated DDoS protection can also distribute incoming traffic and filter attack patterns across its network.

For a typical content website, the setup process is:

1. Choose a CDN that supports your hosting environment and security requirements.

2. Configure your domain and DNS according to the provider’s instructions.

3. Enable the appropriate DDoS protection features.

4. Configure caching for static assets and other content that can safely be cached.

5. Verify that legitimate visitors can access the website and that important application features still work.

6. Monitor traffic, origin load, cache performance, and security events.

Caching should be configured carefully.

Pages containing account information, shopping carts, personalized dashboards, or other private data generally require different handling from public images and static files.

Incorrect caching rules can expose private content or deliver stale information.

A CDN also cannot compensate for every architectural weakness.

Requests that must reach an overloaded origin, unprotected services that bypass the CDN, or attacks against other network endpoints may require additional controls.

The UK National Cyber Security Centre recommends considering CDNs and upstream provider defenses as part of a broader denial-of-service strategy.

3. Configure a Web Application Firewall

A web application firewall, commonly called a WAF, filters HTTP and HTTPS requests before they reach an application.

Depending on the product and configuration, it can block suspicious patterns, enforce access rules, challenge selected requests, and apply rate limits.

A WAF is particularly useful against application-layer DDoS attacks, in which large volumes of web requests consume application, database, or API resources.

Effective WAF configuration starts with understanding normal application behavior.

Identify public endpoints, authentication pages, search functions, APIs, and other routes that could become resource bottlenecks.

Apply managed security rules and customize them when necessary, testing changes to avoid blocking legitimate users.

Do not assume that every unusual request is malicious.

Automated services, search crawlers, mobile applications, and legitimate traffic spikes can produce request patterns that resemble abuse.

Security rules should be monitored and adjusted to balance protection with availability.

A WAF is not a replacement for upstream network-level DDoS mitigation.

If the network connection is saturated before traffic reaches the WAF, application filtering alone may be unable to restore access.

4. Apply Rate Limiting to High-Risk Endpoints

Rate limiting controls how frequently a client can make requests within a defined period.

It can help prevent a single client, automated process, or concentrated set of requests from consuming excessive application resources.

Useful candidates include login forms, search endpoints, password-reset workflows, expensive API operations, and other features that trigger substantial processing.

Limits should reflect the behavior of legitimate users and the cost of each operation.

For example, a public search endpoint may need a different policy from a static image URL.

A login workflow may require controls that slow automated attempts without preventing people from signing in during a legitimate traffic surge.

Rate limiting should account for the limitations of identifying users by IP address alone.

Many legitimate visitors can share a public IP address, while distributed attackers may send requests from many different addresses.

A simple per-IP threshold may therefore be insufficient for a large or sophisticated attack.

Where supported, combine rate limits with authentication controls, application-level quotas, bot-management features, and monitoring.

Test rules before applying aggressive limits to production traffic.

Cloudflare recommends combining managed DDoS protections with custom WAF and rate-limiting rules as part of proactive defense.

5. Protect the Origin Server

The origin server is the infrastructure that ultimately serves the website or application when requests are not handled elsewhere.

If an attacker can bypass the CDN or proxy and reach the origin directly, some protections may be less effective.

Where your architecture supports it, restrict public access to the origin so that web traffic can reach it only through the approved CDN or reverse proxy.

Configure firewall rules to permit the provider’s documented traffic sources, and ensure that administrative interfaces are not unnecessarily exposed to the internet.

Cloudflare specifically recommends preventing direct public access to the origin and, where appropriate, replacing origin IP addresses that have previously been targeted directly.

Other important steps include:

• Remove unused public services and close unnecessary ports.

• Restrict administrative access to trusted networks or secure access systems.

• Keep server software and exposed services updated.

• Review DNS records and public infrastructure exposure.

• Protect separate services, such as mail servers and APIs, instead of assuming that website protection covers them automatically.

• Verify that firewall rules remain correct after infrastructure changes.

Do not make firewall changes without understanding the service dependencies.

Blocking required traffic can create an outage even when no attack is taking place.

6. Build Infrastructure That Can Handle Traffic Spikes

Scalable infrastructure can reduce the impact of sudden increases in legitimate traffic and some application-layer attacks.

Depending on the architecture, scaling may involve adding application instances, increasing capacity, using load balancers, or distributing services across multiple locations.

However, scaling alone is not a complete DDoS defense.

Attack traffic can grow faster than an application can scale, and automated scaling may increase costs substantially if malicious requests continue to arrive.

The better approach is to combine scaling with traffic filtering, resource limits, caching, and monitoring.

Establish limits on expensive operations, protect databases from unnecessary work, and identify which parts of the application become constrained first.

For critical services, consider graceful degradation: keeping essential features available while temporarily disabling or reducing resource-intensive functions.

A public website might continue serving cached information while a costly search feature is temporarily restricted.

The UK National Cyber Security Centre recommends understanding service dependencies, ensuring providers can help with upstream attacks, designing for scale, and preparing for partial service degradation.

7. Monitor Traffic and Set Alerts Before an Attack

DDoS protection is more effective when the organization can distinguish normal activity from unusual patterns.

Monitoring should cover more than total visitor counts.

Useful signals include bandwidth consumption, request rates, server CPU and memory usage, database activity, connection counts, application error rates, latency, and traffic to individual endpoints.

A sudden increase in requests accompanied by rising errors or resource exhaustion may indicate an attack, although legitimate events can produce similar symptoms.

Establish a baseline for normal traffic, including predictable peaks such as product launches, major announcements, promotions, or seasonal demand.

Configure alerts that notify the responsible team when key metrics exceed meaningful thresholds.

Centralized logs and dashboards can help responders determine whether the issue is affecting the CDN, network connection, application, database, or another dependency.

Ensure that the organization can still access administrative monitoring and provider support during an incident.

Monitoring should be tested before an emergency.

Alerts that are too sensitive can overwhelm responders, while thresholds that are too broad may delay detection.

8. Prepare a DDoS Incident Response Plan

A written response plan reduces confusion when a service becomes unavailable.

It should identify who can activate emergency protections, which providers to contact, where monitoring data is available, how customer communications will be handled, and who can approve potentially disruptive changes.

The plan should include:

• Emergency contacts for the hosting provider, ISP, CDN, and DDoS mitigation service.

• Procedures for identifying the affected service and likely attack layer.

• Steps for enabling provider-supported mitigation and reviewing WAF or rate-limiting rules.

• Criteria for scaling resources or temporarily disabling expensive features.

• Backup communication channels if the main website or email service is unavailable.

• Recovery checks and a process for reviewing the incident afterward.

If an attack is underway, first establish what is failing and contact the providers responsible for the affected network or service.

They may be able to filter traffic upstream, where the organization’s own infrastructure cannot do so effectively.

Avoid responding by blocking large groups of users or changing multiple production settings without assessing the likely impact.

Such actions can interrupt legitimate traffic and make diagnosis harder.

The FBI’s Internet Crime Complaint Center recommends preparing with mitigation services, ISP coordination, continuity planning, and secure backups.

The CISA, FBI, and MS-ISAC joint guidance also addresses preparation and response to DDoS incidents.

9. Test Your Defenses Safely

A security control that has never been tested may fail when it is needed most.

Organizations should verify that mitigation features are enabled, alerting works, incident contacts are current, and recovery procedures can be followed.

Use staging environments, provider-supported simulations, and authorized load tests to evaluate how the system behaves under increased traffic.

Coordinate testing with hosting and security providers, particularly when tests could affect shared infrastructure or trigger automated defenses.

Do not launch an unapproved stress test against public systems.

Testing should be limited to infrastructure you own or have explicit authorization to assess.

Review the results for both resilience and false positives.

A successful defense should mitigate harmful traffic while allowing legitimate requests to continue wherever possible.

AWS recommends establishing protection during normal traffic periods, monitoring metrics, and testing configurations in staging before applying changes to production.

10. Choose DDoS Protection Based on Your Infrastructure

Different services require different defenses.

A small business website, a large e-commerce platform, a public API, and a multiplayer game server may face different traffic patterns and technical constraints.

A small website may begin with a CDN, managed DDoS protection, and basic WAF rules.

A business application may also require carefully designed rate limits, protected origin infrastructure, detailed monitoring, and a documented incident response process.

A high-traffic service or a business with strict uptime requirements may need specialized network protection, upstream mitigation agreements, redundancy, and defined incident response support.

The appropriate design depends on the cost of downtime, exposed protocols, expected traffic, application architecture, and available budget.

When comparing providers, ask:

• Which network and application layers are protected?

• Does protection operate automatically, and what can be configured?

• Can the provider filter traffic before it reaches the origin network?

• What happens when attack traffic exceeds the expected capacity?

• Which endpoints, IP addresses, protocols, and cloud resources are covered?

• Are monitoring, incident support, and escalation procedures included?

• Could usage-based charges increase significantly during an attack?

• How can the service be tested without disrupting production?

Review service terms and technical documentation rather than relying on broad claims of unlimited or complete protection.

What to Do If a DDoS Attack Is Happening Right Now

If your website or service is under attack, prioritize restoring availability and coordinating with the organizations that control the affected infrastructure.

First, check provider dashboards and monitoring data to determine whether the problem involves bandwidth, connection capacity, application requests, or a separate service dependency.

Then contact your hosting provider, ISP, or DDoS protection provider and request assistance with mitigation.

Enable the provider-supported protections available for your architecture.

Review rate limits and WAF rules, but avoid broad changes that could block legitimate users.

If the application is overloaded, consider temporarily restricting expensive nonessential features while preserving critical functions.

Keep a record of relevant timestamps, traffic metrics, alerts, error rates, and provider communications.

These details can help with diagnosis, recovery, and post-incident analysis.

Follow your incident response plan and notify affected customers through an alternative channel if necessary.

After service is restored, review how the attack reached the infrastructure, whether any defenses failed, and which changes would reduce the likelihood or impact of a future incident.

If the incident involves other indicators of compromise, investigate those separately rather than assuming every symptom is explained by the DDoS traffic.

Can You Completely Prevent a DDoS Attack?

No security product or configuration can guarantee that every DDoS attack will be prevented.

Organizations can reduce their exposure and limit disruption by combining upstream mitigation, network and application filtering, caching, scaling, monitoring, and incident response planning.

The objective is to make the service harder to overwhelm, reduce the amount of harmful traffic reaching critical resources, detect problems early, and recover quickly when an attack succeeds in disrupting part of the system.

For most organizations, the strongest starting point is to confirm that the hosting or network provider offers appropriate DDoS protection, place public web traffic behind a suitable CDN or reverse proxy where practical, protect the origin, and test a written response plan before an incident occurs.

Key Facts

• A DDoS attack distributes traffic or requests across multiple sources to overwhelm a service.

• Protection should address the network, transport, and application layers relevant to the infrastructure.

• CDNs, WAFs, rate limiting, upstream mitigation, and scalable architecture address different parts of the problem.

• Monitoring and a tested response plan help reduce downtime and confusion during an incident.

• No single product or configuration guarantees complete immunity from DDoS attacks.

  

  VPN

  Proton VPN

  3.5

  3.5

  Proton VPN combines Swiss privacy law, open source audited apps, and Secure Core routing with strong speeds and a genuinely usable free tier.

  • Genuinely unlimited free VPN plan
  • Fully open source client apps

  • Monthly pricing sits above rivals
  • Free plan limited to few countries

  Read review View Plans Affiliate Link