DDoS-Protected VPS Explained — What Filtering Actually Covers

What included L3/L4 DDoS filtering protects, what L7 attacks need, and how BitCloudVPS handles volumetric traffic on every VPS and dedicated plan.

Published 2026-08-30 · Updated 2026-10-21 · BitCloudVPS Editorial

The layers that matter

DDoS attacks are named by the OSI layer they hit. L3/L4 attacks (SYN floods, UDP amplification, ACK storms) try to saturate your pipe or state tables — these are absorbed upstream by the scrubbing centers before traffic reaches the host. L7 attacks (HTTP floods, slowloris, API hammering) look like real requests; no network filter can tell them from your users — they are your application's job (rate limiting, WAF, caching).

What is included on every plan

• VPS and Storage: automatic L3/L4 filtering, always on, no toggle and no extra fee.
• Dedicated: the same filtering, plus IPMI access so a compromised box can be reimaged out-of-band.
• Ultra (top dedicated): L3/L7 scrubbing included.

Sizing against an attack

• Check the plan's port speed: unmetered 1–10 Gbps on VPS lines defines the clean traffic ceiling.
• Put stateful defenses in the app: connection limits, bot scoring, CDN in front of HTTP if the surface is web-only.
• Keep the attack surface small — a VPN endpoint or game server presents far less than a WordPress blog.

Short answer: what you get at each plan price

A DDoS-protected VPS here is not a product tier - it is a property of the network every plan rides on. Scrubbing against volumetric layer 3 and layer 4 attacks (SYN floods, UDP amplification, junk-packet saturation) sits in front of all 21 locations and every SKU: Nano at $5.49/mo list carries it, so does Max at $60, the storage line, and dedicated metal from Dedicated Start $79.50 to Dedicated Ultra $449.50. There is no protection add-on, no upsell checkbox, and no cheaper plan with filtering disabled - the "is it really included" question resolves to the invoice: nothing on it names DDoS because nothing on it has to.

What the inclusion does not mean matters as much as what it does. The filter is volumetric, not semantic: it absorbs floods aimed at the pipe and passes everything that looks like a legitimate request, including the request floods that constitute a layer 7 attack. Uplink capacity differs by location - 10 Gbps at Reykjavik, 40 Gbps at most sites, 100 Gbps at Zurich, Frankfurt, Tokyo, Singapore, Ashburn and Dallas - and that capacity is the first order of attack budget an assault on your IP must exceed. So the honest model is three lines of defense: the edge scrubs gigabits, your uplink sizes the ceiling, and your host config handles what arrives as "traffic". The rest of this guide walks each line: what the layers look like, how to size and test, what to harden, and how to read the counters after a real event.

The layers in practice: what L3, L4 and L7 attacks look like on the wire

Layer 3 attacks abuse the network protocol itself: ICMP floods, malformed or Spoofed-source packets aimed at consuming router capacity rather than your bandwidth. You rarely see these from inside the VM because the scrubbing edge terminates them - the symptom of an L3 attack in progress is usually a graph, not a lagging shell. Layer 4 attacks target the transport and state machinery: a SYN flood opens thousands of half-connections hoping to exhaust the connection table; UDP amplification (DNS, NTP, memcached reflectors elsewhere on the internet) fires large response packets at your IP from spoofed sources, multiplying the attacker's bandwidth tens of times. These are the volumetric classes the edge filter is built against, and on a 40-100 Gbps site the typical amplification attack dies well before your 1-10 Gbps port is a factor.

Layer 7 is different in kind: HTTP GET floods, slow-reading connections, login-form brute force, API hammering - traffic indistinguishable from users except by rate and pattern. No volumetric filter can block it without blocking your customers too, which is why L7 is explicitly your layer: rate limits in nginx, connection caps in the firewall, application-level throttling. The practical diagnostic split follows directly: bandwidth maxed with a flat request rate means L3/L4 residue or an edge event; normal bandwidth with a multiplied request rate means L7, and the counter that matters lives in your access logs, not on the port graph. Knowing which layer you are in decides whether the fix is a ticket to the network or a config change on the box - confusing the two is how people wait out an application flood the edge was never going to stop.

Prerequisites and a test bench: measuring your exposure before the attack

Protection you have not measured is a claim, so build a small test bench at deploy time. Prerequisites: a second machine outside the network to generate load from (a laptop on a different connection qualifies), your baseline figures from a normal week, and the plan's uplink number from the table below. The bench: run iperf3 -c against your own server from the outside machine to confirm achievable throughput; run hping3 -S -p 443 --flood only against servers you own and only at modest rates if at all - the point is observing your own host's SYN-cookie behavior under pressure, not staging an internet attack; and exercise your rate limits with a load generator at 1.5-2x baseline to prove legitimate users still pass.

