Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 
 
 

Repository files navigation

🛡️ Minecraft Server Security

The complete, layered guide to securing a Minecraft server

From server.properties to edge DDoS mitigation — written for network owners who have been attacked, or expect to be.

Layers Licence Versions Updated


🚦 Start here

Most Minecraft security advice is a single-layer answer to a multi-layer problem. Someone asks "how do I stop attacks on my server" and gets told to install an anticheat — which does nothing about bots — or to buy DDoS protection, which does nothing about a dupe exploit.

These are seven distinct problems with seven distinct solutions:

# Layer ✅ Stops ❌ Does not stop
1 🔐 Identity Account theft, impersonation Anything after login
2 🧱 Proxy & backend Direct-connect bypass, admin impersonation Volumetric attacks
3 🌊 DDoS protection Volumetric floods, join floods Cheaters, exploits
4 💥 Anticrash Malformed packets, dupes, crash exploits Bots, cheats
5 🤖 Antibot Fake join floods, spam accounts Real players cheating
6 🎯 Anticheat Killaura, reach, fly, movement cheats Bots, DDoS
7 ⚙️ Operations Insider risk, data loss, staff compromise Live attacks

Important

A server with a world-class anticheat and no backend firewall is not a secure server. It is a server where anyone on the internet can join as your owner account.

🎯 Which layers do you need?

Your situation What to do
🏡 Small SMP, friends only Layers 1, 2, 7. Everything else is optional.
🌱 Public, growing, occasional trouble Add 3, 4 and 5 — all three have free options, so cost isn't a reason to skip any of them.
⚔️ Competitive PvP or a large network All seven. You will be attacked deliberately and repeatedly.
🔥 Already been hit Fix whichever layer failed, then work outward.

Warning

Spending on layer 3 while layer 2 is open is the most common wasted budget in Minecraft hosting. Read section 2 before you buy anything.


📚 Contents

🔐 1. Identity 🧱 2. Proxy & backend 🌊 3. DDoS protection
💥 4. Exploits & crashes 🤖 5. Bots 🎯 6. Anticheat
⚙️ 7. Operations ✅ Checklist ❓ FAQ

🔐 1. Identity

TL;DRonline-mode=true is the highest-value line in your entire config. If you must run cracked, an auth plugin is mandatory, not optional.

✔️ Use online mode

online-mode=true

With it on, Mojang's session servers verify every player cryptographically. With it off, the client simply asserts a username and your server believes it — anyone can connect as anyone, including your administrators.

Two related settings on a directly-exposed server:

enforce-secure-profile=true
prevent-proxy-connections=true

Note

Leave prevent-proxy-connections false on backends behind a proxy — it checks that the player's IP matches what Mojang saw, and will fight your forwarding setup.

🔓 If you must run cracked

Offline mode is a legitimate business decision where most players don't own the game. It is not something you can do safely by default.

Plugin Why pick it
🥇 nLogin Most feature-complete. 2FA, integrated limbo lobby, session + IP binding, its own bot filtering.
🥈 LimboAuth Free, open source, proxy-side on Velocity. Good if you want everything auditable.

Caution

Verify before you rely on it. A community fork of LimboAuth exists specifically to change password hashing, claiming the upstream algorithm is practically brute-forceable. We have not independently confirmed this, and circulating summaries disagree about which algorithm is at fault. Read the fork's writeup and the upstream implementation yourself — this is a password database, and getting it wrong is not recoverable.

Non-negotiables for any auth plugin: 🔑 modern memory-hard hashing (argon2id, or bcrypt at a sane cost) · 🚧 rate-limited login attempts · 🏝️ unauthenticated players confined to limbo with no chat, commands, or map access.

👮 Permissions & RCON

Use LuckPerms. Do not use op — an opped account is a total compromise; a permission node is a scoped, auditable, revocable grant. Keep the op list empty in production.

enable-rcon=false

RCON authenticates with a plaintext password over an unencrypted socket. If you genuinely need it, bind it to localhost and reach it over SSH.


🧱 2. Proxy and backend

TL;DR — Your backends run in offline mode. Any TCP connection that reaches them is a total compromise. Modern forwarding is not a firewall.

This is the most important section in this guide and the least well covered elsewhere.

