Skydda Minecraft Bedrock-servern mot DDoS-attacker

En Minecraft Bedrock-server som försvinner ur serverlistan i några minuter på kvällen och sedan kommer tillbaka har sällan ett hårdvaruproblem. I de allra flesta fall pågår en attack, och den pågår precis när flest spelare är anslutna. Den här artikeln visar hur du skyddar en Minecraft Bedrock-server mot DDoS-attacker: först det du kan säkra själv utan extra kostnad, därefter den punkt där dessa åtgärder tar slut rent fysiskt, och till sist vad som måste hända i nätet framför servern.

Alla uppgifter gäller en Bedrock Dedicated Server, PocketMine-MP eller Nukkit under Debian 12, Debian 13, Ubuntu 22.04 LTS eller Ubuntu 24.04 LTS. Kommandona är skrivna för root, som vanlig användare sätter du sudo framför. Driver du Java Edition hittar du de protokollattacker som är typiska där i DDoS-skydd och nullping-skydd för Minecraft. Själva installationen av en Bedrock-server beskriver Installera en Minecraft Bedrock-server med Nukkit.

Om attacken pågår just nu: ändra ingenting i konfigurationen och starta inte om servern. Säkra först mätvärdena (avsnittet "Samla mätvärden innan det smäller"), efter attacken är de oåterkalleligt borta.

Varför Minecraft Bedrock-servrar så ofta är mål för DDoS-attacker

Bedrock Edition är den version som går på konsoler, smartphones, surfplattor och Windows, och den står för Minecrafts största spelarbas över huvud taget. Där många servrar står uppstår det största incitamentet för attacker: konkurrerande nätverk, bannade spelare, interna gräl. En attack kostar den som utlöser den varken kunnande eller nämnvärda pengar, en server-booter säljs som abonnemang.

Det tekniska skälet ligger djupare. En Bedrock-server talar UDP, inte TCP, och den svarar alla som frågar långt innan någon inloggning har skett. Precis de två egenskaperna gör port 19132 UDP till ett tacksamt mål. Vad en DDoS-attack är i grunden förklarar artikeln Vad är en DDoS-attack?.

RakNet: ett UDP-protokoll som svarar innan någon har loggat in

RakNet är det UDP-nätverksbibliotek som Minecraft Bedrock Edition sköter hela sin speltrafik genom. UDP känner inte till något anslutningsupprättande som en server skulle kunna kräva, och avsändaradresser går därför att förfalska. RakNet bygger sitt eget tillförlitlighetslager ovanpå: sekvensnummer, bekräftelser (ACK) och negativa bekräftelser (NAK), med vilka en klient kan begära om förlorade paket.

Anslutningsupprättandet består av sju paket, fyra från klienten och tre från servern:

Client  -> Server   Open Connection Request 1
Server  -> Client   Open Connection Reply 1
Client  -> Server   Open Connection Request 2
Server  -> Client   Open Connection Reply 2
Client  -> Server   Connection Request
Server  -> Client   Connection Request Accepted
Client  -> Server   New Incoming Connection

Först därefter skickar klienten inloggningspaketet med sina Xbox Live-uppgifter. Det är den avgörande meningen för alla som vill säkra sin Bedrock-server: servern har behandlat sju paket, lagt ner processortid och minne och svarat flera gånger, innan den över huvud taget får veta vem som knackar på. Varje åtgärd som sätter in vid inloggningen griper alltså först när belastningen redan har uppstått.

Till det kommer en andra, ännu tidigare ingång. För att en server ska visas i en spelares serverlista med namn, version och spelarantal besvarar den en Unconnected Ping (paket-ID 0x01) med en Unconnected Pong (paket-ID 0x1C). Det utbytet sker före själva anslutningsupprättandet, kräver inget som helst bevis och går inte att stänga av på Bedrock Dedicated Server utan att ta bort servern ur varje serverlista.

Unconnected Ping som förstärkningsvektor: siffrorna

En förstärkningsattack (amplification) är en attack där angriparen skickar små förfrågningar med förfalskad avsändaradress till främmande servrar, så att deras större svar landar hos offret. Bedrock-servern attackeras därvid inte, den används. Vid Unconnected Ping ser räkningen ut så här:

Två saker följer omedelbart av det. För det första: ett långt servernamn förstorar svaret och därmed den förstärkningsfaktor som du ställer till främmande angripares förfogande. Ett kort namn är ingen kosmetik, utan en skyddsåtgärd. För det andra: faktorn 4 i standardkonfigurationen är liten nog för att din server ska förbli ointressant som reflektor, men stor nog för att en pingflod ska belasta din egen utgående nätanslutning med fyra gånger så mycket som kommer in.

Förstärkningsfelet från 2024 visar hur illa det kan bli när tillförlitlighetslagret självt missbrukas. I det RakNet-bibliotek som användes då var paketet Connection Request Accepted markerat som tillförlitligt. En angripare kunde spela igenom anslutningsupprättandet med förfalskad avsändaradress fram till den punkten och därefter skicka en enda negativ bekräftelse med intervallet 0 till 8191. Servern skickade sedan tusentals paket till den förfalskade adressen utan att angriparen behövde göra något mer. Det åtgärdades genom att paketet ställdes om till otillförlitligt, genom att en cookie skickas med i Open Connection Reply 1 som en äkta klient speglar tillbaka, och genom att paketgränser infördes: 120 paket per källadress och 10-millisekunderstakt, 1 000 paket totalt per takt.

Bedrock Edition eller Java Edition: vad som skiljer i DDoS-skyddet

Den som redan har säkrat en Java-server för över nästan allt fel. De båda editionerna delar namn, men inte nätverksprotokoll:

Raden om SYN-cookies är den viktigaste. Hos Java Edition avvärjer Linux-kärnan en SYN-flod utan att Minecraft-processen märker något av det. Hos Bedrock Edition finns inte den hjälpen: varje enskilt UDP-paket skickas vidare ända in i serverprocessen och utvärderas där. En Bedrock-server har inget inbyggt skydd i operativsystemet mot en flod mot port 19132, eftersom UDP inte känner till något.

Raden om den saknade SRV-posten har en praktisk följd som överraskar många: du kan inte gömma porten bakom en DNS-post i Bedrock Edition. Spelarna skriver in adress och port för hand. Den som flyttar porten måste meddela varje spelare den nya porten.

Portarna som det faktiskt handlar om

En Bedrock Dedicated Server binder sig till exakt två portar, och det på båda över UDP. I server.properties:

server-port=19132
server-portv6=19133
enable-lan-visibility=true
online-mode=true
allow-list=false
max-players=10
player-idle-timeout=30
max-threads=8

Det är Microsofts standardvärden, att läsa i referensen till Bedrock Dedicated Server. Runt de båda portarna ligger ytterligare tjänster som körs med beroende på serverprogramvara:

Den tredje och den fjärde raden är de vanligaste undvikbara felen på Bedrock-servrar. Hos Nukkit och PocketMine-MP står enable-query på från fabrik, och hos Nukkit hamnar ett av misstag påslaget RCON på 19132 TCP, alltså på samma portnummer som spelet. Den som bara tittar efter "19132 är öppen, det stämmer ju" missar det.

En egenhet hos den officiella Bedrock Dedicated Server hör också hemma här: den känner inte till något direktiv server-ip. PocketMine-MP och Nukkit har det (server-ip, hos PocketMine dessutom server-ipv6), den officiella servern inte. Den lyssnar alltså alltid på alla adresser i systemet, och brandväggen är din enda möjlighet att begränsa det.

Vad du kan göra själv innan du lägger pengar på saken

Det här avsnittet är det längsta, och det med avsikt. En rent konfigurerad Bedrock-server klarar små och medelstora attacker av egen kraft, oavsett hos vem den står.

1. Inventering: vad lyssnar egentligen på 19132?

Innan du skriver en enda regel, se efter vad din server erbjuder utåt. Inte gissa, titta efter:

ss -lntup
ss -lnup sport = :19132

Intressant är kolumnen med den lokala adressen. 0.0.0.0:19132 och [::]:19133 betyder "nåbar från hela internet". Dyker det upp en TCP-post på samma portnummer bredvid, körs RCON. Angriparens vy får du genom en portskanning utifrån, för UDP med -sU:

nmap -Pn -sU -p 19132,19133 DIN.SERVER.IP.ADRESS
nmap -Pn -p- --min-rate 1000 DIN.SERVER.IP.ADRESS

2. Lämna bara 19132 UDP öppen, stäng allt annat

För en Bedrock-server räcker en enda öppning utåt, två med IPv6. Med UFW ser det ut så här, och det exakt i den här ordningen, så att du inte låser ute dig själv:

ufw allow 22/tcp comment 'SSH'
ufw allow 19132/udp comment 'Bedrock IPv4'
ufw allow 19133/udp comment 'Bedrock IPv6'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Har du inga IPv6-spelare utelämnar du raden för 19133 och sätter hos PocketMine-MP dessutom enable-ipv6=false. Varje port som du inte öppnar är en port som du inte behöver försvara. Den fullständiga anvisningen inklusive räddningsväg står i Sätta upp UFW-brandväggen utan att låsa ute dig själv.

3. Stäng av LAN-synligheten, annars förblir 19132 öppen

Det är fällan som nästan alla går i som vill flytta porten. Direktivet enable-lan-visibility står från fabrik på true och gör att servern svarar på sökförfrågningar i det lokala nätet. Microsoft skriver uttryckligen att servern därigenom dessutom binder till standardportarna 19132 och 19133, även när server-port och server-portv6 har andra värden.

Den som alltså flyttar porten till 19140 och vaggar sig i säkerhet lyssnar fortfarande på 19132. För en server på internet hör därför detta hemma i server.properties:

enable-lan-visibility=false

Kontrollera därefter med ss -lnup att 19132 verkligen har försvunnit. På köpet löser samma inställning problemet att två Bedrock-servrar på samma värd tar porten från varandra.

4. Stäng av query och RCON

PocketMine-MP och Nukkit har GS4-query inbyggt, en UDP-serverförfrågan enligt mönstret från UT3-protokollet, och de besvarar de förfrågningarna på samma port 19132 som spelet går på. Det utförliga svaret innehåller servernamnet, versionen, världsnamnet, whitelistens tillstånd, adress och port, spelarantalet, namnen på alla anslutna spelare och hos PocketMine-MP på begäran den fullständiga plugin-listan. Det är praktiskt för statussidor och Discord-botar, men avslöjar för en angripare exakt när en attack lönar sig, och kostar processortid per förfrågan.

enable-query=off
enable-rcon=off

Hos PocketMine-MP heter värdena false i stället för off, och plugin-listan stänger du av i pocketmine.yml med settings.query-plugins: false. En bedömning som man sällan läser: GS4-query hos PocketMine-MP kontrollerar en token som är saltad med avsändaradressen. Det stora svaret går därmed inte att reflektera till en förfalskad adress. Förfrågan kostar ändå processortid, och de publicerade uppgifterna hjälper angriparen vid målvalet. Den officiella Bedrock Dedicated Server känner varken till query eller RCON, där faller den här punkten bort.

Om du verkligen behöver RCON sätter du hos Nukkit absolut rcon.port till ett eget värde och öppnar den bara för din egen adress. Återfallet på server-port betyder annars att en fjärrstyrning av din server lyssnar på 19132 TCP, alltså på samma siffra som du ändå har skrivit in överallt som "öppen".

5. Framtvinga Xbox Live-autentisering

Xbox Live-autentiseringen är kontrollen av om en anslutande spelare har ett äkta konto signerat av Microsoft. Den står på från fabrik i alla tre serverprogramvarorna och ska förbli det.

Hos Bedrock Dedicated Server heter direktivet online-mode, hos PocketMine-MP och Nukkit heter det xbox-auth. I båda fallen är true fabriksläget och det rätta värdet:

online-mode=true
xbox-auth=true

Microsoft formulerar en viktig begränsning till detta: klienter som ansluter till en server utanför det lokala nätet behöver Xbox Live-autentiseringen ändå alltid, oberoende av den här inställningen. Beviset överförs som en signerad kedja av tokens i inloggningspaketet, tillsammans med Xbox-identiteten (XUID) och visningsnamnet.

