Ataki TCP vs UDP na serwery Minecraft: rozbiór różnic

Za każdym razem, gdy gracz łączy się z serwerem Minecraft, dane przesyłane są jednym z dwóch protokołów transportowych: TCP lub UDP. Java Edition używa TCP. Bedrock Edition używa UDP. To nie jest tylko detal techniczny. To określa, jakie ataki są możliwe, na ile są groźne i jak się przed nimi bronić.

W tym artykule rozbierzemy oba protokoły z perspektywy ataków DDoS. Bez abstrakcyjnej teorii, z realnymi liczbami i konkretnymi rekomendacjami.

TCP i UDP: podstawowe różnice w 2 minuty

Jeśli znasz już różnicę między TCP a UDP, pomiń tę sekcję. Dla reszty oto sedno.

TCP (Transmission Control Protocol) ustanawia połączenie przed transmisją danych. Trójstronne uzgodnienie: klient wysyła SYN, serwer odpowiada SYN-ACK, klient potwierdza ACK. Dopiero potem zaczyna się wymiana danych. Każdy pakiet jest numerowany, dostarczenie jest gwarantowane, zgubione pakiety są wysyłane ponownie.

UDP (User Datagram Protocol) nie ustanawia połączeń. Pakiety są wysyłane bez potwierdzenia, bez numeracji, bez gwarancji dostarczenia. Wysłał i zapomniał. Robi to UDP szybszym (mniej narzutu), ale mniej niezawodnym.

TCP (Minecraft Java):
Client  --SYN-->     Server
Client  <-SYN-ACK--  Server
Client  --ACK-->     Server
Client  <--DATA-->   Server   <- ustanowione połączenie

UDP (Minecraft Bedrock):
Client  --PKT-->  Server     <- po prostu wysyła
Client  --PKT-->  Server     <- bez potwierdzenia
Client  --PKT-->  Server     <- bez stanu

Minecraft Java Edition słucha na porcie TCP 25565. Minecraft Bedrock Edition słucha na porcie UDP 19132. Niektóre serwery włączają protokół Query, który działa po UDP na porcie 25565. Zapamiętaj to, będzie ważne później.

Ataki TCP: klasyka z przewidywalnym charakterem

Ataki TCP na serwery Minecraft są dobrze zbadane i ogólnie dobrze filtrowane. Ale "dobrze filtrowane" nie znaczy "nieszkodliwe". Oto główne typy.

SYN Flood

Najbardziej rozpowszechniony atak TCP. Atakujący wysyła ogromną liczbę pakietów SYN (pierwszy krok uzgodnienia) ze sfałszowanymi adresami IP. Serwer przy każdym SYN przydziela pamięć pod półotwarte połączenie i wysyła SYN-ACK. Odpowiedź idzie na sfałszowane IP, ACK nigdy nie przychodzi. Tabela półotwartych połączeń zapycha się, nowi legitni klienci nie mogą się połączyć.

Dla serwerów Minecraft SYN flood jest szczególnie groźny, bo serwery Java często działają z ograniczonym backlog (kolejka oczekujących połączeń). Domyślnie w Linuksie net.core.somaxconn wynosi 4096. Przy ataku 100 000 SYN/s ta kolejka zapycha się w ułamku sekundy.

Typowe objętości: od 1 do 50 Gbps. Widzieliśmy ataki na serwery Minecraft ze szczytem 30 Gbps czystego SYN flooda. Więcej o atakach SYN flood można poczytać w naszym osobnym artykule.

ACK Flood

Atakujący wysyła masę pakietów TCP z ustawioną flagą ACK. Serwer dostaje ACK dla połączeń, których nie ma, i marnuje zasoby na wyszukiwanie w tabeli połączeń. Jeśli serwer używa conntrack (a prawie na pewno tak), każdy taki pakiet powoduje lookup w hash-tabeli conntrack.

ACK flood jest mniej skuteczny niż SYN flood, bo pakiety bez istniejącego połączenia są szybko odrzucane. Ale przy wystarczającej objętości (10+ Gbps) obciążenie obsługi pakietów może stać się problemem.

RST Flood

