Minecraft-Bedrock-server beschermen tegen DDoS-aanvallen

Een Minecraft-Bedrock-server die 's avonds een paar minuten uit de serverlijst verdwijnt en daarna terugkomt, heeft zelden een hardwareprobleem. Meestal loopt er een aanval, en wel precies op het moment dat de meeste spelers online zijn. Dit artikel laat zien hoe u een Minecraft-Bedrock-server beschermt tegen DDoS-aanvallen: eerst wat u zonder extra kosten zelf kunt afschermen, daarna de plek waar die maatregelen fysiek ophouden, en tot slot wat er in het netwerk vóór de server moet gebeuren.

Alle informatie hier gaat uit van een Bedrock Dedicated Server, PocketMine-MP of Nukkit onder Debian 12, Debian 13, Ubuntu 22.04 LTS of Ubuntu 24.04 LTS. De commando's zijn voor root geschreven; als gewone gebruiker zet u er sudo voor. Wie de Java Edition draait, vindt de daar gebruikelijke protocolaanvallen in Minecraft-DDoS-bescherming en Nullping-bescherming. De installatie zelf van een Bedrock-server beschrijft Minecraft Bedrock-server met Nukkit installeren.

Loopt de aanval op dit moment: verander nu niets aan de configuratie en start de server niet opnieuw op. Leg eerst de meetwaarden vast (paragraaf "Meetwaarden verzamelen voordat het knalt"), na de aanval zijn ze onherroepelijk verdwenen.

Waarom Minecraft-Bedrock-servers zo vaak doelwit van DDoS-aanvallen zijn

De Bedrock Edition is de uitvoering die op consoles, smartphones, tablets en Windows draait, en zij vormt veruit de grootste spelersbasis van Minecraft. Waar veel servers staan, ontstaat de grootste prikkel voor aanvallen: concurrerende netwerken, verbannen spelers, interne conflicten. Een aanval kost de veroorzaker daarbij kunde noch noemenswaardig geld, een server booter wordt als abonnement verkocht.

De technische reden ligt dieper. Een Bedrock-server spreekt UDP, niet TCP, en hij antwoordt iedereen die vraagt, lang voordat er enige aanmelding heeft plaatsgevonden. Precies die twee eigenschappen maken poort 19132 UDP tot een dankbaar doelwit. Wat een DDoS-aanval in de basis is, legt het artikel Wat is een DDoS-aanval? uit.

RakNet: een UDP-protocol dat antwoordt voordat iemand zich heeft aangemeld

RakNet is de UDP-netwerkbibliotheek waarmee de Minecraft Bedrock Edition haar volledige spelverkeer afwikkelt. UDP kent geen verbindingsopbouw die een server zou kunnen eisen, en afzenderadressen laten zich daarom vervalsen. RakNet bouwt zijn eigen betrouwbaarheidslaag daaroverheen: volgnummers, bevestigingen (ACK) en negatieve bevestigingen (NAK), waarmee een client verloren pakketten opnieuw kan opvragen.

De verbindingsopbouw bestaat uit zeven pakketten, vier van de client en drie van de server:

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

Pas daarna stuurt de client het loginpakket met zijn Xbox Live-gegevens. Dat is de doorslaggevende zin voor iedereen die zijn Bedrock-server wil afschermen: de server heeft zeven pakketten verwerkt, rekentijd en geheugen besteed en meermaals geantwoord voordat hij zelfs maar verneemt wie er aanklopt. Elke maatregel die bij de aanmelding aangrijpt, werkt dus pas nadat de belasting al is ontstaan.

Daar komt een tweede, nog eerder gelegen instappunt bij. Opdat een server in de serverlijst van een speler met naam, versie en spelersaantal verschijnt, beantwoordt hij de Unconnected Ping (pakket-ID 0x01) met een Unconnected Pong (pakket-ID 0x1C). Die uitwisseling vindt vóór de eigenlijke verbindingsopbouw plaats, verlangt geen enkel bewijs en laat zich bij de Bedrock Dedicated Server niet uitschakelen zonder de server uit elke serverlijst te halen.

Unconnected Ping als versterkingsvector: de cijfers

Een versterkingsaanval (amplification) is een aanval waarbij de aanvaller kleine verzoeken met vervalst afzenderadres naar vreemde servers stuurt, zodat de grotere antwoorden daarvan bij het slachtoffer belanden. De Bedrock-server wordt daarbij niet aangevallen, maar gebruikt. Bij de Unconnected Ping ziet de rekensom er zo uit:

Twee dingen volgen daar direct uit. Ten eerste: een lange servernaam vergroot het antwoord en daarmee de versterkingsfactor die u aan vreemde aanvallers ter beschikking stelt. Een korte naam is geen cosmetica, maar een beschermingsmaatregel. Ten tweede: de factor 4 van de standaardconfiguratie is klein genoeg om uw server als reflector oninteressant te houden, maar groot genoeg dat een pingvloed uw eigen uitgaande lijn belast met het viervoudige van wat er binnenkomt.

De versterkingsfout van 2024 laat zien hoe erg het kan worden wanneer de betrouwbaarheidslaag zelf wordt misbruikt. In de toen gebruikte RakNet-bibliotheek was het pakket Connection Request Accepted als betrouwbaar gemarkeerd. Een aanvaller kon de verbindingsopbouw met vervalst afzenderadres tot dat punt doorspelen en daarna één enkele negatieve bevestiging met het bereik 0 tot 8191 sturen. De server stuurde daarop duizenden pakketten naar het vervalste adres, zonder dat de aanvaller verder iets hoefde te doen. Verholpen werd dat door het pakket op onbetrouwbaar te zetten, door in Open Connection Reply 1 een cookie mee te sturen dat een echte client terugkaatst, en door pakketlimieten in te voeren: 120 pakketten per bronadres en cyclus van 10 milliseconden, 1.000 pakketten in totaal per cyclus.

Bedrock Edition of Java Edition: wat bij de DDoS-bescherming anders is

Wie al eens een Java-server heeft afgeschermd, brengt bijna alles verkeerd over. De twee edities delen de naam, maar niet het netwerkprotocol:

De regel over de SYN-cookies is de belangrijkste. Bij de Java Edition weert de Linux-kernel een SYN-vloed af zonder dat het Minecraft-proces daar iets van merkt. Bij de Bedrock Edition bestaat die hulp niet: elk afzonderlijk UDP-pakket wordt tot in het serverproces doorgegeven en daar beoordeeld. Een Bedrock-server heeft tegen een flood op poort 19132 geen ingebouwde bescherming in het besturingssysteem, omdat UDP er geen kent.

De regel over het ontbrekende SRV-record heeft een praktisch gevolg dat velen verrast: u kunt de poort bij de Bedrock Edition niet achter een DNS-record verstoppen. Spelers voeren adres en poort met de hand in. Wie de poort verlegt, moet elke speler de nieuwe poort meedelen.

De poorten waar het werkelijk om gaat

Een Bedrock Dedicated Server bindt zich aan precies twee poorten, en wel op beide via UDP. In de 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

Dat zijn de standaardinstellingen van Microsoft, na te lezen in de referentie bij de Bedrock Dedicated Server. Rondom die twee poorten liggen nog andere diensten die afhankelijk van de serversoftware meedraaien:

De derde en de vierde regel zijn de meest gemaakte vermijdbare fouten op Bedrock-servers. Bij Nukkit en PocketMine-MP staat enable-query af fabriek aan, en bij Nukkit belandt een per ongeluk ingeschakelde RCON op 19132 TCP, dus op hetzelfde poortnummer als het spel. Wie alleen kijkt naar "19132 is open, dat zit wel goed", ziet dat over het hoofd.

Een eigenaardigheid van de officiële Bedrock Dedicated Server hoort hier eveneens thuis: hij kent geen directive server-ip. PocketMine-MP en Nukkit hebben die wel (server-ip, bij PocketMine bovendien server-ipv6), de officiële server niet. Hij luistert dus altijd op alle adressen van het systeem, en de firewall is uw enige mogelijkheid om dat te beperken.

Wat u zelf kunt doen voordat u geld uitgeeft

Dit hoofdstuk is het langste, en dat met opzet. Een netjes geconfigureerde Bedrock-server houdt kleine en middelgrote aanvallen op eigen kracht uit, ongeacht bij wie hij staat.

1. Inventarisatie: wat luistert er eigenlijk op 19132?

Voordat u ook maar één regel schrijft, kijkt u na wat uw server naar buiten aanbiedt. Niet gokken, maar kijken:

ss -lntup
ss -lnup sport = :19132

