DDoS-Protected VPS Explained — What Filtering Actually Covers

What built-in L3/L4 filtering on every plan actually covers, where it stops, and which floods stay your job — VPS from $3.00/mo annual-eff.

Published 2026-08-30 · Updated 2026-10-14 · FYRHost Editorial · 16 min read

Attack names are layer names

Every attack name is an address on the protocol stack, and reading it that way tells you immediately who owns the defense. L3/L4 floods — SYN storms, UDP amplification, ACK abuse — aim at your pipe and your kernel state tables, which is infrastructure the provider can defend before a packet reaches you. L7 floods arrive dressed as legitimate requests, and no filter can separate them from real users without knowing the application. That split is the entire story.

The mechanism on the platform side is a floor, built in two halves. Stateless filters near the network edge drop malformed packets, blunt floods aimed at the wire itself, and neutralize classic reflection vectors that love open UDP services. Stateful tracking closer to the host counts flows per source and rate-limits the greedy, which keeps a million half-open handshakes from filling connection state. The IETF's DoS considerations document frames this division the same way the catalog implements it.

Where assumptions break is the third category that hides in plain sight: traffic that looks exactly like your users. A checkout hammered by valid-shaped POST requests, a login endpoint retried 500 times a second, an API crawled abusively — each one passes the filters by design, because dropping it would drop customers too. Operators who read a protection badge and assume that category is included are the ones who meet it at 2 a.m. unprepared.

The honest mental model: the platform owns the volumetric and state-exhaustion layers permanently, and the application owns everything that looks like traffic. Budget accordingly — network defense from the provider, rate limits and caching from you — and the surprise class of incidents disappears. The sections that follow walk both halves: what the edge drops, what every SKU includes, and where the line sits in practice.

What the edge actually drops

Stateless scrubbing is boring by design, and boring is the goal. Packets with impossible headers, fragments that reassemble into nonsense, amplification responses nobody requested — these die upstream of your virtual NIC, along with the reflection storms that abuse open UDP resolvers on other people's networks. Ingress filtering guidance has described the correct posture for decades; the edge applies it so you never think about it.

Stateful defense closer to the host does the finer work. Flow counting per source catches the SYN storm that passed the edge, and rate ceilings keep any single address from exhausting the connection table. You can watch the boundary from inside: ss -s summarizes socket state, and during a volumetric event it stays flat while the attack graph spikes — the flood is dying upstream, and your kernel never learns about it.

Where the mechanism breaks is traffic the edge cannot judge: valid game packets, valid API calls, valid page loads at hostile rates. A filter that dropped every UDP packet to a game port would be a perfect anti-flood device and a perfect service-killer, so the platform passes what plausibly belongs to the application, and everything past that judgment call is yours. Per-port rate limiting with hashlimit, connection caps with connlimit — both documented in the iptables extensions — carry that layer in your stack.

The typical mistake is tuning those limits from a cold start: setting login caps to 5 per minute, watching a normal evening, and discovering that a school's NAT puts 400 real players behind one address. Set limits loose, baseline real traffic for a week, then tighten to a multiple of observed peaks. ss -uapn during the baseline shows you which ports carry the honest load you are protecting.

Edge and host together form the platform's half of the bargain, and that half is not an option you buy — it ships on. What each SKU actually includes, from the smallest VPS to the top of the metal ladder, is the next section, because the details differ in exactly one place.

What every SKU includes

The floor rides everything: automatic L3/L4 filtering on every VPS, storage and dedicated SKU, always on, with no toggle to forget and no per-IP fee to discover later. Start on Sentry at $7.50/mo list — $6.00 annual-eff — and the same edge defends your 60 GB of NVMe as defends the flagship. Storage Depot cells from $30 to $70 and the dedicated ladder from $38.50 upward all sit behind the same stateless and stateful layers.

Metal adds one capability the virtual tiers cannot offer: IPMI on every dedicated box, which means a compromised or wedged machine can be reimaged out-of-band even while its own operating system is melting. That matters during incidents, because the recovery path that does not depend on the machine being sane is the only one an attacker cannot lock you out of. The top tier changes the filtering itself — Citadel pairs its 25 Gbps uplink with an L3/L7 scrubber, the single place application-layer filtering is a platform feature.

Where understanding breaks is the per-IP assumption carried over from other providers: there is no cleaner SKU, no protection add-on and no ticket that upgrades what the edge does for a smaller plan. The filtering is part of the SKU by design, because selling security as an upsell means the customers who decline it become everyone's problem. If a plan exists in the catalog, its floor is the one described here.

The second confusion is what included means for volumetric scale: included describes the defense mechanism, not an infinite pipe. A 1 Gbps entry uplink passes 1 Gbps of clean traffic no matter how large the attack was upstream, so the ceiling question is a port question — which is exactly where the next section goes, because port speed is the number that decides your clean-traffic budget.

Your pipe is the clean-traffic ceiling

