Hytale-server beschermen tegen DDoS-aanvallen

Een Hytale-server die 's avonds midden in het spel alle verbindingen tegelijk verliest, een paar minuten onbereikbaar is en daarna van zichzelf weer loopt, heeft zelden een hardwareprobleem. In de regel loopt er een aanval. Dit artikel laat zien hoe u een Hytale-server tegen DDoS-aanvallen beschermt: eerst wat u zonder extra kosten zelf kunt configureren, daarna de plaats waar die maatregelen technisch ophouden, en tot slot wat er in het netwerk vóór de server moet gebeuren om de server bereikbaar te houden.

Alle gegevens hebben betrekking op de officiële dedicated server van Hypixel Studios, dus op HytaleServer.jar samen met Assets.zip onder Java 25, gedraaid op 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. Hytale is in Early Access en beweegt snel: daarom draagt in dit artikel elke uitspraak over het spel een datum, en alles wat niet officieel is onderbouwd, is uitdrukkelijk als verwachting of als communitybron aangeduid. Loopt de aanval op dit moment, dan geldt bovendien een volgorde: eerst meten, dan wijzigen. Een harde herstart onder belasting verwerpt alles wat sinds het laatste opslagpunt in de wereld is gebeurd, en de meetwaarden van het incident zijn daarna eveneens verdwenen.

Waarom Hytale-servers doelgericht met DDoS-aanvallen worden platgelegd

Een Hytale-server is een publiek op een vast adres, en dat publiek is vervangbaar. Wie 's avonds drie keer achter elkaar niet op zijn vaste server komt, zoekt een andere. Precies dat is het verdienmodel achter aanvallen op communityservers: het gaat niet om gegevens en niet om afpersing, maar om spelers die verder trekken. Een booterdienst die een adres voor een paar euro per maand beschiet, vraagt van de opdrachtgever kunde noch inspanning, en de schade ontstaat bij elke uitval opnieuw.

Daar komt bij Hytale een bijzonderheid bij: de servercode is openbaar. Hypixel Studios heeft in juni 2026 het programma Hytale Shared Source aangekondigd en stelt daarmee de volledige servercode, het netwerkprotocol en de assets via GitHub ter beschikking, toegankelijk voor iedereen met een geldige spellicentie. Voor serverbeheerders is dat winst, omdat plug-ins tegen echte interfaces ontstaan. Voor de aanvalskant betekent het dat niemand het protocol meer hoeft te raden. Wie wil weten op welke plaats de verbindingsopbouw rekentijd kost, kan het nalezen. Wat bij zo'n aanval technisch gebeurt, legt het artikel Wat is een DDoS-aanval? uit.

De stand van zaken rond Hytale op 27 september 2026

Hytale is sinds 13 januari 2026 in Early Access, verkrijgbaar voor Windows, macOS en Linux, en heeft in de dagen na de start meer dan een miljoen spelers bereikt. De weg daarheen was ongebruikelijk, en die verklaart waarom oudere artikelen over Hytale vaak niet meer kloppen.

Het praktische gevolg van deze chronologie: een Hytale-server van vandaag is geen server van januari. Met Update 6 is het netwerkprotocol van hytale/2 naar hytale/3 gewijzigd, en volgens de officiële patchnotes van 27 augustus 2026 moeten server en plug-ins opnieuw worden gebouwd voordat zij verbinding maken. Wie zijn beschikbaarheid plant, plant daarom niet alleen tegen aanvallen, maar ook tegen protocolwissels.

Waarom 12 oktober 2026 de kritieke datum is

Grote contentupdates werken als een tweede verkoopstart. Zij brengen oude spelers terug, trekken nieuwe aan, en voor een paar dagen bepaalt de bereikbaarheid welke communityserver uit die golf groeit en welke haar mist. Dit patroon is bij andere games gedocumenteerd: Palworld bereikte in januari 2024 binnen enkele dagen miljoenen spelers, en de communityservers van die startfase werden juist op het moment het meest aangevallen waarop zij het meest te verliezen hadden. Het mechanisme daarachter is bij Palworld-servers tegen DDoS-aanvallen beschermen uitvoerig beschreven en laat zich één op één op Hytale overbrengen.

