Null-ataki i exploity BungeeCord: jak chronić serwer Minecraft

Czym są null-ataki i dlaczego są tak skuteczne

Jeśli administrujesz serwerem Minecraft, prędzej czy później zderzysz się z null-atakami. To nie klasyczny DDoS, który zatyka kanał ruchem. Null-ataki działają subtelniej - wysyłają do serwera niepoprawne, puste lub specjalnie spreparowane pakiety, które zmuszają go do marnowania zasobów na obróbkę śmieci.

Istota prosta: protokół Minecraft oczekuje określonego formatu danych. Kiedy przychodzi pakiet z zerową długością, niepoprawnym ID lub obciętymi danymi, serwer próbuje go sparsować, łapie wyjątek i marnuje na to CPU. Pomnóż przez tysiące połączeń na sekundę i nawet mocny serwer zacznie się dławić.

Typy null-ataków na Minecrafta

Null Ping

Najprostszy wariant. Atakujący wysyła zapytanie SLP (Server List Ping) z pustym lub uszkodzonym payloadem. Serwer próbuje odpowiedzieć na każdy taki ping, generuje MOTD, liczy online, formuje odpowiedź JSON. Przy tysiącach takich zapytań na sekundę serwer traci zauważalną część CPU tylko na odpowiadanie pingującym.

W logach wygląda to jak masowe połączenia bez późniejszego wejścia. Gracze w tym czasie skarżą się na lagi albo nie mogą wejść.

Null Login

Bardziej agresywny wariant. Bot zaczyna procedurę logowania, wysyła pakiet Login Start z pustą nazwą lub niepoprawnymi danymi. Serwer wydziela zasoby na nową sesję, zaczyna obróbkę, a potem dostaje błąd parsowania.

Szczególnie boli to serwery z ciężkimi pluginami na wejście - AuthMe, LoginSecurity i podobnymi. Każdy fejkowy login może triggerować zapytania SQL, sprawdzenia i inną logikę.

Invalid Packet Length

Atakujący wysyła pakiet, w którego nagłówku wskazana jest jedna długość, a faktycznie danych jest inna ilość. Albo długość jest ujemna. Albo długość jest wskazana jako VarInt maksymalnej wartości.

Niektóre implementacje serwerów na tym crashują. Vanilla i Paper zazwyczaj obsługują to normalnie, ale pluginy, które parsują pakiety samodzielnie, mogą paść z OutOfMemoryError, jeśli spróbują zaalokować bufor o długości wskazanej w pakiecie.

Protocol Manipulation

Najbardziej wyrafinowany typ. Bot wysyła pakiety w niewłaściwej kolejności, używa nieistniejących packet ID albo wysyła pakiety dla innego stanu protokołu (na przykład pakiety Play podczas Handshake).

Na podatnych serwerach może to wywołać desynchronizację stanu i wyciek pamięci. Widziałem przypadki, kiedy takie ataki doprowadzały do tego, że serwer przestawał przyjmować nowe połączenia, choć formalnie nie crashował.

BungeeCord: główny ból głowy

BungeeCord nadal używany jest na ogromnej liczbie serwerów. I nadal pozostaje źródłem krytycznych luk, jeśli jest skonfigurowany niepoprawnie. A skonfigurowany niepoprawnie jest prawie zawsze.

IPForward Spoofing

Kiedy w BungeeCord włączony jest ip_forwarding, przekazuje IP gracza serwerowi backend przez specjalne pole w pakiecie Handshake. Problem w tym, że mechanizm ten nie ma żadnej autentykacji. Żadnej.

To znaczy, że jeśli ktoś połączy się bezpośrednio z twoim serwerem backend (Spigot/Paper) i podrobi pakiet Handshake, będzie mógł wejść z dowolnym adresem IP. A jeśli na serwerze jest binding po IP, będzie mógł wejść na dowolne konto.

Bezpośredni dostęp do Backend

Najczęstszy błąd - zostawić porty serwerów backend otwarte. Jeśli twoje serwery Spigot/Paper są dostępne z zewnątrz, atakujący może połączyć się bezpośrednio, omijając BungeeCord. Przy włączonym bungeecord: true w spigot.yml taki serwer będzie ufał dowolnemu pakietowi Handshake.

Regularnie widzę serwery, gdzie backend działa na publicznym IP z otwartym portem. To jak zostawić tylne drzwi otwarte na oścież.

Handshake Manipulation

