Palworld-server beschermen tegen DDoS-aanvallen

Een Palworld-server die 's avonds midden in het spel alle spelers tegelijk eruit gooit, een paar minuten offline gaat en daarna vanzelf weer bereikbaar is, heeft zelden een hardwareprobleem. Meestal loopt er een aanval. Dit artikel laat zien hoe u een Palworld-server tegen DDoS-aanvallen beschermt: eerst wat u zonder extra kosten zelf kunt instellen, daarna het punt waarop die maatregelen technisch ophouden, en tot slot wat er in het netwerk vóór de server moet gebeuren zodat de server bereikbaar blijft.

Alle informatie hier gaat uit van de officiële dedicated server van Pocketpair (Steam-app-ID 2394010) 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. Loopt de aanval op dit moment, dan geldt een volgorde: eerst meten, dan wijzigen. Een harde herstart onder belasting gooit alles weg wat sinds het laatste automatische opslagpunt in de wereld is gebeurd, en de meetwaarden van het incident zijn daarna eveneens verdwenen.

Waarom Palworld-servers gericht met DDoS-aanvallen worden platgelegd

Een Palworld-server is een klein, vast publiek op een vast adres. De dedicated server is begrensd op 32 spelers, geregeld via ServerPlayerMaxNum met het geldige bereik 1 tot 32. Wie in plaats daarvan via het spelmenu host, komt op vier spelers en alleen zolang de gastheer zelf online is. Uit die 32 plaatsen volgt al het andere: de groep speelt op vaste avonduren, kent elkaar onderling, en een uitval om 20 uur treft niet een deel van de spelers, maar allemaal.

Het adres van de server is daarbij geen geheim. Palworld kent geen bemiddeling via een dienst van de aanbieder: spelers vullen IP-adres en poort zelf in het veld voor de directe verbinding in, en wie de server daarnaast in de community-serverlijst wil voeren, start hem met -publiclobby en laat de querypoort antwoorden. Iedereen die ooit verbonden is geweest, kent daarmee het doelwit. Een booterdienst die dit adres voor een paar euro per maand beschiet, verlangt van de opdrachtgever kunde noch moeite.

Technisch komt daarbij dat het volledige spelverkeer over UDP loopt. UDP kent geen verbindingsopbouw die u zou kunnen eisen, en het afzenderadres van een UDP-pakket laat zich vervalsen. Een aanvaller hoeft uw server dus niet te betreden en hoeft hem ook niet correct aan te spreken om belasting te veroorzaken. Wat er bij zo'n aanval technisch gebeurt, legt het artikel Wat is een DDoS-aanval? uit.

De poorten waar het bij een Palworld-server werkelijk om gaat

Een Palworld-server heeft precies één open poort nodig: 8211 UDP. Al het andere is optioneel en afhankelijk van de taak zelfs schadelijk wanneer het op het internet staat. Daaruit volgt een nuttig onderscheid: een DDoS-aanval op poort 8211 raakt altijd het spelverkeer zelf, een aanval op poort 27015 UDP daarentegen alleen de vermelding in de serverlijst.

Alle schakelaars daarvoor staan in één enkel bestand: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini, onder Windows navenant Pal\Saved\Config\WindowsServer\PalWorldSettings.ini. Het begint met de sectieregel [/Script/Pal.PalGameWorldSettings], daarna volgt één enkele regel OptionSettings=(...) die alle instellingen als lijst bevat. Een regeleinde binnen de haakjes maakt de volledige configuratie ongeldig, en de server valt zonder melding terug op de standaardwaarden. Het sjabloon DefaultPalWorldSettings.ini in de servermap bewerkt u niet, want het wordt bij elke update overschreven.

Palworld-server in cijfers

De volgende waarden vormen de grondslag voor elke beslissing over filterregels en grenswaarden.

Waarom de querypoort 27015 het gevoeligste punt is

De querypoort beantwoordt statusaanvragen in het Steam-formaat A2S, dus dezelfde opvraag die ook Counter-Strike- en ARK-servers bedienen. Een A2S_INFO-aanvraag is een verbindingsloos UDP-pakket van enkele tientallen byte, het antwoord met servernaam, wereld, spelersaantal en spelstand is daar een veelvoud van. Omdat het afzenderadres zich bij UDP laat vervalsen, kan een aanvaller vreemde querypoorten aanspreken en de grotere antwoorden naar zijn eigenlijke doelwit sturen. Uw server is in dat geval niet het slachtoffer, maar de versterker, en zijn aansluiting betaalt de rekening.