Interessant is de kolom met het lokale adres. 0.0.0.0:19132 en [::]:19133 betekenen "vanaf het hele internet bereikbaar". Duikt daarnaast een TCP-vermelding op hetzelfde poortnummer op, dan draait RCON. Het beeld van de aanvaller levert een poortscan van buitenaf, voor UDP met -sU:

nmap -Pn -sU -p 19132,19133 UW.SERVER.IP.ADRES
nmap -Pn -p- --min-rate 1000 UW.SERVER.IP.ADRES

2. Alleen 19132 UDP openlaten, al het andere sluiten

Voor een Bedrock-server volstaat één enkele openstelling naar buiten, twee met IPv6. Met UFW ziet dat er zo uit, en wel precies in deze volgorde, zodat u zichzelf niet buitensluit:

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

Hebt u geen IPv6-spelers, laat dan de regel voor 19133 weg en zet bij PocketMine-MP bovendien enable-ipv6=false. Elke poort die u niet vrijgeeft, is een poort die u niet hoeft te verdedigen. De volledige handleiding inclusief reddingsweg staat in UFW-firewall instellen zonder uzelf buiten te sluiten.

3. De LAN-zichtbaarheid uitschakelen, anders blijft 19132 open

Dat is de val waar bijna iedereen in trapt die de poort wil verleggen. De directive enable-lan-visibility staat af fabriek op true en zorgt ervoor dat de server op zoekopdrachten in het lokale netwerk antwoordt. Microsoft schrijft daarover uitdrukkelijk dat de server daardoor bovendien aan de standaardpoorten 19132 en 19133 bindt, ook wanneer server-port en server-portv6 andere waarden hebben.

Wie dus de poort naar 19140 verlegt en zich veilig waant, luistert nog steeds op 19132. Voor een server op het internet hoort daarom in de server.properties:

enable-lan-visibility=false

Controleer daarna met ss -lnup dat 19132 werkelijk verdwenen is. Overigens lost dezelfde instelling het probleem op dat twee Bedrock-servers op dezelfde host elkaar de poort afnemen.

4. Query en RCON uitschakelen

PocketMine-MP en Nukkit brengen de GS4-query mee, een UDP-serveropvraag naar het model van het UT3-protocol, en zij beantwoorden die opvragen op dezelfde poort 19132 waarop het spel draait. Het uitgebreide antwoord bevat de servernaam, de versie, de wereldnaam, de toestand van de whitelist, adres en poort, het spelersaantal, de namen van alle verbonden spelers en bij PocketMine-MP desgewenst de volledige pluginlijst. Dat is handig voor statuspagina's en Discord-bots, maar het verraadt een aanvaller precies wanneer een aanval loont, en het kost per opvraag rekentijd.

enable-query=off
enable-rcon=off

Bij PocketMine-MP luiden de waarden false in plaats van off, en de pluginlijst schakelt u in de pocketmine.yml uit met settings.query-plugins: false. Een nuancering die men zelden leest: de GS4-query van PocketMine-MP controleert een token dat met het afzenderadres is gezouten. Het grote antwoord laat zich daarmee niet naar een vervalst adres reflecteren. De opvraag kost toch rekentijd, en de gepubliceerde gegevens helpen de aanvaller bij de doelkeuze. De officiële Bedrock Dedicated Server kent noch query noch RCON, daar vervalt dit punt.

Mocht u RCON werkelijk nodig hebben, zet dan bij Nukkit beslist rcon.port op een eigen waarde en geef die alleen voor uw eigen adres vrij. De terugval op server-port betekent anders dat een afstandsbediening van uw server op 19132 TCP luistert, dus op hetzelfde getal dat u toch al overal als "open" hebt ingevuld.

5. Xbox Live-authenticatie afdwingen

De Xbox Live-authenticatie is de controle of een toetredende speler een echt, door Microsoft ondertekend account bezit. Zij staat in alle drie de serversoftwares af fabriek aan en moet daar ook blijven.

Bij de Bedrock Dedicated Server heet de directive online-mode, bij PocketMine-MP en Nukkit heet zij xbox-auth. In beide gevallen is true de fabrieksinstelling en de juiste waarde:

online-mode=true
xbox-auth=true

Microsoft formuleert daarbij een belangrijke beperking: clients die met een server buiten het lokale netwerk verbinden, hebben de Xbox Live-authenticatie sowieso altijd nodig, onafhankelijk van deze instelling. Het bewijs wordt als ondertekende tokenketen in het loginpakket overgedragen, samen met de Xbox-identificatie (XUID) en de weergavenaam.

