DDoS filters, abuse tickets, and what we will not host

Included DDoS is not unlimited L7. Explain the traffic. CSAM and attack-for-hire are prohibited even on a crypto invoice.

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

What “DDoS included” means

Volumetric filters on the listing. A game or site that looks like a botnet still gets an abuse mail. Answer it. Unmetered is not a cloaking device.

How to answer abuse

IP, UTC timestamp, what the process is. Tor Project: relay operations exits need a published contact. A US U.S. Copyright Office: DMCA template is not a power button. CSAM reports go to abuse@ with URLs — that is not a copyright debate.

Short answer: what is filtered where, in one paragraph

DDoS scrubbing on this network is volumetric and sits in front of every plan - VPS from Nano at $5.49/mo through Max, the storage line, and dedicated metal with IPMI - so there is no protection SKU to buy and no tier that ships without it. The filter handles layer 3 and layer 4 floods: SYN floods, UDP amplification and reflection, junk-packet attacks aimed at saturating the port or the state table. Layer 7 - HTTP request floods, slowloris, application-logic abuse - passes through to your box by design, because an edge that filters application traffic for every customer would also be an edge that inspects it, and that is not the product. The consequence is a clean division of labor: the network absorbs the floods measured in gigabits, your host absorbs the floods measured in requests per second, and the abuse system handles the third axis - what your server sends outward.

The same division explains the abuse policy. Inbound attacks against you are an operations problem the network solves silently. Outbound abuse from your server - spam, scanning, participation in floods - is a policy problem with a ticket lifecycle, a response expectation on your side, and escalation that ends in port suspension. Both halves are covered below: first what to have ready before an attack, then how the layers split, then the verification, troubleshooting, and the abuse ticket lifecycle with the honest limits at the end.

Prerequisites: what to have ready before an attack hits

Attacks are the worst time to discover your own configuration, so treat this as a pre-deployment checklist. First, a baseline: know what normal traffic looks like for your service - requests per second, concurrent connections, bits per second - because every judgment during an incident is "is this the attack or is this my audience", and without a baseline you cannot answer it. Tools as simple as vnstat for volume history and your application's own request logging provide it. Second, out-of-band access: if the attack saturates your port, SSH over the same path dies too, so know how you would reach the panel and issue a ticket without the server itself - which on dedicated plans includes IPMI as the out-of-band channel.

Third, a contact path that works: with optional email accounts, the ticket system in the panel is the channel abuse responses arrive on, so check it during an incident rather than waiting on an inbox you may not have configured. Fourth, host-side mitigations actually deployed: a firewall with sane defaults (nftables or ufw), rate limits on the services you expose, and services bound only where they are needed - a database listening on 0.0.0.0 turns every flood into an application problem. Fifth, DNS with a low TTL if you might need to fail over; a 3600-second TTL turns an emergency switch into a one-hour wait. None of this costs money - it is configuration - but all of it has to exist before the SYN packets do.

The L3/L4 versus L7 split in practice, with the commands

The network filter removes floods before they reach your port, but the residue that does arrive is yours to handle, and most L7 incidents are won with a dozen lines of host config. The division of work: the scrubbing edge handles attacks addressed at the pipe - SYN floods, amplification, malformed packets - while anything that looks like a legitimate request is delivered to your socket. Your box should therefore enforce at the edges the edge cannot see.

1. Rate-limit new connections per source: nft add rule inet filter input tcp syn ct state new limit rate 30/second burst 50 packets accept as a starting shape, tuned to your real baseline.
2. Drop obviously invalid traffic early: ct state invalid drop before your accept rules, and strict reverse-path filtering via sysctl net.ipv4.conf.all.rp_filter=1.
3. Cap application-level abuse where the app supports it - nginx limit_req, or a fail2ban jail for repeated offenders - because request floods are indistinguishable from customers except by rate and behavior.
4. Bind admin surfaces away from the public interface: panel, database, SSH on a non-standard path or behind a jump host.
5. Keep kernel queue defaults sane for your workload: net.core.somaxconn and the SYN cookies knob (net.ipv4.tcp_syncookies=1, usually default) are what let a Linux box shrug off residual SYN pressure the edge let through.

The pattern to internalize: the edge filter is your line against gigabits, these rules are your line against requests, and neither substitutes for the other. A hardened host under a volumetric attack barely notices; an unhardened host can be taken down by a thousand cheap VPS worth of HTTP requests that no volumetric filter would ever block.

Reading an attack: symptoms, tcpdump, and what normal looks like