Valve heeft A2S_INFO daarom op 8 december 2020 aangevuld met een voorgeschakelde challenge: de server antwoordt eerst met S2C_CHALLENGE, de aanvrager moet het token terugsturen en bewijst daarmee dat hij zijn afzenderadres niet vervalst. Dat ontmantelt de versterking, maar beëindigt haar niet, en tegen een simpele vloed van gelijksoortige opvragen uit echte adressen werkt ze helemaal niet.

Voor Palworld volgt daaruit een belangrijk voordeel ten opzichte van de Source-engine: spelverkeer en serverquery liggen op gescheiden poorten. Bij Counter-Strike 2 delen beide de poort 27015, waardoor een grove snelheidsbegrenzing daar de eigen spelers meegooit. Bij Palworld kunt u 27015 UDP hard begrenzen of helemaal sluiten, zonder ook maar één lopende spelverbinding op 8211 UDP aan te raken. Wie de vermelding in de lijst niet nodig heeft, schrapt -publiclobby en de querypoort zonder vervanging en haalt daarmee een volledig aanvalsoppervlak uit het netwerk.

Wat u zelf kunt doen voordat u geld uitgeeft

De volgende stappen houden geen volumetrische aanval tegen, dat kan geen enkele software op de server. Ze ruimen wel alles op wat daaronder ligt: poortscans, queryvloeden, overnamepogingen via de beheerpoorten en het bezetten van alle 32 plaatsen door vreemden. Dat is het grootste deel van wat een Palworld-server in het dagelijks bedrijf stoort, en het kost een half uur.

1. Inventarisatie: wat luistert er op de server?

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

ss -lntup

Interessant is de kolom met het lokale adres. 0.0.0.0:8211 betekent "vanaf het hele internet bereikbaar", 127.0.0.1:8212 betekent "alleen lokaal" en heeft geen firewallregel nodig. Naast het spelproces duiken op een gegroeide server vaak nog een beheerpaneel, een webserver voor de kaartweergave en een database op. Het beeld van de aanvaller levert een poortscan van buitenaf:

nmap -Pn -sU -p 8211,27015 UW.SERVER.IP.ADRES
nmap -Pn -p- --min-rate 1000 UW.SERVER.IP.ADRES

2. Alleen openzetten wat Palworld werkelijk nodig heeft

Twee openstellingen volstaan, en de tweede is optioneel. 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 8211/udp comment 'Palworld spelverkeer'
ufw allow 27015/udp comment 'Palworld Steam-query'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

De derde regel laat u weg wanneer uw server niet in de community-serverlijst hoeft te staan. Uw spelers verbinden dan nog steeds via IP-adres en poort 8211, de server verdwijnt uitsluitend uit de openbare lijst. De volledige handleiding inclusief reddingsweg staat in UFW-firewall instellen zonder uzelf buiten te sluiten.

3. RCON op 25575 en de REST-API op 8212 uit het internet halen

Beide poorten zijn beheertoegangen met volledige controle over de server, en beide staan standaard uitgeschakeld: RCONEnabled=False en RESTAPIEnabled=False. Wie ze inschakelt, hoort te weten wat hij daarmee publiceert.

De REST-API op 8212 TCP authenticeert via HTTP Basic Auth met de vaste gebruikersnaam admin en de waarde uit AdminPassword, en wel over onversleuteld HTTP. Het beheerwachtwoord loopt daarmee bij elke afzonderlijke aanvraag in omkeerbare vorm over de lijn. RCON op 25575 TCP is een al even onversleuteld tekstprotocol, en Pocketpair heeft het ten gunste van de REST-API als verouderd gemarkeerd. Voor nieuwe installaties is de REST-API de juiste keuze, voor beide geldt dezelfde regel: niet op het open internet.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="een lange willekeurige waarde"

Bereikbaar maakt u de interface via een SSH-poortdoorschakeling, daarna werkt u lokaal tegen 127.0.0.1:8212:

ssh -N -L 8212:127.0.0.1:8212 root@UW.SERVER.IP.ADRES

Laat AdminPassword nooit leeg, want leeg is de standaardinstelling. Een waarde uit openssl rand -base64 32 volstaat. Hetzelfde geldt voor ServerPassword, daarover zo meteen meer.

