DDoS Protection for Small Business Websites

A DDoS (distributed denial of service) attack floods a website or server with traffic from many sources at once, aiming to make it slow or unreachable for real visitors. Small businesses face the same three broad attack categories that large enterprises do, but the fix does not need enterprise-level spend: a CDN/proxy in front of the site, sane rate limiting on the server, and a plan for what to do when something slips through.

What a DDoS attack actually is

A DDoS attack is an attempt to exhaust a target's bandwidth, connection capacity, or application resources using traffic from many distributed sources, so that legitimate users cannot get through. The "distributed" part matters: unlike a single attacker hammering your server from one IP (which a basic firewall rule can block), a DDoS attack spreads the load across hundreds, thousands, or in large botnet cases millions of compromised devices, making source-IP blocking alone ineffective.

For a small business, the practical question is rarely "will we be targeted by a nation-state-scale attack." It's "will a botnet, a competitor, an aggrieved former customer, or an automated scanning tool generate enough abnormal traffic to knock our site offline, and do we have anything in place to notice or stop it."

The three DDoS attack types you'll encounter

DDoS attacks fall into three categories: volumetric, protocol, and application-layer, and each one exhausts a different resource, so each needs a different defense.

Volumetric attacks

Volumetric attacks saturate your network pipeline with raw traffic volume, using techniques like UDP floods, ICMP floods, and spoofed or amplified packet floods, until legitimate traffic simply cannot fit through the connection. This is the category behind the record-setting attacks that make headlines: Cloudflare reported defending against a 6.5 terabit-per-second flood and, separately, the most intense packet-rate attack on record at 4.8 billion packets per second, both during 2025 (Cloudflare, 2025 DDoS threat reports). A small business server's uplink is nowhere near that scale, which is exactly why even a modest volumetric flood can take it offline.

Protocol attacks

Protocol attacks target how connections are established and maintained, tying up resources on firewalls, load balancers, and the server's own connection tables rather than raw bandwidth. Common examples include TCP SYN floods, ACK floods, and other forms of TCP state exhaustion, where the attacker opens (or half-opens) far more connections than the server can track.

Application-layer (Layer 7) attacks

Application-layer attacks target the web application itself, typically over HTTP, and are the hardest to detect because the individual requests look legitimate. According to security researchers who track these attacks, Layer 7 floods exhaust server-side resources such as database connections, PHP-FPM workers, or CPU by sending high volumes of requests, or by using "low and slow" connection exhaustion that never triggers a simple volume threshold. This is also the category where the line between "DDoS" and "aggressive scraping or credential stuffing" gets blurry, and it's the one most within reach of server-side mitigation like rate limiting and fail2ban.

Modern attacks increasingly combine all three. Cloudflare's Q3 2025 threat report describes the Aisuru botnet, estimated at one to four million infected devices, launching attacks that routinely exceeded 1 terabit per second and 1 billion packets per second, alongside separate hyper-volumetric HTTP floods exceeding 200 million requests per second (Cloudflare Radar, DDoS threat report for 2025 Q3 and Q4). Across all of 2025, Cloudflare reported DDoS attack volume more than doubled year over year to 47.1 million attacks, averaging 5,376 attacks mitigated per hour.

What DDoS attacks look like for a small business

For a small business, a damaging DDoS attack is usually a fraction of the size of the record-breaking attacks in the headlines, because the target's own infrastructure is far smaller than a large CDN's network. A VPS with a 1 Gbps port and a database that struggles past a few hundred concurrent connections does not need a multi-terabit flood to fall over; a few hundred Mbps of junk traffic, or a few thousand malicious requests per second aimed at a slow endpoint like a search page or login form, is often enough.

The realistic small business scenarios tend to fall into a few patterns: a botnet scanning broad IP ranges that happens to include yours and pounds an open port; a competitor or disgruntled party paying for a cheap "booter" service against your domain; scrapers or credential-stuffing tools disguised as high-volume "normal" traffic; or collateral damage from an attack aimed at another site on shared infrastructure. NIST has noted that smaller businesses often lack the expertise or budget to develop a dedicated anti-DDoS strategy (NIST, Advanced DDoS Mitigation Techniques program), which is precisely why the baseline defenses below matter more for SMBs than the exotic ones.

Realistic mitigation options for SMB budgets

The realistic, budget-appropriate DDoS defense for a small business is layered: a CDN/proxy absorbs volumetric and protocol attacks before they reach your server, and server-side rate limiting plus fail2ban handle application-layer abuse that gets through.

CDN or reverse proxy in front of your site