Incident diagnosis starts with one question: is this an attack, a traffic spike, or my own misconfiguration? The symptoms overlap, so measure instead of guessing. Symptom signature of an L3/L4 flood: bandwidth or packets-per-second far above baseline while your application's request rate stays flat; vnstat or the panel's port graphs show the pipe filling with traffic that never becomes sessions. Symptom signature of an L7 flood: request rate multiples of baseline while bandwidth looks ordinary - the pipe is fine, the application queue is not. Symptom of neither: high latency with normal volume, which is usually a routing or host-resource problem.

On the box, tcpdump -nn -c 1000 and count: a flood of SYNs with no completed handshakes, a wall of UDP from scattered sources toward one port, or ICMP types you never normally see are volumetric signatures - the edge is already absorbing most of it, and what you see is residue. Spread of completed, well-formed requests is L7, and the counters that matter move to your application: queue depth, worker saturation, error rates. One discipline during all of it: change one thing at a time and record it. The mitigation you apply in a panic and forget is the outage you troubleshoot next month, and "the attack stopped" is not evidence your fix worked - attacks also end on their own, which is exactly why the verification section insists on counters rather than vibes.

How to verify it worked: a test plan for your own filtering

Verify your half of the defense before you need it, because under attack is not the time to learn your rate limits block your own users. Test one, firewall ordering: nft list ruleset and read it top to bottom - the drop rules must precede the accepts they are meant to guard, and a rule that is unreachable in the order is a rule you do not have. Test two, rate limits against baseline: from a second machine, generate load slightly above your real baseline and confirm legitimate traffic still passes - if your limit is 30 new connections per second and your login page opens 40, you have built a self-DDoS.

