DDoS is no longer a “big company” problem. A small ecommerce site, a local media portal, a landing page during a promo-anyone can be knocked offline by a wave of junk traffic. The good news: around 80% of the risk can be mitigated with simple, inexpensive actions-smart DNS, perimeter filtering, caching, rate‑limits, and a bit of configuration discipline. This guide is a practical playbook with no magic boxes: which attacks you’re likely to face, what really works, what to do tonight, and how not to overpay with complexity.
How attacks work (and where to defend)
Layers and surfaces
- L3/L4 (network/transport): SYN floods, UDP floods, ICMP floods, fragmentation abuse, and classic reflection/amplification (NTP, DNS, CLDAP, Memcached, etc.). Goal: saturate the pipe or overwhelm state tables.
- L7 (application): HTTP floods, slow‑loris/slow‑read, waves to computationally heavy endpoints (search, cart, PDF render), and newer patterns like HTTP/2 “rapid reset” or HTTP/3/QUIC storms. Goal: exhaust CPU/DB/queues.
Where to filter
- In front of your origin – global anycast edge with CDN/WAF. For a small site this is the most effective and cost‑efficient level: let someone else’s perimeter absorb the punch.
- At your provider’s ingress – datacenter/ISP filtering, “clean pipe,” border ACLs.
- On your own server – OS limits, firewall, web server/proxy settings, caching, and per‑endpoint/app limits.
Resilience is layered. Some junk never reaches your ASN, some gets dropped at the border, and the rest is defused by caches and rate limits.
Why this matters (and why “more horsepower” won’t save you)
- Bandwidth isn’t armor. Many attacks are targeted: they hit state tables, TLS handshakes, queues, or heavy SQL. Doubling CPU won’t fix an ocean of slow connections.
- Reliability = trust. An hour of downtime during a launch burns marketing budget and customer goodwill.
- Misconfigurations cause self‑DoS. A redirect loop, disabled caching, an unbounded request body-under load, these are DoS by your own hand. Good defaults often beat pricey subscriptions.
A pragmatic protection plan (priorities for small sites)
Below is a 12‑step plan split into three tiers. Work down the list; stop when risk and budget meet.
Tier 1 – “Do it tonight” (minimal cost)
- Competent DNS
- Use two or more NS providers/regions.
- Set sensible TTLs: short (5–15 min) for A/AAAA of the site, longer for static records.
- Hide your origin IP: don’t leak it via stray A records for staging/mail/panel.
- CDN/Reverse proxy in front
- Enable full caching of static assets (Cache-Control with long TTL, ETag, gzip/brotli).
- For popular HTML, enable edge caching with short TTL and explicit invalidation on release.
- Minimize passes to origin-fewer origin requests = harder to overwhelm.
- Basic WAF/Bot protection
- Allow only needed methods (GET/HEAD/POST); block the rest.
- Hide admin: restrict by IP/ASN/country and/or require a challenge (JS/captcha).
- Turn on managed rules for SQLi/XSS/scanners and set per‑endpoint frequency limits for “expensive” routes.
- Rate limiting at the edge and on origin
- Limit by IP/prefix/token; set separate quotas for heavy operations (search, login, post/purchase).
- Use a small burst allowance and a grace period so legit users aren’t punished.
- Application‑level cache
- Cache HTML fragments, menus, and slow widgets.
- Externalize sessions/cache to Redis/Memcached; keep hot keys in memory.
- HTTP/2 and HTTP/3 with constraints
- Limit stream/frames concurrency; drop idle/slow streams; enable rapid‑reset protections.
- Disable exotic features you don’t use; they just widen the attack surface.
Tier 2 – “One week to tidy up”
- Firewalling and OS/network limits
- Size nf_conntrack/state tables with headroom and alerts, but apply anti‑scan rate limits.
- Enable SYN cookies and limit half‑open connections; drop legacy protocols/ports.
- Simple ACLs: block obviously abusive ASNs/regions you don’t serve.
- Plug origin backdoors
- No direct IP access to origin: only via CDN/proxy (allowlists of proxy IPs, mTLS, firewall rules).
- Use a separate subdomain and stricter policy for admin/API.
- Solid TLS posture
- Clean cipher profiles, HSTS, automated certificate renewals.
- Prioritize modern ciphers; disable renegotiation/compression.
- Web server/proxy hardening
- Cap header/body sizes, first‑byte/read/send timeouts, max connections, worker/memory limits.
- Sane keep‑alive and buffers so slow‑reads don’t starve workers.
- Signals and alerts
- Watch RPS, p95, 5xx, cache‑HIT ratio, open connections, conntrack, SYN backlog.
- Consolidate by root cause: one incident → one page.
- Defensive degradation plan
- Prepare a lightweight landing (no heavy widgets) you can switch on quickly.
- Fallbacks for critical APIs: queues/cached responses/placeholders.
Tier 3 – “Redundancy and readiness”
- Two independent origins (active‑passive or active‑active) with content/state sync.
- Geo load‑balancing and anycast edge.
- Separate public and admin planes (different domains/paths/keys).
- Fire drills quarterly: simulate an attack (safely) and measure MTTA/MTTR.
Concrete recipes for common attacks
- SYN flood (L4): enable SYN cookies; increase backlog and half‑open timeouts; ask DC/ISP to drop spoofed sources; limit new connections/sec per IP.
- UDP flood/amplification: close unneeded UDP services; rate‑limit per port; block known reflectors; rely on edge scrubbing for volumetrics.
- Slow‑loris/slow‑read (L7): cap header/body sizes; first‑byte deadlines; minimum client read rate; limit concurrent requests per IP; reap hung connections.
- HTTP flood to heavy pages: aggressive caching (edge + app), JS challenges/captcha for suspicious ASNs/UAs; per‑endpoint limits; pre‑render and reduce response weight.
- Brute force/scraping: behavioral rules; block by IP/ASN/geo; mandatory JS/captcha on anomalies; honey endpoints to fingerprint scanners; content protections (robots/headers/controlled throttling).
Mistakes that break resilience more often than attackers do
- No HTML caching (CMS renders every homepage from scratch).
- Origin reachable by direct IP, bypassing WAF/CDN.
- No limits/timeouts on the web server and in the app.
- Public admin panels on the internet without IP filtering or MFA.
- Static assets and the DB on the same disk/pool: a log/static surge starves the database.
- Secrets/keys in public repos → used to bypass checks or hit private endpoints.
- Single points of failure: one NS provider, one region, one balancer.
One‑evening checklist (really)
- Two NS providers; TTL 5–15 min for the site’s A/AAAA.
- CDN/WAF edge enabled; origin hidden and only reachable from trusted proxy ranges.
- Edge cache for static + short HTML cache with release‑driven invalidation.
- Only GET/HEAD/POST allowed; admin restricted by IP + challenge.
- Rate limits on heavy endpoints; token bucket with burst.
- Header/body limits; connect/read/send timeouts set.
- SYN cookies on; conntrack monitored; junk ports dropped.
- Monitoring for p95/5xx/cache‑HIT/open conns + actionable alerts.
- Test plan: quick “ab/k6/locust” load or a mild challenge at the edge.
- Lightweight page/fail‑open mode prepared and documented.
Incident playbook: when it’s on fire
- Confirm: independent checks from 2–3 regions.
- Harden edge policies: suspicious ASNs/geos → challenges; aggressive per‑endpoint limits.
- Reduce origin work: raise HTML/JSON cache TTLs; pause heavy background jobs; switch to the lightweight landing.
- Protect origin: close direct IP; tighten proxy allowlists; bump conntrack/worker limits temporarily.
- Communicate: status page + brief user updates (“elevated load, service recovering”).
- Postmortem: what alerts missed, which links were weak, which defaults to change.
What this costs (pragmatically)
- $0–$20/mo: basic CDN/WAF plan-good enough for many small sites; edge caching, simple rate limits, method restrictions, IP filters.
- $20–$100/mo: add bot protection/challenges, custom L7 rules, reports/alerts, higher quotas.
- $100+: premium options-priority L3/L4 scrubbing, custom policies, geo load‑balancing, SLAs.
On your side it’s a few engineer hours to set up, then occasional tweaks as traffic patterns change.
Measuring success
- Availability (%) and errors (5xx/4xx) on key endpoints.
- Latency p95/p99-confirm filtering didn’t add harmful overhead.
- Cache HIT ratio-target >80% for static, >50% for HTML during peaks.
- Share of traffic challenged/blocked-a proxy for noise level and rule effectiveness.
- Origin utilization (CPU/memory/connections) at comparable RPS before/after changes.
Why Unihost
Network & edge. Routing and peering are tuned for low p95 latency; edge filtering reduces noisy traffic before it hits your servers. Private VLANs help separate public and administrative planes.
Servers for load. NVMe Gen4/Gen5, high‑frequency CPUs, predictable uplinks; edge+app caching synergy; dedicated resources for DB/queues.
Security by default. Firewall/ACL templates, origin shield (no direct IP access), automated TLS renewals, ready‑made rules for method/header/body limits.
Observability. Integrations with Prometheus/Grafana/ELK/OTel, alerts for conntrack/SYN backlog, status page and post‑incident reporting.
Scale path. Start on VPS, grow to dedicated or GPU servers without rearchitecting-configurations move with your stack via IaC.
TL;DR
For small sites, DDoS protection is mostly discipline and a dozen good settings, not a pricey magic box. Hide origin behind an edge, let caches work, set sane limits, lock down admin, enable alerts, and keep a degradation plan. In 8 out of 10 cases this rides out spikes and “cheap” attacks without downtime.
Try Unihost servers – stable infrastructure for your projects.
Order a VPS or dedicated server at Unihost, enable edge protection and caching, and survive the next attack without downtime.