En nu het deel dat misverstanden voorkomt: de Xbox Live-authenticatie beschermt uw spellogica, niet uw lijn. Zij vindt plaats in het loginpakket, dus na de volledige RakNet-verbindingsopbouw. Een aanvaller die uw server overspoelt, wil helemaal niet toetreden. Zijn pakketten worden geweigerd, maar ze zijn wel aangekomen, en precies daar gaat het om.

6. Allowlist en spelerslimiet, en wat ze niet leveren

De allowlist (vroeger whitelist) is de lijst van spelers die mogen toetreden. Bij de Bedrock Dedicated Server schakelt u haar met allow-list=true in, de vermeldingen staan in de allowlist.json met naam, XUID en het veld ignoresPlayerLimit. Bij Nukkit en PocketMine-MP heet de directive nog steeds white-list.

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

Een korte inactiviteitstijd via player-idle-timeout is werkzaam tegen slotuitputting: spelers die alleen een plaats bezetten, vliegen na het opgegeven aantal minuten eruit. De waarde 0 betekent dat niemand ooit wegens inactiviteit wordt losgekoppeld, en precies dat benut een aanvaller die met echte accounts uw plaatsen blokkeert.

Ook hier geldt de grens uit de vorige paragraaf, en zij is het punt dat verreweg het vaakst over het hoofd wordt gezien: de allowlist wordt pas gecontroleerd wanneer het loginpakket verwerkt is. Zij verhindert toetredingen, geen pakketten.

7. Pakketsnelheden per bronadres begrenzen

Tegen kleine aanvallen en slordige bots helpt een bovengrens per bronadres. Voor UDP werkt men met hashlimit, niet met connlimit, want UDP kent geen verbindingen:

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

De regel verwerpt UDP-pakketten zodra hetzelfde bronadres blijvend meer dan 400 pakketten per seconde stuurt. De waarde is een startwaarde, geen waarheid: een volle server met 60 spelers en grote zichtafstand produceert duidelijk meer pakketten dan een lege, en wie te krap instelt, gooit zijn eigen spelers eruit. Meet eerst een week in normaal bedrijf.

Duidelijk scherper mag u instellen bij de Unconnected Ping, want een echte client vraagt de serverstatus alleen op zolang de serverlijst geopend is, en dan in secondetempo. Met nftables laat zich precies dit ene pakket treffen, omdat de pakket-ID de eerste byte achter de UDP-kop is:

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

De uitdrukking @th,64,8 leest acht bits vanaf het 64e bit van de transportkop, dus de eerste byte van de UDP-payload. De waarde 0x01 is de pakket-ID van de Unconnected Ping. Dezelfde plek kunt u gebruiken om te observeren voordat u ook maar iets verwerpt:

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

De eerste regel telt binnenkomende statusopvragen, de tweede uw eigen antwoorden. Lopen beide in secondetempo in de duizenden terwijl er nauwelijks iemand speelt, dan ziet u een pingvloed en niet uw spelers.

Twee opmerkingen over de houdbaarheid. Kale iptables-regels zijn na een herstart verdwenen; onder Debian en Ubuntu bewaart u ze zo:

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

En onder UFW horen zulke regels in /etc/ufw/before.rules, omdat ze anders bij de volgende ufw reload verdwijnen.

8. De verbindingsregistratie van de kernel ontlasten

Een knelpunt dat bij UDP-spellen veel eerder toeslaat dan bij TCP: de kernel legt voor elk UDP-pakketpaar een vermelding in de verbindingsregistratie aan. Bij een vloed met vervalste afzenderadressen is elk pakket een nieuw bronadres en daarmee een nieuwe vermelding. Loopt de tabel vol, dan verwerpt de server ook legitieme pakketten, en in het logboek staat "nf_conntrack: table full, dropping packet".

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Staat de tellerstand blijvend dicht bij de bovengrens, dan kunt u het spelverkeer van de registratie uitzonderen. Dat is werkzaam, maar niet zonder gevolgen, daarom in beide richtingen en met een verbindingstest achteraf:

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

Daarna grijpen toestandsgebaseerde regels voor dit verkeer niet meer. Uw vrijgave voor 19132 UDP moet dus een echte poortvrijgave zijn en mag niet op de toestand ESTABLISHED vertrouwen. Controleer na het instellen met conntrack -L | grep 19132 dat er geen vermeldingen meer ontstaan, en verbind één keer met het spel voordat u de regels permanent opslaat.

