Grief protection and anti-cheat for a Minecraft server

The strongest anti-grief measure in Minecraft is the whitelist, and it costs nothing. A server with no strangers on it has no griefing problem. Everything below is for the servers that cannot do that - the public ones, the ones with a Discord full of people nobody has met - and it comes in three layers that do different jobs. Claims and regions stop damage happening. CoreProtect records what happened so you can undo it. Anti-cheat and anti-xray deal with players who are breaking the game rather than the build. Most servers install all three badly: a rollback plugin with no retention policy, an anti-cheat left on defaults that kicks people off elytra, and no backup at all. This post is about getting each layer to the point where it earns its memory.

Decide what you are defending against#

These are separate problems with separate answers, and conflating them is why people install eight plugins and are still surprised.

• A stranger destroys a build. Claims, regions, and a whitelist. Prevention.
• Somebody you trusted empties the community chest. No claim plugin will stop this, because they are allowed to be there. CoreProtect, and staff who know how to read it.
• A player uses X-ray to find diamonds. Not grief, and not something an anti-cheat catches. Paper's anti-xray, which works by not sending the truth.
• A player flies, reaches through walls, or mines at eight blocks a second. Anti-cheat, which is inference from packets and is never perfect.
• A player crashes the server with a crafted packet or a giant book. Paper's own limits, which are already in your config and mostly already on.
• The world file is gone. None of the above. Backups.

Work out which of those you actually have before you spend anything. A private SMP for twelve friends needs CoreProtect and backups and nothing else. A public survival server needs the lot.

CoreProtect: the log you will wish you had#

CoreProtect records block placements and breaks, container transactions, item drops and pickups, sign text, entity kills, chat, commands and login sessions, and it can put block changes back. It is free, it is the standard, and it is the first plugin to install on any server where strangers can build.

Drop the jar into plugins/, restart, and it creates its own database in plugins/CoreProtect/. On RE:NODE you upload that jar yourself through the file manager or SFTP - the Minecraft line runs Paper with no plugin installer, which also means no plugin is blocked.

The inspector is how most of it gets used. /co inspect toggles it on: left-click a block to see its history, right-click a block to see the history of the space next to the face you clicked, and right-click a chest to see every item that has gone in or out of it. Turn it off again with the same command, because it replaces normal interaction while it is on.

The parameters compose. u: is a user (or several, comma separated), t: is a time window written like t:2h30m or t:7d, r: is a radius in blocks, a: is an action (a:block, a:+block for placements only, a:-block for breaks only, a:container, a:item, a:click, a:kill, a:chat, a:command, a:session, a:sign), b: filters by block type and e: excludes one. #preview on a rollback is the habit to build: look at what it will change before you change it.

Two configuration decisions matter more than the rest. The first is radius. default-radius is what CoreProtect uses when you leave r: out, and max-radius caps how big one operation may be - set them deliberately, because a rollback with an accidentally enormous radius takes the server with it while it runs.

The second is disk. CoreProtect logs everything by default and the database grows steadily; on a busy public server it is hundreds of megabytes a month, and it is sharing your plan's disk with the world. Turn off the categories nobody ever looks up - liquid-tracking, leaves-decay, tree-grow, natural-break and block-movement are the noisy ones - and run /co purge t:30d on a schedule. Thirty days of history catches essentially every grief report that is ever going to be filed.

use-mysql: falsetable-prefix: co_default-radius: 10max-radius: 100liquid-tracking: falseleaves-decay: falsetree-grow: falsenatural-break: falseplayer-messages: trueplayer-commands: true

If the local database gets large enough to worry you, CoreProtect can write to an external database instead: set use-mysql: true and fill in the mysql-* keys. Games plans on RE:NODE include one database slot, created in the panel with a generated host, user and password. Point CoreProtect at it and watch the console on the next start to confirm it connected before you assume it did.

Permissions are worth splitting. coreprotect.inspect and coreprotect.lookup for every moderator; coreprotect.rollback, coreprotect.restore and coreprotect.purge for two or three people. A rollback run with the wrong parameters does as much damage as the grief did. Splitting that is what the group tree in the LuckPerms guide is for.

Claims and regions#

Two different shapes of protection, and most servers want both.

GriefPrevention is player-driven and free. Players claim land with a golden shovel, get a starting allowance of claim blocks and earn more per hour played, and manage access themselves with /trust, /containertrust, /accesstrust and /permissiontrust - the four levels being build, chests only, doors and buttons only, and the right to trust other people. /abandonclaim gives the blocks back. Both the starting allowance and the accrual rate are in plugins/GriefPrevention/config.yml, and the defaults are tuned for a busy public server, so a small SMP usually wants them raised. It also protects a new player's first chest automatically, which quietly prevents a lot of first-day theft.

