Rate limiting dla Minecrafta: ograniczanie szkodliwych polaczen

Atak botow na serwer Minecraft wyglada prosto: setki polaczen na sekunde z roznych IP. Kazdy bot nawiazuje polaczenie TCP, wysyla handshake, czasem nawet przechodzi login. Serwer marnuje zasoby na kazde polaczenie i w ktoryms momencie przestaje odpowiadac prawdziwym graczom.

Rate limiting rozwiazuje problem wprost: jesli z jednego IP leci wiecej niz N polaczen na sekunde, nadmiarowe sa odrzucane. Prosto, grubo, skutecznie. Ale diabel tkwi w szczegolach. Zle ustawiony rate limiter zablokuje legalnych graczy, a za luzny nie zatrzyma ataku.

W tym artykule omawiam wszystkie warstwy rate limitingu dla Minecrafta: od iptables do pluginow. Z konkretnymi configami i wyjasnieniem, dlaczego takie wlasnie wartosci.

Co to jest rate limiting

Rate limiting to mechanizm ograniczania czestotliwosci zadan. Zamiast decydowac, czy zadanie jest dobre czy zle (to zadanie firewalla albo antybota), rate limiter po prostu liczy: ile zadan przyszlo z tego zrodla w jednostce czasu. Przekroczyles prog - dostajesz odmowe.

Dziala, bo normalny gracz laczy sie z serwerem raz. Moze dwa, jesli wyleci i wroci. Dziesiec razy na minute - juz podejrzane. Sto razy na sekunde - na pewno bot.

Rate limiting stosuje sie na roznych poziomach:

• Warstwa sieci (L3/L4) - iptables, nftables. Liczy polaczenia TCP i pakiety. Najszybsze, dziala w jadrze.
• Warstwa proxy (L7) - Velocity, BungeeCord, Waterfall. Liczy polaczenia Minecraft. Rozumie protokol, odroznia handshake od loginu.
• Warstwa aplikacji - pluginy na samym serwerze. Najbardziej elastyczne, ale najbardziej zasobozerne.

Najlepsza ochrona to kombinacja wszystkich trzech. Kazda odcina swoj typ ataku.

server.properties: wbudowany rate-limit

W server.properties jest parametr rate-limit, o ktorym malo kto wie:

# server.properties
rate-limit=0

Domyslnie 0 (wylaczony). Jesli ustawisz wartosc, serwer bedzie rozlaczal klientow wysylajacych wiecej pakietow na sekunde niz podany limit.

# Rozsadna wartosc dla wiekszosci serwerow
rate-limit=500

500 pakietow na sekunde to duzo dla zwyklego gracza. Normalna gra generuje 20-50 pakietow na sekunde (ruch, interakcje, czat). Nawet aktywne PvP rzadko przekracza 200. Ale boty robiace packet spam latwo wyrabiaja tysiace.

Ograniczenia

Ten parametr dziala juz po nawiazaniu polaczenia. Bot, ktory po prostu spamuje polaczeniami bez wysylania pakietow, go nie ruszy. Do ochrony przed connection flood potrzebne sa inne narzedzia.

Poza tym na Paperze ten parametr jest de facto zastapiony wbudowanym packet limiterem:

# paper-global.yml
packet-limiter:
  kick-message: '<red><lang:disconnect.exceeded_packet_rate>'
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0

Implementacja Papera jest bardziej elastyczna: mozna ustawic limity dla konkretnych typow pakietow. Spam tab-complete? Ogranicz ServerboundCommandSuggestionPacket do 15 na sekunde. Podejrzanie duzo pakietow ruchu? ServerboundMovePlayerPacket do 50 na sekunde.

iptables: rate limiting w jadrze

iptables to najpotezniejsze narzedzie do rate limitingu na Linuksie. Dziala w jadrze, nie marnuje zasobow userspace, obsluguje pakiety zanim dotra do procesu Java.

Jesli nie znasz podstaw iptables, przeczytaj nasz poradnik konfiguracji iptables dla Minecrafta.

connlimit: limit jednoczesnych polaczen

Modul connlimit ogranicza liczbe jednoczesnych polaczen TCP z jednego IP.