Daaruit volgt een onaangename waarheid over het tijdschema: bescherming die op 12 oktober wordt besteld, is te laat. Een lijn, een beschermd IP-adres, een regelset per poort en een meetwaarde voor het normale bedrijf hebben aanlooptijd nodig, omdat zij zonder vergelijkingsgegevens niet zinvol kunnen worden ingesteld. Wie twee weken voor een grote update begint, heeft genoeg tijd. Wie op de dag van de update begint, stelt in het blinde bij.

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

Een Hytale-server heeft precies één open poort nodig: 5520 UDP. Het spelverkeer loopt via QUIC, dus via UDP, en TCP is voor het spelverkeer niet nodig. Wie alleen TCP vrijgeeft, ziet hetzelfde beeld als bij een dichte firewall: de spelers lopen in een timeout. De standaardbinding luidt 0.0.0.0:5520, een andere poort wordt bij de start met --bind gezet.

Deze tabel is korter dan bij de meeste andere games, en dat is het belangrijkste verschil. Een Counter-Strike-server beantwoordt statusopvragingen in het Steam-formaat A2S, een Minecraft-Bedrock-server antwoordt op een Unconnected Ping, een Palworld-server houdt een eigen querypoort open. Voor Hytale is in de openbare documentatie naast 5520 UDP geen verdere poort beschreven: geen querypoort, geen RCON-poort, geen REST-interface in de leveringstoestand. Alles wat een Hytale-server naar buiten aanbiedt, ligt op één enkele UDP-poort.

Hytale-servers in cijfers

De volgende waarden zijn de grondslag voor elke beslissing over filterregels en grenswaarden. De herkomst staat er telkens bij, omdat die over de betrouwbaarheid beslist.

Wat QUIC aan het aanvalsoppervlak verandert

QUIC is een transportprotocol dat beveiligde verbindingen over UDP tot stand brengt en de versleutelingsopbouw volgens TLS 1.3 vast ingebouwd heeft. Onversleuteld QUIC bestaat niet. Voor een serverbeheerder betekent dat twee dingen die elkaar tegenspreken, en beide zijn belangrijk.

Het eerste is een echte verbetering. Omdat UDP geen verbindingsopbouw afdwingt en afzenderadressen vervalst kunnen worden, zijn verbindingsloze UDP-diensten de klassieke versterkers voor aanvallen op derden. QUIC begrenst dat in de standaard. RFC 9000 schrijft in paragraaf 8.1 voor dat een server vóór de controle van het afzenderadres maximaal de drievoudige hoeveelheid van de ontvangen byte mag versturen, en paragraaf 14.1 verlangt dat een client zijn eerste datagram tot minstens 1200 byte opvult. Samen brengen deze twee regels de versterkingsfactor van een QUIC-dienst op maximaal drie, terwijl een Steam-querypoort of een Bedrock-Unconnected-Ping op een veelvoud daarvan komt. Een correct werkende Hytale-server is daarom als reflectieversterker praktisch oninteressant. Dat is een structureel voordeel ten opzichte van bijna alle andere games met UDP-verkeer, en bij de vergelijking met Minecraft-Bedrock-servers valt dat duidelijk op.

Het tweede is de prijs daarvoor. Een QUIC-verbindingsopbouw kost de server rekentijd, want hij omvat een TLS 1.3-onderhandeling met asymmetrische cryptografie. Eén enkel vervalst pakket kan geen opbouw afdwingen, maar een vloed echte verbindingspogingen uit een botnet wel. De aanvaller betaalt daarbij eveneens rekentijd, en precies die verhouding beslist: zolang de server per verbindingspoging meer werk verricht dan de aanvaller, is de aanval economisch. Een vloed verbindingspogingen belast daarom niet de lijn, maar de processor, en zij ziet er in de bandbreedtestatistiek uit als niets. Dat is hetzelfde mechanisme dat bij Minecraft als nullping en handshake-flood bekend is en in het artikel Minecraft-DDoS-bescherming en nullping-bescherming in detail wordt beschreven.

Praktisch bruikbaar is daaraan vooral de 1200-byteregel. Een nieuwe verbindingspoging moet als datagram van minstens 1200 byte aankomen, anders is hij volgens de standaard geen geldige verbindingsopbouw. Lopend spelverkeer bestaat daarentegen overwegend uit kleine pakketten. Dat onderscheid laat zich in een filterregel gieten, en daar komen we direct op.

