Protocol-aware filtering: why generic DDoS protection fails Minecraft

The three signals generic protection uses

Strip the marketing from any general-purpose DDoS product and it filters on some combination of three things. Packet shape: is this well-formed, is the header sane, does it match a known attack signature. Rate: how much is arriving, from how many sources, how fast. Reputation: is this source known bad, is it a datacenter, has it misbehaved before. These three catch an enormous amount of real attack traffic and they are genuinely valuable.

Now consider what a competent Minecraft bot attack looks like against each one. The packets are valid Minecraft protocol — the bot completes a real TCP handshake and sends a real login sequence, because it has to in order to cost you anything. The rate per source is deliberately low, because the attacker knows about rate limits and has thousands of sources. And the origins are increasingly residential proxies, which are indistinguishable from your actual players because they *are* actual consumer connections.

All three signals read normal. Not marginal — normal. This is not a tuning problem that a better threshold solves; it is a category error. The information needed to make the decision is in the application payload, and generic filtering does not look there.

What the protocol actually tells you

The moment a filter parses the Minecraft protocol, a set of decisions becomes available that simply do not exist at the packet layer:

• The hostname the client asked for. The handshake carries the address the player typed. A connection requesting a hostname you do not serve is not a player who mistyped — it is scanning or misdirected traffic, and it can be dropped before anything is allocated.
• Whether this is a ping or a join. The same port carries both, and they have wildly different costs. Status pings can be answered from cache at the edge; logins cannot. A filter that cannot tell them apart must treat cheap traffic as expensive, or expensive traffic as cheap.
• The claimed client version, checked against behaviour. Bots declare a protocol version like everyone else. Whether the rest of the connection behaves the way that version actually behaves is a much harder thing to fake than the number itself.
• Join rate in game terms, not connection terms. Ten connections that ping and leave are nothing. Ten connections that all reach login-start in the same second, from one network, are a pattern. Only a protocol-aware filter can tell those apart — to a packet counter they are identical.
• Connection state across the sequence. A real client progresses: handshake, login-start, encryption, play. One that opens and stalls is starving your connection table, and the giveaway is the sequence never advancing.

The part that decides outcomes: what happens to the residue

Even perfect protocol parsing leaves something behind. A bypass bot — one written specifically against a known antibot — paces itself correctly, sends plausible fields, connects from residential addresses and does nothing anomalous, because that is the entire design goal. Scoring cannot catch it. If your defence only ever *scores*, the attacker can query it until they pass.

So the last step stops scoring and starts asking. Suspicious joins are detoured into a limbo server and required to demonstrate they are a real client: movement that obeys the game's physics, correct responses to server state, behaviour a headless bot has to genuinely implement rather than imitate. Passing is nearly free for a player and expensive per-bot for an attacker, which is the whole economic argument. And because those checks are not published, a bot tuned against one of them does not automatically pass the next — the structural advantage an unpublished gauntlet has over an open-source plugin whose checks an attacker can simply read.

Why position matters as much as knowledge

A Minecraft plugin is protocol-aware by definition; it lives inside the server. Its problem is where it sits. By the time a plugin can reject a connection, your kernel has accepted it, your proxy has allocated a session and your CPU has parsed it. During a flood, the resources are spent before the verdict is reached — which is why plugin-based antibot works well against small attacks and collapses against large ones. The full argument is in edge antibot vs plugin antibot.

The same logic applies upward. Protocol-aware filtering does not replace volumetric absorption — if the flood is larger than your uplink, the uplink is full and nothing behind it gets a vote. The two solve different halves: absorption handles the traffic that was never pretending to be anything, and protocol awareness handles the traffic that was. A stack needs both, in that order, which is what the stage-by-stage walkthrough shows end to end.

How to tell whether a provider actually does this

• Ask how join floods are separated from real players, specifically. "We filter Layer 7" is not an answer; "we parse the handshake and evaluate hostname, version and join intent" is.
• Ask what happens to a connection that passes scoring but is still a bot. If there is no verification step, the answer is that it reaches your server.
• Ask whether status pings are served from cache at the edge. If they are forwarded, ping floods become your CPU's problem.
• Ask whether real client IPs are delivered via PROXY protocol — and on which plans. Protection that breaks your ban list has traded one problem for another.
• Ask whether an attack results in **filtering or a null route**. Blackholing is not mitigation; it is the outage, applied by your own side.

Common questions

Every layer described here runs on every Arvoris plan, including the free one — paid tiers add capacity and control, not protection. Create a free network and put it in front of your server in about five minutes, or read the glossary if any of the terms above were new.

Related reading