# Maksimum 3 jednoczesne polaczenia na port 25565 z jednego IP
iptables -A INPUT -p tcp --dport 25565 \
  -m connlimit --connlimit-above 3 \
  -j DROP

Czemu 3? Bo gracz zwykle ma jedno aktywne polaczenie. Dwa - jesli sie przelacza (stare jeszcze nie zamkniete). Trzy - zapas na wszelki wypadek. Atak botow z jednego IP tworzy dziesiatki i setki polaczen, a connlimit utnie wszystko powyzej progu.

Dla sieci BungeeCord/Velocity, gdzie proxy laczy sie z serwerami backend, trzeba whitelistowac IP proxy:

# Przepusc proxy bez limitow
iptables -A INPUT -p tcp --dport 25565 -s 10.0.0.1 -j ACCEPT

# Ogranicz reszte
iptables -A INPUT -p tcp --dport 25565 \
  -m connlimit --connlimit-above 3 \
  -j DROP

hashlimit: limit predkosci polaczen

connlimit ogranicza jednoczesne polaczenia, ale nie predkosc tworzenia nowych. Bot moze tworzyc i zamykac polaczenia szybciej, niz connlimit je liczy. Do tego potrzebny jest hashlimit.

# Maksimum 10 nowych polaczen na sekunde z jednego IP
iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit \
  --hashlimit-name minecraft \
  --hashlimit-above 10/sec \
  --hashlimit-burst 20 \
  --hashlimit-mode srcip \
  --hashlimit-htable-expire 30000 \
  -j DROP

Parametry:

• --syn - liczymy tylko pakiety SYN (poczatek nowego polaczenia)
• --hashlimit-above 10/sec - prog: ponad 10 polaczen na sekunde
• --hashlimit-burst 20 - pozwol na wzrost do 20 (dla legalnego reconnectu)
• --hashlimit-mode srcip - licz osobno dla kazdego IP
• --hashlimit-htable-expire 30000 - czysc wpisy po 30 sekundach nieaktywnosci

10 polaczen na sekunde to hojny limit dla jednego gracza. Nawet przy slabym polaczeniu, gdy klient ciagle sie przelacza, nie osiagnie tego progu. Ale bot generujacy setki polaczen zostanie zatrzymany.

recent: prosty rate limiter

Modul recent to prostsza alternatywa dla hashlimit. Zapamietuje adresy IP i liczy trafienia.

# Tworzymy lancuch do rate limitingu
iptables -N MC_RATELIMIT

# Oznaczamy kazde nowe polaczenie
iptables -A MC_RATELIMIT -m recent --name mc_conn --set

# Jesli wiecej niz 15 w 60 sekund - blokujemy
iptables -A MC_RATELIMIT -m recent --name mc_conn \
  --rcheck --seconds 60 --hitcount 15 \
  -j DROP

# Inaczej przepuszczamy
iptables -A MC_RATELIMIT -j ACCEPT

# Kierujemy nowe polaczenia do naszego lancucha
iptables -A INPUT -p tcp --dport 25565 --syn \
  -j MC_RATELIMIT

recent jest latwiejszy do skonfigurowania, ale mniej precyzyjny niz hashlimit. Dla malych serwerow z ruchem do 100 graczy wystarczy.

Kombinacja regul

W praktyce uzywa sie kilku regul razem:

# 1. Przepusc localhost i zaufane IP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 -s 10.0.0.1 -j ACCEPT

# 2. Przepusc istniejace polaczenia
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# 3. Ogranicz jednoczesne polaczenia
iptables -A INPUT -p tcp --dport 25565 \
  -m connlimit --connlimit-above 3 -j DROP

# 4. Ogranicz predkosc nowych polaczen
iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit \
  --hashlimit-name minecraft \
  --hashlimit-above 10/sec \
  --hashlimit-burst 20 \
  --hashlimit-mode srcip \
  -j DROP

# 5. Przyjmij pozostale
iptables -A INPUT -p tcp --dport 25565 -j ACCEPT

Kolejnosc jest wazna. Najpierw przepuszczamy zaufanych, potem filtrujemy po liczbie, potem po predkosci. Kazda regula odcina swoja warstwe smieci.

Velocity: connection throttle

Jesli uzywasz Velocity jako proxy (a powinienes, jesli masz siec serwerow), ma wbudowany mechanizm ograniczania polaczen.