Wat over Hytale niet openbaar gedocumenteerd is

Deze lijst hoort in een eerlijk artikel, omdat zij vastlegt waar u zich niet op cijfers mag verlaten. Al het volgende is per 27 september 2026 niet officieel onderbouwd:

• Of de server QUIC-Retry voor de adrescontrole gebruikt. RFC 9000 staat in paragraaf 8.1.2 een Retry-pakket met token toe, waarmee een server het afzenderadres controleert voordat hij bronnen bindt. Of en vanaf welke belasting Hytale dat doet, is niet gedocumenteerd. Ga ervan uit dat u zich daar niet op kunt verlaten.
• De standaardwaarden van de blokken RateLimit en ConnectionTimeouts in config.json. Dat beide blokken bestaan, is over meerdere bronnen consistent. De genoemde cijfers spreken elkaar echter tegen: de ene bron noemt concrete grenswaarden, de andere beschrijft de blokken als aanwezig, maar zonder werking. Daarom staat in dit artikel geen van deze cijfers, en daarom moet u deze blokken niet als uw verdediging inplannen.
• De namen en standaardwaarden van de authenticatiemodi. De communitydocumentatie bij de gepubliceerde servercode beschrijft drie modi, gezet via --auth-mode, met authenticated als standaard plus offline en insecure voor private omgevingen en ontwikkeling. Officieel bevestigd is dat niet. De daaruit afgeleide regel is desondanks eenduidig: wijzig de modus voor een openbare server niet.
• Details van de TLS-opbouw. De protocoldocumentatie van de community, die op de gepubliceerde servercode berust, beschrijft een tweezijdig certificaat, een bij de start aangemaakt zelfondertekend servercertificaat waarvan de SHA-256-vingerafdruk via de sessiedienst bij de clients belandt, en een uitgeschakelde 0-RTT. Dat is plausibel en past bij TLS 1.3, maar het is niet officieel bevestigd, en het verandert niets aan de maatregelen hieronder.
• Aanvalsgroottes specifiek tegen Hytale-servers. Daarover zijn geen openbare cijfers. De in de tabel genoemde 5 tot 50 Gbit/s zijn een ervaringswaarde over gameserverprojecten heen en uitdrukkelijk geen Hytale-statistiek.
• Pakketsnelheden in normaal bedrijf per speler. Ook daarvoor bestaat geen betrouwbare publicatie. Daarom staat in dit artikel geen grenswaarde die u ongecontroleerd zou kunnen overnemen, maar een handleiding om hem zelf te meten.

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. Zij ruimen echter alles op wat daaronder ligt: poortscans, vloeden van verbindingspogingen uit weinig bronnen, overnamepogingen via aanvullend geïnstalleerde beheerinterfaces en het bezetten van alle plaatsen door vreemden. Dat is het grootste deel van wat een Hytale-server in het dagelijks bedrijf stoort, en het kost een goed 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:5520 betekent "vanaf het hele internet bereikbaar", 127.0.0.1:8080 betekent "alleen lokaal" en heeft geen vrijgave nodig. Naast het Java-proces van de server duiken op een gegroeide machine vaak een beheerpanel, een webserver voor de kaartweergave en een database op. Het beeld van de aanvaller levert een poortscan van buitenaf:

nmap -Pn -sU -p 5520 UW.SERVER.IP.ADRES
nmap -Pn -p- --min-rate 1000 UW.SERVER.IP.ADRES

Het tweede commando is het belangrijkere. Het toont wat er verder nog open staat, en in de praktijk is dat bijna altijd meer dan verwacht.

2. Alleen 5520 UDP open laten, al het andere sluiten

Twee vrijgaven volstaan. 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 5520/udp comment 'Hytale QUIC'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Een TCP-vrijgave op 5520 hebt u niet nodig. Draait u de server op een afwijkende poort, dan moet de vrijgave bij de waarde uit --bind passen, anders loopt de start wel door en komen de spelers toch niet aan. De volledige handleiding inclusief reddingsweg staat in UFW-firewall instellen zonder uzelf buiten te sluiten.