Potok pakietów TCP z flagą RST (reset). Cel: zresetować istniejące połączenia graczy. Jeśli atakujący odgadnie sequence number aktywnego połączenia, może przymusowo je zerwać. W praktyce odgadnąć sequence number jest trudno, więc RST flood zwykle działa jak atak objętościowy, zapychając łącze.

Slowloris

Wyrafinowany atak, który nie wymaga dużych objętości ruchu. Atakujący otwiera mnóstwo połączeń TCP z serwerem i wysyła nagłówki HTTP (albo w przypadku Minecrafta, początkowe pakiety uzgodnienia) bardzo wolno, po jednym bajcie co 10-30 sekund. Serwer trzyma te połączenia otwarte, czekając na zakończenie, i w końcu wyczerpuje limit jednoczesnych połączeń.

Dla serwerów Minecraft Slowloris wygląda tak: setki połączeń zaczyna uzgodnienie, ale nigdy go nie kończy. Każde takie połączenie zajmuje slot. Gdy sloty się kończą, realni gracze nie mogą wejść.

Dlaczego ataki TCP łatwiej filtrować

Ataki TCP są przewidywalne, bo TCP z natury ma stan. Każde połączenie ma wyraźny cykl życia: SYN, SYN-ACK, ACK, DATA, FIN. Firewall może śledzić ten stan i odrzucać pakiety, które nie pasują do oczekiwanej sekwencji.

SYN cookies rozwiązują problem SYN flooda niemal całkowicie. Zamiast przydzielać pamięć przy każdym SYN, serwer koduje informacje o połączeniu w sequence number SYN-ACK. Pamięć jest przydzielana dopiero, gdy przyjdzie poprawny ACK z właściwym sequence number. Oznacza to, że SYN flood ze sfałszowanymi IP nie zajmuje ani bajta pamięci.

Conntrack (connection tracking) pozwala śledzić stan każdego połączenia TCP. Pakiet ACK dla nieistniejącego połączenia? Odrzucić. RST z niewłaściwym sequence number? Odrzucić. Tanio i skutecznie.

# Przykład: włączenie SYN cookies w Linux
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Zwiększenie backlog dla serwera Minecraft
echo 65535 > /proc/sys/net/core/somaxconn

# Ograniczenie półotwartych połączeń
echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog

Ataki UDP: inne zwierzę

Ataki UDP na serwery Minecraft działają zasadniczo inaczej. Tu nie ma stanu, nie ma uzgodnienia, nie ma kolejności pakietów. I to tworzy ogromne problemy dla ochrony.

UDP Flood

Najprostszy atak: wysyłanie masy pakietów UDP na docelowy port. Ponieważ UDP nie wymaga ustanawiania połączenia, atakujący może wysyłać pakiety ze sfałszowanymi adresami IP bez żadnych ograniczeń. Serwer musi przyjąć każdy pakiet i sprawdzić, czy jest aplikacja słuchająca na tym porcie. Jeśli nie, wysyłany jest ICMP Port Unreachable. Jeśli tak, pakiet trafia do aplikacji do obsługi.

Dla serwerów Bedrock jest to krytyczne: każdy przychodzący pakiet UDP na port 19132 trafia do RakNet (biblioteka sieciowa Bedrock), która marnuje zasoby na próbę jego parsowania.

Objętości UDP flooda mogą być kolosalne. Ponieważ pakiety są generowane bez oczekiwania na odpowiedź, jeden serwer atakującego może wysyłać gigabity śmieciowego ruchu na sekundę. Botnet z kilku tysięcy węzłów łatwo generuje 100+ Gbps czystego UDP flooda. I każdy pakiet trzeba przetworzyć choć minimalnie, zanim się zrozumie, że jest śmieciowy.

Osobny problem: UDP flood na losowe porty. Jeśli atakujący wysyła pakiety nie na 19132, a na losowe porty, serwer na każdy taki pakiet generuje ICMP Port Unreachable. Tworzy to dodatkowe obciążenie CPU i może zapchać wychodzące łącze odpowiedziami ICMP. Rozwiązanie: ograniczyć rate ICMP przez sysctl lub iptables.