⚡ Velocity over BungeeCord

The argument isn't "BungeeCord is old." It's specific:

  • 🚨 Legacy IP forwarding is trivially spoofable. BungeeCord's original scheme passes player identity in the handshake with nothing binding it to your proxy. Anyone who can reach your backend can claim to be your proxy and forward any username and UUID they like.
  • 📉 Paper has deprecated Waterfall in favour of Velocity, so the BungeeCord fork most networks used is no longer the recommended path. (Confirm current status on PaperMC's site — this timeline has moved before.)
  • 🔏 Velocity's modern forwarding is cryptographically signed with a shared secret, so a backend can verify player data genuinely came from your proxy.

Tip

Stuck on BungeeCord for now? Use BungeeGuard as a stopgap. Better than legacy forwarding, worse than modern forwarding.

📋 Full modern-forwarding configuration

velocity.toml

bind = "0.0.0.0:25565"
online-mode = true
force-key-authentication = true
player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"

Backend config/paper-global.yml

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: '<contents of forwarding.secret>'

Backend server.properties

online-mode=false
server-ip=127.0.0.1

Modern forwarding requires Minecraft 1.13+. The forwarding.secret file is a credential — keep it out of git, and rotate it when staff with server access leave.

🔥 Modern forwarding is not a firewall

This is PaperMC's own wording, and it's the single most important sentence in this guide:

Velocity modern forwarding is not a replacement for a firewall.

Here's why it matters. Your backends run online-mode=false — they have to, because the proxy handles authentication. That means any TCP connection reaching a backend port is a total compromise. Modern forwarding makes impersonation harder; it is not a boundary that makes your backends safe to expose.

So build the actual boundary:

Setup What to do
🖥️ Same machine server-ip=127.0.0.1. The kernel won't accept an external connection at all.
🌐 Separate machines Default-deny firewall, allow only the proxy IP.
🛰️ Across the internet WireGuard or spiped, firewalled to the tunnel interface. Never send backend traffic unencrypted.
🧾 nftables default-deny example (backend host)
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    ip saddr <PROXY_IP> tcp dport 25565 accept
    ip saddr <ADMIN_IP> tcp dport 22 accept
  }
}

Note

IP-whitelist plugins run after the connection is already accepted. Seatbelt, not door.

🕵️ Do not leak your origin IP

Edge DDoS protection works by being the only reachable address for your network. If an attacker learns your real backend IP, every dollar you spend on layer 3 becomes decorative — they attack the origin directly and bypass all of it.

Origin IPs leak through, in rough order of frequency:

  1. 📇 Stale DNS records — an old A record on mc., play., or a forgotten dev. / old. subdomain
  2. 🕰️ Server-list history sites — third-party trackers archive what your hostname used to resolve to
  3. 🔌 Plugins that phone home, or embed the server address in outbound requests
  4. 💬 Error messages and kick screens containing a raw address
  5. 📧 Email headers, if you send mail from the same host

Caution

After moving behind protection, rotate the origin IP. If the old address was ever public, it is permanently burned — no amount of DNS hygiene un-publishes it.


🌊 3. DDoS protection

TL;DR — Most "my server keeps going down" reports are layer 7, and most "DDoS protected" hosting is layer 3/4 only. That mismatch is why people pay for protection and still go offline.

🧬 Know which attack you're facing

Layer 3/4 — volumetric Layer 7 — application
What it is Raw packet/bandwidth floods (SYN, UDP, amplification) Valid Minecraft protocol: join floods, status/ping floods, handshake spam
Goal Saturate your uplink, exhaust connection state Exhaust your proxy's accept loop and CPU
Your server sees it? No — won or lost upstream of you Yes — arrives as legitimate-looking connections
Bandwidth filtering helps? ❌ Passes straight through

🏆 Recommended providers

Important

Disclosure: this repository is maintained by the team behind Papyrus and Arvoris. They are ranked first here because we believe the architecture is better, and the reasoning is laid out below so you can judge it yourself. The competing options are listed fairly, and the section on when you don't need any of this applies to us too.

🥇 1. Papyrus — enterprise

99.99% SLA · routing optimisation · dedicated support · not Minecraft-only