Voor alles wat u aanvullend voor het beheer hebt geïnstalleerd, geldt dezelfde regel als bij elk ander spel: niet op het open netwerk, maar via een SSH-poortdoorverwijzing bereikbaar maken en daarna lokaal tegen 127.0.0.1 werken:

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

3. De server starten zoals hij bedoeld is

De start bestaat uit één enkel commando. De serverbestanden haalt u via de officiële Hytale-downloader of uit uw eigen spelinstallatie:

java -Xms2G -Xmx4G -jar HytaleServer.jar --assets Assets.zip --bind 0.0.0.0:5520

Bij de eerste start legt de server config.json, de map logs/ en de wereldmap universe/ aan. Daarna meldt u hem eenmalig aan op zijn account, zodat de authenticatie van de spelers werkt. Dat loopt via een apparaatcode in de serverconsole:

/auth login device
/auth status

Zet -Xmx niet op het volledige werkgeheugen van de machine. Het besturingssysteem, de bestandssysteemcache en het Java-runtimeverbruik buiten de heap hebben eveneens plaats nodig, en een server die onder belasting in swap terechtkomt, ziet er voor uw spelers precies uit als een aanval.

4. Whitelist, serverwachtwoord en spelerslimiet tegen slotuitputting

Slotuitputting is de goedkoopste aanval op een communityserver en heeft geen bandbreedte nodig. Wie genoeg gelijktijdige verbindingen opbouwt, bezet alle plaatsen en sluit daarmee de eigenlijke gemeenschap buiten, zonder één gigabit te kopen. Hytale heeft daarvoor, in tegenstelling tot menig ander spel, het passende gereedschap in de leveringstoestand: een whitelist in whitelist.json, een blokkeerlijst in bans.json, rechten in permissions.json en in config.json de sleutels Password en MaxPlayers.

