SYN-flood: najczęstszy atak DDoS na serwery Minecraft

Każdy właściciel serwera Minecraft prędzej czy później zetknie się z atakami DDoS. I w większości przypadków pierwszym, co przylatuje, jest SYN-flood. Nie dlatego, że to najbardziej skomplikowany atak. Odwrotnie, bo to najprostsza i nadal skuteczna technika, która może położyć niezabezpieczony serwer w sekundy.

Żeby zrozumieć, jak działa SYN-flood, trzeba najpierw rozkminić, jak w ogóle nawiązuje się połączenie TCP. Minecraft działa po TCP (Bedrock Edition używa UDP, ale Java Edition to czyste TCP), więc każde połączenie gracza przechodzi przez ten proces.

Jak działa TCP three-way handshake

Kiedy gracz łączy się z twoim serwerem, zachodzi tak zwane "trójstronne uściśnięcie dłoni". Trzy pakiety, trzy kroki.

Krok 1: SYN. Klient wysyła serwerowi pakiet z flagą SYN (synchronize). Ten pakiet mówi: "Cześć, chcę nawiązać połączenie. Oto mój początkowy sequence number."

Krok 2: SYN-ACK. Serwer dostaje SYN, rezerwuje zasoby dla nowego połączenia (tworzy wpis w SYN backlog) i wysyła z powrotem pakiet SYN-ACK. To znaczy: "Słyszę cię, oto mój sequence number, potwierdź."

Krok 3: ACK. Klient wysyła finalny ACK. Połączenie nawiązane. Teraz można przesyłać dane, i Minecraft zaczyna proces login.

Cały proces zajmuje zwykle mniej niż 100 milisekund. Ale jest krytyczny moment: między krokiem 2 i krokiem 3 serwer trzyma połączenie w stanie "półotwartym" (half-open). Już wydał zasoby, ale jeszcze nie dostał potwierdzenia. I właśnie to eksploatuje SYN-flood.

Jak SYN-flood łamie serwer

Idea ataku jest elementarna. Atakujący wysyła tysiące (albo miliony) pakietów SYN na port twojego serwera. Każdy pakiet przychodzi z podrobionym adresem IP (IP spoofing). Serwer na każdy SYN uczciwie odpowiada SYN-ACK i tworzy wpis w backlogu. Ale SYN-ACK idzie na podrobiony adres, skąd ACK nigdy nie przyjdzie.

W rezultacie dzieje się to:

1. SYN backlog wypełnia się półotwartymi połączeniami
2. Każde półotwarte połączenie wisi w pamięci, czekając na ACK (domyślnie 75 sekund w Linuksie)
3. Kiedy backlog jest pełny, serwer przestaje przyjmować nowe połączenia
4. Prawdziwi gracze dostają "Connection timed out" albo "Can't connect to server"

Standardowy rozmiar SYN backlog w Linuksie to 128 albo 256 wpisów. Nawet ze zwiększonym backlogiem do 1024 wpisów, przy prędkości ataku 50 000 pakietów SYN na sekundę backlog zapełnia się natychmiast. Przy czym sam atak może być generowany z jednego wynajętego serwera - do SYN-flooda nie trzeba botnetu.

Oddzielny problem to zużycie zasobów kernela. Każdy wpis w SYN backlog zajmuje około 300-400 bajtów w pamięci kernela. Niby niewiele. Ale przy 65535 wpisach to już ~25 MB tylko na kolejkę. Plus kernel wydaje CPU na obsługę każdego przychodzącego SYN, generację SYN-ACK, planowanie retransmisji. Na serwerze, gdzie proces Java Minecrafta już pożera większość zasobów, to dodatkowe obciążenie może stać się krytyczne. softirq (obsługa przerwań od pakietów sieciowych) zaczyna zabierać rdzenie CPU, które są potrzebne serwerowi do obsługi ticków.

Dlaczego serwery Minecraft są szczególnie podatne

Serwer Minecraft ma kilka cech, które robią z niego idealny cel dla SYN-flooda.

Jeden port. Cały ruch idzie na jeden port TCP (zwykle 25565). Atakujący nie musi rozpraszać wysiłków, wystarczy zalać jeden port.

Protokół TCP. W przeciwieństwie do gier na UDP (Bedrock, CS2, Valorant), Java Edition używa TCP. To znaczy, że każde połączenie wymaga pełnego handshake'u, a każdy pakiet SYN zjada zasoby serwera.