# Ograniczenie ICMP Port Unreachable
sysctl -w net.ipv4.icmp_ratelimit=100
iptables -A OUTPUT -p icmp --icmp-type port-unreachable -j DROP

Ataki amplifikacji: gdzie 1 bajt zamienia się w 50

Tu właśnie UDP staje się naprawdę groźny. Amplification (amplifikacja) wykorzystuje legalne serwisy w internecie jako wzmacniacze ruchu. Zasada jest prosta:

1. Atakujący wysyła małe zapytanie na otwarty serwis (DNS, NTP, memcached)
2. W polu nadawcy podstawia IP ofiary (spoofing)
3. Serwis odpowiada objętościową odpowiedzią na IP ofiary
4. Ofiara dostaje ruch dziesiątki i setki razy większy niż ten, co wysłał atakujący

Współczynnik amplifikacji różnych protokołów:

Protokół	Współczynnik amplifikacji	Typowa objętość ataku
DNS	28-54x	10-100 Gbps
NTP (monlist)	556x	50-400 Gbps
Memcached	10 000-51 000x	100-1700 Gbps
SSDP	30x	5-50 Gbps
CLDAP	56-70x	10-100 Gbps
Chargen	358x	5-50 Gbps

Tak, dobrze przeczytałeś. Memcached może wzmocnić ruch 51 000 razy. Atakujący wysyła 1 MB danych, ofiara dostaje 51 GB. W praktyce takich objętości trudniej osiągnąć (nie ma tak wielu otwartych serwerów memcached), ale ataki 1-5 Tbps przez memcached były odnotowywane.

W kontekście Minecrafta: jeśli twój serwer Bedrock siedzi na IP bez ochrony, atak przez NTP amplification ze współczynnikiem 556x może wygenerować 100+ Gbps ruchu. Łącze dowolnego hostingu zapcha się w mgnieniu oka.

Query Flood: atak przez wbudowaną funkcję

Protokół Minecraft Query działa po UDP, zwykle na porcie 25565 (tym samym co Java Edition). Zwraca informacje o serwerze: liczbę graczy, MOTD, listę pluginów, wersję. Jedno zapytanie Query zajmuje około 9 bajtów. Odpowiedź to od 200 do 2000+ bajtów, w zależności od liczby pluginów i graczy.

Daje to współczynnik amplifikacji od 20x do 200x. I wszystko środkami samego Minecrafta, bez eksploatacji zewnętrznych serwisów.

# Zapytanie protokołu Query (9 bajtów)
\xFE\xFD\x09\x00\x00\x00\x00

# Odpowiedź (200-2000+ bajtów)
Server: MyServer
Plugins: WorldEdit, EssentialsX, LuckPerms...
Players: 50/100
...

Gorzej: wiele serwerów Minecraft włącza Full Query, który zwraca pełną listę pluginów i graczy. Na serwerze z 50 pluginami i 100 graczami odpowiedź Full Query może mieć 3-4 KB. Współczynnik amplifikacji: 400x+.

Rozwiązanie jest proste: wyłącz Query, jeśli ci nie jest potrzebny.

# server.properties
enable-query=false

Jeśli potrzebujesz informacji o serwerze do monitoringu, używaj Server List Ping (TCP) albo RCON (z uwierzytelnianiem), a nie Query.

Dlaczego UDP trudniej filtrować

Z TCP firewall może popatrzeć na pakiet i zapytać: "Czy ten pakiet należy do ustanowionego połączenia?" Jeśli nie, odrzucić. Z UDP takiego pytania nie można zadać, bo połączeń nie ma. Każdy pakiet jest samodzielny. Legitny pakiet od gracza Bedrock Edition wygląda dokładnie tak samo, jak atakujący pakiet. Oba są po prostu datagramami UDP na port 19132.

Firewall nie może odróżnić pierwszego pakietu od nowego gracza Bedrock od pierwszego pakietu w ataku DDoS. Nie ma stanu, na którym można się oprzeć.

Co zostaje:

• Rate limiting po IP: ograniczyć liczbę pakietów na sekundę z jednego IP. Działa przeciwko atakom z prawdziwych IP, bezużyteczne przeciwko spoofed IP.
• Payload inspection (DPI): analizować zawartość pakietów UDP. Legitne pakiety RakNet mają określoną strukturę. Atakujące pakiety często są losowymi bajtami. Ale to droga operacja.
• Geofiltracja: odrzucać pakiety z regionów, skąd nie ma graczy. Zgrubna metoda, ale skuteczna.
• Behavioral analysis: analizować wzorce ruchu. 10 000 pakietów UDP na sekundę z jednego IP na jeden port to nie gracz.

# iptables: rate limiting UDP na port Bedrock
iptables -A INPUT -p udp --dport 19132 \
  -m hashlimit \
  --hashlimit-above 100/sec \
  --hashlimit-burst 200 \
  --hashlimit-mode srcip \
  --hashlimit-name bedrock_limit \
  -j DROP

Porównanie: ataki TCP vs UDP w liczbach

Zbierzmy wszystko w tabelę.

Parametr	Ataki TCP	Ataki UDP
Minecraft Edition	Java (port 25565)	Bedrock (port 19132)
Typowa objętość	5-50 Gbps	50-500+ Gbps
Maksymalny odnotowany	~300 Gbps	~3.5 Tbps
Amplifikacja	Niemożliwa	Do 51 000x
Spoofing IP	Trudno (trzeba ACK)	Trywialnie
Filtrowanie stateful	Skuteczne	Niemożliwe
SYN cookies	Tak	Nie ma zastosowania
Connection tracking	Tak	Ograniczone
Koszt ataku	$$$	$
Koszt ochrony	$	$$$

Zwróć uwagę na koszt. Atak TCP wymaga realnych zasobów: potrzebne są serwery, które będą kończyć uzgodnienia lub generować duże objętości pakietów. Atak UDP z amplifikacją kosztuje prawie nic: parę skryptów, lista otwartych resolverów, gotowe.

Według danych z 2026, ataki UDP na serwery Minecraft stanowią około 70% wszystkich incydentów DDoS. Ataki TCP pozostają aktualne, ale przesuwają się w stronę application-level: imitacja uzgodnienia Minecraft, login flood, bot join.

Realny scenariusz: atak hybrydowy

Rozbierzmy typowy scenariusz ataku na serwer, który wspiera i Java, i Bedrock. Atakujący działa w kilku fazach.

Faza 1: rekonesans. Atakujący skanuje porty serwera. Znajduje TCP 25565 (Java), UDP 19132 (Bedrock), UDP 25565 (Query włączony). Przez Query dostaje listę pluginów i wersję serwera.

Faza 2: UDP amplification. Startuje DNS amplification na IP serwera. 5 Gbps ruchu wychodzącego zamienia się w 150 Gbps przychodzącego. Łącze serwera zapchane. Wszyscy gracze, i Java, i Bedrock, są odłączeni. Serwer traci łączność z monitoringiem.

Faza 3: SYN flood. Równolegle z atakiem UDP startuje SYN flood na port 25565. Nawet jeśli upstream-provider odfiltruje część UDP amplification, SYN flood tworzy obciążenie na conntrack i backlog. Serwer nie może przyjmować nowych połączeń TCP.

Faza 4: bot join. Po osłabieniu pierwszych dwóch fal atakujący wysyła boty, które przechodzą TCP handshake, wysyłają poprawny login Minecraft i wchodzą na serwer. Sloty zapełniają się botami, realni gracze trafiają do kolejki.

To nie teoria. Takie wielopoziomowe ataki stały się standardem w 2025-2026. Ochrona musi działać na wszystkich poziomach jednocześnie.

Różne protokoły, różne strategie ochrony

Ochrona serwera Java (TCP) i Bedrock (UDP) wymaga różnych podejść. Nie można zastosować tej samej logiki do obu.

Ochrona Java Edition (TCP)

Dla TCP mamy potężne narzędzia na poziomie jądra OS:

1. SYN cookies - rozwiązują SYN flood bez dodatkowego oprogramowania
2. Connection tracking (conntrack) - śledzenie stanu połączeń
3. TCP handshake verification - sprawdzanie zakończenia uzgodnienia przed przepuszczeniem do serwera
4. Application-level sprawdzenia - po ustanowieniu połączenia TCP można sprawdzić poprawność uzgodnienia Minecraft

Warstwowa ochrona dla Java:

Poziom 1: XDP/eBPF - odrzucanie śmieciowych pakietów przed jądrem
Poziom 2: SYN cookies - ochrona przed SYN flood
Poziom 3: Conntrack - filtrowanie po stanie
Poziom 4: Application proxy - sprawdzanie protokołu Minecraft
Poziom 5: Captcha/challenge - weryfikacja graczy

Ochrona Bedrock Edition (UDP)

Dla UDP tracimy warstwy 2 i 3 z powyższego schematu. Nie ma SYN cookies, nie ma stateful conntrack. Trzeba skompensować innymi metodami:

1. Rate limiting na poziomie XDP - odrzucanie pakietów powyżej progu przed jądrem
2. RakNet payload validation - sprawdzanie struktury pakietów Bedrock
3. Cookie-based verification - własna implementacja challenge-response na UDP
4. GeoIP filtering - ograniczenie po geografii
5. Upstream filtering - filtrowanie na poziomie providera (BGP Flowspec)

Poziom 1: Upstream BGP Flowspec - blokada amplifikacji
Poziom 2: XDP/eBPF - rate limiting plus payload validation
Poziom 3: Application proxy - RakNet protocol verification
Poziom 4: Behavioral analysis - wzorce ruchu

Dla właścicieli serwerów używających obu edycji (Java i Bedrock) krytycznie ważne jest zrozumienie, że jednego rozwiązania dla obu protokołów nie ma. Usługa ochrony musi mieć osobne moduły dla ruchu TCP i UDP. MineGuard na przykład obsługuje ruch Java i Bedrock różnymi pipeline'ami, każdy ze swoim zestawem reguł i algorytmów.

Minecraft Query: ukryte zagrożenie

Osobno warto pomówić o protokole Query. Wielu administratorów o nim zapomina, a szkoda.

Query działa po UDP na tym samym porcie co Java Edition (25565 domyślnie). Jest włączony domyślnie w wielu konfiguracjach hostingów. Nawet jeśli masz tylko Java Edition i myślisz, że UDP cię nie dotyczy, Query tworzy powierzchnię ataku UDP.

Trzy problemy z Query:

1. Amplifikacja - małe zapytanie, duża odpowiedź. Twój serwer może być wykorzystany jako wzmacniacz do ataku na innych.
2. Information disclosure - Query zwraca wersję serwera, listę pluginów (z wersjami), adresy IP graczy przy Full Query. To rekonesans przed prawdziwym atakiem.
3. Resource consumption - każde zapytanie Query jest obsługiwane przez główny wątek serwera. Potok zapytań Query może spowodować spadki TPS.

# Wyłącz Query w server.properties
enable-query=false

# Jeśli Query jest potrzebny do monitoringu, ogranicz dostęp przez iptables
iptables -A INPUT -p udp --dport 25565 \
  -s 10.0.0.0/8 -j ACCEPT          # tylko z sieci wewnętrznej
iptables -A INPUT -p udp --dport 25565 -j DROP

Praktyczne rekomendacje: co zrobić teraz

Niezależnie od tego, jaki masz serwer, oto checklista:

Dla wszystkich serwerów

• Wyłącz Query (enable-query=false)
• Zamknij wszystkie nieużywane porty (szczególnie UDP)
• Włącz firewall i skonfiguruj whitelistę portów
• Nie wystawiaj RCON do internetu (używaj tylko przez localhost lub VPN)
• Ukryj prawdziwe IP serwera za ochroną DDoS

Dodatkowo dla Java Edition (TCP)

# SYN cookies
sysctl -w net.ipv4.tcp_syncookies=1

# Zwiększ backlog
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=65535

# TCP timestamps (potrzebne do SYN cookies)
sysctl -w net.ipv4.tcp_timestamps=1

# Ogranicz retry dla SYN-ACK
sysctl -w net.ipv4.tcp_synack_retries=2