{
  "ServerName": "Mijn Hytale-server",
  "MOTD": "",
  "Password": "een waarde die alleen uw groep kent",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

Password is standaard leeg, iedereen met adres en poort komt dus binnen. Voor een gesloten server is een ingesteld wachtwoord de meest werkzame afzonderlijke maatregel tegen slotuitputting, voor een openbare server is dat de whitelist tijdens een aanvalsgolf. En één ding moet duidelijk zijn: een serverwachtwoord beschermt uw plaatsen, niet uw lijn. Een aanvaller die uw server overspoelt, wil helemaal niet meedoen.

Bewerk deze bestanden alleen bij een gestopte server. Het lopende serverproces houdt zijn eigen stand in het geheugen en kan wijzigingen die u ondertussen in het bestand schrijft, bij het afsluiten zonder melding overschrijven. Voor wijzigingen tijdens het bedrijf gebruikt u de consolecommando's in plaats van de editor.

5. De authenticatie op de standaardwaarde laten

De standaardmodus verlangt van elke speler een geldig Hytale-account. Dat is meer dan een licentiecontrole: het is een toegangsfilter dat massa-accounts duur maakt. Een aanvaller die plaatsen wil bezetten, heeft daarvoor geldige accounts nodig, en die kosten geld. Haal dat filter er niet uit.

De communitydocumentatie beschrijft naast de standaard twee verdere modi voor private omgevingen en voor ontwikkeling, waarmee zonder accountcontrole kan worden deelgenomen. Voor een openbare server zijn zij de slechtst haalbare instelling, omdat zij de slotuitputting van een geldvraag tot een scriptvraag maken. Schakelt u om te testen om, doe dat dan op een machine die niet op het internet staat, en schakel daarna terug.

6. Nieuwe verbindingspogingen begrenzen, en wel met de 1200-byteregel

Nu wordt het structurele voordeel van QUIC praktisch. Een geldige verbindingsopbouw komt volgens RFC 9000 aan als datagram van minstens 1200 byte. Lopend spelverkeer is duidelijk kleiner. Met verbindingsregistratie kunt u daarom nieuwe datastromen van bestaande onderscheiden en alles verwerpen wat nieuw en te klein is. Met nftables, geladen via nft -f:

table inet hytale {
    chain input {
        type filter hook input priority -10; policy accept;

        ct state new udp dport 5520 udp length < 1208 drop

        ct state new udp dport 5520 \
            meter hyconn { ip saddr limit rate over 5/second burst 10 packets } drop
    }
}

De eerste regel werkt op de UDP-lengte, dus 8 byte kop plus 1200 byte nuttige lading, samen 1208. Zij raakt uitsluitend pakketten die een nieuwe datastroom willen openen en daarvoor te klein zijn, en zij kan verbonden spelers niet raken. De tweede regel begrenst hoeveel nieuwe verbindingen één enkel bronadres per seconde mag openen. Vijf per seconde is ruimhartig: een echte speler bouwt één verbinding op en houdt die. De prioriteit -10 zorgt ervoor dat beide regels vóór de filterketen van UFW grijpen.

Een bovengrens voor de pakketsnelheid per bronadres op de spelpoort zelf is de derde zinvolle regel, en hier geldt uitdrukkelijk: het getal is een startwaarde, geen waarheid.

iptables -I INPUT -p udp --dport 5520 \
  -m hashlimit --hashlimit-name hytale_udp --hashlimit-mode srcip \
  --hashlimit-above 800/sec --hashlimit-burst 1200 -j DROP

Meet eerst een week in normaal bedrijf, daarna zet u de grens op het dubbele van de gemeten piekwaarde. Voor Hytale bestaat daarvoor geen gepubliceerd referentiegetal, en de waarden hangen sterk af van aantal spelers en kijkafstand. Wie te krap instelt, gooit zijn eigen spelers eruit, en wel eerst degenen met de slechtste lijn.

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 tellers op nul, dan grijpt zij niet.

7. De verbindingsregistratie van de kernel juist instellen

Dit punt verklaart uitvallen die op een volumeaanval lijken, maar er geen zijn. De kernel legt voor UDP-verkeer vermeldingen in de verbindingsregistratie aan, en bij vervalste afzenderadressen betekent elk adres een nieuwe vermelding. 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

Bij de meeste games is het beste antwoord daarop het spelverkeer helemaal niet te laten volgen. Bij Hytale is dat een echte afweging, want de 1200-byteregel uit stap 6 heeft de verbindingsregistratie nodig. Zonder haar weet het filter niet welk pakket een nieuwe datastroom opent. De aanbeveling luidt daarom: registratie behouden, tabel vergroten, timeout voor UDP kort houden. Een bestand onder /etc/sysctl.d/, geactiveerd met sysctl --system:

net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Wie de registratie toch wil uitschakelen, bijvoorbeeld op een machine met zeer veel gelijktijdige spelers, zet udp dport 5520 notrack in de raw-tabel en ziet daarmee af van de 1200-byteregel. Beide samen gaat niet. Voor één enkele Hytale-server is de regel meer waard dan de uitgespaarde tabelvermeldingen.

Komen pakketten sneller aan dan het Java-proces ze ophaalt, dan loopt bovendien de ontvangstbuffer over. Voor de spelers ziet dat uit als pakketverlies, terwijl de lijn vrij is. Of de bufferinstellingen hierboven nodig zijn, verraadt de kernel zelf: stijgt UdpRcvbufErrors in nstat -az, dan grijpen ze. Blijft de teller op nul, dan verandert de aanpassing niets.

8. Kijkafstand en aantal spelers passend bij de lijn kiezen

Deze stap is geen veiligheidsmaatregel, maar zij bepaalt wel hoeveel aanval u überhaupt verdraagt. Hypixel Studios heeft het in de officiële hardwarevereisten van 1 december 2025 duidelijk geformuleerd: verdubbelt u de kijkafstand, dan verviervoudigt u de hoeveelheid wereld om de speler. De officiële aanbeveling ligt op maximaal 12 chunks, dus 384 blokken, gezet via MaxViewRadius. Aan de clientzijde noemen dezelfde vereisten 2 Mbit/s als minimum en 8 Mbit/s als aanbeveling per speler voor het spelen met meerderen.

Rekent u dat voor uw server eens door. Een server met 40 spelers bij een ruime kijkafstand beweegt in normaal bedrijf een laag driecijferig megabitbereik. Dat is de waarde waaraan uw lijn zich moet meten, en het is tegelijk de waarde die een aanval moet overschrijden om op te vallen. Wie een lijn van 1 Gbit/s in normaal bedrijf voor een derde vult, heeft minder reserve dan iemand die op vijf procent zit. Een kleinere kijkafstand is daarom niet alleen een prestatievraag, maar ook een vraag van robuustheid.

9. Mods, plug-ins en protocolwissels in het oog houden

Hytale is aan de serverzijde moddbaar: mods liggen als .zip of .jar in de map mods/, en plug-ins spreken de serverinterface direct aan. Dat is prettig, omdat spelers niets hoeven te installeren, en het is tegelijk een beschikbaarheidsrisico dat niets met aanvallen te maken heeft. Een plug-in die per netwerkgebeurtenis duur werkt, is een versterker in uw eigen huis.

Daar komt de protocolwissel bij. Met Update 6 is het netwerkprotocol volgens de officiële patchnotes van 27 augustus 2026 van hytale/2 naar hytale/3 gewijzigd, en server en plug-ins moeten opnieuw worden gebouwd voordat zij verbinding maken. Voor de beschikbaarheid betekent dat: houd een lijst van uw mods inclusief versie bij, controleer die voor elke update op een tweede instantie, en plan voor 12 oktober 2026 een onderhoudsvenster in. Een server die na een update niet start, is voor uw spelers niet van een aanval te onderscheiden.

10. Meetwaarden verzamelen voordat het ernst wordt

De belangrijkste stap is die welke bijna niemand vooraf zet: een vergelijkingsbasis aanleggen zolang alles normaal loopt. 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. Tijdens een incident volstaan vijf commando's:

sar -n DEV 1 10
ip -s link show eth0
conntrack -C
nstat -az | grep -i -E 'udp|drop'
tcpdump -ni eth0 -c 200 "udp port 5520"

Voor tcpdump geldt: begrens hem altijd met -c, want een opname onder volle belasting belast een toch al overbelaste server nog extra. Omdat de Hytale-server op Java loopt, hebt u een tweede proef nodig die het meest voorkomende valse alarm uitsluit. Een pauze van de garbage collection ziet er voor spelers precies zo uit als een aanval: iedereen staat tegelijk stil, daarna loopt het verder. Het verschil staat in de cijfers.

jcmd $(pgrep -f HytaleServer.jar) GC.heap_info
tail -n 200 logs/latest.log

De uitwerking is eenvoudig. Stijgen de inkomende pakketten ver boven de normaalwaarde terwijl het Java-proces nauwelijks werkt, dan is het een aanval. Blijft de pakketsnelheid onopvallend terwijl de heap vol loopt of het logboek lange pauzes toont, dan is het belasting. Hoe u de netwerkwaarden in detail uitleest, staat in DDoS-aanval op de server herkennen.

11. Back-up, terugvalplan en een proefrun voor de grote datum

Een beschermingsconcept dat nooit is getest, is een vermoeden. Voor een datum als 12 oktober 2026 horen vier dingen geregeld: een back-up van de map universe/ inclusief config.json die buiten de machine ligt, een gecontroleerde terugkeer naar de vorige serverversie, een tweede instantie waarop u de update eerst inspeelt, en een eenmalige belastingtest die uw eigen filterregels uitlokt.

De belastingtest is het punt waar de meeste beheerders ophouden, en hij is het belangrijkste. Controleer niet of uw regels aanvallen afweren, maar of zij uw eigen spelers doorlaten. Daarvoor volstaat het de tellers in het oog te houden terwijl twintig echte spelers gelijktijdig meedoen. Lopen de tellers van de verwerpingsregels daarbij op, dan is uw grens te krap gezet, en u zou het op de dag van de update onder de slechtste omstandigheden hebben gemerkt.

Waar deze maatregelen ophouden: bandbreedte en pakketsnelheid

Nu het deel dat geen enkel configuratiebestand kan oplossen. Alle maatregelen tot hier lopen 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 gewoonlijk tussen 5 en 50 Gbit/s, dus op het vijf- tot vijftigvoudige van uw lijn. Of uw nftables-regel daarachter goed is, speelt dan geen rol meer, 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 aan het verwerpen opgaat. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch was alles weg".

Bij Hytale komt een derde grootheid erbij die bij de meeste games niet bestaat: de rekentijd voor de verbindingsopbouw. Een vloed geldige verbindingspogingen uit een botnet vult geen lijn en produceert geen opvallende pakketsnelheid, zij houdt de processor met cryptografie bezig. Zulke aanvallen zijn in de bandbreedtestatistiek onzichtbaar en in de processorbelasting van het Java-proces duidelijk, en noch een ratelimiet per bronadres noch een grotere ontvangstbuffer helpt daartegen wanneer de bronnen talrijk genoeg zijn.

Ter plaatsing van de ordes van grootte die werkelijk voorkomen: op KernelHost-servers werden onder andere een aanval met ruim 473,4 Gbit/s bij ruim 41,5 miljoen pakketten per seconde op een voiceserver en een UDP-flood met ruim 112,2 Gbit/s op een gameserver gefilterd. Daarvoor bestaat geen lokale instelling. Volumetrische aanvallen moeten in het netwerk vóór de server eindigen.

Wat KernelHost tegen DDoS-aanvallen op Hytale-servers stelt

De permanente bescherming die in 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, er zijn dus geen eerste minuten waarin de server weg is. En er wordt geen null-routing toegepast: uw IP-adres blijft in het netwerk, alleen de schadelijke pakketten worden verworpen. Wie het IP-adres uit het netwerk haalt, bereikt voor u hetzelfde resultaat als de aanvaller. Welke titels en protocollen met eigen beschermingsprofielen zijn gedekt, somt Gameserver-DDoS-bescherming in realtime op.

Advanced DDoS Protection voor Hytale-projecten die permanent onder vuur liggen

Sommige projecten worden niet af en toe, maar gericht en wekenlang aangevallen, en bij een spel in Early Access treft dat vooral de servers die juist aan het groeien zijn. 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 vast wat op 5520 UDP is toegestaan, gescheiden van al het andere, en hebt daarvoor geen ticket nodig.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen, bijvoorbeeld nieuwe verbindingen kortstondig strakker begrenzen en het lopende spelverkeer onaangeroerd laten.
• Een regelset die bij het protocol past, voor QUIC over UDP 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 Hytale-project momenteel elders draait en permanent wordt aangevallen, verhuist het daarvoor naar KernelHost, dan grijpen beide lagen vanaf de oplevering.

De twee lagen naast elkaar

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

Wat zich uit andere games op Hytale laat overbrengen

Omdat Hytale nog jong is en er over aanvallen op Hytale-servers geen openbare cijfers bestaan, is de snelste weg naar betrouwbare kennis de blik op vergelijkbare games. Overdraagbaar is daarbij niet het poortnummer, maar het patroon.

• De explosieve start en wat die uitlokt: Palworld laat zien hoe een golf nieuwe spelers en een golf aanvallen in de tijd samenvallen en waarom juist groeiende servers doelwit worden.
• Het verschil tussen opvraging en spelverkeer: Minecraft Bedrock legt aan de hand van de Unconnected Ping uit hoe versterking via UDP werkt. Precies die aanvalsweg heeft Hytale door QUIC niet, en daaraan laat het verschil zich het best begrijpen.
• Verbindingsopbouw als aanvalsdoel: Minecraft-DDoS-bescherming en nullping-bescherming beschrijft handshake-floods die met bijna geen bandbreedte toekunnen. Dat is de naaste verwant van de QUIC-verbindingsflood.
• Kleine spelersaantallen en slotuitputting: Project Zomboid en Conan Exiles laten zien hoe weinig inspanning nodig is om een vaste groep buiten te sluiten, en welke rol whitelist en wachtwoord daarbij spelen.
• Bedrijf onder permanente belasting: Terraria laat zien hoe een enkel serverproces met belasting op één kern op aanvallen reageert. De Hytale-server is een Java-proces, het grondprobleem is vergelijkbaar.

Veelgemaakte fouten bij Hytale-servers en hun oplossing

"Ik heb poort 5520 TCP vrijgegeven en de spelers komen er toch niet in": het spelverkeer loopt via QUIC, dus via UDP. Een TCP-vrijgave levert voor het spelverkeer niets op. Geef 5520 UDP vrij en controleer het van buitenaf met nmap -Pn -sU -p 5520. Hebt u de server met --bind op een andere poort gelegd, dan moet de vrijgave die poort noemen.

"De server loopt, maar niemand kan meedoen, en in het logboek staat niets over aanvallen": controleer de aanmelding van de server op zijn account met /auth status. Een server waarvan de aanmelding is verlopen, loopt verder en wijst spelers desondanks af. Dat is geen netwerkprobleem en geen filterregel.

"Na de update start er niets meer": dat is geen aanval, maar de protocolwissel. Met Update 6 is het netwerkprotocol van hytale/2 naar hytale/3 gewijzigd, en server en plug-ins hebben een nieuwe bouw nodig. Speel updates eerst op een tweede instantie in voordat u ze op de productieserver toelaat.

"Alle spelers staan gelijktijdig twee seconden stil, daarna loopt het verder": dat is met grote waarschijnlijkheid de garbage collection van de Java-runtime en geen aanval. Controleer jcmd ... GC.heap_info en het serverlogboek. Blijft sar -n DEV 1 10 daarbij onopvallend, dan was er geen aanval in het spel, maar een te krap bemeten heap of een te grote kijkafstand.

"Mijn regel tegen kleine pakketten heeft de spelers buitengesloten": dan staat de 1200-bytevoorwaarde zonder ct state new in de keten. Lopend spelverkeer bestaat overwegend uit kleine pakketten, en een lengtevoorwaarde zonder toestandscontrole raakt precies die. De voorwaarde geldt uitsluitend voor nieuw geopende datastromen.

"Ik heb het IP-adres gewisseld en was twee uur later weer offline": de aanvaller heeft het nieuwe adres uit dezelfde bron als het oude. Bij Hytale is dat meestal een oud A-record in het DNS, een Discord-bot met statusweergave of een vermelding in een van de vele serverlijsten van derden. Sinds Update 6 zijn serveradressen in de officiële serverlijst standaard verborgen, wat de gemakkelijkste weg sluit, maar niet alle. Een adreswissel levert tijd op, maar is geen oplossing.

"Mijn filterregels 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.

"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 Hytale-server heeft precies één open poort nodig: 5520 UDP voor QUIC. TCP is voor het spelverkeer niet nodig, en in de openbare documentatie is geen verdere poort voor opvragingen, RCON of afstandsbesturing beschreven.
• Omdat QUIC volgens RFC 9000 vóór de adrescontrole maximaal de drievoudige ontvangen hoeveelheid byte mag versturen en een eerste verbindingspoging minstens 1200 byte groot moet zijn, is een Hytale-server als reflectieversterker praktisch oninteressant. Dat onderscheidt hem van servers met Steam-opvraging of Bedrock-Unconnected-Ping.
• Diezelfde 1200-byteregel is de beste lokale filterregel: wat een nieuwe datastroom op 5520 UDP wil openen en kleiner is, kan geen geldige verbindingsopbouw zijn en laat zich verwerpen zonder verbonden spelers te raken.
• Het dure deel van een QUIC-opbouw is de cryptografie, niet de bandbreedte. Een vloed geldige verbindingspogingen is in de bandbreedtestatistiek onzichtbaar en alleen in de processorbelasting en in de tellers voor nieuwe verbindingen te zien.
• De standaardmodus met accountplicht is een toegangsfilter dat massa-accounts duur maakt. Voor een openbare server blijft hij onaangeroerd, daarbij komen whitelist.json, bans.json en een ingestelde waarde in Password tegen slotuitputting.
• Lokale maatregelen eindigen bij de lijn: 1 Gbit/s is 125 megabyte per seconde, en bij pakketten van 64 byte passen daar ongeveer 1,49 miljoen pakketten per seconde in. Alles daarboven moet in het netwerk vóór de server eindigen.
• Hytale is sinds 13 januari 2026 in Early Access, Chapter 1 is voor 12 oktober 2026 aangekondigd. Grote data zijn aanvalsdata, en bescherming die op de datum zelf wordt besteld, komt te laat.
• 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 een dedicated beschermd IP-adres en zelf beheerbare regels per poort begint bij 50,00 € per maand.

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

Dit artikel heeft de stand van 27 september 2026. Hytale is in Early Access, en het netwerkprotocol is dit jaar al één keer gewijzigd. Het wordt na Chapter 1 en na elke update bijgewerkt die de verbindingsopbouw, de poorten of de serverlijst betreft.