9. Geyser en Floodgate netjes draaien

Geyser is een brug die Bedrock-clients op een Java-Edition-server laat spelen: het neemt op 19132 UDP Bedrock-verbindingen aan, vertaalt het protocol en praat aan de andere kant met de Java-server op 25565 TCP. Floodgate is de aanvulling die deze Bedrock-spelers toetreding zonder Java-account toestaat. Voor de DDoS-bescherming betekent dat drie dingen.

Ten eerste: houd Geyser actueel. Precies deze brug was tweemaal de aanleiding voor gedocumenteerde aanvallen. In maart 2024 werd de hierboven beschreven versterkingsfout in de RakNet-bibliotheek breed uitgebuit, verholpen vanaf build 478. In juli 2025 volgde een tweede geval: een herhaald verstuurd pakket ter bevestiging van de resource packs maakte meerdere sessies per speler aan, en losgekoppelde clients konden verder pakketten sturen omdat het netwerkkanaal niet werd gesloten. Verholpen vanaf build 897. Beide gevallen zijn door het project zelf met tijdlijn gepubliceerd.

Ten tweede: de Java-server hoort niet op het open internet. In de Geyser-configuratie wijst remote.address naar auto respectievelijk 127.0.0.1 en remote.port naar 25565. Bind de Java-server dienovereenkomstig lokaal en geef 25565 TCP naar buiten niet vrij. Anders hebt u twee aanvalsoppervlakken in plaats van één, en het tweede is dat waarvoor u nooit regels hebt bedacht.

Ten derde: het bestand key.pem is een geheim. Het is de sleutel waarmee Floodgate de Java-authenticatie voor Bedrock-accounts overslaat. Wie het in een openbare repository zet, in een supportticket kopieert of op een schermafbeelding toont, heeft de aanmelding van zijn server weggegeven. Het project waarschuwt daar uitdrukkelijk voor.

10. Meetwaarden verzamelen voordat het knalt

De belangrijkste stap is die welke bijna niemand vooraf zet: een vergelijkingsbasis aanleggen zolang alles normaal draait. Zonder normaalwaarde kunt u na een incident niet zeggen of 40.000 pakketten per seconde veel was of gewoon zaterdagavond. Met apt-get install -y vnstat sysstat conntrack loopt de meting permanent mee.

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

Drie van deze waarden zijn bij een Bedrock-server bijzonder veelzeggend. Een blijvend van nul verschillende Recv-Q op de UDP-socket van 19132 betekent dat het serverproces de binnenkomende pakketten niet snel genoeg meer ophaalt. UdpRcvbufErrors telt precies de pakketten die daarom zijn verworpen en is het hardste bewijs dat niet de lijn, maar het proces het knelpunt is. UdpNoPorts stijgt wanneer iemand poorten beschiet waarop helemaal niets luistert, een typisch beeld bij een breed uitgestrooide poortscan vóór de eigenlijke aanval.

Voor tcpdump geldt: altijd met -c begrenzen, want een opname onder volle belasting belast een toch al overbelaste server nog extra. Hoe u de waarden uitleest, staat in DDoS-aanval herkennen.

Waar deze maatregelen ophouden: bandbreedte en pakketsnelheid

Nu het deel dat geen enkel configuratiebestand kan oplossen. Alle maatregelen tot hier draaien op uw server, dus aan het einde van de lijn. Een firewallregel beslist over een pakket dat al over de kabel is gekomen. U kunt het verwerpen, maar u kunt niet terugdraaien dat het verstuurd is.

Rekent u even mee. Uw lijn zit vol zodra iemand meer dan 125 megabyte per seconde stuurt. Een aanval van 5 tot 50 Gbit/s ligt op het vijf- tot vijftigvoudige daarvan. Of uw hashlimit-regel daarachter goed is, doet dan niet meer ter zake, want de pakketten van uw spelers komen al eerder niet door.

De tweede grootheid is de pakketsnelheid, en bij een Bedrock-server slaat die bijna altijd het eerst toe. Het volledige spelverkeer bestaat uit veel kleine UDP-pakketten, en precies in die discipline is een aanvaller het goedkoopst uit. Een aanval die uw lijn niet eens voor een derde vult, kan uw server toch platleggen, omdat de rekentijd opgaat aan het beoordelen en verwerpen. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch lag iedereen eruit". In het spel uit zich hetzelfde als lag spikes, rubberbanding en verbindingsafbrekingen midden in het bouwen.