# velocity.toml
[advanced]
connection-timeout = 5000
login-ratelimit = 3000

login-ratelimit to minimalny czas (w milisekundach) miedzy probami polaczenia z jednego IP. Wartosc 3000 oznacza: maksimum jedno polaczenie co 3 sekundy z jednego IP.

Dla serwerow z duza liczba graczy za NATem (szkoly, kafejki internetowe) wartosc mozna podniesc do 1000 (jedno polaczenie na sekunde). Dla malych serwerow 3000-5000 to dobry balans.

BungeeCord connection_throttle

BungeeCord ma analogiczne ustawienie:

# config.yml (BungeeCord)
connection_throttle: 4000
connection_throttle_limit: 3

connection_throttle: 4000 to minimalny odstep miedzy polaczeniami (4 sekundy). connection_throttle_limit: 3 - po trzech naruszeniach IP jest blokowane.

Waterfall

Waterfall (fork BungeeCord od PaperMC) uzywa tych samych ustawien plus dodatkowych:

# waterfall.yml
connection_throttle: 4000
throttle: 4000

Rekomendacja: jesli siedzisz na BungeeCord, przejdz na Velocity. Jest szybszy, bezpieczniejszy i lepiej obsluguje rate limiting. Wiecej w naszym artykule Velocity vs BungeeCord.

Token bucket: algorytm, ktory za tym stoi

Wiekszosc rate limiterow uzywa algorytmu token bucket (koszyk z zetonami). Idea jest prosta:

1. Kazdy IP ma "koszyk" z zetonami
2. Kazde zadanie zabiera jeden zeton
3. Zetony sa dodawane do koszyka ze stala predkoscia (np. 10 na sekunde)
4. Koszyk ma maksymalna pojemnosc (np. 50 zetonow)
5. Jesli nie ma zetonow, zadanie zostaje odrzucone

Czemu lepsze niz prosty licznik "N zadan na sekunde"? Bo token bucket obsluguje skoki. Jesli gracz sie nie laczyl przez 5 sekund, koszyk jest pelny (50 zetonow). Moze szybko przelaczyc sie 10 razy z rzedu i wszystkie polaczenia przejda. A bot, ktory ciagle generuje ruch, szybko oprozni swoj koszyk.

Przyklad w pseudokodzie:

bucket_size = 50        # maksimum zetonow
refill_rate = 10        # zetonow na sekunde
tokens = bucket_size    # startujemy z pelnym koszykiem

function handle_request(ip):
    bucket = get_bucket(ip)
    bucket.refill()     # dodaj zetony za miniony czas

    if bucket.tokens > 0:
        bucket.tokens -= 1
        return ACCEPT
    else:
        return DROP

hashlimit w iptables dziala podobnie. --hashlimit-burst to rozmiar koszyka, --hashlimit-above - predkosc uzupelniania (odwrocona: to prog, powyzej ktorego zaczyna sie blokowanie).

Pluginy do rate limitingu

LimboFilter

LimboFilter to plugin dla Velocity, ktory tworzy "przedsionek" przed glownym serwerem. Nowe polaczenia trafiaja na lekki serwer limbo, gdzie przechodza weryfikacje (captcha, falling check), i dopiero potem sa przekierowywane na glowny serwer.

Rate limiting dziala tu na poziomie protokolu Minecraft. LimboFilter liczy polaczenia, sledzi powtorne proby i moze blokowac IP probujace za czesto sie laczyc.

Wiecej o ochronie captcha w naszym artykule o capchy dla Minecrafta.

BotSentry

BotSentry to plugin dla BungeeCord/Velocity specjalizujacy sie w ochronie przed botami. Zawiera rate limiting jako jedna z funkcji:

• Limit polaczen na sekunde (globalnie i per-IP)
• Automatyczna blokada IP przy przekroczeniu progu
• Integracja z zewnetrznymi blocklistami
• Konfigurowalne akcje (kick, tempban, captcha)

EPL (ExtraProxyLimiter)

Lekka alternatywa dla Velocity:

• Liczy polaczenia per-IP i globalnie
• Konfigurowalne progi dla roznych akcji
• Minimalny wplyw na wydajnosc

Precyzyjne strojenie: jak nie zablokowac swoich