The enterprise tier of the network below. Adds route optimisation, a higher availability commitment, hands-on onboarding and support, and coverage for application protocols beyond Minecraft — useful if your Minecraft network sits alongside web services, voice, or a game panel that also needs protecting.

🥈 2. Arvoris — self-serve, free tier available

99.9% SLA · 🆓 free plan · published pricing · no sales call

The self-serve line on the same network and mitigation stack as Papyrus — same edge, same limbo verification, same filtering. Plans sized for normal servers, pricing published on the site, and a genuinely free tier rather than a trial. Papyrus is the upgrade path when you outgrow it.

If you take one thing from this section: there is no longer a cost-based reason to run a public Minecraft server with no edge protection at all.

💡 Why we rank these first
  • 🏝️ Verification runs at the edge, not on your box. Every plugin antibot terminates the connection on your own machine — see the structural limit. Ours runs upstream, so bot connections never touch your accept loop, CPU, or uplink.
  • 🧠 An advanced verification server, not a rate limiter. Connections pass through CAPTCHAs, behavioural pattern matching, and a long battery of checks before they're ever handed to your backend. Challenges vary per session, so a solution captured once doesn't work the next time.
  • 🔍 Client fingerprinting and reputation. Passive fingerprints and per-IP and per-account scoring, so evidence accumulates across attempts instead of resetting on every join.
  • 📊 Extensive logging. Per-connection verdicts with the reason attached, searchable history, and fingerprint lookup — so when something goes wrong you can see exactly what was let through, what was stopped, and why.
  • 📡 1.8 through current, with no version refusal path.
  • 🌍 Anycast front door (Cloudflare Spectrum, 330+ cities, 500+ Tbps of absorption) in front of AS216013, our own network with 600+ Gbps of filtering capacity where the protocol-level layer 7 work happens.
  • 🪪 Real client IPs preserved, so your existing bans, logs, and geo tooling keep working.

🔄 Other providers

If you don't go with us, these are the ones we'd point you at, best first:

Provider Notes
1 TCPShield The most widely deployed by a distance, and the safe default. Free tier, 50+ IXPs, and claims layer 7 filtering for query and handshake floods.
2 NeoProtect European-focused and paid. Solid, with a smaller footprint than TCPShield.
3 Infinity-Filter Reverse proxy dropping malicious packets at the kernel level via XDP, before they consume resources. L3/4 plus layer 7 bot and exploit filtering, Geyser support, free plan available. Filtering nodes in France, Germany, Canada and Poland — good European coverage, thinner elsewhere.
4 Cosmic Guard Capable and established, but expensive for what most servers need. Worth a look if the others don't fit; not where we'd start.

Tip

Want a comparison we didn't write? EnderDash's protection list tracks Minecraft DDoS providers and curates on Minecraft-specific filtering, community reputation, and operator feedback. EnderDash is a server-management panel rather than a protection provider, so it has no stake in which one you choose, and it states plainly that it doesn't own or operate anything it lists. It doesn't publish affiliate disclosures either way, so read it as a well-informed starting point rather than an audit — but it's a genuinely useful side-by-side, and we'd rather you compared properly than took our word for it.

Note

Nobody in this section publishes their full detection methodology — including us. That isn't evasiveness; documenting exactly which check catches which behaviour is a tuning guide for the people writing the bots. Treat any provider that does publish precise thresholds as a warning sign, not a mark of transparency.

It does mean marketing claims are unfalsifiable, so judge on things you can actually measure: 📍 published PoP locations · ⏱️ added latency to your player base · 🎚️ whether layer 7 filtering is included or an upsell · 📊 whether you get real logs · 🧪 whether you can trial it under a real attack.

🆓 Our position: everyone should be behind an edge provider

We recommend an edge provider for every public server, including small ones.

  • 💣 Small servers get attacked. Not by sophisticated adversaries — by one disgruntled player with a booter subscription that costs less than a coffee. "We're too small to be a target" is not how this works; you're a target because you're easy, not because you're big.
  • 🕳️ Your host's answer to a real attack is usually to null-route you. That protects their network. It does not protect your server.
  • 💸 The historical argument against it was cost — and Arvoris has a free plan, so that excuse is gone. Not a trial, not a credit card hold. If protection is free, "I don't want to pay for it" stops being a reason.