Daarvoor bestaat geen lokale instelling. Volumetrische aanvallen moeten in het netwerk vóór de server eindigen.

Wat KernelHost tegenover DDoS-aanvallen op Bedrock-servers zet

De permanente bescherming die bij elke server inbegrepen is

De DDoS-bescherming van KernelHost is in twee lagen opgebouwd en permanent actief, zonder dat u iets hoeft in te schakelen, te bestellen of te configureren:

• Laag 1: 17 Tbps mitigatiecapaciteit in het globale scrubbing-netwerk. Volumetrische aanvallen worden dicht bij hun bron geschoond, nog voordat ze het datacenter bereiken.
• Laag 2: Arbor realtime filtering met 3,2 Tbps in Frankfurt am Main. Direct vóór de server worden protocolspecifieke patronen herkend en verworpen, pakket voor pakket. Daartoe behoren ook UDP-patronen op 19132 die geen RakNet-gedrag vertonen.

Twee eigenschappen zijn doorslaggevend. De bescherming loopt permanent en hoeft niet eerst op een aanval te reageren, dus er zijn geen eerste minuten waarin de server weg is. En er wordt geen null-routing toegepast: uw IP-adres blijft in het netwerk, alleen de kwaadaardige pakketten worden verworpen. Wie het IP-adres uit het netwerk haalt, bereikt voor u hetzelfde resultaat als de aanvaller. De locatie is Frankfurt am Main. Welke games en protocollen gedekt zijn, somt Gameserver-DDoS-bescherming in realtime op.

Advanced DDoS Protection voor projecten die permanent onder vuur liggen

Sommige projecten worden niet af en toe, maar gericht en wekenlang aangevallen. Daarvoor is er de Advanced DDoS Protection vanaf 50,00 € per maand, PrePaid en zonder minimale looptijd. Het verschil zit niet in meer capaciteit, maar in de controle:

• Een dedicated beschermd IP-adres uit het Frankfurtse kernnetwerk, waarnaar uw server binnen ons eigen netwerk wordt omgezet. Aan uw kant is geen enkele aanpassing nodig.
• Zelf beheerbare beschermingsregels per poort en protocol in het klantenpaneel: u stelt in wat op 19132 UDP is toegestaan, wat op 19133 UDP, en wat op een afwijkende poort, mocht u uw server hebben verlegd.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen in plaats van op een onderhoudsvenster te wachten.
• Een beschermingsprofiel dat bij het betreffende spel past. Voor Minecraft zijn er kant-en-klare profielen, net zo goed als voor aangepaste en eigen applicaties op willekeurige TCP- of UDP-poorten, dus ook voor Nukkit, PocketMine-MP of een Geyser-instantie op een zelfgekozen poort.

De twee lagen naast elkaar

Voor de meeste Bedrock-projecten volstaat de inbegrepen permanente bescherming samen met een nette serverconfiguratie. De Advanced DDoS Protection is het antwoord op iemand die het persoonlijk maakt. Wie zijn server momenteel elders draait, lost het probleem het best op met een verhuizing: de filtering werkt in het netwerk vóór de server, en dat netwerk moet van ons zijn.

Veelgemaakte fouten en oplossingen

"Ik heb de poort naar 19140 gewijzigd, 19132 is toch open": dat is enable-lan-visibility=true. De Bedrock Dedicated Server bindt dan bovendien aan 19132 en 19133, ongeacht wat er in server-port staat. Op false zetten, server opnieuw starten, met ss -lnup controleren.

"Ik heb de allowlist.json bewerkt en kom er zelf niet meer in": twee oorzaken komen vaak voor. Er ligt nog een oude whitelist.json in de map die de server in plaats daarvan leest, of de XUID-vermelding ontbreekt dan wel is verkeerd. De naam alleen volstaat bij actieve Xbox Live-authenticatie niet betrouwbaar.

"Mijn hoster heeft mijn server geblokkeerd hoewel ik de aangevallene was": controleer of uw server zelf pakketten heeft uitgestuurd. Precies dat gebeurde bij de RakNet-versterkingsfout van 2024: de getroffen servers stuurden duizenden pakketten naar vreemde adressen, en in de abusemeldingen stond poort 19132 als bron. Met tcpdump -ni eth0 'udp src port 19132' -c 200 -q ziet u waarheen uw server antwoordt. Een actuele build neemt de oorzaak weg.

