Business DDoS Protection: Layers and Playbook

A distributed denial of service attack does not need to break into anything to hurt a business. It only needs to exhaust one resource that your application depends on: the bandwidth of an uplink, the state table of a firewall, the connection pool of a load balancer, or the CPU of a database.

Good DDoS protection is therefore less about a single product and more about knowing which resource each kind of attack targets, and making sure there is a control in front of it that has more capacity than the attacker.

Three classes of attack, three different bottlenecks

Attacks are usually grouped by the layer they stress. The grouping matters because each class is measured differently, saturates a different component and is stopped in a different place.

• Volumetric. The goal is to fill the pipe. Traffic is measured in bits per second, and large events are reported in hundreds of gigabits or terabits. Reflection and amplification are common, where third party servers on the internet are tricked into sending large responses toward the victim. No server tuning helps here: if your uplink is 10 Gbps and 40 Gbps arrives, the link is full before a single packet reaches your firewall.
• Protocol. The goal is to exhaust state or packet processing capacity in network devices. These attacks are measured in packets per second rather than bandwidth. SYN floods and fragmented packet floods are typical examples. For reference, a 1 Gbps link carrying minimum size Ethernet frames delivers about 1.49 million packets per second, and a 10 Gbps link about 14.9 million, which is enough to overwhelm stateful firewalls and load balancers that were sized for normal traffic.
• Application layer. The goal is to make the application do expensive work. Traffic is measured in requests per second and often looks like ordinary HTTPS. A few thousand requests per second against a search endpoint, a login form or an uncached report page can exhaust database connections while total bandwidth stays modest. These are the hardest to detect because each request can be individually valid.

Real incidents often mix classes. Plan for each class separately, then test what happens when two arrive together.

Where mitigation happens

There are four places where attack traffic can be filtered. The further upstream a control sits, the more volume it can absorb but the less it knows about your application.

• Network edge and upstream provider. Your hosting or transit provider can drop traffic before it reaches your port, using access lists, flow based detection and remotely triggered blackholing. Blackholing protects the rest of the network but also drops legitimate traffic to the targeted address, so it is a last resort, not a defense.
• Scrubbing. Dedicated mitigation systems, either inline in the provider network or in remote scrubbing centers reached by rerouting traffic through BGP or DNS, inspect traffic at high volume and forward only clean packets. Scrubbing is the main answer to volumetric and protocol attacks. Ask whether it is always on or activated on detection, and how long activation takes, because the first minutes of an attack are often the most damaging.
• CDN and WAF. A content delivery network terminates connections at many edge locations, absorbs traffic across a wide footprint and serves cached content without touching your origin. A web application firewall adds HTTP level rules, bot detection and challenge pages. This is the main layer for application attacks against public websites and APIs.
• Application and origin. Your own load balancers, reverse proxies and code enforce connection limits, timeouts, per user quotas and graceful degradation. This layer has the most context (who the user is, what the endpoint costs) but the least capacity. It should never be the first line of defense against volume.

Upstream controls protect capacity, the CDN and WAF protect the application surface, and the origin protects itself from whatever gets through. The common failure is assuming one layer covers the others, for example relying on a WAF while the origin IP address is publicly known and reachable directly.

Rate limiting that holds up under load

Rate limiting is the most useful control against application layer attacks, and also the easiest to get wrong. The work is in choosing the right key, the right threshold and the right response.

• Start from measured baselines. Collect at least two to four weeks of request rates per endpoint, per client and per minute, including peak events. Set thresholds at a multiple of the observed 99th percentile rather than at a round number.
• Choose the key carefully. Limiting by IP address alone fails for customers behind corporate NAT or mobile carrier gateways, where thousands of users share one address. Where possible, combine IP with session, API key or authenticated user ID.
• Weight limits by cost. A static image and a full text search should not share a budget. Give expensive endpoints (login, search, export, checkout) their own tighter limits.
• Enforce at more than one layer. Apply coarse limits at the CDN or WAF and finer, identity aware limits at the API gateway or application. The edge stops bulk traffic cheaply, and the origin catches what looks legitimate at the edge.
• Respond proportionately. Return HTTP 429 with a Retry-After header for well behaved clients, use challenges for suspicious browsers, and drop silently only when you are confident the traffic is hostile.
• Use shared counters. If you run several application nodes, keep counters in a shared store such as Redis, otherwise each node enforces its own limit and the effective ceiling multiplies by the number of nodes.

Test limits before you need them. Replay production traffic patterns in a staging environment, raise volume gradually and confirm that legitimate flows keep working while the excess is rejected.

Architecture patterns that reduce exposure

Filtering is only half of the defense. The other half is designing the system so that there is less to attack and more room to absorb what arrives.