After the filters do their work, what reaches you is bounded by the port, and that number is the one to size deliberately. Entry VPS ship unmetered 1 Gbps; the ladder climbs through 2.5 and 5 to 10 Gbps; dedicated runs 1 to 25 Gbps across its tiers. An attack absorbed upstream still leaves you the whole port for real users — but a burst that passes as valid-shaped traffic competes for that same budget, so headroom is the defense.

Watch it live rather than trusting the invoice: ip -s link prints per-interface counters, and during an incident the gap between RX dropped packets and your application's request rate tells you whether the edge or the pipe is the constraint. tc lets you shape outbound and prioritize the flows that matter — game ticks over downloads, checkout over assets — which is free capacity you already own.

Where the ceiling breaks expectations is the big-plan instinct: upgrading to 10 Gbps because an attack once saturated 1 Gbps fixes a volumetric problem that mostly was not yours. If valid-shaped traffic is what saturates the port, the fix is filtering closer to the application — a CDN in front of HTTP, per-source caps at the host — and the port upgrade only helps after that. Buy port for users, filters for floods.

The second mistake is ignoring the return path: responses to a reflected flood can saturate your uplink from the inside even when inbound garbage died upstream. If your service amplifies — DNS resolvers, NTP, game query protocols — the platform drops the reflection, but an application that answers every stranger generously still pays for it. Cap response rates per source at the host and the return path stops being an attack surface.

Pipe sized and shaped, the remaining exposure is the layer no pipe upgrade touches: requests that look like users. That is application defense — rate limits, bot scoring, caching — and it is where most real incidents against small services are actually won or lost, which is the next section's territory.

The application layer is yours

Slowloris holds connections open a byte at a time; an API flood repeats valid requests at hostile rates; a login hammer retries credentials through the front door. Every one of these passes volumetric filtering because every one of them is indistinguishable from a customer at the packet level. The platform's floor keeps the pipe and state tables alive so the box still answers — deciding which requests deserve answers is your application's job.

The tools are ordinary and effective. Reverse-proxy rate zones cap requests per second per source; the hashlimit and connlimit matches cap them per source at the kernel; caching absorbs read-heavy floods so the origin never sees them; and a CDN in front of HTTP moves the judgment point to a network built for it. Packet-level details rarely matter here — request patterns do — which is why the defense lives in configuration rather than in hardware.

Where it breaks is the static defense against a moving baseline: limits tuned once and never revisited fail twice, first against real growth — the caps that fit 50 users strangle 500 — and then against distributed abuse, where per-source caps mean nothing across 3,000 sources. Layer the responses: cheap caps at the edge of your stack, costlier checks behind them, and cache whatever can be cached so the expensive path stays short under pressure.

The typical mistake is defending everything equally. A web-only surface wants a CDN; an API wants per-token rate zones; a game wants port-level caps and login throttling in the engine itself. Treating all three with one nginx config produces a policy that is too strict for players and too loose for crawlers — the game server guide covers that split in detail, and the pattern generalizes: defense follows the shape of the traffic.

Application defense settled, one platform capability remains that matters on the worst days, and it is not a filter: out-of-band access to the box itself. Why IPMI changes incident recovery on metal — and what it costs on the ladder — is the next section.

Reimaging under fire: why IPMI matters

An attack that saturates your service has a second, quieter effect: the box's own management paths degrade. SSH times out because the CPU is pinned, the panel feels distant, and the recovery you planned assumes a machine healthy enough to accept it. IPMI breaks that dependency — the dedicated tiers ship it, giving you keyboard, screen and virtual media over a path that does not run through the guest operating system at all.

Order the Shield at $38.50/mo list — $30.80 annual-eff — and the reimage-under-fire workflow is real: mount an installer image through IPMI, rebuild the box, and bring the service back while the attack continues, no KVM ticket and no waiting on a human. Vault at $68.50, Bastion at $108.50 and Fortress at $173.50 extend the same out-of-band access up the ladder, and Citadel adds the L3/L7 scrubber on top for workloads that genuinely need application-layer filtering at the platform.

Where the plan breaks is treating IPMI as a backup strategy. It restores availability, not data: the reimage is only as good as the restore procedure behind it, and a box rebuilt without tested backups is a fresh machine wearing your hostname. The hardening checklist puts the restore rehearsal where it belongs — quarterly, into a scratch directory, before anything is on fire.

The second break is assuming IPMI replaces the network defense described earlier: it does not, and the two fail independently. A volumetric flood can still saturate the service port while IPMI stays reachable — that is the point — but nothing about out-of-band access drops a single packet. On virtual tiers, where IPMI is not part of the SKU, the equivalent discipline is snapshots plus the discipline to rebuild from them quickly.

Filters, port, application, out-of-band recovery: the defensive stack is complete, but two placement questions change what reaches it in the first place. Where the box sits decides which attacks are cheap to aim at it — and whether some classes arrive at all — which is where the next section goes.

