# DDoS and Abuse: Filters, Tickets, What's Banned | FYRHost

> L3/L4 filtering ships on every plan, L7 floods stay rate-limiter work. How abuse mail gets answered, what the AUP bans, when null-routing hits. From $3.

Source: https://fyrhost.com/guides/ddos-and-abuse/

[Home](https://fyrhost.com/) / [Guides](https://fyrhost.com/guides/) / DDoS and Abuse: Filters, Tickets, What's Banned Guide

# DDoS and Abuse — What Included Filtering Covers, How Abuse Mail Gets Answered, and What No Plan Hosts

![FYRHost jurisdiction abstract: papers dissolving at a glass shield](https://fyrhost.com/img/theme-legal.png) L3/L4 filtering ships on every plan, L7 floods stay rate-limiter work. How abuse mail gets answered, what the AUP bans, when null-routing hits. From $3.

Published 2026-08-30 · Updated 2026-10-09 · FYRHost Editorial · 19 min read

**Short answer** L3/L4 filtering ships on every plan, L7 floods stay rate-limiter work. How abuse mail gets answered, what the AUP bans, when null-routing hits. From $3.

FYRHost: VPS from $3/mo and dedicated from $30.80/mo annual. The map spans forty locations — Reykjavik (Iceland) and Zurich (Switzerland) among them, plus Singapore, Dubai, Cape Town and fourteen others. Signup is email plus a 12-character password, or token-only. No KYC. Checkout is crypto-only across BTC, XMR, ETH, BNB, SOL, LTC, TRX, XRP, DOGE, DASH, ADA, GRAM (TON), and USDT (TRC-20/ERC-20/BEP-20/SPL). No payload or guest traffic logs; connection metadata ≤24h. DDoS included. One SKN company, one crypto checkout. Deploy at https://fyrhost.com/deploy/.

## What “included filtering” actually covers

Every plan on the price page hides behind the same volumetric scrubbing, which unsettles buyers who expect protection to scale with the invoice. L3 and L4 floods — `SYN` storms, `UDP` amplification, `ACK` abuse — die at the network edge on every VPS, storage and dedicated SKU. There is no toggle to enable, no per-IP fee to find on the invoice, and no plan label that marks one tier as more protected than another; absorption is part of the network, not an add-on you forgot to order.

The mechanism is deliberately boring. Edge devices drop spoofed and reflected traffic before it reaches your port, following the ingress-filtering discipline set out in [RFC 2827](https://datatracker.ietf.org/doc/html/rfc2827), so an amplifier chain never turns your 1 Gbps port into the weak link of someone else's attack. Whatever survives that first screen is addressed to you and behaves like traffic, and that is exactly where the network's job ends. The full taxonomy of denial-of-service techniques, from resource exhaustion to reflection chains, is catalogued in [RFC 4732](https://datatracker.ietf.org/doc/html/rfc4732) if you want the vocabulary precise when you describe an incident.

Inclusion breaks at the application layer, and it breaks predictably. An HTTP flood that completes real TLS handshakes and requests real URLs is, packet by packet, indistinguishable from a rush of customers; no edge filter can reject it without rejecting your real users. That traffic crosses, and the counters that matter move onto your box: `limit_req` in nginx, connection caps in `nftables`, a cache in front of the origin. The recurring mistake is filing a ticket mid-flood and expecting the network to do what your application config does.

Test the included layer once, so you never have to take it on faith. From a spare box, a `hping3` SYN burst against your own port shows the edge absorbing what arrives while your traffic graphs stay flat; if you would rather not synthesize a flood, weeks of `vnstat` history tell the same story quietly. What you should never do is rent a booter to test — outbound attack traffic is an AUP category, whichever direction it flies. One controlled drill and one clean graph buy more certainty than any brochure line you will ever read about filtering.

One machine changes that boundary: Citadel carries an L3/L7 scrubber on its 25 Gbps uplink, the only SKU where application-layer filtering ships as part of the product instead of your config. Below that line the edge hands you clean packets and the judgment stays local — which is the honest shape of the deal behind the word “included”, and the shape every section below assumes.

VPS from $3* (fund $50+), storage 1–5 TB NVMe from $24/mo annual-eff, dedicated with IPMI from $30.80/mo. Crypto invoice, no KYC.

[Launch now](https://fyrhost.com/deploy/?kind=vps&plan=business/)

## How an abuse mail gets answered

Abuse reports here are answered with data, and the desk reads for exactly three things before anything else: the IP, the timestamp in UTC, and the process that owned the socket at that moment. A reply containing those three fields usually closes a case in one round. A reply containing an apology and a promise opens a second round, and escalation lives in the gap between the two.

The working reply assembles itself from three commands. `date -u` pins your clock to the reporter's frame of reference, `journalctl -u nginx.service --since "2026-10-09 13:00:00Z"` pulls the exact window a report points at, and `ss -tnp` on the live box names the process holding the port. Paste the log line next to the timestamp, state what the process was and what you changed, and the exchange ends there. [RFC 2142](https://datatracker.ietf.org/doc/html/rfc2142) is the reason an abuse mailbox exists on every serious network, and the convention works in your favor when you feed it facts instead of feelings.

Write your reply template before the first mail forces the issue. Four lines — reported IP, your UTC timestamp, the process, the action taken — with a subject that quotes the ticket, and the whole exchange costs you ten minutes when a report lands. Fill the lines from `journalctl`, send, done; a report answered this way reads like it came from an operator, because it did. Desks remember responsive sources, and the quiet dividend of a good first reply is that later reports arrive with the benefit of the doubt attached.

Tor operators are the standing exception worth naming, because exits attract complaints by design rather than by failure. Publishing an operator contact and an exit policy, the way the [Tor Project's relay documentation](https://community.torproject.org/relay/) walks through, keeps your address routable: a reporter reaches a human before reaching for a null-route request. The same logic scales down to any service that draws reports as a side effect of doing its job — a mail server, a public mirror, a chat bridge.

The typical failure is silence, and the second-typical is a reply with neither timestamp nor process name in it. Both convert a ten-minute fix into an escalation thread, and escalation is where an address stops being yours to lose. Answer with data and the thread dies in your inbox, which is the entire art of the abuse desk from your side of it — and the habit that makes every later section here cheaper.

## Copyright notices are mail, not switches

A `DMCA` notice lands as copyright mail, and on this network copyright mail is read as mail, not as an order. The notice-and-takedown machinery described by the [U.S. Copyright Office](https://www.copyright.gov/dmca/) gives a complainant a format and a safe-harbor theory; it does not hand anyone a power switch over a rack in another country. What happens next depends on the facility's jurisdiction, because abuse handling reads only claims backed by the law where the disks physically sit.

That is the layer most boilerplate notices ignore. The safe-harbor bargain written into the [OCILLA](https://en.wikipedia.org/wiki/Online_Copyright_Infringement_Liability_Limitation_Act) statute presumes a provider inside the legal system that created it; a Saint Kitts company operating Reykjavik metal is a different legal object, and the [flag-by-flag guide to copyright mail](https://fyrhost.com/guides/jurisdictions-that-ignore-dmca/) shows how much the practical response varies from rack to rack. Some jurisdictions treat an overseas template as correspondence; none treat a local court order that way, and the two arrive in different envelopes on purpose.

The mistake runs in both directions. Operators who assume a notice means instant suspension burn a weekend migrating boxes that were never threatened, while operators who assume a notice means nothing at all skip over the one letter that cites an actual order. Read each notice against the facility's law, answer with the facts-and-timestamps format from the previous section, and keep the [jurisdiction overview](https://fyrhost.com/dmca-ignored-hosting/) as the standing reference for what process actually reaches each of the forty sites.

Sort your own mail into the two envelopes before either arrives. Civil copyright mail comes as a `PDF` template quoting a statute and gets a dated, factual reply; court process arrives citing a case number and gets read in full, twice, then forwarded to the desk the same day. What you never do is answer either with a panic `rsync` — the emergency migration is the classic wrong response to a letter that was never an order, and it costs you a weekend plus the stability you were protecting by staying put.

Handled this way, a copyright thread is correspondence with a deadline, not an outage. The content stays up while the mail is read, the operator keeps the rollback window, and the only irreversible step in the whole sequence is the one a court takes — which no template in anyone's outbox can imitate.

## What no invoice covers, in any coin

Named plainly, because every host has a list and this one is ours: CSAM, phishing, spam and attack traffic are prohibited on every plan, paid with any of the nineteen coins, in all forty locations. Payment rail and acceptable use are separate layers by design, which is why the [acceptable use policy](https://fyrhost.com/aup/) would read identically under a Monero invoice and a card-receipted one — the list travels with the rack, not with the checkout.

Child-safety reports route to the abuse address with URLs and are handled as the serious reports they are; that category is not a copyright debate and does not wait on jurisdictional argument. Attack traffic you send — as opposed to floods you receive — sits in the same bucket: renting a box does not rent a launchpad, and booter-for-hire setups die at the AUP layer long before any external process needs to get involved.

The standard mistake is arithmetic. A buyer concludes that anonymity of payment converts into amnesty of use, and it does not: the coins make the checkout private, while the AUP keeps the content bounded. If a project needs the banned categories, no plan here fits it, and the honest move is to stop reading at this paragraph rather than to test the boundary from inside a paid account.

Test your own content against the list the way the desk will. A mailer you wrote is a newsletter until the complaints arrive — then it is `spam`, and `double opt-in` logs are the difference between a conversation and a suspension. A stress-testing tool you run for friends becomes attack traffic the moment it points outward, whatever your intention was. Hold the four categories in your head as behaviors rather than topics — `CSAM`, `phishing`, `spam`, attack traffic — and your own logs become the only witness whose testimony you control.

Everything past this point assumes the traffic you defend is traffic you are allowed to have. With that fixed, the interesting questions become operational — what the edge absorbs, what your config must carry, and how the two layers hand work to each other, which is where the next sections go.

## Null-routing: the last tool, not the first response

Null-routing exists for one case: the AUP is being broken flagrantly and the abuse ticket has gone unanswered. The normal sequence runs report, reply with facts, fix on your side, restore to quiet — and the route comes back when the behavior does. Operators who answer with timestamps and process names, in the format from earlier, never meet the last step of that sequence at all.

The mechanism is crude by design. A route to `blackhole` costs the network nothing to apply and costs you everything while it stands, which is precisely why it stays at the end of the toolbox instead of the front. Before that point you receive tickets with data in them, and the thread is where the actual negotiation happens; answer the first mail properly and the sequence stops at the fix, invisible from the outside and final in effect.

The misreading to avoid is treating a null-route as censorship rather than as the end of an unanswered conversation. If your address goes dark, the abuse mailbox is checked before the router config: the path back is the same reply with IP, UTC timestamp and process, plus the fix you applied. Nothing in the sequence changes with plan size, coin, or flag — a $3 Scout and a $298.50 Citadel meet the same procedure, which is either reassuring or not, depending on how you run your box.

Read the sequence as a service level running in reverse. Four steps — `report`, `reply`, `fix`, `restore` — and your reply is the step you own: answer within a day and the process never reaches the route; ignore for a week and you are betting your address on a desk's patience. Your abuse mailbox deserves the same watch as your ops inbox, because on the day it matters they are the same inbox. The fix that keeps you at step three forever is also the cheapest monitoring you will ever deploy.

Read as policy, null-routing is the network declining to host a conversation you stopped having. Read as an operator, it is a deadline with a mailbox attached. Either reading rewards the same habit, so the next section stays on the theme of controlling what draws reports in the first place.

## Shrink the target instead of outrunning the flood

The cheapest defense is a narrower face. A game server with a community whitelist presents a small front to scanners; a VPN endpoint that answers one protocol on one port gives a filter less to think about; a web application behind a cache survives hammering that would flatten a bare origin. None of that costs a plan change, and all of it compounds with the unmetered port you already hold — 1 Gbps on Scout, 2.5 Gbps on Ranger, 5 Gbps on Warden, 10 Gbps on Sentinel.

Sizing follows the face, not the flood. A public game world draws rivals, bot ranges and booter traffic within days of appearing in a master list, and the [game-server hosting guide](https://fyrhost.com/guides/ddos-vps-game-server-hosting/) covers the plugin layer that network filters never touch — vote spam, chat abuse, account farming. Order Sentry at $6.00 annual-eff ($7.50 list) for a 32-slot world, keep the whitelist on, and the volumetric layer above it absorbs what the scanners send while your config handles what gets through.

Storage separates from compute for the same reason: an asset you can move is worth more than one you must defend in place. Downloads and archives behind a public URL belong off the web origin entirely, so a flood against the front page never reaches the bytes people actually came for. Isolation is a design decision before it is a hardware purchase, and it is the one variable fully under your control before anything touches the network.

Pick the face on purpose and write the decision down: which ports answer publicly, which communities may connect, which endpoints cache. A VPN endpoint that answers only `udp/51820` gives a scanner one question; a game server with a whitelist answers members only; a blog behind a cache answers `443` requests the origin never sees. Your `nftables` ruleset is that decision in written form, and twenty lines of it buy more flood resistance than any upgrade you could order this afternoon. You can change a small face in minutes; you can only defend a wide one for money.

The sections that follow assume you have done this trimming. A narrow target with a prepared operator is a hard story for an attacker and a short story for an abuse desk; a wide target with an unprepared one is the profile every escalation checklist is written for.

## Evidence that shortens a ticket

When a flood does cross to your port, capture before you act. `tcpdump -ni any port 443 -w cap.pcap` running during the event, `ss -s` for socket totals, `conntrack -S` if the box tracks state — those three lines separate a reportable incident from a vague feeling. Stamp everything against `date -u`, because the abuse desk and the edge both speak UTC, not your server's local zone.

The capture gives a ticket a shape the network can act on: which protocol, which source ranges, whether the SYN rate or the request rate is the anomaly. Attach it through the [support-ticket walkthrough](https://fyrhost.com/guides/how-to-open-support-ticket/) and the escalation path shortens from days to hours, because the engineer reading it starts at your evidence instead of at your adjectives. The [DDoS-protection explainer](https://fyrhost.com/guides/ddos-protected-vps-explained/) lists what each layer can and cannot see, which is the exact vocabulary to argue with.

Acting first and capturing never is the standard regret. After `nftables` drops the noise, the evidence drops with it, and the ticket becomes an argument about a past neither side can inspect. Capture, mitigate, then report — in that order — and the edge sees the same flood you saw, at the same seconds, in the same byte counts.

One capture also teaches you your own baseline, which is the number every later incident is measured against. Operators who have seen their normal 200 req/s know instantly what 20,000 req/s means; operators who have never looked call both of them an attack, and only one of those calls gets taken seriously.

Keep the capture habit warm between incidents. A monthly five-minute drill — start `tcpdump`, generate load against yourself, stop, read the file — means a real event finds your fingers already knowing the keys. Store one capture from a quiet period as your baseline, because a flood capture means little until it sits beside what normal looks like. Put the drill in your calendar as `capture practice` and treat a skipped month as a real gap, because the muscle decays faster than the tooling. Your future ticket reads twice as well with a before and an after attached, and the before cannot be reconstructed once the noise starts. Your sizing note should also say which side of the boundary each past incident sat on, because next year's budget reads better with evidence than with adjectives.

## Where the limits genuinely sit

The included layer stops at volumetric, and saying so is the point of this page. Application-layer judgment is yours on every SKU below Citadel; abuse handling follows the facility's jurisdiction rather than your preference; and no filter reads your application's business logic. A plan with more gigabits absorbs a bigger wave — it does not decide which requests deserve answers, and that distinction is the whole boundary of the product.

What the boundary means in practice: keep the origin thin, and put bulk bytes on the storage tiers where they cost less and draw less. Put archives on the 1 TB Storage Depot at $24/mo annual-eff ($30 list) when the web tier needs room, and take IPMI-equipped metal from $30.80/mo annual-eff when a wedged box should reimage out-of-band instead of waiting on a rescue console you cannot reach. Those are sizing decisions, not protection decisions, and keeping the two apart prevents most regrettable invoices.

Price the boundary honestly when you size. A bigger port absorbs more volumetric noise — `1 Gbps` on Scout, `10 Gbps` on Sentinel — and changes nothing about explainable HTTP, so spend where your incident history actually points. If your floods were L7, buy cache and config first; if they were raw and personal, the port ladder is your ladder. Metal enters when the box itself must survive what the port invites — and what saves your night there is `IPMI`, not gigabits. Note which side of that line each past incident sat on, because next year's budget reads better with evidence than with adjectives.

The limits are published rather than discovered, which is why they are written here at length. The single filtering upgrade in the entire catalog is Citadel's scrubber; everything else in this page is configuration you own, evidence you capture, and mail you answer. A host that claims otherwise is selling you the same edge with a longer invoice line.

With the boundary stated, the remaining work is procedural — so the closing section compresses everything above into the order you actually run it, from baseline to ticket.

## The defense-and-abuse routine, in the order to run it

Start by writing the attack surface down: every listening port, every public hostname, every service that would make a story if it were flooded — `ss -tlnp` produces the first draft in one line. Cut the surface where you can, whitelist where the community allows it, and move bulk assets off the origin so the valuable bytes are not stored behind the visible door. A surface you chose is worth several gigabits of absorption before a single packet flies.

Confirm the included layer rather than assume it: L3/L4 filtering ships enabled on every SKU, so the check is that your port answers clean while a volumetric test passes, not a purchase. Then carry your own layer — `limit_req` zones in nginx, connection caps in `nftables`, a cache in front of anything dynamic — because explainable HTTP is your traffic to judge, on every plan below Citadel's scrubber.

Prepare the abuse procedure before any mail arrives: a reply template holding IP, UTC timestamp and process name, the habit of `date -u` before every log pull, and the `journalctl` window syntax ready to paste. Check the AUP against the project once, deliberately, and note the facility jurisdiction your box sits in so a notice's reach surprises nobody on your side.

When a flood comes: capture with `tcpdump -w`, mitigate, then open one ticket with the capture, the UTC window and the anomaly stated in numbers. When a notice comes: read it against the rack's law, reply with data, keep the rollback window. When neither comes: leave the surface narrow and the mailbox watched — that is the entire routine, and every step of it is free.

Then leave it alone. A routine that runs quietly for a quarter is the goal; churn — new filters monthly, ports opened for a weekend, whitelists loosened for an event — is how a narrow target grows back into a wide one. Review the four steps when your service changes, not when your anxiety does, and let the `abuse@` mailbox stay the quietest line in your week. You will know the posture works when the exciting incidents stop being yours: small face, prepared reply, evidence first, and a checklist you rarely need.

Will you null-route my server? Only when the AUP is being broken openly and the abuse ticket sits unanswered — the sequence runs report, reply, fix, restore. A reply with IP, UTC timestamp and process name stops the sequence at the fix, and the route is restored once the behavior stops.

Does the coin I pay with change the AUP? No. Payment rail and acceptable use are separate layers by design, so the same banned list — CSAM, phishing, spam, attack traffic — applies under all nineteen coins at every one of the forty locations. The checkout's privacy never transfers to the content.

Is DDoS filtering an extra charge? No. L3/L4 filtering ships enabled on every VPS, storage and dedicated SKU with no per-IP fee and no request form. The only filtering upgrade in the catalog is the L3/L7 scrubber on Citadel's 25 Gbps uplink at the top of the metal ladder.

What makes an abuse reply useful? The IP, the UTC timestamp, and the process that owned the socket, plus the fix applied if the report was right. Those fields close a case in one round; apologies and promises without them open a second round, and escalation happens in that gap.

Do game servers actually attract attacks? Yes — a public world draws rivals, bot ranges and booter services within days of hitting a master list. Included volumetric filtering absorbs the flood layer, while vote spam and chat abuse are plugin territory and a community whitelist narrows the target more than any filter.

Does filtering include stopping an HTTP flood? Not below Citadel: an HTTP flood that completes real TLS sessions looks like traffic to the edge, so rate limits, caching and connection caps on your box carry it. Citadel's L3/L7 scrubber is the one SKU where application-layer filtering ships in the product.

## Primary sources

- [RFC 4732: Internet Denial-of-Service Considerations](https://datatracker.ietf.org/doc/html/rfc4732)
- [Tor Project: relay operations](https://community.torproject.org/relay/)
- [U.S. Copyright Office: DMCA](https://www.copyright.gov/dmca/)

## Related guides

- [Minimum-data no-KYC checkout](https://fyrhost.com/guides/anonymous-vps-crypto-no-kyc/)
- [Buy a VPS with crypto](https://fyrhost.com/buy-vps-with-crypto/)
- [No-KYC VPS: requirements and limits](https://fyrhost.com/no-kyc-vps/)
- [Pay with Monero](https://fyrhost.com/monero-vps/)
- [Offshore VPS](https://fyrhost.com/offshore-vps/)
- [VPS vs dedicated bare-metal](https://fyrhost.com/guides/vps-vs-dedicated/)
- [Best no-KYC VPS 2026](https://fyrhost.com/best-no-kyc-vps-2026/)
- [FAQ: crypto VPS](https://fyrhost.com/guides/faq-crypto-vps/)

## More ways to pay

[Pay with Bitcoin](https://fyrhost.com/bitcoin-vps/) · [Pay with Monero](https://fyrhost.com/monero-vps/) · [Pay with USDT (TRC-20/ERC-20/SPL)](https://fyrhost.com/usdt-vps/) · [Pay with XRP](https://fyrhost.com/xrp-vps/) · [Pay with TRX](https://fyrhost.com/tron-vps/) · [Pay with Dogecoin](https://fyrhost.com/dogecoin-vps/) · [Pick the jurisdiction first](https://fyrhost.com/jurisdiction/).

## Checkout facts

- **Price** VPS from $3/mo. Dedicated from $30.80/mo.
- **Identity** No KYC. Token-only (no email) or email plus a 12-character password. No passport, phone, or card.
- **Payment** Nineteen ways to settle, none of them a card: XMR and BTC lead, ETH, SOL, LTC, BNB and TRX follow, then XRP, DOGE, DASH and ADA, GRAM (TON) for Telegram-adjacent rails, and USDT on seven networks — TRC-20, ERC-20, BEP-20, SPL, Polygon, Arbitrum, Optimism. Live-rate invoice.
- **Logs** No payload / no guest traffic logs. Billing and panel actions retained. Connection metadata ≤24h.
- **Platform** KVM on ECC and local NVMe. DDoS filtering included. Facilities in 40 cities across four continents — the locations table lists each one's tier, uplink and governing law. Need Iceland or Switzerland plus no KYC? Those two carry a published premium (+20% / +35%); every other flag stays at base list. Pay BTC, USDT, XMR, BNB, XRP, GRAM (TON) or 10 more. Open deploy to pick a plan.

## Ready to launch?

Build the box — VPS, storage or bare metal — create the password, pay the invoice that follows.

[Launch now](https://fyrhost.com/deploy/?kind=vps&plan=business/)[Dedicated](https://fyrhost.com/dedicated/)