BungeeCord przy przekazywaniu gracza dodaje do pakietu Handshake dodatkowe dane: IP gracza, UUID i dane profilu. Atakujący może spreparować pakiet z dowolnymi danymi w tych polach.

Przez to można podrobić UUID gracza i wejść na cudze konto ze wszystkimi uprawnieniami. Dla serwerów w offline-mode to w ogóle trywialny atak, ale nawet serwery online-mode są podatne, jeśli backend przyjmuje UUID z Handshake bez weryfikacji.

UUID Spoofing

Rozszerzenie poprzedniego ataku. BungeeCord przekazuje UUID gracza serwerowi backend. Jeśli atakujący może połączyć się z backendem bezpośrednio, wysyła Handshake z UUID admina i dostaje pełne uprawnienia.

Na serwerach z LuckPerms lub podobnymi systemami uprawnień to natychmiastowy pełny dostęp. Znam przypadki, kiedy przez to kradli dane donatów, przedmioty, a nawet dostęp do konsoli przez pluginy typu ServerUtils.

Velocity vs BungeeCord: porównanie bezpieczeństwa

Velocity od początku był projektowany z uwzględnieniem błędów BungeeCorda. Różnica jest znacząca.

BungeeCord:

• IPForward bez autentykacji
• Brak wbudowanej ochrony serwerów backend
• Obróbka pakietów często blokuje główny wątek
• Plugin BungeeGuard potrzebny jako proteza do podstawowego bezpieczeństwa
• Luki w parsowaniu pakietów znajdowane są regularnie

Velocity:

• Modern forwarding z sekretnym kluczem (HMAC)
• Backend przyjmuje połączenia tylko z ważnym podpisem
• Bardziej rygorystyczne parsowanie protokołu
• Lepsza izolacja między połączeniami
• Aktywny rozwój i szybkie fixy

Jeśli stawiasz proxy od zera, używaj Velocity. Jeśli już jesteś na BungeeCord i migracja nie wchodzi w grę, czytaj dalej.

Jak zabezpieczyć BungeeCord

Zamknij porty serwerów backend

To pierwszy i najważniejszy krok. Serwery backend powinny być dostępne tylko z adresu IP BungeeCord.

Przez iptables:

iptables -A INPUT -p tcp --dport 25565 -s BUNGEE_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 -j DROP

Jeśli BungeeCord i backend są na jednej maszynie, przypnij backend do localhost w server.properties:

server-ip=127.0.0.1

Zainstaluj BungeeGuard

BungeeGuard dodaje sekretny token do procesu przekazywania. Serwer backend sprawdza ten token i odrzuca połączenia bez niego. To nie idealna ochrona, ale znacząco podnosi poprzeczkę.

Instalacja:

1. Plugin na BungeeCord - dodaje token do Handshake
2. Plugin na każdy serwer backend - sprawdza token
3. Wygenerowany token musi się zgadzać

Skonfiguruj IPForward poprawnie

W config.yml BungeeCord:

ip_forward: true

W spigot.yml na backendzie:

settings:
  bungeecord: true

Ale pamiętaj, że bez BungeeGuarda lub firewalla to jest bezużyteczne. IPForward bez ochrony to po prostu dziura.

Jak zabezpieczyć Velocity

Modern Forwarding

W velocity.toml:

player-info-forwarding-mode = "modern"

Velocity wygeneruje plik forwarding.secret. Ten sam sekret trzeba wskazać w ustawieniach serwera backend.

Dla Paper w config/paper-global.yml:

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "skopiuj sekret z forwarding.secret"

Modern forwarding używa HMAC do podpisu danych. Podrobić tego bez znajomości sekretu jest niemożliwe.

Dodatkowe środki

W velocity.toml warto też skonfigurować:

show-max-players = 500
online-mode = true
force-key-authentication = true

force-key-authentication wymaga od klientów podpisu kluczem Mojanga, co odsiewa większość botów.

Jak rozpoznać ataki w logach

Oznaki null-ataku

W logach Paper/Spigot szukaj:

[WARNING] Exception caught: io.netty.handler.codec.DecoderException
[WARNING] Disconnecting: Internal Exception
[INFO] [/1.2.3.4:12345] <-> InitialHandler - disconnect

Masowe DecoderException to prawie gwarancja null-ataku. Jeśli widzisz setki takich linii na sekundę, twój serwer jest pod atakiem.

Oznaki exploitu BungeeCord

[INFO] UUID of player Admin is 00000000-0000-0000-0000-000000000000
[WARNING] Player connected with invalid handshake data