"Mijn iptables-regels grijpen niet": drie oorzaken komen vaak voor. De regels staan achter de UFW-ketens en worden nooit bereikt, ze waren na de laatste herstart verdwenen (dan helpen netfilter-persistent save of een regel in /etc/ufw/before.rules), of de aanval is volumetrisch en de regel werkt correct aan een lijn die al vol zit. Controleer met iptables -L INPUT -n -v of de tellers oplopen. Blijven ze op nul staan, dan wordt de regel niet bereikt.

"De server staat in de lijst, maar niemand komt erin": wanneer de vermelding naam en spelersaantal toont, werkt de Unconnected Pong, dus is de poort in principe bereikbaar. Mislukt het toetreden toch, dan ligt het meestal aan de Xbox Live-aanmelding of aan de allowlist. Komen omgekeerd alleen IPv6-spelers er niet in, dan ontbreekt de vrijgave voor 19133 UDP.

"De server draait, maar iedereen heeft lag spikes": dat is vaker een plugin dan een aanval. Kijk eerst na of Recv-Q op de UDP-socket groeit en of UdpRcvbufErrors stijgt. Blijven beide rustig en sar -n DEV 1 10 onopvallend, dan was het geen DDoS-aanval, maar het serverproces zelf. Bij de Bedrock Dedicated Server helpen dan de script-watchdogs verder, waarvan de drempels in de server.properties onder script-watchdog-hang-threshold en script-watchdog-slow-threshold staan.

"Mijn vorige aanbieder heeft mijn IP-adres geblokkeerd": dat is null-routing. De aanbieder beschermt daarmee zijn eigen netwerk; voor u is het resultaat identiek aan een geslaagde aanval, meestal nog urenlang daarna. Vraag bij twijfel na of er wordt gefilterd of null-geroutet. Dat antwoord bepaalt meer over uw beschikbaarheid dan welke hardwarespecificatie ook.

"In de tcpdump zie ik niets opvallends": wordt het verkeer al in het netwerk ervoor gefilterd, dan komt er op de server zoals verwacht niets aan. Dat is het normale beeld bij een werkende filtering. Omgekeerd geldt: zit de lijn vol, dan bereikt u onder omstandigheden zelfs de SSH-sessie niet meer waarmee u wilde meten. Gebruik dan de VNC-console in het klantenpaneel, die losstaat van het netwerk van het gastsysteem.

Kort samengevat

• Een Minecraft-Bedrock-server heeft precies één open poort naar buiten nodig: 19132 UDP, daarbij 19133 UDP alleen voor IPv6-spelers. Query, RCON, de script-debugger op 19144 TCP en een Java-server achter Geyser op 25565 TCP horen niet op het open internet.
• Wie de poort verlegt, moet enable-lan-visibility=false zetten, anders bindt de Bedrock Dedicated Server bovendien verder aan 19132 en 19133.
• Xbox Live-authenticatie en allowlist grijpen pas in het loginpakket aan, dus na de volledige RakNet-verbindingsopbouw. Zij beschermen uw spellogica en uw plaatsen, niet uw lijn.
• De Unconnected Ping wordt met 33 byte opgevraagd en met ongeveer 131 byte beantwoord, een versterkingsfactor van ongeveer vier. Een korte servernaam houdt die factor klein.
• Bij UDP helpt hashlimit in plaats van connlimit, en de verbindingsregistratie van de kernel loopt bij vervalste afzenderadressen als eerste vol. Beide zou u vóór de eerste aanval gemeten moeten hebben.
• Vanaf ongeveer 1 Gbit/s zit uw lijn vol, en bij pakketten van 64 byte passen daar ongeveer 1,49 miljoen pakketten per seconde in. Daarboven beslist uitsluitend de filtering in het netwerk vóór de server.
• Bij KernelHost is de permanente bescherming in twee lagen in elk serverpakket inbegrepen, vanaf de oplevering actief en zonder null-routing. De Advanced DDoS Protection vult haar aan met een dedicated beschermd IP-adres en zelf beheerbare regels per poort.

Draait uw project al bij KernelHost, dan is de filtering actief zonder dat u iets hoeft te doen. Merkt u toch iets ongewoons, open dan een supportticket, zodat de filterregels voor uw IP-adres worden bijgesteld. Bij een lopende aanval bereikt u ons daarnaast via de WhatsApp-noodchat op +43 650 8209883.