Placement, privacy and the no-target trick

One hosting decision removes entire attack classes before any filter runs: publishing no public address at all. A Tor onion service presents no IP to flood, so volumetric attacks have no coordinate to aim at — a structural property rather than a product, and the onion guide covers the setup. For workloads that can live behind an address like that, it is the cheapest defense available at any price.

For everything that needs a public IP, geography changes exposure less than people assume: scanners enumerate all 40 locations within hours of an IP going live, and the edge filtering is the same fabric everywhere. What location changes is jurisdiction — abuse complaints route under the facility's law, priced at Iceland and Norway plus 20 percent, Switzerland plus 35 percent, Luxembourg, Cyprus and Panama plus 15 percent, list elsewhere. Pick by law and latency, not by imagined filter quality.

Tor exits are the special case worth naming: they get the same protection terms as any server, and they attract more ambient noise than almost any workload because the role generates complaints by design. Exits are provisioned on request with an abuse contact attached, which is the mechanism that keeps the mail flowing to the right place instead of into a void. Running one from a plan with IPMI saves the reimage walk when a targeted flood finds the range.

Where placement breaks is ideology for latency-sensitive workloads: choosing a rack by flag for a game server whose players vote in milliseconds, or a checkout whose customers abandon after 300 milliseconds of extra handshake. The map is large precisely so the trade can be tuned — jurisdiction where it matters, proximity where it pays — and pretending one factor dominates every workload is how quiet degradations start.

Platform, pipe, application, recovery, placement: five pieces, one incident drill left. Reading an attack correctly in its first minute decides whether the fix is a ticket, a config change or nothing at all — and that diagnostic discipline is the last section before the ordered recap.

Reading an incident in the first minute

The first minute decides the response, and the question is always the same: which layer is actually under pressure. ss -s first — flat socket totals during a visible event mean the volumetric layer is dying upstream and your box is a bystander. Rising counts of SYN-RECV or UDP flows on a specific port mean state exhaustion or application-shaped abuse, and the response branches from there: ticket versus config versus nothing.

ss -uapn names the port and the shape: thousands of sources hammering a query port is flood traffic the per-port caps should soften, while a few hundred sources completing handshakes is application load that caps would strangle. The kernel's network counters under /proc/net fill in the detail — retransmits, listen drops, buffer failures each point at a different fix, and none of them is visible from an attack graph.

Where diagnosis breaks is premature remediation: restarting the application mid-attack drops every legitimate session, tightening caps during a flood locks out the users you were keeping, and opening tickets for absorbed volumetric events spends goodwill on nothing. The platform's connection metadata is kept at most 24 hours, so evidence for a post-mortem lives in your own logs and metrics — collect them before the next incident, not after.

The second break is the absence of a baseline: an operator who has never seen ss -s on a quiet evening cannot recognize the loud one, and every judgment call above assumes a known normal. Snapshot the quiet numbers weekly — socket totals, per-port flows, drop counters — and the first minute of an incident becomes comparison instead of archaeology.

That is the whole discipline: know the layers, know your normal, and respond to the layer that is actually moving. The final section compresses everything above into the order you would run it — from choosing a SKU to rehearsing the incident drill — so the defense exists before the first attack does.

The DDoS-protected VPS, in the order to run it

Start at the account — inbox plus a 12-character password or a bare token — and fund it in one of 19 coins; the box boots about 60 seconds after the credit. Pick the location by jurisdiction and latency, knowing the premiums: Iceland and Norway at 20 percent, Switzerland at 35, Luxembourg, Cyprus and Panama at 15, list elsewhere. The L3/L4 floor is already on; nothing about protection is a line item.

Second, draw the network surface: default-deny inbound, 80 and 443 or the game ports your service actually uses, admin over SSH only. Third, set the application defenses where the traffic is shaped — reverse-proxy rate zones for HTTP, hashlimit caps for UDP services, cache in front of anything read-heavy — tuned loose and baselined against a real week of traffic before tightening. Fourth, record the quiet-evening numbers with ss -s and ip -s link so the loud evening has a reference.

Fifth, decide the recovery path before it is needed: on virtual tiers, snapshots plus an off-box copy and a restore you have actually run; on metal, IPMI plus an installer image and the same tested restore. Sixth, schedule the drill quarterly — reimage or restore into scratch, re-read the firewall, confirm the service answers end to end — because the plan that has never been run is a plan you do not have.

Seventh, review placement and exposure twice a year: workloads that can live behind an onion address move toward no-target, workloads that need proximity stay near players, and anything whose jurisdiction no longer fits migrates while the move is calm. Re-run the whole sequence once every 12 months — firewall diff, restore drill, incident reading against the recorded quiet numbers — because a stack you have not rehearsed in a year is a stack you hope about. Run in that order, the stack keeps its best property: the volumetric half is never your problem, and the application half is one you practiced.