• Hide the origin. Put public services behind a CDN or proxy and allow inbound traffic to the origin only from that provider's published address ranges. Rotate origin addresses if they have leaked through old DNS records, mail headers or certificate transparency logs.
• Separate critical paths. Host the marketing site, the customer application, the API and administrative interfaces on different addresses and, where practical, different infrastructure. An attack on the public homepage should not take down the payment API.
• Keep management off the public internet. SSH, RDP, database ports and control panels should be reachable only through a VPN or private network, never on the same addresses that serve customers.
• Cache aggressively. Every response served from cache is a request the origin never sees. Review cache headers on pages that could be cached for even 30 to 60 seconds; under attack, a short TTL removes most of the origin load.
• Design for degradation. Identify features that can be turned off under pressure, such as recommendations, live search or non essential widgets, and put them behind feature flags so the core transaction path keeps working.
• Spread across locations. Running in two or more regions, with DNS or anycast steering, means one saturated site does not end the service. It also gives you somewhere to shift traffic while a provider activates mitigation.
• Plan headroom. Know the capacity of every link and device in the path. A 1 Gbps port moves roughly 10 TB per day at full load, which sounds large but is small compared with attack volumes, so upstream mitigation has to absorb what your port cannot.

DNS is a frequent single point of failure: use a provider with a large anycast network, or two providers, and keep record TTLs short enough to make changes quickly during an incident.

Incident playbook

Most of the damage in a DDoS incident comes from slow decisions, not from missing technology. A written playbook, with names and phone numbers, turns a confusing hour into a routine fifteen minutes.

• 1. Detect. Alert on traffic and behavior, not only on server health: inbound bandwidth, packets per second, requests per second per endpoint, error rates and latency at the edge and at the origin. Define thresholds in advance so the on call engineer does not have to judge in the moment.
• 2. Classify. Determine whether the attack is volumetric, protocol or application layer, which addresses and endpoints are targeted, and whether the impact is at the link, the network devices or the application. Flow data and edge logs answer this faster than server logs.
• 3. Engage the right layer. For volumetric and protocol attacks, contact the hosting provider or scrubbing service through the agreed channel and confirm mitigation is active. For application attacks, tighten WAF rules and rate limits, enable challenges and shed non essential features.
• 4. Protect the core. Prioritize the revenue path and customer authentication. If needed, temporarily restrict access by geography or block whole client categories, accepting some collateral impact for a short period.
• 5. Communicate. Post a status page update early, brief customer support with a short script and keep executives informed on a fixed cadence. Avoid speculating about the source of the attack.
• 6. Watch for follow up. Attacks often change vector when the first one is blocked. Keep heightened monitoring for at least 24 to 48 hours and be alert to other activity, such as login attempts or intrusion attempts, that may be hiding behind the noise.
• 7. Review. Within a week, record the timeline, what was detected and when, which controls worked, what was slow and which thresholds should change. Update the playbook and schedule the fixes.

Rehearse the playbook at least twice a year with a tabletop exercise. Never run unannounced tests against production or third party infrastructure.

DDoS readiness checklist

Use this list in your next infrastructure review.

• Inventory. All public IP addresses, domains and endpoints are listed, with the business service each one supports.
• Provider mitigation. You know what DDoS protection your hosting and transit providers include, its capacity, whether it is always on, and how to request activation.
• Escalation contacts. Provider support and mitigation contacts are documented and tested, including outside business hours.
• Origin protection. Origin servers accept web traffic only from the CDN or proxy, and old origin addresses have been retired.
• Management access. Administrative ports and panels are not exposed on public addresses.
• DNS resilience. DNS is hosted on a large anycast network or two providers, with TTLs reviewed.
• Rate limits. Limits exist per endpoint, are based on measured baselines, use shared counters and can be changed through configuration.
• WAF rules. A tested emergency rule set is ready to enable, including challenge mode and geographic restrictions.
• Caching. Cacheable pages and assets are actually cached at the edge, with hit ratios monitored.
• Degradation. Non essential features can be disabled through feature flags without a deploy.
• Monitoring. Alerts cover bandwidth, packets per second, requests per second, error rates and latency at edge and origin.
• Playbook. A written playbook exists, names an incident lead and has been rehearsed in the last six months.
• Communication. Status page, support scripts and executive update templates are prepared.
• Post incident review. There is a standard template and a deadline for completing it.

How Vonahost can help

Vonahost dedicated servers are single-tenant AMD EPYC machines with a dedicated 1 Gbps port on a 100/200 Gbps network fabric and include Arbor DDoS mitigation, so volumetric and protocol filtering happens in the network before traffic reaches your port. Vonahost managed cloud includes a CDN, monitoring and Redis, which cover the edge caching and shared rate limit counters described above, and runs on Vonahost's own platform, on AWS or on Google Cloud.

Every proposal states the configuration, location, responsibilities and monthly price in US dollars, so it is clear which parts of this checklist the provider covers and which remain with your team. You choose the country of each server, and data is not moved without your approval.