Two notes on reading the table. The uplink is the ceiling for what reaches your server after scrubbing, not the size of attack the edge can absorb - the scrubbing layer sits upstream of the port and is shared across the site. And the plan does not change the uplink class: a Nano and a Max at the same location ride the same port class, which means DDoS resilience across plans differs by what your workload can absorb, not by network headroom.

Step by step: hardening the host so the edge is your second line

The scrubbing layer cannot tell your customers from your attackers at the application layer, so the host finishes the job. This sequence takes about twenty minutes on a fresh deploy and closes the gaps that actually get VPS boxes taken down.

1. Firewall first: ufw default deny incoming; ufw allow 22,80,443/tcp; ufw enable - or the nftables equivalent. Everything not public is now unreachable, which removes both attack surface and amplifier risk.
2. Syncookies and queue sanity: sysctl -w net.ipv4.tcp_syncookies=1 (persist in /etc/sysctl.d/), and raise net.core.somaxconn if your service accepts bursts of real connections.
3. Rate-limit new connections per source in nftables: tcp syn ct state new limit rate 30/second burst 50 accept, tuned against your measured baseline rather than a wiki number.
4. Application throttles: nginx limit_req_zone on the endpoints that matter (login, search, API), fail2ban jails for repeat offenders. This is your actual L7 defense.
5. Bind admin surfaces to localhost or a private path - databases, panels, and anything with a login form do not belong on the public interface.
6. Monitoring that would catch an incident: vnstat for volume history, the panel's port graphs, and application request metrics. If none of it would page you within a minute, re-do this step.

Do this and an attack has to beat three layers in sequence: the scrubbing edge, the uplink's capacity, and a host whose queues and limits are sized. Attacks beat that stack far less often than they beat a default-configured box that assumed the network would do everything.

How to verify it worked: reading counters after a real event

After an incident - or a test - verification means counters, not the absence of complaints. On the network side: the panel's port graphs show the shape of what reached your server; a volumetric event appears as a spike that ends abruptly (edge absorbed or attack ceased), and comparing the spike's peak against your uplink class tells you how close you came to the ceiling. On the host side, four readings: ss -s during and after the event, where half-open counts returning to near zero confirm the SYN pressure is gone; nft list counters if you attached counters to your drop rules, which quantify exactly how much your firewall rejected; your rate-limit hit counts in nginx or fail2ban logs, which size the L7 component; and vnstat's daily total, which catches slow-drip attacks a graph spike would hide.

The judgment calls the numbers enable: if the edge absorbed the event and your host saw only residue, nothing needs changing. If your rate limits rejected large volumes of what turned out to be real users, the limits are too tight - mobile-carrier NAT means thousands of people share one source IP, so per-source limits need headroom. If traffic reached your port at volumes that degraded the service despite the edge, your workload may belong on a higher uplink class (the 100 Gbps sites) or on dedicated metal with the same filtering and IPMI for out-of-band control during events. One habit worth forming: save the graphs and counter dumps from every event with a timestamp. Patterns across incidents - attacker types, timing, targets - are visible only in the archive, and they are what tell you whether the next incident is generic noise or aimed specifically at you.

Troubleshooting: symptoms that look like DDoS but are not

Misdiagnosis wastes more incident hours than attacks do, so rule these out before escalating anything. Symptom: service slow, bandwidth normal, request rate normal. Cause: host resource exhaustion - a runaway process, a full disk, a swap-thrashing database. Check htop, df -h, and iostat -x 1 before blaming the network; an NVMe box at 100% utilization looks from the outside exactly like a flood. Symptom: intermittent timeouts from one region only. Cause: routing path issues, not attack - mtr from the affected region versus a clean region separates path from host in one run.

Symptom: your own monitoring shows a traffic spike that repeats on schedule. Cause: your cron, your backup job, or your analytics crawler - check crontab -l and the process table at the spike time before reporting an attack. Symptom: new connections fail but established ones work fine. Cause: your conntrack table is full (sysctl net.netfilter.nf_conntrack_count versus nf_conntrack_max) - raise the max or reduce per-IP connection limits; this is self-inflicted and survives any amount of edge scrubbing. Symptom: the port is unreachable and nothing above explains it. Cause: abuse-side null-routing following a ticket you may not have seen - check the panel's ticket system over the out-of-band path, which is the same advice as the abuse guide and for the same reason: the panel works when your port does not. What none of these fixes: an actual sustained volumetric event that the graphs confirm. That one goes to the network via ticket with timestamps and destination IP - and while you wait, the honest-limits section below describes what the filter can and cannot do about it.

Sizing plan and location against an attack budget

Sizing for DDoS is sizing three things: how much legitimate traffic your service must survive sharing the pipe with, how much attack traffic the uplink class can shrug off after scrubbing, and what happens to your IP reputation while events repeat. For a typical web service, any 40 Gbps site gives orders of magnitude more post-scrub headroom than the service consumes - a Business plan (6 vCPU, 16 GB ECC, 240 GB NVMe, $24/mo annual) at Amsterdam or Frankfurt saturates long before the site's 40 Gbps does. The 100 Gbps class (Zurich, Frankfurt, Tokyo, Singapore, Ashburn, Dallas) is for services whose availability under targeted attack is itself the product: trading fronts, APIs other businesses depend on, anything where an hour of degradation costs more than the plan difference.