Dodatkowo dla Bedrock Edition (UDP)

# Zwiększ bufor odbioru UDP
sysctl -w net.core.rmem_max=26214400
sysctl -w net.core.rmem_default=1048576

# Rate limiting przez iptables
iptables -A INPUT -p udp --dport 19132 \
  -m hashlimit \
  --hashlimit-above 50/sec \
  --hashlimit-burst 100 \
  --hashlimit-mode srcip \
  --hashlimit-name bedrock \
  -j DROP

# Zamknij port UDP 25565, jeśli Query jest wyłączony
iptables -A INPUT -p udp --dport 25565 -j DROP

Błędy, które robią administratorzy

Skoro mówiliśmy o technicznej stronie, warto wspomnieć typowe błędy, które robią administratorzy serwerów Minecraft. To właśnie one zamieniają drobny atak w pełnoprawny downtime.

Błąd 1: otwarte porty. Na serwerze otwarte wszystko: 25565 TCP i UDP, 19132, RCON na 25575, SSH na standardowym 22, czasem nawet MySQL na 3306. Każdy otwarty port to wektor ataku. Zamknij wszystko, czego nie używasz.

Błąd 2: Query włączony. Powtórzę, bo to ważne. Query domyślnie jest włączony w wielu paczkach. Nie jest potrzebny do działania serwera. Jest potrzebny tylko do monitoringu, a i do tego są lepsze alternatywy.

Błąd 3: prawdziwe IP serwera w DNS. Jeśli IP twojego serwera jest znane atakującemu, może bić bezpośrednio, omijając dowolną ochronę chmurową. Używaj ochrony DDoS z proxyowaniem i nigdy nie ujawniaj prawdziwego IP.

Błąd 4: brak rate limiting. Bez ograniczenia prędkości połączeń jeden IP może wysyłać tysiące żądań na sekundę. Nawet podstawowy hashlimit w iptables znacząco obniża skuteczność ataków.

Błąd 5: ignorowanie sysctl. Domyślne parametry Linuksa nie są obliczone na pracę pod obciążeniem. SYN cookies wyłączone, backlog mały, bufory UDP minimalne. Pięć minut konfiguracji sysctl może ocalić od godziny downtime.

Co czeka w przyszłości

Trendy ataków DDoS na serwery Minecraft w 2026 pokazują przesunięcie w stronę ataków hybrydowych. Atakujący kombinują ataki TCP i UDP jednocześnie: SYN flood zapycha CPU obsługą półotwartych połączeń, a UDP amplification zapycha łącze. Ochrona skonfigurowana tylko na jeden protokół przepuszcza drugi.

Rośnie liczba ataków application-level: boty imitujące prawdziwych graczy, przechodzą TCP handshake, wysyłają poprawny login Minecraft i nawet rozwiązują proste captche. To już nie o objętości ruchu, a o jakości imitacji.

Po stronie ochrony rozwijają się rozwiązania XDP/eBPF, które pozwalają filtrować pakiety przed jądrem OS, obsługując miliony pakietów na sekundę na jednym rdzeniu CPU. Dla UDP jest to szczególnie ważne, bo pozwala zrealizować szybki payload inspection bez obciążenia głównego stosu.

Podsumowanie

Ataki TCP i UDP na serwery Minecraft to dwa różne światy. Ataki TCP (SYN flood, ACK flood, Slowloris) są groźne, ale dobrze zbadane i skutecznie filtrowane przez SYN cookies, conntrack i stateful inspection. Ataki UDP (flood, amplification, Query abuse) są trudniejsze i groźniejsze: większe objętości, prostszy spoofing, trudniejsze filtrowanie.

Jeśli masz Java Edition, upewnij się, że SYN cookies są włączone, a Query wyłączony. Jeśli Bedrock, zadbaj o rate limiting i upstream filtering. Jeśli oba, używaj ochrony, która rozumie różnicę między protokołami i filtruje każdy swoim zestawem reguł.

Uniwersalnego przycisku "chroń przed wszystkim" nie ma. Ale zrozumienie, jak działają ataki na każdy protokół, to pierwszy krok do zbudowania realnej ochrony.