Jeśli gracz z nickiem admina loguje się z zerowym UUID lub nieznanego IP, to próba spoofingu.

Monitoring

Ustaw alerty na anomalną liczbę połączeń. Normalny serwer na 100 graczy dostaje 5-15 nowych połączeń na minutę. Jeśli widzisz 500+ na minutę, coś jest nie tak.

Kiedy anty-bot pluginy pomagają, a kiedy nie

Pluginy anty-bot typu BotSentry, Antibot, EpicGuard działają na poziomie aplikacji. Sprawdzają zachowanie po połączeniu - prędkość przemieszczania, wysyłanie pakietów, captchę.

Pomagają przy:

• Wolnych bot-atakach (dziesiątki połączeń na sekundę)
• Botach, które próbują się zalogować i grać
• Spamie na chacie przez fejkowych graczy

Nie pomagają przy:

• Null-atakach na poziomie protokołu - pakiet crashuje obróbkę zanim plugin go zobaczy
• Masowych połączeniach (tysiące na sekundę) - serwer nie nadąża z obróbką
• Atakach na fazę Handshake/Login - pluginy anty-bot działają po wejściu

Dla null-ataków i protocol-level floodu potrzebna jest filtracja zanim pakiet dotrze do serwera Java. To robota dla warstwy proxy lub filtra sieciowego. MineGuard filtruje takie pakiety na poziomie sieci jeszcze przed dotarciem na twój serwer, odsiewając niepoprawne połączenia bez obciążania gry.

Rekomendacje dotyczące pluginów

BungeeGuard

Obowiązkowy, jeśli używasz BungeeCorda. Dodaje autentykację między proxy a backendem. Darmowy, lekki, bez konfiguracji (poza tokenem).

TCPShield Plugin

Jeśli używasz TCPShield jako ochrony, ich plugin poprawnie wyciąga realne IP z Proxy Protocol. Bez niego wszyscy gracze będą widoczni z IP proxy TCPShield.

EpicGuard

Jeden z najlepszych anty-botów. Sprawdza GeoIP, prędkość połączeń, DNSBL. Dobrze radzi sobie z wolnymi bot-atakami. Nie uratuje przed atakami protocol-level, ale jako dodatkowa warstwa ochrony - świetna opcja.

Geyser + Floodgate

Jeśli wspierasz klientów Bedrock, poprawna konfiguracja Floodgate zapobiega spoofingowi kont Bedrock. Niepoprawna - tworzy jeszcze jedną dziurę.

Dlaczego Proxy Protocol jest lepszy niż IPForward

IPForward w BungeeCord przekazuje IP przez zmodyfikowany pakiet Handshake. To niestandardowe rozwiązanie, przywiązane do ekosystemu Minecrafta. Proxy Protocol (HAProxy Protocol) to standard przemysłowy.

Zalety Proxy Protocol:

• Standaryzowany, wspierany przez wiele systemów
• Działa na poziomie transportowym, przed parsowaniem protokołu Minecraft
• Trudniejszy do podrobienia, bo jest obrabiany przed przekazaniem danych aplikacji
• Kompatybilny z dowolnymi zewnętrznymi systemami ochrony

Jak włączyć:

W Velocity (velocity.toml):

haproxy-protocol = true

Na backendzie potrzebny jest plugin do przyjmowania Proxy Protocol (na przykład HAProxyDetector lub wbudowane wsparcie w Paper).

MineGuard wspiera Proxy Protocol out of the box, co pozwala poprawnie przekazywać realne adresy IP graczy na twój serwer bez IPForward i związanych z nim luk.

Checklist bezpieczeństwa

Szybka kontrola dla twojego serwera:

• Porty backend zamknięte firewallem dla zewnętrznych połączeń
• BungeeGuard lub modern forwarding skonfigurowany i działa
• online-mode włączony na proxy
• Logi monitorowane pod kątem anomalnych połączeń
• IPForward nie używany bez dodatkowej ochrony
• Na serwerach backend server-ip przypięty do localhost lub wewnętrznego IP
• Zainstalowany plugin anty-bot jako dodatkowa warstwa
• Proxy Protocol skonfigurowany, jeśli używana jest zewnętrzna ochrona

Jeśli choć jeden punkt nie jest spełniony, twój serwer jest podatny. Null-ataki i exploity BungeeCorda to nie teoretyczne zagrożenie, to coś, z czym zderza się każdy serwer z 50+ online. Zadbaj o ochronę zanim stanie się to problemem.