Plan tier matters differently: more vCPU and RAM buy absorption capacity for L7 residue - a request flood is a CPU problem once it passes the edge, and a 2 vCPU Starter saturates on request volume a 6 vCPU Business processes while rate-limiting. So the pairing rule: volumetric exposure is a location decision (uplink class), application-layer exposure is a plan decision (absorption capacity), and neither substitutes for the host hardening above. When a service outgrows what shared virtualization should absorb entirely - sustained targeting, or an IP whose reputation is the business - the same filtering fronts dedicated metal from Dedicated Start $79.50 to Dedicated Ultra $449.50, with IPMI keeping you in control during exactly the events this guide describes. Deploy wherever the uplink math fits: ../deploy/?kind=vps&plan=business&location=frankfurt puts a Business box behind the DE-CIX 100 Gbps class in about a minute.

What the filtering changes for an operator's monthly bill and architecture

The direct answer: included L3/L4 filtering removes the classic "pay for protection or pray" decision, so the architecture question changes from "can I afford a scrubbing service" to "where do I put my one IPv4 and one /64 of IPv6". That has two billable consequences worth spelling out.

First, no protection surcharge anywhere in the sheet. The VPS line prices at Nano $5.49/mo list, Starter $8.50, Plus $13.50, Business $30, Pro $45, Max $60, and the filtering rides along on all of them - so a two-box setup (an edge box and a backend box, both protected, split across two locations) costs what two ordinary boxes cost. Compare that with the common alternative pattern, where the protection product costs more than the server it protects. Second, uplink capacity is part of the defense: VPS ports run unmetered from 1 to 10 Gbps, and volumetric floods that would saturate a small shared port terminate in the scrubbing layer before they crowd your pipe. The dedicated line extends the same idea with DDoS scrubbing listed as a feature of the metal from Dedicated Start $79.50 up to Dedicated Ultra $449.50.

Architecturally, the /64 of IPv6 every plan includes is an underused defensive asset. Public services can publish AAAA records on one address while an administrative interface lives on another address from the same /64 that appears in no DNS record at all - attackers must enumerate instead of resolving. Combine that with the location choice: because all 21 racks price identically, you can put the public edge near your users (Frankfurt at 100 Gbps for EU traffic, Singapore on SGIX for APAC) and keep the backend in a quieter rack, and the only cost is the latency between the two.

The honest boundary: what is included is network-layer defense. An attacker who spends nothing can still open thousands of real TLS connections per second from residential addresses, and no edge can distinguish those from customers. Your second line - rate limits, caches, and an origin that refuses to serve unauthenticated work - is not optional overhead; it is the part the bill does not cover.

A pre-mortem drill: rehearsing an attack on a quiet Tuesday

The direct answer: you cannot reliably improvise around an attack, but you can rehearse one cheaply - generate controlled load against your own service, watch what breaks, and fix it while nothing is on fire. An hour of drills buys more real protection than any paragraph on a provider's product page, ours included.

Drill one, connection pressure. From a second server, run a TCP connection flood against a staging port: hping3 -S -p 8443 --flood --rand-source stage.example.com for sixty seconds, no more. Watch three gauges on the target: SYN backlog (ss -n state syn-recv | wc -l), CPU steal, and whether legitimate connections still complete. If backlog explodes and legitimate handshakes time out, your kernel's syncookies are off or your rate limits are too generous - fix net.ipv4.tcp_syncookies=1 and tighten nft rate rules until the drill passes.

Drill two, application saturation. Point a load generator at the real public endpoint - even ab -n 200000 -c 500 tells you something - and confirm the failure mode is graceful: cache serves, queues hold, the origin database does not fall over. Most real "DDoS downtime" at the application layer is actually an unprotected origin behind a thin front door; the drill finds that door.

Drill three, recovery. Redeploy the whole service from scratch to a different rack using your own notes and time it. This is the number that decides whether an attack that burns your IP costs an hour or a weekend. Because plans and prices are identical across all 21 locations, the drill only tests your automation, not your budget. Run all three drills quarterly; write the new numbers into the runbook.

Where the limits are (October 2026)

Keep the threat model precise. Anonymous-adjacent hosting removes the host-side identity trail: token-only signup, optional email, no KYC review, crypto invoices that record a txid rather than a name. It does not blind the host to traffic it must carry, it does not make a logged-in panel session anonymous, and it does not protect workloads that identify themselves — an admin login from your home IP defeats the whole design. Exact limits of no-KYC anonymity. OPSEC guide. Full checklist. Payment-side note: chain analysis happens on public blockchains, not at the host. Coin choice and network choice are your OPSEC knobs, and the checkout keeps 19 of them open.