Publiczny adres. Większość serwerów Minecraft publikuje swój IP w listingach serwerów, na forach, na Discordzie. Atakujący zawsze wie, gdzie bić.

Ograniczone zasoby. Typowy serwer Minecraft działa na VPS albo dedyku z ograniczonymi zasobami sieciowymi. Nawet jeśli łącze to 1 Gbit/s, SYN-flood 500 Mbit/s już stworzy poważne problemy.

Brak wbudowanej ochrony. Ani Vanilla, ani Paper, ani Velocity nie mają wbudowanych mechanizmów ochrony przed SYN-floodem. To zadanie na poziomie OS i sieci, nie aplikacji.

Przewidywalny port. Domyślnie Minecraft słucha na 25565. Nawet jeśli zmienisz port, atakujący znajdzie go prostym skanowaniem. A rekordy SRV w DNS ujawniają port każdemu chętnemu. W przeciwieństwie do serwerów webowych, gdzie ruch może być rozkładany między wiele portów i usług, Minecraft ma jeden punkt wejścia.

Długie sesje. Gracze Minecraft trzymają połączenia godzinami. To znaczy, że tablica connection tracking i tak jest obciążona realnymi połączeniami. SYN-flood dodaje do tego tysiące fejkowych wpisów, i tablica conntrack może się przepełnić, zaczynając dropować już nawiązane połączenia prawdziwych graczy.

Jak rozpoznać SYN-flood

Zanim zaczniesz walczyć z atakiem, trzeba go zdiagnozować. Oto konkretne komendy.

Sprawdzanie stanu połączeń przez ss

ss -s

Ta komenda pokaże ogólną statystykę socketów. Jeśli widzisz anormalnie wysoką liczbę synrecv - to SYN-flood.

ss -tnp state syn-recv | wc -l

Pokazuje liczbę połączeń w stanie SYN_RECV. Normalna wartość dla serwera Minecraft z 200 graczami - 0-5. Jeśli widzisz setki albo tysiące, jesteś atakowany.

Analiza przez netstat

netstat -n | awk '/^tcp/ {print $6}' | sort | uniq -c | sort -rn

Ta komenda grupuje połączenia TCP według stanów. Przy SYN-floodzie zobaczysz coś takiego:

  4891 SYN_RECV
    47 ESTABLISHED
    12 TIME_WAIT
     3 CLOSE_WAIT

Tysiące SYN_RECV przy dziesiątkach ESTABLISHED - pewny znak ataku.

Monitoring przez tcpdump

tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0' -c 100

Pokaże pakiety SYN w czasie rzeczywistym. Przy SYN-floodzie zobaczysz strumień pakietów z różnych (podrobionych) adresów IP. Zwróć uwagę na TTL - jeśli jest taki sam u pakietów z różnych "IP", znaczy że pakiety naprawdę idą z jednego źródła.

Prędkość przychodzących pakietów SYN

watch -n 1 'ss -s | grep synrecv'

Monitoring w czasie rzeczywistym. Jeśli SYN_RECV rośnie o tysiące na sekundę, to aktywny atak.

Analiza adresów IP

ss -tn state syn-recv | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Pokaże top-20 adresów IP z połączeniami SYN_RECV. Przy SYN-floodzie z IP spoofingiem zobaczysz równomierny rozkład po tysiącach adresów. Jeśli atak bez spoofingu - zobaczysz kilka IP z tysiącami połączeń każdy.

Ochrona na poziomie kernela Linux

Pierwsza linia obrony - poprawna konfiguracja kernela. To nie zatrzyma poważnego ataku, ale da czas na reakcję.

SYN Cookies

sysctl -w net.ipv4.tcp_syncookies=1

SYN cookies to mechanizm, w którym serwer nie trzyma stanu półotwartego połączenia. Zamiast tego koduje informacje o połączeniu bezpośrednio w sequence number pakietu SYN-ACK. Kiedy przychodzi ACK, serwer odtwarza informacje z sequence number.

Plusy: backlog się nie zapełnia, serwer nadal przyjmuje połączenia. Minusy: niektóre opcje TCP (window scaling, timestamps) nie działają, co może zwiększyć latencję. Dla Minecrafta to zwykle nie jest krytyczne.

# Ustawić na stałe
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
sysctl -p

Zwiększenie SYN backlog

sysctl -w net.ipv4.tcp_max_syn_backlog=65535
sysctl -w net.core.somaxconn=65535