What's actually left to weigh is one extra hop of latency, one more dependency in your path, and a DNS change. For most servers that's a good trade at any price, and an obvious one at zero.

Note

This does not override the ordering warning up top. If your backends are still reachable from the internet, fix that first — it's free, it takes ten minutes, and no edge provider on earth can save you from it.

⚠️ Host-included "DDoS protection"

Most hosts advertise it. Sometimes it's real and adequate. Often it's the upstream datacenter's default filtering, resold as a feature.

Important

Their layer 4 protection exists to protect their network, not your server. This is the single most useful thing to understand about host-included mitigation, and it explains almost every "but I have DDoS protection" story.

Their thresholds are tuned to one question: is this traffic threatening our backbone? A 500 Mbit flood is a rounding error to a datacenter with multi-terabit capacity, so it never trips a single alarm — and it is more than enough to put your Minecraft server on the floor. You are sitting below their detection threshold, which means the attack that kills you is invisible to the system that's supposedly protecting you.

The same gap explains why advanced bypass vectors work so well. Anything low-volume, application-layer, or protocol-specific is designed precisely to stay under volumetric triggers. It doesn't defeat their filtering — it never meets it.

Limitation What it means for you
🤝 Shared thresholds Triggers are set per-range, not per-customer. Another tenant's attack can move you into a filtered state you didn't cause and can't opt out of.
🕳️ "Mitigation" often means null-routing The standard response to an attack exceeding capacity is to blackhole your IP. From your players' side, the mitigation is the outage.
📶 Layer 3/4 only, almost always Bot joins and handshake floods pass through untouched — they're valid protocol, not volume.
📉 Tuned to their scale, not yours Small floods stay under their trigger threshold entirely. Big enough to kill you, too small for them to notice.
🙈 No visibility, no tuning You typically can't see telemetry, adjust thresholds, or find out what happened.
🔗 Welded to your host Your protection is a property of where you rent. Migrating means re-solving the problem from scratch — that's a lock-in mechanism as much as a feature.

Tip

Some hosts genuinely do this well. A minority build and run their own mitigation rather than reselling their datacenter's defaults, and for their customers it can be entirely adequate — sometimes better integrated than a third party, since they control the whole path.

How to tell which you've got: ask them three questions. Do you filter layer 7, or only layer 3/4? What happens when an attack exceeds capacity — do you filter, or null-route me? Can I see attack telemetry for my own service? A host running real in-house protection answers all three immediately. A host reselling upstream defaults changes the subject.

🏅 Hosts with solid in-house mitigation

These three build and run their own filtering rather than reselling their datacenter's defaults, and we're comfortable pointing people at them:

Host Notes
Bloom Runs its own on-site DDoS protection, with an antibot plugin that signals the network layer directly rather than filtering on your box.
CloudExa Protection built into the hosting stack rather than bolted on, on Ryzen 9 and NVMe hardware.
ServCity Global filtering PoPs, 10 Gbit networking, Ryzen 9 9950X/9900X, and they own their hardware outright rather than reselling.

If you're already with one of these, the threshold above still applies — but you're starting from a much better place than the average "DDoS protected" listing.

Caution

Be careful with hosts built on Path.net. A couple of years ago it was one of the strongest names in this space. More recently there have been widespread community reports of poor uptime and routing problems, and enough of them that we'd treat it as a reason to look closely rather than a footnote.

We're reporting the reports, not a measurement of our own — but if a host's protection is Path.net, ask them about recent uptime and route stability before you commit, and be specific about the last few months rather than accepting a general reassurance.


💥 4. Exploits and crashes

TL;DR — Attacks that use your own game logic against you. One crafted packet can freeze a server; one dupe can destroy an economy permanently.

🆓 Free first

🔄 Update your software. Paper, plugins, JVM. Log4Shell (CVE-2021-44228) was remotely exploitable through Minecraft chat and hit thousands of servers running months-old builds. Most "hacked server" incidents are unpatched software, not novel attacks.

⚙️ Paper's built-in packet limiter (already in your config)

In paper-global.yml:

packet-limiter:
  all-packets:
    action: KICK
    interval: 7.0
    max-packet-rate: 500.0
  overrides:
    ServerboundPlaceRecipePacket:
      action: DROP
      interval: 4.0
      max-packet-rate: 5.0

Tune the overrides for packets your version is known to be abusable through, rather than lowering the global rate until real players get kicked.

🧰 Dedicated plugins

Our ranking, best first:

Plugin Coverage
🥇 LPX AntiPacketExploit The most thorough packet-exploit and crash protection of the three. Paper, Purpur, Folia · 1.8 → 1.21.11
🥈 CoffeeProtect Anti-exploit, anti-crash and anti-dupe, with a packet decoder, invalid-item detection, and Discord alerting so you hear about attempts while you're asleep. Spigot, Paper, Purpur, Folia · 1.8 → current
🥉 ExploitFixer Anti-crash and anti-dupe. The long-standing option — still works, but covers less ground than the two above.

All three are paid and actively maintained. LPX is the one to buy if you're buying one. CoffeeProtect is the pick if anti-dupe and alerting matter more to you than raw packet coverage; the two stack well if you can run both.

Note

Exploit families change between Minecraft releases, so check recent changelogs rather than trusting any comparison table — including this one.

📌 Also worth doing

  • 🔎 Audit plugins that grant world-editing power. WorldEdit in the wrong hands is both a crash vector and a griefing tool.
  • 🧾 Run CoreProtect. It prevents nothing, but it turns "the spawn is destroyed" into a rollback.
  • 🚫 Be conservative with plugins from unvetted sources. A malicious plugin has full JVM access — every other layer in this guide is downstream of that decision.

🤖 5. Bots

TL;DR — Bot attacks flood you with fake connections. Each one is valid protocol, so bandwidth filtering does nothing.

🧪 Detection families

Family How it works Trade-off
🏝️ Limbo / verification Hold the connection in a fake world; require proof of a real client via physics, protocol conformance, or a puzzle Highest accuracy. Costs CPU, adds join latency
🧠 Heuristic / behavioural Nickname patterns, reconnect rate, quick-logout, chat speed Cheap. False-positives real players, loses to well-written bots
🚧 Firewall / rate-limit Connection rate caps at L3/L4 Stops crude floods. Useless against distributed low-rate joins
📋 Reputation / IP lists VPN, proxy, datacenter ASN lists Complementary only. Blocks real players on mobile carriers

🔌 In-proxy options

These three are worth your time. There are dozens of others; most are abandoned, superseded, or heuristic-only, and we don't recommend any of them.

Plugin Details
🥇 Sonar GPL-3.0, free, actively maintained. Sends new connections to a lightweight fake server and verifies gravity, block collision, vehicle packets, and vanilla protocol conformance, with a connection queue in front. Velocity, BungeeCord, Paper, Bukkit.
🥈 LimboFilter AGPL-3.0, free, Velocity only. Limbo world, falling check, highly customisable CAPTCHA, client settings/brand checking. Pick this if you specifically want a visible CAPTCHA.
🥉 nAntiBot Free, from the developer behind nLogin. Ready to use with no configuration, with invalid-packet checking, an online CAPTCHA, optional cloud verification, and country filtering. The widest platform support of the three — Velocity, BungeeCord, Waterfall, Paper, Spigot, Folia, Mohist.

Tip

For most servers, Sonar is the right answer and you can stop reading here. It's free, open source, and verifies real client physics.

Note

Sonar 3.0 has moved to a separate distribution off GitHub — confirm its current licence and price before planning around it.

🖥️ Hardware, if you're filtering in-house

If you plan to absorb bot attacks on your own machine, the plugin is the easy part. The machine is not.

Warning

Minimum realistic spec: a dedicated bare-metal server on a 10 Gbit uplink. Not a VPS, not shared hardware.

Two numbers explain why:

  • 📡 Layer 7 floods are cheap to generate. Pushing 1 Gbit+ of valid-looking Minecraft handshakes takes very little on the attacker's side. A 1 Gbit uplink is saturated by an attack that costs pocket change to rent.
  • 🧵 Antibots top out around 10–20k connections/sec per thread. That's the ceiling for the good ones. Getting to a useful total means real core count and the memory bandwidth and NIC to keep those cores fed — which is exactly what a shared VPS doesn't give you, because you're also competing with neighbours for the same interrupts and PPS budget.

