By PistonmasterUpdated 5 min read

Testing Anti-Bot Systems - Protecting Your Minecraft Server

How to test and configure anti-bot protection, from EpicGuard to iptables, with strategies to defend against bot attacks

minecraftsecurityanti-botepicguardddos-protectionserver-security

Defending Your Minecraft Server Against Bots

Bot attacks range from dumb connection floods to proxy-rotated campaigns that'll drain your bandwidth, crash your server, and drive away the players who actually matter. This guide covers how to build layered defenses and how to test that they hold up under pressure.

This guide is for server admins testing their own infrastructure. Don't run bot attacks or load tests on servers you don't own or have explicit permission to test. Unauthorized attacks are illegal and unethical.

Common Attack Types

  • Connection flooding: Hundreds or thousands of simultaneous connection attempts overwhelm the server's handler before authentication even begins.
  • Join/leave spam: Bots join, immediately disconnect, and reconnect, consuming resources during authentication and world loading.
  • Proxy-rotated attacks: Traffic routed through thousands of proxies makes IP-based blocking useless.
  • Protocol-level attacks: Malformed or excessive packets exploit server vulnerabilities or burn CPU cycles.

Defense in Layers

There's no silver bullet here. You want multiple layers so that when attackers get past one, they still hit another.

LayerWhereToolsCatches
Network/FirewallBefore Minecraftiptables, nftables, UFWRaw connection floods, IP-based attacks
ProxyBungeeCord/VelocityProxy anti-bot pluginsDistributed attacks, early filtering
ServerPaper/SpigotEpicGuard, BotSentryBehavioral analysis, challenge-response
GamePlugin-levelAuthMe, custom systemsIn-game bot behavior, AFK farming

Network-Level Protection

Your first line of defense should block attacks before they ever touch your Minecraft process.

iptables

Rate-limit new connections and use ipset for scalable blacklisting. See the iptables documentation for more details.

# Allow established connections
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Rate limit new connections to port 25565 (3 per minute per IP)
sudo iptables -A INPUT -p tcp --dport 25565 -m state --state NEW \
  -m recent --set
sudo iptables -A INPUT -p tcp --dport 25565 -m state --state NEW \
  -m recent --update --seconds 60 --hitcount 4 -j DROP
sudo iptables -A INPUT -p tcp --dport 25565 -j ACCEPT

# SYN flood protection
sudo sysctl -w net.ipv4.tcp_syncookies=1
sudo iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
sudo iptables -A INPUT -p tcp --syn -j DROP

For managing large blacklists efficiently, use ipset:

sudo ipset create minecraft-blacklist hash:ip hashsize 4096 maxelem 100000
sudo ipset add minecraft-blacklist 1.2.3.4
sudo iptables -I INPUT -p tcp --dport 25565 \
  -m set --match-set minecraft-blacklist src -j DROP
# Make rules persistent (Debian/Ubuntu)
sudo apt-get install iptables-persistent
sudo netfilter-persistent save

nftables

The modern replacement for iptables with cleaner syntax and better performance.

sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0 \; }

# Allow established connections
sudo nft add rule inet filter input ct state established,related accept

# Rate limit new connections to port 25565
sudo nft add rule inet filter input tcp dport 25565 ct state new \
  limit rate 3/minute accept

# Drop the rest
sudo nft add rule inet filter input tcp dport 25565 drop
# Save ruleset (loads automatically on boot with nftables service enabled)
sudo nft list ruleset > /etc/nftables.conf

UFW (Uncomplicated Firewall)

A simpler frontend for iptables, good for basic setups.

sudo ufw allow 25565/tcp
sudo ufw limit 25565/tcp
sudo ufw enable

UFW's rate limiting is less flexible than iptables/nftables. For advanced protection, use one of the other options.

Server-Level Anti-Bot Plugins

Network filtering stops crude attacks, but sophisticated bots need behavioral analysis at the server level.

EpicGuard

EpicGuard is a popular open-source anti-bot plugin (discontinued as of 2025, but still widely used and forked). It's a great pick for smaller servers -- straightforward to configure, low overhead, and it gets the job done without a lot of fuss. Consult the official documentation for the latest configuration options.

plugins/EpicGuard/config.yml
check-mode:
  # ALWAYS / ATTACK / NEVER
  server-list-check: ATTACK    # Require ping before join
  reconnect-check: ALWAYS      # Force re-authentication
  settings-check: ATTACK       # Validate client settings packet
  proxy-check: ATTACK          # Check for VPN/proxy usage
  nickname-check: ATTACK       # Validate nickname patterns

auto-whitelist:
  enabled: true
  time: 300  # Seconds online before auto-whitelisting

attack:
  connection-threshold: 8      # Connections/sec to trigger attack mode
  decay-time: 120              # Seconds to stay in attack mode
  deny-join: false             # Block all new joins during attacks
SettingRecommendedWhy
server-list-checkATTACKBots often skip the server list ping
reconnect-checkALWAYSStops simple join spam
connection-threshold5-10Lower = more sensitive, higher risk of false positives
auto-whitelisttrueReduces overhead for known players