4. De querypoort 27015 begrenzen zonder de vermelding in de lijst te verliezen

Verbindingsloze Steam-pakketten beginnen met vier gezette byte (0xffffffff), regulier spelverkeer heeft die kop niet. Daarop laat zich een snelheidsbegrenzing per bronadres leggen die opvragen afremt en de vermelding in de lijst behoudt. Met nftables, geladen via nft -f:

table inet palworld {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

De prioriteit -10 zorgt ervoor dat de regel vóór de filterketen van UFW grijpt, en @th,64,32 leest de eerste vier byte achter de UDP-kop. Met klassiek iptables bereikt dezelfde scheiding een vergelijking op de kenmerkende reeks van A2S_INFO:

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Tien opvragen per seconde en per adres zijn ruim bemeten: een lijstdienst vraagt gewoonlijk elke paar minuten, niet meerdere malen per seconde. Belangrijk is alleen dat deze regel op 27015 staat en niet op 8211, anders raakt u uw eigen spelers.

5. Pakketsnelheden op 8211 UDP begrenzen

Op de spelpoort zelf helpt een bovengrens per bronadres tegen kleine vloeden uit weinig bronnen. Bij Palworld is die grens betrekkelijk ongevaarlijk te zetten, omdat er hoogstens 32 spelers tegelijk verbonden zijn en ieder van hen precies één bronadres bezet:

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

Het getal is een startwaarde, geen waarheid. Een volle server met 32 spelers en veel bases produceert duidelijk meer pakketten dan een ronde met zijn vieren, en wie te krap instelt, gooit zijn eigen spelers eruit. Meet eerst een week lang in normaal bedrijf, daarna zet u de grens op het dubbele van de gemeten piekwaarde.

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

Onder UFW horen zulke regels daarnaast in /etc/ufw/before.rules, omdat ze anders bij de volgende ufw reload verdwijnen. Of een regel überhaupt wordt bereikt, toont iptables -L INPUT -n -v: blijven de treffertellers op nul staan, dan grijpt ze niet.

6. Serverwachtwoord, banlijst en de 32 plaatsen tegen slotuitputting

Slotuitputting is de goedkoopste aanval op een Palworld-server en heeft geen bandbreedte nodig. Een dedicated server heeft hoogstens 32 plaatsen, dus 32 gelijktijdige verbindingen volstaan om de hele gemeenschap buiten te sluiten. Een volumetrische aanval kost de opdrachtgever geld, 32 sessies kosten hem niets. Dat maakt deze weg voor kleine servers aantrekkelijker dan elke vloed.

Palworld heeft geen ingebouwde whitelist. De moderatiemiddelen zijn kick, ban en een serverwachtwoord, en juist dat serverwachtwoord is tegen slotuitputting de meest werkzame afzonderlijke maatregel:

ServerPassword="een waarde die alleen uw groep kent"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword is standaard leeg, iedereen met IP-adres en poort komt er dus binnen. BanListURL wijst standaard naar de door Pocketpair bijgehouden lijst en laat zich omzetten naar een eigen tekstbestand wanneer u projecteigen blokkades wilt voeren. ServerPlayerMaxNum zet u niet hoger dan 32: hogere waarden worden niet ondersteund en breken u uiterlijk bij de volgende update op. En één ding moet duidelijk zijn: een serverwachtwoord beschermt uw plaatsen, niet uw lijn. Een aanvaller die uw server overspoelt, wil helemaal niet meedoen.

7. De verbindingsregistratie ontlasten en buffers vergroten

Dit punt verklaart uitvallen die op een volumeaanval lijken, maar er geen zijn. De kernel legt voor UDP-verkeer records aan in de verbindingsregistratie (conntrack), en bij vervalste afzenderadressen betekent elk adres een nieuw record. Is de tabel vol, dan verwerpt de kernel pakketten zonder onderscheid, de aanval en uw spelers vliegen er samen uit, en in het logboek staat "nf_conntrack: table full". Stand en bovengrens toont:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

De meest werkzame stap is om het spelverkeer helemaal niet te laten volgen, want Palworld beheert zijn sessies zelf:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 8211, 27015 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 8211, 27015 } notrack
    }
}