Och nu den del som hjälper mot missförstånd: Xbox Live-autentiseringen skyddar din spellogik, inte din nätanslutning. Den sker i inloggningspaketet, alltså efter det fullständiga RakNet-upprättandet. En angripare som flodar din server vill inte ansluta alls. Hans paket avvisas, men de har ändå kommit fram, och det är precis poängen.

6. Allowlist och spelartak, och vad de inte klarar

Allowlist (tidigare whitelist) är listan över de spelare som får ansluta. Hos Bedrock Dedicated Server slår du på den med allow-list=true, posterna står i allowlist.json med namn, XUID och fältet ignoresPlayerLimit. Hos Nukkit och PocketMine-MP heter direktivet fortfarande white-list.

allow-list=true
max-players=60
player-idle-timeout=15

En kort inaktivitetstid via player-idle-timeout är verksam mot platsutmattning: spelare som bara upptar en plats åker ut efter det angivna antalet minuter. Värdet 0 betyder att ingen någonsin kopplas bort på grund av inaktivitet, och precis det utnyttjar en angripare som blockerar dina platser med äkta konton.

Även här gäller gränsen från föregående avsnitt, och den är den punkt som förbises allra oftast: allowlist kontrolleras först när inloggningspaketet har behandlats. Den förhindrar anslutningar, inte paket.

7. Begränsa paketfrekvensen per källadress

Mot små attacker och slarviga botar hjälper en övre gräns per källadress. För UDP arbetar man med hashlimit, inte med connlimit, eftersom UDP inte känner till några anslutningar:

iptables -I INPUT -p udp --dport 19132 -m hashlimit --hashlimit-name bedrock_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

Regeln förkastar UDP-paket så snart samma källadress varaktigt skickar mer än 400 paket per sekund. Värdet är ett startvärde, inte en sanning: en full server med 60 spelare och stor siktvidd genererar betydligt fler paket än en tom, och den som ställer in för snävt kastar ut sina egna spelare. Mät först en vecka i normal drift.

Betydligt snävare får du ställa in vid Unconnected Ping, eftersom en äkta klient bara frågar efter serverstatus så länge serverlistan är öppen, och då i sekundtakt. Med nftables går det att träffa exakt det ena paketet, eftersom paket-ID är den första byten efter UDP-huvudet:

nft add table inet bedrock
nft add chain inet bedrock prerouting '{ type filter hook prerouting priority -150 ; policy accept ; }'
nft add rule inet bedrock prerouting udp dport 19132 @th,64,8 0x01 limit rate over 500/second drop

Uttrycket @th,64,8 läser åtta bitar från den 64:e biten i transporthuvudet, alltså den första byten i UDP-nyttolasten. Värdet 0x01 är paket-ID för Unconnected Ping. Samma ställe kan du använda för att observera innan du förkastar någonting:

tcpdump -ni eth0 'udp dst port 19132 and udp[8] = 0x01' -c 200 -q
tcpdump -ni eth0 'udp src port 19132 and udp[8] = 0x1c' -c 200 -q

Den första raden räknar inkommande statusförfrågningar, den andra dina egna svar. Går båda upp i tusental i sekundtakt medan knappt någon spelar, ser du en pingflod och inte dina spelare.

Två anmärkningar om hållbarheten. Rena iptables-regler är borta efter en omstart, under Debian och Ubuntu sparar man dem så här:

apt-get install -y iptables-persistent
netfilter-persistent save

Och under UFW hör sådana regler hemma i /etc/ufw/before.rules, eftersom de annars försvinner vid nästa ufw reload.

8. Avlasta kärnans anslutningsspårning

En flaskhals som slår till mycket tidigare vid UDP-spel än vid TCP: kärnan lägger upp en post i anslutningsspårningen för varje par av UDP-paket. Vid en flod med förfalskade avsändaradresser är varje paket en ny källadress och därmed en ny post. Går tabellen full förkastar servern även legitima paket, och i loggen står "nf_conntrack: table full, dropping packet".

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Ligger räknarställningen varaktigt nära den övre gränsen kan du undanta speltrafiken från spårningen. Det är verksamt, men inte utan följder, därför i båda riktningarna och med ett anslutningstest efteråt:

iptables -t raw -I PREROUTING -p udp --dport 19132 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --sport 19132 -j NOTRACK

Därefter griper tillståndsbaserade regler inte längre för den trafiken. Din öppning för 19132 UDP måste alltså vara en riktig portöppning och får inte förlita sig på tillståndet ESTABLISHED. Kontrollera efter att du satt dem med conntrack -L | grep 19132 att inga poster uppstår längre, och anslut en gång med spelet innan du sparar reglerna permanent.

9. Driv Geyser och Floodgate på ett rent sätt

Geyser är en brygga som låter Bedrock-klienter spela på en Java Edition-server: den tar emot Bedrock-anslutningar på 19132 UDP, översätter protokollet och talar på andra sidan med Java-servern på 25565 TCP. Floodgate är komplementet som låter dessa Bedrock-spelare ansluta utan Java-konto. För DDoS-skyddet betyder det tre saker.

För det första: håll Geyser uppdaterat. Just den bryggan var två gånger orsaken till dokumenterade attacker. I mars 2024 utnyttjades det ovan beskrivna förstärkningsfelet i RakNet-biblioteket brett, åtgärdat från build 478. I juli 2025 följde ett andra fall: ett upprepat skickat paket för bekräftelse av resurspaketen skapade flera sessioner per spelare, och frånkopplade klienter kunde fortsätta skicka paket eftersom nätverkskanalen inte stängdes. Åtgärdat från build 897. Båda fallen har publicerats av projektet självt med tidslinje.

För det andra: Java-servern hör inte hemma på öppna nätet. I Geyser-konfigurationen pekar remote.address på auto respektive 127.0.0.1 och remote.port på 25565. Bind Java-servern lokalt i enlighet med det och öppna inte 25565 TCP utåt. Annars har du två angreppsytor i stället för en, och den andra är den som du aldrig har tänkt ut några regler för.

För det tredje: filen key.pem är en hemlighet. Den är nyckeln som Floodgate hoppar över Java-autentiseringen för Bedrock-konton med. Den som lägger den i ett offentligt repository, kopierar in den i ett supportärende eller visar den på en skärmbild har skänkt bort inloggningen till sin server. Projektet varnar uttryckligen för det.

10. Samla mätvärden innan det smäller

Det viktigaste steget är det som nästan ingen tar i förväg: lägga upp en jämförelsegrund medan allt fungerar normalt. Utan ett normalvärde kan du efter en incident inte säga om 40 000 paket per sekund var mycket eller helt enkelt lördagskväll. Med apt-get install -y vnstat sysstat conntrack löper mätningen permanent i bakgrunden.

sar -n DEV 1 10
ip -s link show eth0
ss -lunp sport = :19132
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|UdpRcvbufErrors'
dmesg -T | tail -50

Tre av de här värdena är särskilt talande på en Bedrock-server. Ett Recv-Q som varaktigt skiljer sig från noll på UDP-socketen för 19132 betyder att serverprocessen inte längre hinner hämta de ankommande paketen tillräckligt snabbt. UdpRcvbufErrors räknar exakt de paket som därför förkastades, och är det hårdaste beviset för att det inte är nätanslutningen utan processen som är flaskhalsen. UdpNoPorts stiger när någon beskjuter portar där ingenting alls lyssnar, en typisk bild vid en brett spridd portskanning före den egentliga attacken.

För tcpdump gäller: begränsa alltid med -c, en inspelning under full belastning belastar en redan överlastad server ytterligare. Hur du tolkar värdena står i Upptäcka en DDoS-attack.

Var de här åtgärderna tar slut: bandbredd och paketfrekvens

Nu den del som ingen konfigurationsfil kan lösa. Alla åtgärder hittills går på din server, alltså i änden av nätanslutningen. En brandväggsregel avgör vad som händer med ett paket som redan har gått genom kabeln. Du kan förkasta det, men inte göra det oskickat.

Räkna på det en gång. Din nätanslutning är full så snart någon skickar mer än 125 megabyte per sekund. En attack på 5 till 50 Gbit/s ligger på fem till femtio gånger så mycket. Om din hashlimit-regel bakom den är bra spelar då ingen roll längre, för dina spelares paket kommer inte fram redan innan dess.