Zwiększamy rozmiar kolejki półotwartych połączeń. To nie rozwiązuje problemu, ale przy włączonych syncookies daje dodatkowy zapas.

Zmniejszenie SYN-ACK retries

sysctl -w net.ipv4.tcp_synack_retries=2

Domyślnie Linux wysyła SYN-ACK ponownie 5 razy, czekając na ACK. Każda retransmisja zwiększa czas życia półotwartego połączenia. Zmniejszamy do 2 - jeśli ACK nie przyszedł po dwóch razach, połączenie jest zrzucane.

Włączenie TCP timestamps

sysctl -w net.ipv4.tcp_timestamps=1

TCP timestamps są potrzebne do poprawnej pracy SYN cookies i pomagają kernelowi skuteczniej śledzić połączenia.

Pełny zestaw sysctl do ochrony

# /etc/sysctl.conf - SYN flood mitigation
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 65535
net.core.somaxconn = 65535
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.core.netdev_max_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535

Zastosowujemy:

sysctl -p

Ochrona przez iptables

Drugi poziom - filtrowanie na poziomie netfilter/iptables. Te reguły działają w userspace i nie są tak szybkie jak XDP, ale dla średniego serwera wystarczą.

Ograniczenie prędkości pakietów SYN

iptables -A INPUT -p tcp --syn -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

Przyjmujemy maksymalnie 100 pakietów SYN na sekundę z burst do 200. Wszystko powyżej - dropujemy. Dla serwera Minecraft z 200-300 graczami 100 SYN/s aż nadto, bo gracze nie łączą się co sekundę.

Blokowanie nieprawidłowych pakietów TCP

iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP

Te reguły odcinają pakiety z nieprawidłowymi kombinacjami flag TCP. Normalny stos TCP nigdy nie generuje pakietu z jednocześnie ustawionymi SYN i FIN. Takie pakiety to albo atak, albo skanowanie.

Ograniczenie nowych połączeń na IP

iptables -A INPUT -p tcp --dport 25565 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP

Nie więcej niż 3 jednoczesne nowe połączenia z jednego IP. Zwykły gracz tworzy 1 połączenie. Jeśli z jednego IP idzie 3+ SYN jednocześnie, to podejrzane.

Użycie SYNPROXY

iptables -t raw -A PREROUTING -p tcp --dport 25565 --syn -j CT --notrack
iptables -A INPUT -p tcp --dport 25565 -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

SYNPROXY to target iptables, który realizuje SYN proxy bezpośrednio w kernelu. Odpowiada na pakiety SYN zamiast aplikacji, i dopiero po otrzymaniu prawidłowego ACK tworzy realne połączenie do serwera. To jedna z najskuteczniejszych ochron iptables przed SYN-floodem.

Dlaczego ochrona na poziomie aplikacji to za mało

Czasami właściciele serwerów stawiają "anti-DDoS" pluginy na Paperze albo Velocity i myślą, że są zabezpieczeni. To niebezpieczne złudzenie.

Plugin Minecraft działa na poziomie aplikacji (Layer 7). Kiedy pakiet SYN przylatuje na serwer, przechodzi przez stos sieciowy kernela, stos TCP/IP, accept queue, i dopiero potem trafia do Javy. SYN-flood zabija serwer na etapie stosu TCP, zanim Java w ogóle zobaczy pakiet.

Plugin typu "Anti-Bot" chroni przed botami, które już nawiązały połączenie TCP i próbują się logować do Minecrafta. To inny typ ataku (Layer 7 bot flood). Przeciwko SYN-floodowi plugin jest bezużyteczny, bo połączenie do niego nie dochodzi.

Analogia: to jak stawiać ochroniarza wewnątrz budynku, kiedy napastnicy zabarykadowali drzwi wejściowe z zewnątrz. Ochroniarz nic nie może zrobić, bo problem jest przed nim.

Jak profesjonalna ochrona DDoS obsługuje SYN-flood

Profesjonalne rozwiązania takie jak MineGuard działają zasadniczo inaczej. Zamiast chronić serwer, nie dają ruchowi dotrzeć do niego.

Filtrowanie na poziomie XDP/eBPF

XDP (eXpress Data Path) obsługuje pakiety, zanim trafią do stosu TCP kernela. To najszybszy sposób filtrowania - pakiet jest dropowany bezpośrednio na poziomie sterownika sieciowego. Dla SYN-flooda w 10 Gbit/s to jedyna opcja, która nie obciąży CPU.

SYN Proxy na poziomie filtra