Rate limiting to balans. Za ostre limity blokuja legalnych graczy. Za luzne sa bezuzyteczne. Kilka sytuacji, gdzie potrzebna jest specjalna konfiguracja.

Otwarcie serwera

Gdy oglaszasz otwarcie nowego serwera i przychodzi 500 graczy jednoczesnie, standardowy rate limiter moze zablokowac polowe z nich. Rozwiazania:

1. Tymczasowo podniesc limity. Przed otwarciem zwieksz hashlimit-burst i hashlimit-above. Po stabilizacji cofnij.
2. Uzyc kolejki. Velocity Limbo albo LimboFilter moze stworzyc kolejke, przepuszczajac graczy porcjami.
3. Stopniowy start. Najpierw zapros przez invite, potem otworz dla wszystkich.

NAT i wspolne IP

W szkolach, akademikach i kafejkach kilku graczy siedzi za jednym IP. connlimit z progiem 3 zablokuje czwartego gracza. Rozwiazania:

• Podnies connlimit do 10-15 dla takich przypadkow
• Uzyj whitelisty dla znanych IP instytucji
• Bardziej opieraj sie na hashlimit (predkosc) niz connlimit (liczba)

Gracze na internecie mobilnym

Internet mobilny czesto zmienia IP, a gracz moze trafic na IP, z ktorego niedawno byl bot. Jesli uzywasz dlugich blokad (30 minut i wiecej), gracz mobilny moze okazac sie zablokowany "w spadku".

Rozwiazanie: uzywaj krotkich TTL dla blokad. 60-120 sekund wystarczy, zeby zatrzymac aktywny atak, ale nie zablokowac przypadkowego gracza mobilnego.

Whitelisting: zaufane IP

Niektore IP nigdy nie powinny trafiac pod rate limiting:

# Serwery proxy sieci
iptables -I INPUT -p tcp --dport 25565 -s 10.0.0.1 -j ACCEPT
iptables -I INPUT -p tcp --dport 25565 -s 10.0.0.2 -j ACCEPT

# Monitoring (uptime check)
iptables -I INPUT -p tcp --dport 25565 -s 1.2.3.4 -j ACCEPT

Reguly z -I (insert) dodawane sa na poczatek lancucha i obslugiwane przed regulami rate limitingu. To krytyczne: jesli twoj serwer proxy wpadnie pod hashlimit, wszyscy gracze strace polaczenie.

W Velocity/BungeeCord whitelisting zwykle niepotrzebny, bo rate limiting stosowany jest do polaczen zewnetrznych, a serwery backend komunikuja sie przez siec wewnetrzna.

Rate limiting warstwami

Najbardziej skuteczna strategia to rate limiting na kazdym poziomie z rozna logika:

Warstwa sieci (iptables)

Co ograniczac: pakiety TCP SYN, jednoczesne polaczenia.

Cel: odciac grubiansko connection flood, zanim pakiety dotra do Javy.

# SYN flood protection
iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit --hashlimit-above 10/sec \
  --hashlimit-burst 20 --hashlimit-name mc_syn \
  --hashlimit-mode srcip -j DROP

Warstwa proxy (Velocity)

Co ograniczac: proby loginu Minecraft, powtorne polaczenia.

Cel: odciac boty, ktore przeszly handshake TCP, ale nie sa prawdziwymi graczami.

# velocity.toml
[advanced]
login-ratelimit = 3000

Warstwa aplikacji (pluginy)

Co ograniczac: akcje w grze (komendy, czat, interakcje).

Cel: odciac boty, ktore przeszly login, ale zachowuja sie anomalicznie.

# paper-global.yml
packet-limiter:
  limits:
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0

Kazda warstwa lapie swoj typ zagrozenia. iptables zatrzymuje SYN flood. Velocity zatrzymuje connection spam. Pluginy zatrzymuja packet abuse.

Rate limiting a ochrona DDoS

Rate limiting to czesc ochrony DDoS, ale nie cala. Przeciwko powaznemu atakowi DDoS (dziesiatki gigabitow ruchu) rate limiting na serwerze jest bezuzyteczny: lacze zapchane, pakiety nie dochodza.