Den andra storheten är paketfrekvensen, och på en Bedrock-server slår den nästan alltid till först. Hela speltrafiken består av många små UDP-paket, och just i den disciplinen är en angripare som billigast ute. En attack som inte ens fyller en tredjedel av din nätanslutning kan ändå lägga din server, eftersom processortiden går åt till att utvärdera och förkasta. Operatörer upplever det som "belastningen var ju inte alls hög, ändå åkte alla ut". I spelet visar sig samma sak som lagspikar, gummibandseffekter och avbrutna anslutningar mitt i bygget.

För det finns ingen lokal inställning. Volymetriska attacker måste ta slut i nätet framför servern.

Vad KernelHost ställer mot DDoS-attacker på Bedrock-servrar

Det permanenta skyddet som ingår i varje server

KernelHosts DDoS-skydd är uppbyggt i två steg och permanent aktivt, utan att du måste slå på, beställa eller konfigurera något:

• Steg 1: 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket. Volymetriska attacker rensas nära sin källa innan de når datacentret.
• Steg 2: Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main. Direkt framför servern känns protokollspecifika mönster igen och förkastas, paket för paket. Dit hör även UDP-mönster på 19132 som inte visar något RakNet-beteende.

Två egenskaper är avgörande. Skyddet går permanent och behöver inte först reagera på en attack, det finns alltså inga minuter i början då servern är borta. Och ingen null-routning används: din IP-adress blir kvar i nätet, bara de skadliga paketen förkastas. Den som tar IP-adressen ur nätet uppnår för dig samma resultat som angriparen. Platsen är Frankfurt am Main. Vilka spel och protokoll som täcks listar DDoS-skydd för spelservrar i realtid.

Advanced DDoS Protection för projekt under ständig beskjutning

Vissa projekt attackeras inte tillfälligt utan riktat och under veckor. För sådana fall finns Advanced DDoS Protection från 50,00 EUR i månaden, PrePaid och utan bindningstid. Skillnaden ligger inte i mer kapacitet, utan i kontrollen:

• Dedikerad skydds-IP ur Frankfurt-kärnan, som din server ställs om till inom det egna nätet. På din sida behövs ingen ombyggnad.
• Skyddsregler per port och protokoll som du hanterar själv i kundportalen: du ställer in vad som tillåts på 19132 UDP, vad som tillåts på 19133 UDP och vad som tillåts på en avvikande port, om du har flyttat din server.
• Ändringar träder i kraft i realtid, du kan alltså justera under en pågående attack i stället för att vänta på ett underhållsfönster.
• Skyddsprofil anpassad till respektive spel. För Minecraft finns färdiga profiler, likaså för modifierade och egna applikationer på valfria TCP- eller UDP-portar, alltså även för Nukkit, PocketMine-MP eller en Geyser-instans på en självvald port.

De båda stegen i jämförelse

För de flesta Bedrock-projekt räcker det inkluderade permanenta skyddet tillsammans med en ren serverkonfiguration. Advanced DDoS Protection är svaret på att någon tar det personligt. Den som för närvarande driver sin server någon annanstans löser problemet enklast med en flytt: filtreringen verkar i nätet framför servern, och det nätet måste vara vårt.

Vanliga fel och lösningar

"Jag ändrade porten till 19140, 19132 är ändå öppen": Det är enable-lan-visibility=true. Bedrock Dedicated Server binder då dessutom till 19132 och 19133, oavsett vad som står i server-port. Sätt till false, starta om servern, kontrollera med ss -lnup.

"Jag redigerade allowlist.json och kommer själv inte in längre": Två orsaker är vanliga. Det ligger kvar en gammal whitelist.json i katalogen som servern läser i stället, eller så saknas XUID-posten eller är felaktig. Namnet ensamt räcker inte tillförlitligt vid aktiv Xbox Live-autentisering.

"Min leverantör spärrade min server trots att jag var den angripne": Kontrollera om din server själv har skickat ut paket. Precis det hände vid RakNet-förstärkningsfelet 2024: de berörda servrarna skickade tusentals paket till främmande adresser, och i abuse-anmälningarna stod port 19132 som källa. Med tcpdump -ni eth0 'udp src port 19132' -c 200 -q ser du vart din server svarar. En aktuell build undanröjer orsaken.

