← News
/PLAYBOOK · 2026-09-12

Small site under DDoS: buy high-defense or self-build?

High-defense IP runs from a few thousand to hundreds of thousands a year. Does a small site need it? Eight Q&As cover DDoS protection price tiers, three axes for buying high-defense, how much pure self-build can absorb with sysctl/iptables/Nginx configs, and whether the carrier will help under a massive flood.

We run small sites. Do we pay for high-defense? One of the questions site ops agonize over. Buy it: thousands to tens of thousands a year, idle most of the time. Skip it: one hit can cost more than the fee in downtime. Eight Q&As cover DDoS protection cost tiers, the buy/no-buy bar, and how far a zero-cost self-built mitigation actually goes.

Q: What DDoS protection tiers exist, and what is the price order of magnitude?

Four tiers, cheap to expensive. Capability gaps are orders of magnitude:

The price gap is protection bandwidth and whether traffic is scrubbed — not the vendor brand. One rule: advertised capacity is usually the guaranteed floor. The real elastic ceiling and overage billing rules are what you pin down before signing.

Q: Does a small site need to buy high-defense? What is the decision standard?

Don't go by feel. Score three dimensions:

Two of three on the high side → start with a CDN plan that includes protection. All three high → high-defense IP directly. Worst pattern: spend nothing in peacetime, shop only after you are hit. Vendor provisioning still takes time; the business is already down.

Q: Zero spend, pure self-build — how much can it absorb? What must be configured?

Straight answer: self-build only mitigates small floods. Your egress bandwidth and hardware sit where they sit. Hundreds of Mbps to a few Gbps is the ceiling. Against low-intensity and connection-oriented attacks, system tuning is clearly effective.

Step 1, kernel parameter tuning to mitigate SYN Flood and connection exhaustion:

# /etc/sysctl.conf
net.ipv4.tcp_syncookies = 1              # Enable SYN cookies; mitigate SYN flood
net.ipv4.tcp_max_syn_backlog = 8192      # Enlarge half-open (SYN) queue
net.ipv4.tcp_synack_retries = 2          # Reduce SYN-ACK retries
net.ipv4.tcp_fin_timeout = 15            # Shorten TIME_WAIT
net.ipv4.ip_conntrack_max = 1000000      # Enlarge connection tracking table
net.core.somaxconn = 65535               # Enlarge fully established connection queue
net.ipv4.tcp_tw_reuse = 1                # Reuse TIME_WAIT connections
sysctl -p   # Apply

Step 2, iptables per-IP connection limits — the most direct bleed-stop:

# Drop when a single IP exceeds 50 concurrent connections to port 80
iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 50 -j DROP
# Drop when a single IP exceeds 30 new connections per second
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m limit --limit 30/s --limit-burst 60 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j DROP
# Persist (CentOS)
iptables-save > /etc/sysconfig/iptables

Step 3, Nginx-layer concurrency limits so connections cannot be filled from a single source:

http {
    limit_conn_zone $binary_remote_addr zone=perip:10m;
    limit_req_zone $binary_remote_addr zone=reqip:10m rate=30r/s;
    server {
        location / {
            limit_conn perip 20;
            limit_req zone=reqip burst=50 nodelay;
        }
    }
}

With these three layers done, you can effectively mitigate connection-oriented attacks (SYN Flood, high-concurrency CC) and small volumetric floods. Against tens of Gbps of bandwidth flood they are basically useless — bandwidth is a physical limit. Config cannot create it.

Q: Is free/cheap CDN protection enough, and how does it differ from high-defense?

Enough or not depends on attack type and scale. CDN strength is origin hiding + traffic spreading: the domain resolves to CDN nodes, attack traffic is split across many edges. A few Gbps to tens of Gbps of volumetric attack usually holds, cost is low, and you get acceleration as a side effect. High-defense IP strength is centralized scrubbing: all traffic (including 100G+ attack traffic) is steered to a scrubbing POP, cleaned, then returned to origin. Protection ceiling is much higher, but there is no acceleration in peacetime, and cost is high.

The usual optimum for a small site is CDN first + temporary cutover to high-defense when overage hits: daily, CDN stops junk attacks; once traffic exceeds CDN capacity, flip DNS to the high-defense IP for emergency. Prerequisite: origin IP must stay hidden. If the attacker bypasses the CDN and hits origin directly, every prior investment is wasted.

Q: How is high-defense IP billed? How do you avoid getting burned?

High-defense billing has three main line items: guaranteed protection bandwidth (mandatory, e.g. 50G/year), elastic protection bandwidth (temporary ceiling above the guarantee, billed per incident or per day), and origin-return / forwarded traffic (billed per GB). Avoid-the-trap checklist:

One line: before signing, nail down how money is counted during an attack, and what happens when capacity is exceeded. That kills most later arguments.

Q: Under a massive volumetric attack, can the carrier help?

You can request it, but treat it as an auxiliary measure. When attack traffic exceeds the DC egress, the DC side usually blackholes first (fully drops the attacked IP) to protect the rest of the network. The business goes down with it. The more proper path is to request IP diversion / traffic scrubbing from the carrier: steer the attacked IP's traffic to the carrier or a third-party scrubbing center, then reinject after cleaning. Process: contact your IDC or carrier account manager and file a request. Handling time ranges from tens of minutes to several hours. Unsuitable as first response.

Domestic mainstream practice is still DC diversion into high-defense scrubbing. That is why pre-onboarding high-defense is more reliable than requesting it after you are hit — a blacklist can wait; the business cannot.

Q: What zero-cost emergency measures exist?

While under fire, if you bought no protection in advance, do these in order:

These turn "fully unreachable" into "opens but slow" and buy a window to purchase high-defense.

Q: Any extra advice?

A practical budget path: small site spends small money first — buy a CDN plan with a protection quota (hundreds per year), hide the origin IP, and finish system tuning plus iptables rate limits. Cost is near zero. Upgrade after the business has revenue — when one hour of downtime costs more than the high-defense annual fee, or you are clearly being targeted, then take high-defense IP. High-value business goes high-defense from day one — do not bet business income against attack probability. Last reminder: DDoS protection is layered. CDN handles hiding and spreading. WAF handles CC and the application layer. High-defense handles large-volume scrubbing. Self-built tuning handles small connection-oriented attacks. The four stacked is a complete scheme. Any single layer has a clear blind spot.