BotSentry

If you're running a larger server or dealing with more persistent attacks, BotSentry is worth the investment. It has more advanced challenge-response checks than EpicGuard and handles high-volume attacks more gracefully. The detection logic is smarter out of the box, and it's actively maintained.

UltimateAntiBot

Another solid option with iptables integration. It adds detected bot IPs straight to your firewall, blocking them at the kernel level. This is nice because it means repeat offenders don't even make it to your Java process.

config.yml
settings:
  use-iptables: true
  blacklist-command: "ipset add minecraft-blacklist %ip%"
  unblacklist-command: "ipset del minecraft-blacklist %ip%"

checks:
  connect-speed:
    enabled: true
    max-per-second: 4
  ping-check:
    enabled: true
    required-before-join: true

verification:
  enabled: true
  method: CHAT
  chat-verification:
    code-length: 6
    timeout-seconds: 60

DDoS Protection Services

Firewall rules and anti-bot plugins handle application-level attacks -- bot joins, connection spam, protocol abuse. But a volumetric DDoS attack saturates your network link before packets even reach your server. That's a completely different problem, and it requires a TCP reverse proxy that absorbs attack traffic at the edge.

Some DDoS protection providers like NeoProtect and CosmicGuard also bundle their own bot protection layer that stacks on top of whatever server-side plugins you're running. That's a real advantage -- you get network-level filtering and application-aware bot detection before traffic ever hits your box.

For a full walkthrough of how these services work and how to make sure your real IP isn't leaking, see our DDoS protection guide.

Testing Your Defenses

Configuring anti-bot plugins without testing them is wishful thinking. You need to confirm that your setup actually blocks attacks while letting legitimate players through.

Setting Up a Test Environment

Never test against production. Clone your setup to an isolated server:

cp -r /path/to/prod-server /path/to/test-server

# Change port in server.properties to avoid conflicts
# server-port=25566

cd /path/to/test-server
java -Xms2G -Xmx2G -jar paper.jar nogui

What to Test

Start with legitimate traffic. Join with a real client. Have a few friends join within 30 seconds. Disconnect and reconnect a bunch of times. Everything should work without delays or false blocks.

Then move to simulated attacks. Start small -- 10 bots over 60 seconds -- and escalate from there. 50 bots in 10 seconds, sustained reconnect spam over 5 minutes. Watch which checks trigger, how fast attack mode kicks in, and whether your TPS tanks.

Don't skip false positive testing either. Multiple players behind the same router, players on VPNs, players with flaky connections that cause rapid reconnects. If any of those get blocked, you need to loosen your thresholds or add whitelist exceptions.

Using SoulFire for Testing

SoulFire is built on Fabric and runs actual Minecraft client code, which makes it ideal for anti-bot testing. Your protection can't tell SoulFire apart from a real client by checking for protocol quirks. That's the whole point -- your tests should look like real attacks.

Useful SoulFire plugins for testing:

  • server-list-bypass: Tests whether your server-list check actually catches bots that skip the ping step
  • anti-afk: Generates random movement to test behavioral analysis
  • auto-chat-message: Tests chat-based challenge-response systems
  • client-settings: Sends proper client configuration packets

Interpreting Results

After running tests, look at your plugin's statistics.

Most bots getting through? You need stricter checks or lower thresholds. Most blocked but some slipping through? Figure out which specific checks failed and tighten those. And if nearly all bots are blocked, start worrying about false positives -- make sure real players behind VPNs or shared IPs aren't getting caught in the crossfire.

You're not aiming for a 100% block rate. That always means blocking real players too. The goal is reducing attacks to a level your server can absorb while real players still get in without friction.

Monitoring

Log Analysis

Parse your server logs to spot attack patterns early:

check-bot-attack.sh
#!/bin/bash
THRESHOLD=50
LOG="/path/to/minecraft/logs/latest.log"

MAX_CONNECTS=$(grep "logged in" "$LOG" | grep "$(date +%Y-%m-%d)" | \
  awk '{print $4}' | sort | uniq -c | sort -rn | head -1 | awk '{print $1}')

if [ "$MAX_CONNECTS" -gt "$THRESHOLD" ]; then
  curl -X POST "https://discord.com/api/webhooks/YOUR_WEBHOOK" \
    -H "Content-Type: application/json" \
    -d "{\"content\": \"Bot attack detected: $MAX_CONNECTS connections from single IP\"}"
fi
# Run every 5 minutes via cron
*/5 * * * * /usr/local/bin/check-bot-attack.sh

Track these metrics over time: blocks per hour, attack frequency, detection speed, and TPS during attacks versus baseline. Also keep an eye on how often you're manually whitelisting false positives -- if that number keeps growing, it's time to dial back your thresholds.

The best anti-bot setup is one you've actually tested, not one you copied from a guide and hoped for the best. Clone your server, throw SoulFire at it, tune your configs, and re-test after every change. That's it.