"Mina iptables-regler biter inte": Tre orsaker är vanliga. Reglerna står bakom UFW-kedjorna och nås aldrig, de var borta efter den senaste omstarten (då hjälper netfilter-persistent save eller en post i /etc/ufw/before.rules), eller så är attacken volymetrisk och regeln arbetar korrekt vid en nätanslutning som redan är full. Kontrollera med iptables -L INPUT -n -v om träffräknarna stiger. Står de kvar på noll nås regeln inte.

"Servern står i listan, men ingen kommer in": Visar posten namn och spelarantal fungerar Unconnected Pong, alltså är porten i grunden nåbar. Misslyckas anslutningen ändå hänger det oftast på Xbox Live-inloggningen eller på allowlist. Kommer omvänt bara IPv6-spelare inte in, saknas öppningen för 19133 UDP.

"Servern går, men alla har lagspikar": Det är oftare ett plugin än en attack. Se först efter om Recv-Q växer på UDP-socketen och om UdpRcvbufErrors stiger. Förblir båda lugna och sar -n DEV 1 10 oförändrad var det ingen DDoS-attack, utan serverprocessen själv. Hos Bedrock Dedicated Server hjälper då skriptvakthundarna vidare, vilkas trösklar står i server.properties under script-watchdog-hang-threshold och script-watchdog-slow-threshold.

"Min tidigare leverantör har spärrat min IP-adress": Det är null-routning. Leverantören skyddar därmed sitt eget nät, för dig är resultatet identiskt med en lyckad attack, oftast i timmar därefter. Fråga i tveksamma fall om det filtreras eller null-routas. Svaret avgör mer om din tillgänglighet än varje hårdvaruuppgift.

"I tcpdump ser jag inget anmärkningsvärt": Filtreras trafiken redan i nätet framför kommer som väntat ingenting fram på servern. Det är normalfallet vid fungerande filtrering. Omvänt gäller: är nätanslutningen mättad når dig under vissa omständigheter inte ens SSH-sessionen som du ville mäta med. Använd då VNC-konsolen i kundportalen, som fungerar oberoende av gästsystemets nätverk.

Kort sammanfattat

• En Minecraft Bedrock-server behöver exakt en öppen port utåt: 19132 UDP, därtill 19133 UDP bara för IPv6-spelare. Query, RCON, skriptfelsökaren på 19144 TCP och en Java-server bakom Geyser på 25565 TCP hör inte hemma på öppna nätet.
• Den som flyttar porten måste sätta enable-lan-visibility=false, annars binder Bedrock Dedicated Server dessutom fortfarande till 19132 och 19133.
• Xbox Live-autentisering och allowlist griper först i inloggningspaketet, alltså efter det fullständiga RakNet-upprättandet. De skyddar din spellogik och dina platser, inte din nätanslutning.
• Unconnected Ping frågas med 33 byte och besvaras med cirka 131 byte, en förstärkningsfaktor på ungefär fyra. Ett kort servernamn håller den faktorn liten.
• Vid UDP hjälper hashlimit i stället för connlimit, och kärnans anslutningsspårning går full först av allt vid förfalskade avsändaradresser. Båda bör du ha mätt före den första attacken.
• Från ungefär 1 Gbit/s är din nätanslutning full, och vid paket på 64 byte får cirka 1,49 miljoner paket per sekund plats där. Däröver avgör uteslutande filtreringen i nätet framför servern.
• Hos KernelHost ingår det permanenta skyddet i två steg i varje serverpaket, är aktivt från leveransen och utan null-routning. Advanced DDoS Protection kompletterar det med en dedikerad skydds-IP och regler per port som du hanterar själv.

Går ditt projekt redan hos KernelHost är filtreringen aktiv utan att du behöver göra något. Märker du ändå något anmärkningsvärt öppnar du ett supportärende, så att filterreglerna för din IP-adress justeras. Vid en pågående attack når du oss dessutom via WhatsApp-nödchatten på +43 650 8209883.