Putting a CDN/proxy service such as Cloudflare in front of your domain is the single highest-leverage step available to a small business, because it hides your origin server's IP address and absorbs network-layer attacks using infrastructure sized for exactly that purpose. This is also the layer where AWS Shield and AWS WAF operate for AWS-hosted applications: AWS's own documentation describes using a rate-based rule in a WAF web ACL as the starting point for application-layer DDoS protection, evaluating traffic over a rolling window and automatically blocking IP addresses that exceed the configured threshold (AWS WAF developer guide, "Configuring application layer DDoS protections"). The Cloudflare equivalent works similarly at the edge, before traffic ever reaches your VPS.

Rate limiting at the web server

Nginx's limit_req and limit_conn directives cap how many requests and connections a single IP can make in a given window, which handles the predictable, everyday class of abuse: too many requests from too few sources hitting too few endpoints. This is a server-side control that works whether or not you're using a CDN, and it's worth pairing with sensible limits on login pages, search endpoints, and anything that triggers a database query, since those are the cheapest targets for an attacker to exhaust.

limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;

server {
    location /login {
        limit_req zone=general burst=5 nodelay;
    }
}

For a deeper walkthrough of server-side hardening beyond rate limiting, see our nginx security best practices guide.

fail2ban for application-layer abuse

Fail2ban reads server logs for patterns like repeated failed logins or triggered rate-limit rejections, then escalates persistent offenders to firewall-level IP bans, commonly stepping bans up from short timeouts to 24 or 48 hours for repeat abusers. It has a built-in filter for nginx rate-limit rejections specifically, so it can automatically convert "this IP keeps hitting the rate limit" into "this IP is now firewalled." Fail2ban will not stop a volumetric flood, since that traffic never gets far enough to generate a log entry it can act on, but it is genuinely effective against the login brute-forcing, scraping, and low-volume HTTP abuse that make up most of the application-layer incidents a small business actually sees. It works as one layer within a broader firewall setup; see our Linux firewall guide for how it fits alongside iptables/nftables and default-deny policies.

Upstream provider filtering

Most hosting providers and VPS platforms apply some level of network-layer DDoS filtering upstream, simply to protect their own shared infrastructure, and this stops a meaningful share of attacks before you ever see them. The catch is that this protection is tuned for the provider's network, not your specific application, so it will not catch application-layer abuse or attacks sized just below the provider's own trigger thresholds. Know your provider's DDoS policy and escalation contact before an incident, not during one.

What's oversold versus what's realistic

The most oversold idea in small business DDoS protection is that any single product is a complete solution. A CDN alone does not replace server-side rate limiting, and rate limiting alone does not replace a CDN, because they defend against different attack layers, and vendors selling either one in isolation tend to understate that gap.

It's also worth being realistic about scale. Marketing materials for enterprise DDoS products lean heavily on record-breaking numbers, terabits per second, billions of packets per second, because those numbers are dramatic. A small business almost never needs to defend against that scale directly; the CDN or upstream provider absorbs attacks at that size long before they reach a small origin server. What a small business actually needs to defend against is the much smaller, much more common application-layer abuse and modest volumetric floods that specifically target under-provisioned infrastructure, which is a different (and more achievable) problem than "stop a multi-terabit attack."

Conversely, "we're too small to be targeted" is also wrong. Botnets scan broad ranges indiscriminately, booter services are cheap enough that even a minor grudge can trigger an attack, and a small unpatched server is often an easier target than a well-defended large one, not a less interesting one. The right posture is proportionate, not absent.

Building a practical response plan

A practical DDoS response plan for a small business answers three questions in advance: how will we detect an attack, who do we contact, and what do we change temporarily while it's happening. Detection can be as simple as monitoring for abnormal spikes in bandwidth, connection counts, or request rates to specific endpoints, ideally with alerting rather than someone noticing the site is down.

Know in advance whether your CDN/proxy has an "under attack" mode that adds a JavaScript challenge or CAPTCHA to visitors, since flipping that on temporarily during a real attack is far better than discovering the option exists mid-incident. Keep your hosting provider's abuse or DDoS escalation contact somewhere accessible that doesn't depend on the affected server being reachable. And review your rate limit thresholds periodically as traffic grows, since limits tuned for a small site two years ago may now be blocking legitimate customers or, worse, sitting so loose they no longer do anything.

This response plan is really a subset of a broader server hardening baseline. If you haven't worked through the fundamentals, our VPS security checklist is the place to start before layering DDoS-specific controls on top.

In the news: the October 2026 strikes on Yandex data centers are a reminder that DDoS protection is one layer among several, alongside multi-zone design and off-provider backups.

On nginx, the limit_req directive is the usual way to apply application-layer rate limits.

Related attack types: SYN flood and Botnet.