Met iptables luidt het equivalent iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK en dezelfde regel voor OUTPUT met --sport. De poorten hebben daarna een uitdrukkelijke openstelling nodig, want zonder registratie grijpt geen enkele regel meer die op een bestaande toestand controleert. Komen pakketten sneller binnen dan het serverproces ze ophaalt, dan loopt bovendien de ontvangstbuffer over. Voor de spelers ziet dat eruit als pakketverlies, hoewel de lijn vrij is. Een aanvulling onder /etc/sysctl.d/, geactiveerd met sysctl -p:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Of de waarden nodig zijn, verraadt de kernel zelf: stijgt UdpRcvbufErrors in nstat -az, dan grijpen ze. Blijft de teller op nul staan, dan verandert de aanpassing niets.

8. Meetwaarden verzamelen voordat het ernst wordt

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 loopt de meting permanent mee. Tijdens een incident volstaan vier commando's:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 -c 200 "udp port 8211 or udp port 27015"

Voor tcpdump geldt: begrens hem altijd met -c, want een opname onder volle belasting belast een toch al overbelaste server nog extra. Palworld levert daarnaast een meetgrootheid die geen ander werktuig heeft. Is de REST-API geactiveerd, dan geeft het metriek-endpoint onder meer de beeldsnelheid van de server, het actuele spelersaantal en de looptijd terug:

curl -s -u admin:UW_BEHEERWACHTWOORD http://127.0.0.1:8212/v1/api/metrics

Dat ene getal scheidt de twee meest voorkomende oorzaken netjes van elkaar. Zakt de beeldsnelheid van de server in terwijl de pakketsnelheden onopvallend blijven, dan is het geen aanval, maar belasting of de bekende geheugengroei van het serverproces. Blijft de beeldsnelheid stabiel terwijl de inkomende pakketten ver boven de normaalwaarde stijgen, dan is het een aanval. Hoe u de netwerkwaarden in detail uitleest, staat in DDoS-aanval op de server 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. Een typische gameserver hangt aan 1 Gbit/s, dat is 125 megabyte per seconde, en de lijn zit vol zodra iemand meer stuurt. Aanvallen tegen gameserverprojecten liggen doorgaans tussen 5 en 50 Gbit/s, dus op het vijf- tot vijftigvoudige van uw lijn. Of uw iptables-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 die slaat vaak eerder toe dan de bandbreedte. Bij kleine pakketten van 64 byte passen er in een lijn van 1 Gbit/s ongeveer 1,49 miljoen pakketten per seconde. Een gewone serverkernel verwerkt daarvan, afhankelijk van processor en netwerkkaart, enkele honderdduizenden voordat hij begint te verwerpen. Een aanval die uw lijn nog niet eens voor een derde vult, kan uw server dus toch platleggen, omdat de rekentijd opgaat aan het verwerpen. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch was alles weg", en bij Palworld uit het zich eerst als lagpieken en pas daarna als verbindingsverlies.

Bij een Palworld-server komt daar een ongunstige verhouding bij. Een volledig bezette server met 32 spelers belast maar een fractie van een lijn met 1 Gbit/s. De aanval hoeft dus niet groot te zijn om een veelvoud van het normale bedrijf te bereiken, en juist daarom volstaan hier al aanvallen die op een groot platform niet zouden opvallen.

Ter oriëntatie, welke ordes van grootte werkelijk voorkomen: op KernelHost-servers zijn onder meer een aanval met meer dan 473,4 Gbit/s bij meer dan 41,5 miljoen pakketten per seconde op een voiceserver en een UDP-flood met meer dan 112,2 Gbit/s op een gameserver weggefilterd. Daarvoor bestaat geen lokale instelling. Volumetrische aanvallen moeten in het netwerk vóór de server eindigen.

Wat KernelHost daartegenover zet

De permanente bescherming die bij elk serverpakket 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.

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. Palworld hoort bij de spellen met een eigen beschermingsprofiel; welke andere titels en protocollen gedekt zijn, somt Gameserver-DDoS-bescherming in realtime op.

Advanced DDoS Protection voor permanent beschoten Palworld-projecten

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, zonder minimale looptijd en zonder installatiekosten. 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 legt gescheiden vast wat op 8211 UDP is toegestaan en wat op 27015 UDP, zonder daarvoor een ticket te schrijven.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen, bijvoorbeeld de querypoort tijdelijk harder begrenzen en de spelpoort onaangeroerd laten.
• Een beschermingsprofiel dat bij het spel past, voor Palworld net zo goed als voor eigen applicaties op willekeurige TCP- of UDP-poorten.