Do powaznej ochrony potrzebna jest filtracja na poziomie sieci przed twoim serwerem. MineGuard filtruje ruch na poziomie sieci, odrzucajac smieciowe pakiety zanim dotra do twojego serwera. Rate limiting na serwerze dziala jako druga linia: lapie to, co przeszlo przez filtr sieciowy.

Razem tworza ochrone warstwowa:

1. Filtr DDoS (MineGuard) - zatrzymuje ataki wolumenowe na poziomie sieci
2. Rate limiting iptables - ogranicza predkosc polaczen, ktore przeszly filtr
3. Rate limiting proxy - filtruje na poziomie protokolu Minecraft
4. Rate limiting pluginow - chroni przed naduzyciami w grze

Wiecej o atakach botow i metodach ochrony w naszym artykule o atakach botow na Minecraft.

Monitoring skutecznosci

Rate limiting jest bezuzyteczny, jesli nie wiesz, czy dziala. Co warto monitorowac:

Liczniki iptables

# Pokaz liczniki regul
iptables -L -n -v | grep hashlimit

Kazda regula iptables ma licznik pakietow i bajtow. Jesli twoja regula hashlimit pokazuje tysiace dropow, to dziala. Jesli zero - albo atakow nie ma, albo regula nie dziala (sprawdz kolejnosc regul).

Logowanie zablokowanych

# Loguj przed dropem (ogranicz logowanie, zeby nie zapchac dysku)
iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit --hashlimit-above 10/sec \
  --hashlimit-burst 20 --hashlimit-name mc_syn \
  --hashlimit-mode srcip \
  -m limit --limit 5/min \
  -j LOG --log-prefix "MC_RATELIMIT: "

iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit --hashlimit-above 10/sec \
  --hashlimit-burst 20 --hashlimit-name mc_syn \
  --hashlimit-mode srcip \
  -j DROP

Zwroc uwage na -m limit --limit 5/min w regule LOG. Bez tego przy aktywnym ataku samo logowanie moze stac sie problemem: tysiace wpisow na sekunde zabija dysk i obciaza CPU.

Statystyki Velocity

Velocity loguje throttlowane polaczenia do stdout:

[INFO] [ratelimiter] Connection from 1.2.3.4 throttled

Parsuj te logi do monitoringu. Jesli widzisz masowy throttle z roznych IP - to atak botow. Jesli z jednego IP - jeden uparty bot albo gracz z problemem polaczenia.

Praktyczna sciaga

Minimalna konfiguracja rate limitingu dla serwera Minecraft:

iptables (na serwerze):

# Whitelista dla proxy (jesli jest)
iptables -I INPUT -p tcp --dport 25565 -s YOUR_PROXY_IP -j ACCEPT

# Limit jednoczesnych polaczen
iptables -A INPUT -p tcp --dport 25565 \
  -m connlimit --connlimit-above 5 -j DROP

# Limit predkosci nowych polaczen
iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit --hashlimit-name mc \
  --hashlimit-above 10/sec --hashlimit-burst 25 \
  --hashlimit-mode srcip -j DROP

Velocity:

[advanced]
login-ratelimit = 3000

Paper:

packet-limiter:
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0

To wystarczy do podstawowej ochrony. Potem dostrajaj progi pod swoj ruch: monitoruj liczniki, patrz w logi, koryguj wartosci.

Czeste bledy

Za niski connlimit. connlimit: 1 zablokuje gracza przelaczajacego sie (stare polaczenie wisi jeszcze w TIME_WAIT). Minimum 3.

Zapomniana whitelista. Serwer proxy wpada pod rate limit i wszyscy gracze traca polaczenie. Zawsze dodawaj proxy do whitelisty.

Brak bursta. hashlimit bez burst blokuje kazdy krotkotrwaly skok. Gracz wszedl, wylecial, wrocil - zablokowany. Burst 15-25 rozwiazuje problem.

Rate limit na ESTABLISHED. Stosuj rate limiting tylko do nowych polaczen (--syn), inaczej ograniczysz ruch juz podlaczonych graczy.

Globalny limit bez per-IP. Globalny limit "100 polaczen na sekunde na caly serwer" zablokuje wszystkich, gdy jeden IP generuje 100 polaczen. Zawsze uzywaj limitow per-IP.

