DDoS Protection on a Romania VPS: What It Actually Stops (and What It Doesn't)

"DDoS protection included" is one of the most common lines on a VPS pricing page, and one of the least understood. Here is the short version: upstream DDoS filtering protects your server from attacks big enough to fill your network port — volumetric floods, SYN floods, UDP amplification. It does almost nothing against a well-built application-layer attack, and nothing at all if the attacker already knows your origin IP and you never configured rate limits on your own side.

That split matters when you're choosing a host and when you're configuring a server. Network-level mitigation is something only the provider can do, because it has to happen before the traffic reaches you. Application-level defence is entirely yours, and no provider can do it for you without terminating your TLS. This article covers both halves honestly, including the parts marketing pages usually skip.

Direct answer: which attacks are filtered where

DDoS traffic falls into three rough categories, and they are stopped in three different places.

Volumetric attacks try to saturate your bandwidth. UDP reflection and amplification — abusing open DNS resolvers, NTP, CLDAP, memcached or SSDP servers to bounce inflated replies at your IP — is the classic form. These are measured in gigabits or terabits per second.

Protocol and state-exhaustion attacks aim at the connection tracking layer rather than raw bandwidth: SYN floods that leave half-open connections, ACK floods, fragmented packet floods, connection-per-second floods. Packet rate matters more than byte rate here.

Application-layer (Layer 7) attacks send requests that look legitimate. HTTP floods against a search endpoint, slowloris-style connections that trickle headers to hold worker slots, or repeated hits on an expensive page that bypasses your cache. Volume can be low enough that no network filter would ever flag it.

Only the first two can be handled upstream. Here's the physics of why that matters: if your VPS has a 1 Gbps port and someone points 10 Gbps of amplified UDP at it, your firewall rules are irrelevant. The packets are already discarded by a congested link before your kernel sees them — and the packets it does see arrive with everything else crowded out. Filtering has to happen in the provider's network, upstream of your port, or it doesn't happen.

What "DDoS protection included" actually means in practice

There are two very different things a host can mean by that phrase, and the difference is worth asking about before you pay.

Scrubbing / filtering means attack traffic is inspected upstream and dropped, while legitimate traffic continues to reach your IP. Your service stays online during the attack, usually with some added latency.

Null-routing (blackholing) means that once traffic to your IP crosses a threshold, the provider's upstream drops everything destined for that IP — attack and legitimate traffic alike — until the attack subsides. Your server is protected; your service is down. This is a normal, standard operational tool across the industry, not a scam, but it is not the same product as scrubbing.

Most real-world setups sit somewhere between: automated filtering for common attack signatures, with null-routing as the fallback for anything that threatens the node or the upstream link. Fair questions to ask any provider before you commit:

• Is mitigation always-on, or triggered after detection? Triggered systems usually mean 10–60 seconds of impact before filtering kicks in.
• Is the protection scrubbing or null-routing at the top end, and roughly what threshold triggers the fallback?
• Does mitigated attack traffic count against my monthly bandwidth allowance?
• Are UDP-based services (game servers, DNS, WireGuard) treated differently from TCP? Some filtering profiles are tuned for HTTP and behave badly with UDP protocols.
• What happens if my IP is attacked repeatedly? Some hosts terminate accounts that attract sustained attacks, which is worth knowing in advance if you host something contentious.

Every IronBalkans plan includes DDoS protection along with a dedicated IPv4, a /64 IPv6 block and a 1 Gbps port, from €3.99/mo on Iron 1 up to €29.99/mo on Iron 4 — and because signup needs no email, name or ID, you can get a server up and test how it behaves under your own traffic patterns before committing anything else to it. If your project has unusual requirements — UDP-heavy traffic, or a history of being targeted — ask about the specifics over Telegram or SimpleX first rather than assuming. Any host that won't answer that question directly is telling you something.

Your side of the line: state exhaustion and Layer 7

Upstream filtering ends at your network port. Everything past it is your configuration, and this is where most avoidable outages happen — not from 100 Gbps floods, but from a few thousand requests per second hitting an uncached endpoint on a 2 vCPU box.

Kernel-level basics

SYN cookies let the kernel handle a SYN flood without allocating state per half-open connection. On most modern distributions this is already on; verify rather than assume:

sysctl net.ipv4.tcp_syncookies

If it isn't set to 1, add the following to /etc/sysctl.d/99-hardening.conf and apply with sysctl --system:

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.core.somaxconn = 4096
net.netfilter.nf_conntrack_max = 262144

Connection tracking is a real bottleneck on small instances. Every tracked connection consumes memory, and when nf_conntrack_max fills, new connections are dropped and you'll see nf_conntrack: table full, dropping packet in the kernel log. Raising the limit costs RAM — roughly a few hundred bytes per entry — so on a 1 GB plan raise it modestly, and consider marking high-volume stateless traffic notrack instead.

Rate limiting at the packet layer

nftables can cap new connection rates per source before requests ever reach your application. A simple example, assuming you already have a working ruleset:

table inet filter {
  set flood {
    type ipv4_addr
    flags dynamic, timeout
    timeout 10m
  }

  chain input {
    type filter hook input priority 0; policy drop;

    tcp dport { 80, 443 } ct state new \
      add @flood { ip saddr limit rate over 50/second burst 100 packets } \
      drop

    # ... rest of your rules
  }
}

This drops new connections from any single IP exceeding the rate, and remembers the offender for ten minutes. It is effective against crude single-source floods and useless against a distributed botnet with thousands of source IPs — which is exactly why it belongs alongside, not instead of, application-level controls. If you don't already have a coherent base ruleset, start from a practical nftables baseline for a VPS and add the rate limiting on top, rather than assembling rules ad hoc during an incident.

Rate limiting and caching at Layer 7

For HTTP, nginx gives you the controls that actually matter:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

server {
    limit_req zone=perip burst=20 nodelay;
    limit_conn conn 20;

    client_body_timeout 10s;
    client_header_timeout 10s;
    send_timeout 10s;
    keepalive_timeout 30s;
}

The timeouts are the slowloris defence: connections that stall mid-request get cut instead of holding a worker. The limit_req zone protects expensive endpoints — login forms, search, anything that touches the database — from being hammered.

More important than any of it: cache aggressively. An HTTP flood that hits static files served from the page cache is a bandwidth problem. The same flood hitting PHP-FPM and a database is an outage. Put your dynamic pages behind a proxy cache or a CDN, keep /wp-login.php-style endpoints behind rate limits or an IP allowlist, and monitor the difference between "requests per second" and "requests per second reaching the application."

Watch out for one more trap: when you rate-limit by $binary_remote_addr behind a proxy or CDN, every request appears to come from the proxy's IP. You need set_real_ip_from and real_ip_header configured correctly, or you'll either rate-limit the whole world as one client or trust a spoofable header.

The leak that makes all of this pointless

If you put your site behind a CDN or scrubbing proxy for Layer 7 protection and your origin IP is discoverable, an attacker will simply bypass the proxy and attack the server directly. This is the single most common failure in DDoS setups, and it rarely happens through the website itself — it happens through historical DNS records, Certificate Transparency logs, mail sent directly from the origin, or a subdomain that was never proxied.

The fix is a firewall that only accepts traffic from your proxy's published ranges, plus closing the discovery paths. That's a detailed topic in its own right, covered in the guide on how origin IPs leak past a CDN and how to close every path.

Don't become the amplifier

Reflection attacks run on misconfigured servers, and a VPS you rent is a perfectly good one. An open DNS resolver, an unauthenticated memcached bound to 0.0.0.0, an NTP server with monlist enabled — any of these can be used to attack someone else while burning your bandwidth and building a bad reputation for your IP. That reputation follows the address, not the account, and it shows up later as blocked mail and CAPTCHAs.

Bind services to localhost or a private interface unless they genuinely need public exposure, and set explicit ACLs on anything that answers queries. If you're running your own resolver, the self-hosted Unbound guide covers the access-control configuration that keeps it from being abused. Being the source of an attack is also one of the faster routes to an abuse complaint landing on your account.

Common mistakes

Assuming "DDoS protected" covers Layer 7. It almost never does without a WAF or reverse proxy that terminates TLS. Network filtering can't read encrypted HTTP.

Blaming an attack for a capacity problem. A traffic spike that kills a 1 vCPU instance isn't necessarily malicious. Check CPU steal time, I/O wait and request logs before assuming hostility — the methods in the guide on spotting an oversold VPS apply just as well to diagnosing a slow server under load.

Rate limits tuned during the incident. Test your limits under synthetic load on your own server first. Setting rate=1r/s in a panic will block your legitimate users more effectively than any attacker could.

No out-of-band access plan. If your IP gets null-routed, SSH over that IP is gone too. Know how to reach your provider's console or panel before you need it.

Treating DDoS defence as a privacy feature. It isn't. Mitigation systems necessarily see traffic patterns, and a CDN in front of your site sees your visitors' requests in cleartext. Layered protection and minimal data exposure pull in opposite directions; decide consciously which one your project needs more.

Honest pros and cons of included network-level protection

What you gain: survival against the attack types that no amount of server configuration can fix, at no extra cost. Crude floods and amplification attacks — the overwhelming majority of what a small server actually receives — get absorbed upstream.

What you don't get: protection against sophisticated low-volume Layer 7 attacks, immunity from downtime if mitigation falls back to null-routing, or a substitute for caching and rate limits. Filtering can also add latency and occasionally misclassify unusual-but-legitimate traffic, which is why UDP-heavy and non-HTTP workloads deserve a specific question to the provider before deployment.

FAQ

Does DDoS protection slow my server down? Always-on filtering adds a small amount of latency because traffic passes through an extra hop. For most workloads it's not noticeable. Detection-triggered systems add nothing until an attack starts.

Can I get DDoS protection on a cheap VPS? Yes — network-level protection is applied at the network, not per plan, which is why it's included across all tiers on many hosts including the €3.99/mo entry plan here. Your own Layer 7 defences, though, depend on having enough CPU and RAM to serve cached responses under load, which is a sizing question rather than a protection question.

Will attack traffic use up my bandwidth allowance? Depends entirely on where the counter sits. If mitigation drops traffic upstream, it typically doesn't reach your port at all. Ask the provider directly; treat a vague answer as a no.

Is Cloudflare enough on its own? Only if your origin IP is genuinely hidden and your firewall rejects everything that doesn't come from Cloudflare's ranges. Otherwise it's a front door with the back door wide open.

What should I do the moment an attack starts? Check whether the application is actually saturated or just the link. Look at request logs for a pattern — a single URL, a single user agent, a narrow IP range — and block on the narrowest characteristic that works. Then contact the provider with concrete numbers rather than "my site is down."

Get started

Network-level DDoS filtering is the part you should buy rather than build; rate limiting, caching and origin protection are the parts you have to configure yourself. Get both and a small VPS handles far more hostile traffic than people expect.

If you want a server in Bucharest with DDoS protection, a dedicated IPv4 and a /64 IPv6 block on every plan — paid in Monero, Bitcoin or Litecoin, with no email, name or ID at signup and deployment in under 60 seconds — create an account and deploy. Plan specs and pricing are on the pricing page if you want to size it first.