Filtr przyjmuje SYN od klienta, odpowiada SYN-ACK z SYN cookie i czeka na ACK. Jeśli ACK przyjdzie i cookie jest prawidłowe, filtr nawiązuje nowe połączenie do backendu i łączy je. Serwer backend widzi tylko ukończone, zwalidowane połączenia. Cały śmieć zostaje na filtrze.

Analiza wzorców

Profesjonalne filtry analizują TTL, TCP window size, MSS i inne parametry pakietów SYN. U prawdziwych klientów te wartości różnią się w zależności od OS (Windows, macOS, Linux, Android). U narzędzi do generowania SYN-flooda (hping3, scapy) wartości są zwykle domyślne albo anormalne. To pozwala filtrować podrobione SYN jeszcze przed sprawdzeniem cookie.

Różnica między SYN-floodem a innymi typami flooda

SYN-flood często mylą z innymi typami ataków TCP. Rozłóżmy różnice.

UDP Flood

UDP to protokół bez nawiązywania połączenia. UDP-flood po prostu zalewa łącze śmieciowymi pakietami. Nie eksploatuje handshake'u, tylko zapycha pasmo. Dla Java Edition (TCP) UDP-flood jest mniej groźny, bo pakiety UDP na port TCP są po prostu dropowane. Ale i tak zajmują łącze.

Dla Bedrock Edition (UDP) sytuacja jest odwrotna - UDP-flood tworzy bezpośrednie zagrożenie, a SYN-flood nie działa, bo Bedrock nie używa TCP.

ACK Flood

ACK-flood wysyła pakiety z flagą ACK bez poprzedzającego SYN. Dla stateful firewalla łatwo to wykryć i zdropować, bo nie ma odpowiadającego wpisu w connection tracking. Ale dla stateless serwerów pakiety ACK mogą dotrzeć do aplikacji i wywołać RST, tworząc obciążenie.

RST Flood

Pakiety RST są przeznaczone do przymusowego zerwania połączenia. Jeśli atakujący zgadnie sequence number aktywnego połączenia, może zerwać połączenie między graczem a serwerem. To bardziej celowany atak, i trudniejszy w realizacji niż SYN-flood.

TCP Connection Flood

Pełnoprawny TCP-flood: atakujący kończy handshake (SYN -> SYN-ACK -> ACK) i tworzy prawdziwe połączenia. To obchodzi SYN cookies, ale wymaga od atakującego użycia prawdziwych IP (bez spoofingu), co czyni go podatnym na blokowanie.

Realne scenariusze i liczby

Dla zrozumienia skali problemu, kilka realnych liczb.

Typowy SYN-flood na serwer Minecraft - od 100 000 do 5 000 000 pakietów na sekundę. Objętościowo to 50-200 Mbit/s, co nie wydaje się dużo w porównaniu z atakami objętościowymi 100+ Gbit/s. Ale SYN-flood to nie o objętość, tylko o wyczerpanie zasobów.

Niezabezpieczony serwer z domyślnymi ustawieniami (backlog 128) pada przy 1000 SYN/s. Serwer z tuningiem sysctl (backlog 65535, syncookies) wytrzymuje 50 000-100 000 SYN/s, ale zaczyna gubić pakiety i zwiększać latencję. Tylko filtrowanie sprzętowe albo XDP radzi sobie z milionami SYN/s.

W praktyce atakujący często łączą SYN-flood z innymi technikami. Najpierw idzie SYN-flood do przeciążenia stosu sieciowego, potem atak botowy Layer 7 z prawdziwymi połączeniami. Pierwsza fala odciąga zasoby, druga dobija. O tych kombinowanych atakach pisaliśmy szczegółowo w artykule o trendach ataków DDoS na Minecraft w 2026.

Scenariusz: atak na serwer podczas eventu

Typowa sytuacja: zapowiedziałeś turniej PvP, na serwerze 300 graczy. W momencie szczytowego obciążenia zaczyna się SYN-flood. Serwer i tak pracuje na granicy - 16 GB RAM, TPS balansuje na 19.5. SYN-flood dokłada obciążenia na CPU przez softirq, TPS spada do 15, gracze zaczynają narzekać na lagi. Potem backlog się przepełnia, nowi gracze nie mogą wejść. Ci, którzy się rozłączyli i próbują przełączyć, też nie mogą. W 10 minut tracisz połowę audytorium.

Scenariusz: SYN-flood jako zwiad