Rate limiting to nie srebrna kula. To jedna warstwa wielowarstwowej ochrony. Ale bez niej reszta warstw dziala gorzej. Skonfiguruj podstawowe limity, monitoruj skutecznosc i koryguj wedle potrzeb.

Globalny vs per-IP rate limiting

Wazne rozroznienie, ktore wiele osob pomija. Globalny rate limiter ogranicza calkowita liczbe polaczen do calego serwera. Per-IP rate limiter liczy polaczenia osobno dla kazdego adresu IP.

Globalny limit przydaje sie jako "hamulec awaryjny". Jesli twoj serwer jest na 200 graczy, nie ma sensu przyjmowac 10000 polaczen na sekunde. Globalny limit w okolicy 500-1000 polaczen na sekunde ochroni przed sytuacja, gdy atak idzie z tysiecy roznych IP (kazdy wysyla po 1-2 polaczenia, a limit per-IP nie zadziala).

Przyklad implementacji limitu globalnego:

# Globalny limit: nie wiecej niz 200 nowych polaczen na sekunde na caly serwer
iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit \
  --hashlimit-name mc_global \
  --hashlimit-above 200/sec \
  --hashlimit-burst 300 \
  --hashlimit-mode dstip \
  -j DROP

Kluczowa roznica: --hashlimit-mode dstip zamiast srcip. Teraz iptables liczy wszystkie polaczenia do naszego IP, a nie od kazdego pojedynczego zrodla.

Kombinacja obu typow daje maksymalna ochrone:

1. Limit per-IP lapie boty spamujace z jednego adresu
2. Limit globalny lapie ataki rozproszone z tysiecy IP

Automatyczna adaptacja limitow

Statyczne limity dzialaja, ale nie sa idealne. Na pustym serwerze w nocy 10 polaczen na sekunde z jednego IP to oczywisty bot. W sobote wieczorem, gdy online jest 300 osob, szczytowe obciazenie moze byc norma.

Prosty sposob na dynamiczny rate limiting:

#!/bin/bash
# adaptive-ratelimit.sh
# Odpalac przez cron co 5 minut

CURRENT_PLAYERS=$(screen -S minecraft -p 0 -X stuff "list\n" 2>/dev/null; sleep 1; grep -c "players online" /path/to/latest.log)

if [ "$CURRENT_PLAYERS" -gt 200 ]; then
    # Duzy online - rozluznij limity
    RATE=20
    BURST=40
elif [ "$CURRENT_PLAYERS" -gt 50 ]; then
    # Sredni online
    RATE=15
    BURST=30
else
    # Niski online - ostre limity
    RATE=8
    BURST=15
fi

# Zaktualizuj reguly (usun stare, dodaj nowe)
iptables -D INPUT -p tcp --dport 25565 --syn \
  -m hashlimit --hashlimit-name mc_adaptive \
  --hashlimit-above ${RATE}/sec --hashlimit-burst ${BURST} \
  --hashlimit-mode srcip -j DROP 2>/dev/null

iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit --hashlimit-name mc_adaptive \
  --hashlimit-above ${RATE}/sec --hashlimit-burst ${BURST} \
  --hashlimit-mode srcip -j DROP

To bazowy przyklad. W produkcji lepiej uzyc fail2ban albo wlasnego demona, ktory analizuje logi w czasie rzeczywistym i koryguje reguly.

GeoIP i rate limiting

Jesli 95% twoich graczy jest z Polski, a atak botow idzie z IP z Brazylii i Indonezji, mozna zastosowac ostrzejszy rate limiting dla konkretnych krajow:

# Zainstaluj modul geoip dla iptables
# Na Ubuntu/Debian: apt install xtables-addons-common

# Ostry limit dla krajow poza PL
iptables -A INPUT -p tcp --dport 25565 --syn \
  -m geoip ! --src-cc PL,DE,CZ,SK \
  -m hashlimit --hashlimit-name mc_foreign \
  --hashlimit-above 3/sec --hashlimit-burst 5 \
  --hashlimit-mode srcip -j DROP

Ostroznie z tym podejsciem: bazy GeoIP nie sa idealne, a mozesz zablokowac graczy uzywajacych VPN do obnizenia pingu. Uzywaj jako dodatkowego filtra, a nie podstawowego.