WorldGuard is admin-driven, needs WorldEdit alongside it, and is how you protect spawn. Select a region with the wand, define it, and set flags:

$ /rg define spawn$ /rg flag spawn build deny$ /rg flag spawn pvp deny$ /rg flag spawn chest-access allow$ /rg flag spawn greeting Welcome to spawn$ /rg setpriority spawn 10

The flags you will use most are build, pvp, chest-access, use, tnt, creeper-explosion, fire-spread, mob-spawning, entry and exit. There is a special region called __global__ that applies to a whole world when nothing more specific does, which is how you make a world read-only by default and then open specific areas. Priority decides which of two overlapping regions wins.

Beyond those two: Towny builds towns and nations on top of claims, PlotSquared is the right answer for a creative server with a grid of plots, and Lands and GriefDefender are paid alternatives with more features and more configuration to get wrong. Start with GriefPrevention plus WorldGuard and add the rest only if you find a hole.

What claims do not do is worth stating plainly. They do not protect against someone you trusted. They do not stop a player standing outside a claim with a bucket of lava unless the plugin is configured for it. They do not stop mobs. And they do not stop a claim being abandoned and the land being taken. Claims reduce the number of incidents; CoreProtect is how you deal with the ones that happen anyway.

Anti-xray on Paper#

X-ray is not a server exploit. The server sends chunk data, the client decides what to draw, and a modified client simply draws stone as air. The only defence is to send data that is not true, and Paper has one built in.

It lives in config/paper-world-defaults.yml on current Paper builds, under anticheat.anti-xray, with per-world overrides in each world's paper-world.yml. Older builds keep it in paper.yml. It is off by default.

anticheat:  anti-xray:    enabled: true    engine-mode: 1    max-block-height: 64    update-radius: 2    lava-obscures: false    use-permission: false

engine-mode: 1 replaces the blocks on the hidden-blocks list with a single filler block before sending them, so ores simply are not there until you are close enough for the server to send the real data. Modes 2 and 3 take the other approach and scatter convincing fake ores through the stone instead, which makes X-ray actively misleading rather than merely useless. Mode 1 is cheaper in CPU and bandwidth; the higher modes cost more of both and are more thorough. Paper's own documentation describes the current behaviour of each mode for your exact build, and it is worth reading before you pick, because the modes have been revised.

max-block-height is the Y level above which no obfuscation happens - the default of 64 covers the depths where ores actually are, including everything below zero in modern worlds, and leaves the surface alone so the cost is not paid for chunks nobody is mining. use-permission: true lets you exempt staff with the paper.antixray.bypass permission, which is handy when a moderator is trying to find an actual X-rayer.

Two honest limits. Anti-xray does not stop freecam, does not stop a player who has simply memorised the Y levels, and does nothing about entity-based cheats. And it can interfere with legitimate client mods - cave-mode minimaps in particular will show nonsense, because you are deliberately feeding them nonsense. The CPU cost is real but small next to view distance and entity counts; if the server is already struggling, the settings in Paper optimisation matter more.

Anti-cheat: what it catches and what it cannot#

An anti-cheat plugin sees packets and nothing else. It never sees the client. Everything it reports is an inference, and the quality of an anti-cheat is entirely the quality of those inferences.

Reliably detectable: flight, speed, no-fall damage, step and jump modifications, scaffold and tower placement, nuker and fast-break, inventory actions while the inventory should be closed, and the more obvious auto-clicker patterns. These all leave traces in movement and timing that cannot be hidden without also not working.

Not reliably detectable: X-ray (that is what anti-xray is for), freecam, aim assist that stays inside human limits, macro use, and anything that only changes rendering. Reach checks are genuinely hard because latency and lag compensation make a legitimate hit at 200 ms look like an illegitimate one at 20 ms, which is why they produce most of the false positives on an international server.

For choices: GrimAC is the free, open-source, prediction-based option and is strong on the movement side - check its current build and licensing before you deploy it, because both have changed. The paid options - Vulcan, Matrix, Themis, Polar, Intave and others - differ mostly in how much tuning they need and how responsive their support is. NoCheatPlus still exists and is free but shows its age.

Whichever you pick, three rules:

1. Run one. Two anti-cheats double every check, disagree with each other, and produce a stream of contradictory flags. It is the most common self-inflicted wound in this category.
2. Start in alert-only mode. Run for a week with no punishments, watch what it flags, and find out what your own server's elytra routes, ice roads, boat tracks and piston contraptions do to it. Then turn on punishments for the checks you trust.
3. Exempt the players who are not playing normally. Bedrock players arriving through Geyser have genuinely different movement, and clients on older protocol versions through ViaVersion do too. Every anti-cheat has a bypass permission; use it rather than loosening a check for everybody.