Czasami SYN-flood jest używany nie po to, żeby położyć serwer, tylko do zwiadu. Atakujący wysyła umiarkowany strumień pakietów SYN (5000-10000/s) i obserwuje reakcję. Jeśli serwer zaczyna odpowiadać wolniej, dostaje informację o jego zasobach i ochronie. Potem przychodzi prawdziwy atak, już z uwzględnieniem wykrytych słabości. Monitoring logów i alerty na anormalny wzrost SYN_RECV - sposób, żeby zauważyć taki zwiad.

Checklist: co robić, jeśli atakują teraz

Jeśli jesteś pod SYN-floodem i trzeba działać szybko:

1. Diagnostyka (30 sekund):

ss -s | grep synrecv
ss -tn state syn-recv | wc -l

2. Awaryjne włączenie syncookies:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=65535
sysctl -w net.ipv4.tcp_synack_retries=1

3. Iptables rate limiting:

iptables -I INPUT -p tcp --dport 25565 --syn -m limit --limit 50/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 --syn -j DROP

4. Jeśli atak trwa - podłączaj profesjonalną ochronę DDoS. Szczegółowy plan działań przy DDoS opisaliśmy w przewodniku "Serwer Minecraft pod DDoS: co robić".

Jak nie mylić SYN-flooda z innymi problemami

Nie każdy timeout to DDoS. Czasami serwer laguje z innych powodów, i ważne, żeby je rozróżniać.

Jeśli ss -s pokazuje normalną liczbę SYN_RECV (mniej niż 10), ale gracze narzekają na lagi, problem jest raczej w samym serwerze: spadki TPS, brak RAM, przeciążone chunki. Mamy osobny artykuł o diagnostyce lagów: DDoS czy problemy serwera.

Jeśli SYN_RECV jest podwyższony, ale nie krytycznie (20-50), być może to nie atak, tylko dużo graczy łączy się jednocześnie (po restarcie serwera albo event na serwerze). Sprawdź, czy IP w SYN_RECV odpowiadają prawdziwym graczom.

Jeszcze jeden częsty przypadek: hostingowiec włącza SYN flood protection po swojej stronie, która zaczyna dropować legalne pakiety SYN przy niewielkim obciążeniu. Symptomy wyglądają jak DDoS, ale naprawdę to nadmiernie agresywne filtrowanie. Sprawdza się wyłączeniem rate limit po stronie hostingu.

Automatyzacja monitoringu

Czekać, aż gracze zaczną narzekać - zła strategia. Prosty skrypt bash może monitorować SYN_RECV i wysyłać alert:

#!/bin/bash
THRESHOLD=100
COUNT=$(ss -tn state syn-recv | wc -l)
if [ "$COUNT" -gt "$THRESHOLD" ]; then
    echo "SYN flood alert: $COUNT SYN_RECV connections" | \
    curl -X POST -d @- https://discord.com/api/webhooks/YOUR_WEBHOOK
fi

Odpalaj przez cron co 10 sekund. Kiedy SYN_RECV przekroczy próg, dowiesz się o ataku natychmiast, a nie po 5 minutach, kiedy gracze zaczną pisać na Discordzie "serwer laguje".

Do bardziej zaawansowanego monitoringu można użyć nstat - narzędzia, które pokazuje deltę liczników sieciowych kernela:

nstat -z | grep -i syn

Zwróć uwagę na TcpExtTCPReqQFullDrop - to liczba pakietów SYN zdropowanych z powodu przepełnienia backlogu. Jeśli ten licznik rośnie, backlog jest pełny i prawdziwi gracze nie mogą się połączyć.

Wnioski

SYN-flood używa fundamentalnego mechanizmu TCP, i całkowite wyeliminowanie tej podatności jest niemożliwe bez zmiany samego protokołu. Ale można zminimalizować skutki.

Dla małego serwera (do 50 graczy) zwykle wystarczy poprawna konfiguracja sysctl + podstawowe reguły iptables. Dla serwerów większych z prawdziwą audytorium profesjonalna ochrona DDoS to nie luksus, tylko konieczność. Różnica między utratą wszystkich graczy na 4 godziny a filtrowaniem ataku bez ani jednego disconnecta, to różnica między hobby a projektem zarobkowym.

Skonfiguruj sysctl, dodaj reguły iptables, trzymaj pod ręką komendy diagnostyki. I pamiętaj: SYN-flood to tylko jeden typ ataku. Dobra ochrona zamyka wszystkie wektory jednocześnie.