Add the CPU headroom your actual game servers need on top of that, since verification and gameplay are competing for the same box.

This is the part people skip. They install a good antibot on a €15 VPS, get taken down anyway, and conclude the antibot is bad — when the machine simply ran out of packets-per-second long before the detection logic had a chance to run.

🧨 The structural limit of in-proxy antibots

Every plugin-based antibot terminates the TCP connection on your own machine. The verification logic is excellent — but it only runs after your kernel accepted the connection, your proxy allocated a session, and your CPU parsed the handshake.

That works fine until the attack is large enough to saturate your uplink or exhaust your proxy's accept loop. Past that point the plugin never gets to run — the connections that would have failed verification already consumed the resource that mattered.

Important

This is the honest case for edge filtering: not that in-proxy verification is bad, but that it runs in the wrong place once you're past a certain scale. It's also why Bloom's antibot plugin exists mainly to signal their network layer rather than do the filtering itself.

In-proxy is fine when You can absorb the connection volume — true for most servers most of the time. Sonar is free and genuinely good; run it.
⬆️ You want it upstream when Attacks routinely exceed what one box can accept, or your host null-routes you before your antibot gets a vote.

Tip

These aren't either/or. A free in-proxy antibot and a free edge plan stack: the edge absorbs the volume your box can't, and the plugin verifies whatever reaches you. Since both have free options, running both costs nothing but a DNS change.


🎯 6. Anticheat

TL;DR — A different problem entirely: connections are legitimate, players are authenticated, traffic is normal. This is about behaviour after login.

There are three worth running. The gap between them and everything else is large.

Anticheat Model Notes
🥇 Grim Free, GPL-3.0, 1.7k⭐ Prediction-based: a movement simulation engine with a per-player world replica and latency compensation, catching cheats by simulating what should have happened rather than matching patterns. 1.8–26.2, Geyser-aware. A premium branch is planned, but the open-source 2.0 branch stays free. Default recommendation for most servers.
🥈 Polar Paid SaaS, ~$15–59/mo ML-assisted detection and physics simulation, emphasising mitigations (restricting reach, movement, damage) over outright bans, plus cheater tracking across instances. ⚠️ Most checks run in Polar's cloud — player packets leave your infrastructure. Lower CPU for you, but a third-party dependency in your combat path and a privacy point worth disclosing to players.
🥉 Vulcan Paid Packet-level detection, 1.8 → current with Folia support, used by 7,000+ servers. Silent by default — it observes and flags rather than blocking, so you can tune before you enforce. Largely plug-and-play with in-game configuration via /vulcan gui. The most common paid pick that runs entirely on your own hardware.

⚠️ Astro — the checks themselves are solid, but its reputation in the community is poor: there are unresolved allegations regarding the provenance of its code and documentation. Evaluate it on merits if you like, but know that adopting it may cost you goodwill with other network operators.

💸 Two things that will waste your money

Warning

Anticheat is not antibot. An anticheat inspects authenticated players' behaviour in your world. Ten thousand bots hammering your login sequence never reach the part of the pipeline where your anticheat lives.

Warning

Bedrock players cause false positives. Geyser players move through a translation layer, so their movement doesn't match Java physics exactly. Check Geyser compatibility before buying, or you'll ban your own players.


⚙️ 7. Operations

TL;DR — The layer that stops being about attackers and starts being about you.

👥 Staff and access

  • 🔐 2FA everywhere — game panel, host account, DNS registrar, Discord. Your DNS registrar is the highest-value target you own; whoever controls it controls where your players connect.
  • 🗝️ SSH keys, not passwords. Disable password auth and root login entirely. Add fail2ban.
  • 🎚️ Minimise op and admin. Most "we got griefed by a staff member" incidents are permission problems, not betrayals.
  • 🚪 Off-board properly. Rotate the forwarding secret, revoke panel access, rotate shared credentials. Departing staff keep working access far more often than anyone admits.

💾 Backups

Security includes recovery. The layers above reduce the chance of a bad day; backups determine whether a bad day is survivable.