Anti-cheat costs CPU, and prediction-based ones cost the most, because they are simulating player physics on the server for every player. That is a fair trade on a PvP server and a poor one on a co-operative SMP with a whitelist.

Hardening that costs nothing#

Before any of the plugins, there are switches you already own.

• enable-command-block=false in server.properties. A command block is a level 2 command executor that runs without a player attached. Unless you are building with them, leave them off.
• white-list=true with enforce-whitelist=true, which also removes anyone already online who is not on the list when it reloads.
• spawn-protection is a radius in blocks around the world spawn where non-operators cannot build. The default of 16 is small; set it to cover your spawn build, or use a WorldGuard region, which is more precise.
• paper-global.yml holds packet-limiter, which rate-limits incoming packets and drops connections that flood, and spam-limiter, which caps tab-completion and recipe-book requests. Both are on with sane defaults and are the reason most crash exploits bounce off a Paper server. item-validation in the same file limits book page count, title and author lengths, which is the specific defence against the classic oversized-book crash.
• De-op everybody and use permissions. Operator status bypasses plugin permission checks, so every negation you have carefully configured is void for an op.
• Install plugins only from their official source. A plugin is arbitrary code running with your server's full privileges, and the single most damaging "grief" incidents are not griefing at all - they are a backdoored jar from a reuploaded download. Keeping a modded server clean is the longer version.

On the panel side: turn on two-factor authentication, and give staff subusers with roles rather than your account password. Roles carry granular permissions - console only, files only, no billing - and every server has its own activity log and its own SFTP credentials. That is the difference between a moderator who can restart the server and a moderator who can delete it. Subusers and least privilege covers how to split it.

Staff, permissions and the paper trail#

A rollback tool in the hands of somebody who has never used it is a second incident waiting to happen.

Grief handling is a process, not a plugin. The version that works is short: any moderator can inspect and look up; two people can roll back; every rollback is announced in a staff channel with the parameters used; and the logAdminCommands gamerule stays true so admin commands are in the server log. CoreProtect's own a:command lookup covers the rest, and the panel keeps a per-server activity log of who did what in the panel itself.

Keep the logs long enough to be useful. Thirty days of CoreProtect and whatever your log rotation gives you is the usual answer; what to keep and what to throw away is in logs worth keeping. And write the ban appeal process down before you need it, because the moment you need it is the moment you are angry.

Backups are the only real undo#

CoreProtect is not a backup, and treating it as one is the mistake that ends servers.

It rolls back block changes it logged. It does not rescue a corrupted region file, a world folder deleted by accident, a plugin that wrote nonsense into its own data, or a chunk that never came back after a bad update. Mass-edit tools are a particular blind spot: WorldEdit operations bypass the normal block events, so whether a //set is logged at all depends on your versions and integrations. Test that on your own server before you rely on it.

On RE:NODE, backup slots are on every plan, backups can be taken on demand or on a schedule, they are stored off the machine they protect, they can be downloaded, and one can be locked so rotation does not delete it. Restoring is a button. The one thing to know is that deleting a server deletes its backups, locked ones included, so a download before a cancellation is not optional. Backups that actually restore and testing a restore before you need it cover the habits.

FAQ#

Is CoreProtect enough on its own?

For a whitelisted server with friends, yes. For a public server, no: it tells you what happened and puts blocks back, but it does nothing to stop the next person. Pair it with a claim plugin so that most incidents never need a rollback.

How far back can I roll a grief incident?

As far as your CoreProtect retention goes, and no further. If you purge at 30 days, a report from six weeks ago cannot be actioned. Rolling back a very long window is also slow and will affect everything that user legitimately built in it, so filter by radius and preview first.

Does anti-xray hurt performance?

Yes, measurably but not dramatically. Mode 1 is the cheap one. The higher modes cost more CPU when chunks are sent and more bandwidth, because there is more data that does not compress well. On a server already at its CPU limit, fix that first.

Can an anti-cheat ban someone automatically?

They all can, and it is usually worth leaving off for the first weeks. Automatic bans on a freshly installed anti-cheat with untuned checks will ban real players, and the ones you lose that way do not come back to appeal. Alert first, punish later.

What about players who grief by building rather than breaking?

Obscene builds, lava casts, giant cobblestone monuments - CoreProtect logs placements too, so /co rollback u:Name t:2h r:100 removes them as easily as it restores broken ones. That is the same command with the same care required, and #preview is still your friend.