Test three, SYN cookies: confirm sysctl net.ipv4.tcp_syncookies reads 1, and that ss -s shows sane half-open counts under load. Test four, monitoring: your baseline tools (vnstat, application metrics, the panel's graphs) should show a live incident as a deviation within a minute, not a surprise discovered in a weekly report - if nothing you have would have alerted you, the test failed regardless of how the filters behave. Test five, the ticket path: know before an incident how you would report an ongoing volumetric attack larger than the scrubbing edge is absorbing, and that the answer is the panel's support channel, reachable without the server. Run the whole plan quarterly; filters, baselines and services all drift, and a test plan that ran once at deploy time is a snapshot, not a control.

Troubleshooting: SYN floods, UDP amplification, and locked-out legitimate users

Symptom: service unreachable, port graphs flatlined at maximum. Cause: volumetric flood exceeding what the scrubbing edge absorbs before your port - rare, but the fix is a ticket while it is happening, not a forum post after. Include the timeframe and destination IP; the edge can be tuned against a specific profile. Symptom: service slow but alive, tcpdump full of half-open SYNs. Cause: residual SYN pressure past the edge. Fix: confirm tcp_syncookies=1, tighten the new-connection rate limit, and verify the backlog (net.core.somaxconn) matches your service's accept loop - a queue of 128 behind a busy worker pool is a self-inflicted flood.

Symptom: UDP from many sources toward one high port. Cause: reflection or amplification residue, or your own service replying to spoofed requests - if the port is one you opened (DNS, memcached, NTP), you are the amplifier. Fix: close the service to the world immediately; an open resolver on a no-KYC network is the fastest route from "victim" to "abuse ticket". Symptom: legitimate users report blocks during an incident. Cause: your rate limits or fail2ban jails are scoring real customers as attackers - NAT'd mobile carriers share source IPs across thousands of users, which is why per-source limits need headroom and short jails. Symptom: everything fine from inside, unreachable from outside. Cause: null-routing of your IP following an abuse escalation (see the ticket lifecycle below) - the panel and ticket system work over the out-of-band path even while your port is blocked, which is precisely why the prerequisites insisted on having one.

Abuse complaints: the ticket lifecycle and what gets a port suspended

The abuse system exists for outbound problems: your server sending spam, scanning the internet, participating in outbound floods, or hosting content that triggers legal process. The lifecycle is consistent. A complaint arrives at the network from an outside party - a blocklist operator, another network's abuse desk, a rights holder. It becomes a ticket against your account with the evidence attached, and the expectation is a response from you within the timeframe stated in the ticket, typically measured in hours to a day, not weeks. A first complaint about, say, a compromised WordPress install is a cleanup job: patch, remove the payload, reply with what you did. That closes it.

What escalates: silence, because an unanswered abuse ticket is treated as indifference to the network's reputation; recurrence of the same class of complaint after you said you fixed it; and complaints in categories that are not curable by patching - the network does not host attacks outbound, spam at scale, or content in the categories every host must refuse, and no response changes that. The end state of escalation is port suspension or null-routing of the offending IP, which is reversible for technical abuse after cleanup and terminal for policy abuse. Three things worth knowing about the no-KYC interaction: crypto payment and optional identity do not change the AUP - the coin does not buy the behavior; anonymity does not shield the IP reputation, which is shared infrastructure everyone on the range pays for; and honest operators actually prefer a system that acts on evidence, because the alternative is ranges that decay into blocklist oblivion and take your clean IP down with them.

Security hardening around the filter: the box still defends itself

Everything above assumes the attack comes from outside wanting in. The other failure mode is your server being the attacker - and hardening against that is the same discipline. Keep the attack surface minimal: only the services that need to be public are public, everything else bound to localhost or behind a jump host; unattended-upgrades or the equivalent on, because a known-CVE service is how servers join botnets; and SSH keyed rather than passworded, with root password login off. Audit outbound as well as inbound: a server that suddenly generates 10 Mbps of traffic at 4 a.m. has a baseline violation, and vnstat's daily numbers plus ss -tupn at the time will name the process.

Then close the loop with the platform: the /64 IPv6 block every plan includes is address space you can segment with - services on different sub-addresses, so a compromise of one does not quietly inherit the reputation of all; the unmetered 1-10 Gbps port is generous enough that your own misconfigured service can do real damage fast, which is an argument for the baseline tooling, not against the port. And when the workload outgrows what a VPS should absorb - sustained attack surface, or a service whose IP reputation is the product - the same filter exists in front of dedicated metal from Start at $79.50 upward, with IPMI as the out-of-band channel during exactly the incidents this page describes. The filter is the network's promise; the hardening is yours, and the two are priced to be used together.

Writing the incident runbook before the first attack lands

The direct answer: an attack is the worst possible time to invent a procedure, so the runbook you write on a calm afternoon is the only thing standing between a bad evening and a lost service. Four entries belong in it, each testable in advance.

Entry one: what normal looks like. Capture a baseline on an ordinary day - iftop -i eth0 for the top talkers, ss -s for socket counts, your monitoring system's p95 for requests per second and bandwidth. Without the baseline you will read an attack graph as "high", which is unactionable; with it you can say "eight times p95, same five source ASNs" and act. Entry two: who does what. Name the person who reads graphs, the person who can change firewall rules, and the person who talks to the host's abuse and support channels. A one-operator project fills all three rows with the same name in advance rather than mid-incident.

Entry three: the escalation ladder. First rung is the edge you control - nft add rule inet filter input tcp dport 443 ct state new limit rate 50/second accept style rate limits, or an application-level queue for logged-in users only. Second rung is the host's L3/L4 scrubbing, which is included on every VPS plan here rather than sold per-attack; know before the incident whether your traffic pattern is volumetric (the edge handles it) or application-shaped (you handle it). Third rung is relocation: because the same plan sheet - Nano through Max - is deployable at any of the 21 locations, moving a clean service to a fresh IP is a redeploy, not a migration project. Write down how long that takes you with a real restore, because that number is your recovery point.

Entry four: the customer message. A status note drafted in advance - what users see, what you know, where updates land - turns an outage into an incident with a reputation attached.

Shared racks, shared reputation: your port is also your neighbor's problem

The direct answer: on any multi-tenant host, abuse is a commons - one tenant's spam run or scanning wave can slow every tenant's tickets, and one tenant's victimhood (being attacked) can saturate an uplink that your traffic shares. You cannot control your neighbors, but you can control how much of the commons you consume and how fast you are cleared when a complaint touches you.

On the consumption side: the unmetered 1-10 Gbps ports on the VPS line are unmetered in bytes, not exempt from physics. A service that floods its own port - an open proxy, a misconfigured relay, a backup job left unthrottled - degrades latency for co-tenants on the same host and invites both an abuse ticket and rate-limiting from upstream. Audit your own outbound for the patterns that generate complaints: ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head tells you in one line whether your box is talking to thousands of hosts it has no business knowing.

On the response side: abuse complaints here follow a ticket lifecycle - you are notified, you respond, and only ignored or repeated complaints escalate to port suspension. The practical move is to answer fast even when the complaint is wrong: a two-line reply that says what the traffic was, plus a fix or a denial with evidence, closes the loop. Keep journalctl retention long enough to reconstruct a specific hour, because "we checked, here is what happened at 14:00 UTC" is the reply that keeps a clean record. When the workload genuinely needs to make outbound connections to thousands of random peers - a crawler, a node - disclose it to support before someone else does.

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.