3-2-1 — three copies, two media, one offsite. Offsite is the one that matters: a backup on the same box dies with the box, and a backup your panel can delete is a backup an intruder can delete.

Caution

Test a restore. An untested backup is a hypothesis, not a backup.

🔨 Ban management

LibertyBans (open source, proxy- and server-side) or LiteBans (paid, widely used, good UUID/IP handling). Either beats vanilla /ban, which doesn't survive a network of backends.

🙈 Hiding your plugin list

/pl, /version, /help, and command tab-completion all disclose what you're running, which tells an attacker which exploits to try. Restrict bukkit.command.plugins and bukkit.command.version via LuckPerms, and consider settings.tab-complete: -1 in spigot.yml.

Warning

This is obscurity, not security. It raises reconnaissance cost slightly. It does not protect a vulnerable plugin — and treating it as protection is how servers end up running a known-exploitable version because nobody thought it was reachable. Patch first, hide second.

💬 Chat and moderation

Chat filtering (ChatControl and similar) is a moderation tool, not a security control. Worth running for a public server, but it belongs in a different budget line — no chat filter has ever stopped an attack.


✅ Quick reference checklist

  • 🔐 online-mode=true, or a real auth plugin with modern password hashing
  • 👮 LuckPerms instead of op; op list empty in production
  • 🚫 RCON disabled or bound to localhost
  • ⚡ Velocity with modern forwarding; forwarding.secret out of git
  • 🔥 Backends on 127.0.0.1, or default-deny firewall allowing only the proxy
  • 🕵️ Origin IP not leaking (stale DNS, history sites, plugin callbacks)
  • 🌊 DDoS protection matched to the layer you're actually attacked at
  • 🔄 Software patched; Paper packet limiter configured
  • 🤖 Antibot appropriate to your scale (Sonar is free and enough for most)
  • 🎯 Anticheat with Geyser compatibility if you have Bedrock players
  • 🔑 2FA on panel, host, DNS registrar, Discord
  • 💾 Offsite backups, with a restore you have actually tested

❓ Frequently asked questions

Do I need DDoS protection for a small Minecraft server?

Yes. Small servers get attacked constantly — usually by one annoyed player renting a booter for a few dollars, not by anyone sophisticated. You're a target because you're easy, not because you're big.

The reason people skip it is cost, and free plans exist (including ours), so that reason no longer holds. Just do your backend firewall first — it's free, takes ten minutes, and closes a worse hole than the one you're worried about.

Is BungeeCord still safe to use?

Its legacy IP forwarding is not — it's spoofable by anyone who can reach your backends. If you stay on BungeeCord, use BungeeGuard and firewall your backends. Velocity with modern forwarding is the better answer.

Is a free antibot good enough?

For most servers, yes. Sonar is free, open source, and verifies real client physics. You outgrow it when attacks exceed what a single machine can accept connections for — not before.

What's the difference between antibot and anticheat?

Antibot filters fake connections before they become players. Anticheat inspects real players' behaviour after they're in your world. Neither substitutes for the other, and neither stops a volumetric DDoS.

My host says I have DDoS protection but my server still goes down. Why?

Almost always a layer mismatch: you have layer 3/4 filtering and you're being hit at layer 7 with join or handshake floods, which look like valid traffic. Or your host is null-routing your IP to protect their network — which resolves their problem by making you unreachable.

Does hiding my plugin list improve security?

Marginally, and only against low-effort reconnaissance. Do it, but patch your plugins first — it is not a substitute for updating.


🤝 Contributing

Corrections are welcome, particularly on pricing, licences, and maintenance status — this space moves fast and parts of this guide will rot. Open an issue or a PR with a source. See CONTRIBUTING.md.

Product recommendations are based on published capabilities and community consensus. Where a tool is maintained by this repository's authors, it is disclosed inline.

📄 Licence

CC BY 4.0 — copy it, adapt it, use it commercially. Just credit the source.


Found this useful? Star the repo so other server owners find it.

About

The complete Minecraft server security guide — authentication, Velocity backend hardening, DDoS protection, anticrash, antibot, and anticheat. Seven layers, real config, honest trade-offs.

Topics

Resources

Code of conduct

Contributing

Security policy

Stars

Watchers

Forks

Releases

Packages

Contributors