De Advanced DDoS Protection richt zich op servers die bij KernelHost staan. Wie zijn Palworld-project momenteel elders draait en permanent wordt aangevallen, verhuist het daarvoor naar KernelHost, dan gelden beide lagen vanaf de oplevering.

De twee lagen naast elkaar

Voor de meeste Palworld-servers volstaat de inbegrepen permanente bescherming samen met een nette serverconfiguratie. De Advanced DDoS Protection is het antwoord erop dat iemand het persoonlijk maakt.

Veelgemaakte fouten bij Palworld-servers en hun oplossing

"Ik heb 27015 geblokkeerd en nu is de server uit de community-lijst verdwenen": dat is het verwachte gedrag, want de querypoort draagt de vermelding in de lijst. Blokkeer hem niet in het geheel, maar begrens de verbindingsloze pakketten per bronadres zoals in stap 4. Hebt u de vermelding in de lijst toch niet nodig, laat de poort dan gesloten, schrap -publiclobby en geef uw spelers IP-adres en poort 8211 voor de directe verbinding.

"Ik heb het IP-adres gewisseld en was twee uur later weer offline": de aanvaller haalt het nieuwe adres uit dezelfde bron als het oude. Bij Palworld is dat bijna altijd een van drie wegen: een speler die het adres toch al in het veld voor de directe verbinding heeft staan, een Discord-bot met statusweergave die het opnieuw publiceert, of een oud A-record in het DNS dat naar het vorige adres wijst. Een adreswissel levert tijd op, geen oplossing.

"De server heeft lagpieken, maar de lijn is rustig": dat is bij Palworld vaker belasting dan aanval. Het serverproces neemt gedurende de looptijd gestaag meer werkgeheugen in beslag, waardoor een geplande herstart bij het normale bedrijf hoort en niet als noodgreep moet worden opgevat. Controleer de beeldsnelheid van de server via het metriek-endpoint en het geheugengebruik van het proces. Blijft sar -n DEV 1 10 daarbij onopvallend, dan was het geen DDoS-aanval.

"Alle 32 plaatsen zijn bezet, maar in het spel is niemand te zien": dat is slotuitputting en raakt de spellogica, niet de lijn. Zet een ServerPassword, blokkeer de opvallende accounts via de banlijst en begrens de pakketten per bronadres op 8211 UDP.

"De REST-API was een paar dagen open bereikbaar": dan is uw beheerwachtwoord gecompromitteerd, want HTTP Basic Auth over onversleuteld HTTP verstuurt het bij elke aanvraag in omkeerbare vorm. Wijzig AdminPassword, sluit 8212 TCP naar buiten af en bereik de interface alleen nog via een SSH-poortdoorschakeling.

"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 treffertellers oplopen.

"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 Palworld-server heeft precies één open poort nodig: 8211 UDP. De querypoort 27015 UDP is alleen nodig voor de vermelding in de community-serverlijst.
• RCON op 25575 TCP en de REST-API op 8212 TCP horen nooit op het open internet, want beide versturen hun toegangsgegevens onversleuteld. RCON is door Pocketpair bovendien als verouderd gemarkeerd.
• Omdat spelverkeer en serverquery bij Palworld op gescheiden poorten liggen, laat 27015 UDP zich hard begrenzen zonder het lopende spelverkeer op 8211 UDP aan te raken.
• De dedicated server is begrensd op 32 plaatsen, daarom is slotuitputting de goedkoopste aanval. Een gezet ServerPassword is daartegen de meest werkzame afzonderlijke maatregel, want Palworld heeft geen ingebouwde whitelist.
• Lokale maatregelen eindigen bij de lijn: 1 Gbit/s is 125 megabyte per seconde, en bij pakketten van 64 byte passen daarin ongeveer 1,49 miljoen pakketten per seconde. Alles daarboven moet in het netwerk vóór de server eindigen.
• Bij KernelHost is de permanente bescherming in twee lagen bij elk serverpakket zonder meerprijs inbegrepen en vanaf de oplevering actief, zonder null-routing. De Advanced DDoS Protection met dedicated beschermd IP-adres en zelf beheerbare regels per poort begint bij 50,00 € per maand.

Draait uw Palworld-server 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 wij de filterregels voor uw IP-adres bijstellen. Bij een lopende aanval bereikt u ons daarnaast via de WhatsApp-noodchat op +43 650 8209883.