Terraria-server beschermen tegen DDoS-aanvallen

Wie zijn Terraria-server wil beschermen tegen DDoS-aanvallen, heeft met een bijzonder geval te maken: Terraria spreekt uitsluitend TCP. Het spelverkeer loopt over precies één poort, 7777 TCP, en een UDP-poort opent het spel helemaal niet. Bijna alle adviezen die op het net over gameserverbescherming circuleren, zijn voor UDP-spellen geschreven en grijpen hier ofwel in het luchtledige ofwel op de verkeerde plek.

Dit artikel laat eerst zien wat u zonder extra kosten zelf kunt afschermen, daarna waar die maatregelen technisch ophouden, en tot slot wat er dan in het netwerk vóór de server moet gebeuren. Alle gegevens gaan uit van een Terraria-dedicated-server (vanilla, TShock of tModLoader) 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, verander dan eerst niets aan de configuratie en start de server niet opnieuw op: leg de meetwaarden vast (zie de paragraaf "Vastleggen"), na de aanval zijn ze verdwenen.

Waarom juist Terraria-servers door DDoS-aanvallen worden getroffen

Terraria-servers zijn een gemakkelijk doelwit, omdat hun adres onvermijdelijk openbaar is. Vanilla-Terraria heeft geen ingebouwde serverbrowser: spelers verbinden via "Multiplayer" en "Join via IP", dus via een adres dat iemand vooraf bekend moet hebben gemaakt. Wie nieuwe spelers wil, schrijft de server in op lijstsites als terraria-servers.com, tserverweb.com of topg.org, of verspreidt het adres via Discord. Elk van die wegen levert een aanvaller hetzelfde als de speler: IP-adres en poort in leesbare vorm.

Gaat een Terraria-server voortdurend offline hoewel er aan hardware, wereld en modlijst niets is veranderd, dan is een aanval daarom de waarschijnlijkste verklaring. Daar komt de typische constellatie van een project bij: vaste speeltijden, concurrerende servers, verbannen spelers en ruzie in de community. Een aanval kost de opdrachtgever kunde noch noemenswaardig geld, een Terraria server booter wordt als abonnement voor een paar euro per maand verkocht. Wat een DDoS-aanval technisch is en hoe hij wordt opgebouwd, legt het artikel Wat is een DDoS-aanval? uit.

Terraria loopt over TCP, niet over UDP

Dat is het belangrijkste verschil met vrijwel elke andere gameserver. De Terraria-dedicated-server neemt verbindingen aan met een TCP-listener (in de spelengine de klasse Terraria.Net.Sockets.TcpSocket) en opent geen UDP-socket. Dat heeft vier gevolgen die uw hele verdediging bepalen:

• Een volledig opgebouwde TCP-verbinding laat zich niet vervalsen. De aanvaller moet het SYN-ACK van de server ontvangen om de handshake af te ronden. Wie dus werkelijk verbonden is, komt van een echt adres. IP-blokkades en bovengrenzen voor verbindingen werken bij Terraria daarom duidelijk beter dan bij een UDP-spel.
• Een SYN-flood laat zich wel degelijk vervalsen, omdat hij de handshake nooit afrondt. Tegen die soort helpt geen IP-blokkade, maar uitsluitend SYN-cookies en filtering ervóór.
• Elke aangenomen TCP-verbinding naar poort 7777 bezet middelen in het spelproces, niet alleen in de kernel. Dat maakt slotuitputting tot de werkzaamste aanval met de geringste bandbreedte.
• Een UDP-flood treft uw server toch. De pakketten hoeven niet te worden aangenomen om uw lijn te vullen. Dat Terraria geen UDP spreekt, beschermt de lijn niet, het verhindert alleen dat het spelproces zelf de pakketten verwerkt.

Er is één uitzondering: start men de dedicated server met -steam en -lobby friends of -lobby private, dan loopt de verbinding over het Steam-netwerk en daarmee over UDP-poorten in het bereik 27000 tot 27100. Dat is een andere bedrijfsmodus en niet de klassieke, via het IP-adres bereikbare server.

De poorten waar het werkelijk om gaat

Een Terraria-server heeft precies één poort op het open internet nodig: 7777 TCP. Al het andere in deze tabel hoort ofwel helemaal niet op het internet ofwel alleen op uw eigen adres.

Dat Terraria noch een querypoort noch RCON kent, is voor de afscherming goed nieuws: de twee endpoints die bij Counter-Strike, Rust of ARK regelmatig voor reflection-aanvallen worden misbruikt, bestaan hier eenvoudigweg niet. Daarvoor is het aanvalsoppervlak des te sterker geconcentreerd op poort 7777, en wie TShock inzet, haalt er met poort 7878 een tweede oppervlak bij.

Wat u zelf kunt doen voordat u geld uitgeeft

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

1. Inventarisatie: wat luistert er eigenlijk?

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:7777 betekent "vanaf het hele internet bereikbaar", 127.0.0.1:7878 betekent "alleen lokaal" en heeft geen firewallregel nodig. Duikt er in die lijst een UDP-vermelding voor uw Terraria-proces op, dan draait de server in de Steam-modus. Het beeld van de aanvaller levert een poortscan van buitenaf:

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

2. Alleen 7777 TCP openlaten en al het andere sluiten

Voor Terraria volstaat één enkele openstelling naar buiten. Een UDP-regel hebt u niet nodig, en een UDP-regel voor 7777 zou gewoonweg verkeerd zijn: ze laat verkeer door naar een poort waarop helemaal niets luistert. 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 7777/tcp comment 'Terraria'
ufw allow from 203.0.113.10 to any port 7878 proto tcp comment 'TShock REST'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Vervang 203.0.113.10 door uw eigen adres. De volledige handleiding inclusief reddingsweg vindt u onder UFW-firewall instellen zonder uzelf buiten te sluiten. Wie een paneel draait, beperkt ook 8080 en 2022 tot het eigen adres.

3. serverconfig.txt: wachtwoord, maxplayers en secure juist instellen

Het centrale configuratiebestand van de Terraria-server heet serverconfig.txt en wordt bij de start met -config serverconfig.txt meegegeven. Vier directieven zijn voor de afscherming doorslaggevend:

port=7777
maxplayers=16
password=EenLangWillekeurigWachtwoord
secure=1
upnp=0
banlist=banlist.txt

password= is de werkzaamste kosteloze maatregel tegen joinfloods die de reguliere weg nemen. De reden ligt in het protocol: een client stuurt eerst bericht 1 met zijn versieaanduiding (bijvoorbeeld Terraria279), de server antwoordt bij een ingesteld wachtwoord met bericht 37, de client moet met bericht 38 correct antwoorden, en pas daarna stuurt de server met bericht 3 de vrijgave inclusief spelersslot. Zonder het juiste wachtwoord komt een aanvaller dus nooit tot de overdracht van de wereld, het dure deel van een toetreding.

maxplayers neemt waarden van 1 tot 255 aan, de standaardinstelling is 16 (vóór versie 1.4.0.1 was het 8). De bovengrens van 255 is geen willekeurig getal: Terraria adresseert spelers met één enkele byte. Zet maxplayers niet hoger dan u werkelijk nodig hebt, want elk slot is een middel dat een aanvaller kan bezetten. secure=1 schakelt de ingebouwde cheatcontrole in (op de commandoregel -secure), upnp=0 verhindert dat de server op eigen houtje poorten op een router opent.

4. TShock afschermen: REST-API op 7878 en loginflood

TShock is de meest verbreide serveruitbreiding voor Terraria en brengt met de REST-API een tweede, volwaardig aanvalsoppervlak mee. Die ligt standaard op poort 7878 TCP en is in tshock/config.json geconfigureerd, dus niet in de serverconfig.txt. In de uitleveringstoestand staat ze uit ("RestApiEnabled": false), en precies zo hoort ze te blijven zolang u ze niet nodig hebt.

Hebt u ze wel nodig, dan zijn deze waarden relevant:

"RestApiEnabled": true,
"RestApiPort": 7878,
"EnableTokenEndpointAuthentication": true,
"LogRest": true,
"RESTMaximumRequestsPerInterval": 5,
"RESTRequestBucketDecreaseIntervalMinutes": 1

Twee dingen zijn daaraan belangrijk. Ten eerste levert het endpoint /status zonder token servernaam, poort, spelersaantal en spelersnamen uit, zolang EnableTokenEndpointAuthentication op false staat. Dat is handig voor statuspagina's en Discord-bots en tegelijk kosteloze verkenning voor elke aanvaller die wil weten wanneer een aanval loont. Ten tweede maakt het endpoint /v2/token/create uit gebruikersnaam en wachtwoord een toegangstoken, en het is van buitenaf bereikbaar zodra poort 7878 open staat: een wachtwoordraadaanval tegen uw beheerdersaccount, die en passant rekentijd kost. De emmer uit RESTMaximumRequestsPerInterval en RESTRequestBucketDecreaseIntervalMinutes remt dat af, maar vervangt geen firewallregel.

Voor de speltoegang zelf gelden verdere TShock-waarden. MaximumLoginAttempts staat op 3 en gooit een speler er na drie mislukte pogingen uit. RequireLogin (standaard false) verlangt een account voor elke speler. EnableIPBans (standaard true) en KickProxyUsers (standaard true) zijn bij een TCP-spel bijzonder werkzaam, omdat het bronadres van een opgebouwde verbinding nu eenmaal niet vervalst kan zijn. Tegen griefing, dat vaak als aanval wordt gemeld, werken de drempelwaarden TileKillThreshold (60), TilePlaceThreshold (20), TileLiquidThreshold (15) en ProjectileThreshold (50), telkens acties per seconde.

5. Verbindingen per bronadres begrenzen en SYN-cookies controleren

Omdat Terraria op TCP draait, is de werkzaamste lokale regel een bovengrens voor gelijktijdige verbindingen per bronadres. Een echte speler heeft er precies één nodig:

iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m hashlimit --hashlimit-name terraria_syn --hashlimit-mode srcip --hashlimit-above 10/min --hashlimit-burst 20 -j DROP

De eerste regel verwerpt nieuwe verbindingen zodra één adres er meer dan drie tegelijk open heeft staan. De tweede begrenst de snelheid van de verbindingspogingen uit dezelfde bron tot tien per minuut met een speelruimte van 20. Beide getallen zijn startwaarden, geen waarheden: een server achter een gedeelde aansluiting (studentenhuis, schoolnetwerk, mobiele provider) ziet meerdere legitieme spelers onder hetzelfde adres. Meet daarom eerst een week lang in normaal bedrijf.

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 in /etc/ufw/before.rules, omdat ze anders bij de volgende ufw reload verdwijnen. Tegen vervalste SYN-pakketten die de handshake nooit afronden, helpt geen van deze regels, maar de kernel zelf. Controleer de drie waarden:

sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn

net.ipv4.tcp_syncookies moet op 1 staan, op Debian en Ubuntu is dat doorgaans al het geval. SYN-cookies zien af van de wachtrij met halfopen verbindingen en reconstrueren de toestand uit het antwoord van de client; een SYN-flood loopt daarmee in het luchtledige, zolang de lijn niet vol zit. net.core.somaxconn staat sinds Linux 5.4 op 4096 en daarvoor op 128: is de waarde klein, dan verwerpt de kernel volledig opgebouwde verbindingen voordat het spelproces ze überhaupt kan aannemen.

6. Slotuitputting verhinderen: waarom een poortscan uw server vult

Slotuitputting is de goedkoopste werkzame aanval op een Terraria-server: de aanvaller opent zoveel TCP-verbindingen naar poort 7777 als de server spelersslots heeft, en houdt ze open. Dat kost hem bijna geen bandbreedte, maar vult wel de server. Echte spelers zien "Server is full" en komen er niet meer in, hoewel er op uw lijn niets opvallends gebeurt. Precies dat is de reden waarom beheerders bij Terraria vaak niet merken dat ze worden aangevallen.

De oorzaak ligt in de manier van tellen: een verbinding wordt aangenomen voordat de client zijn versieaanduiding überhaupt heeft gestuurd. Historisch bleven zulke spookverbindingen bezet totdat de TCP-sessie was verlopen. De 1.4.5-reeks heeft dat verzacht, daar worden voor clients die zich meteen weer losmaken geen slots meer gereserveerd. In de eerste uitgaven van 1.4.5.7 en 1.4.5.8 stortte de dedicated server echter neer met een onafgehandelde ObjectDisposedException zodra een TCP-verbinding werd geopend en de handshake niet werd afgerond. Een nc -z of een bereikbaarheidscontrole van een monitoring volstond al. De fout is binnen enkele weken stil verholpen, in oudere containerimages zit hij deels nog. Houd uw serverversie daarom actueel; dat is hier geen gemeenplaats, maar een concrete kwestie van beschikbaarheid.

Twee instellingen helpen daarnaast. Wie TShock gebruikt, zet MaxSlots op het gewenste spelersaantal en maxplayers in de serverconfig.txt twee plaatsen hoger: dan verwerpt TShock overtollige verbindingen met een nette melding, in plaats van dat het spelproces ze in het laatste gat laat. En de bovengrens voor verbindingen uit de vorige paragraaf is precies de regel die één enkel adres verhindert om alle slots tegelijk te bezetten.

7. UPnP uitschakelen en het adres niet zelf publiceren

De Terraria-server probeert standaard zijn poort via UPnP op een router te openen. Op een gehuurde server is dat zinloos, in een thuisnetwerk opent het poorten waar u later niets meer van weet. Schakel het uit met upnp=0 in de serverconfig.txt of met -noupnp op de commandoregel.

Hier loont bovendien eerlijkheid meer dan wensdenken: uw IP-adres laat zich niet geheimhouden. Iedere speler die ooit verbonden is geweest, kent het, en een vermelding op een lijstsite publiceert het sowieso. Werkzaam zijn twee gewoonten. Publiceer het kale IP-adres nergens zelf, maar laat uw spelers via een hostnaam verbinden: de Terraria-client lost een hostnaam op, u kunt het adres in geval van nood dus wisselen zonder dat alle verwijzingen breken. En ruim oude DNS-records op, want een vergeten A-record naar het vorige adres maakt elke wissel zinloos.

8. Statusopvragingen tussentijds opslaan in plaats van doorgeven

Omdat Terraria geen opvraagprotocol heeft, bepalen statuspagina's, Discord-bots en lijstsites de toestand van uw server op een van twee manieren: ze bouwen een echte TCP-verbinding naar 7777 op en doen zich voor als client, of ze vragen de TShock-REST-API op. Beide kosten uw server werk, en beide schalen mee met het aantal opvragers.

De tegenmaatregel kost niets: vraag nooit vanuit de bezoeker op. Laat één enkele dienst de status op vaste intervallen ophalen (30 of 60 seconden volstaan), sla het resultaat tussentijds op en lever alle bezoekers de tussentijds opgeslagen stand uit. Daarmee veroorzaakt een druk bezochte statuspagina één opvraag per interval in plaats van één per bezoeker. Wie daarvoor de REST-API gebruikt, beperkt poort 7878 tot het adres van die ene dienst.

9. Vastleggen zodat u in geval van nood gegevens hebt

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 vijf commando's:

sar -n DEV 1 10
ss -s
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 tcp port 7777 -c 200 -q

Het derde commando is het terraria-specifieke: het telt de halfopen verbindingen. Een tweecijferige waarde is normaal, een vier- of vijfcijferige is een SYN-flood. ss -s toont daarnaast het totale aantal TCP-verbindingen, en komt dat getal ongeveer overeen met uw maxplayers terwijl er in het spel niemand is, dan ziet u een slotuitputting. Voor tcpdump geldt: begrens hem altijd met -c, 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

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 op gameserverprojecten van deze omvang liggen doorgaans tussen 5 en 50 Gbit/s, dus op het vijf- tot vijftigvoudige van uw lijn. Of uw connlimit-regel daarachter goed is, doet dan niet meer ter zake, want de pakketten van uw spelers komen al eerder niet door. Precies zo ontstaan lag-spikes op een Terraria-server waarbij de CPU-belasting er normaal uitziet.

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 CPU en netwerkkaart, enkele honderdduizenden voordat hij begint te verwerpen. Bij een SYN-flood ligt de grens nog lager, omdat elk SYN-pakket een toestandsbeslissing uitlokt: al enkele tienduizenden SYN-pakketten per seconde volstaan om de verbindingsaanname van een standaard-Linux plat te leggen, lang voordat de lijn vol zit. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch was alles weg".

En het derde punt is het punt dat bij Terraria het vaakst over het hoofd wordt gezien: een aanvaller richt zich niet naar uw protocol. Hij stuurt UDP-vloeden en reflection-verkeer naar uw adres, hoewel er op geen enkele UDP-poort iets luistert. Uw server verwerpt die pakketten correct, maar ze hebben uw lijn al bezet, en uw Terraria-server gaat offline zonder dat één enkel pakket het spelproces heeft bereikt. 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 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 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. Voor Terraria betekent dat concreet: SYN-vloeden en verbindingsfloods tegen 7777 TCP eindigen hier, niet op uw netwerkkaart.

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, 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 stelt in wat op 7777 TCP is toegestaan, en kunt al het andere dichtzetten zonder daarvoor een ticket te schrijven.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen, bijvoorbeeld de toegestane verbindingssnelheid per bronadres strakker trekken.
• Een beschermingsprofiel dat bij de toepassing past. Voor TCP-spellen zoals Terraria en voor eigen of aangepaste applicaties op willekeurige TCP- of UDP-poorten bestaan passende profielen.

De twee lagen naast elkaar

Voor de meeste Terraria-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 ergens anders draait, krijgt de bescherming niet achteraf ingebouwd, maar door de verhuizing naar KernelHost: de filtering is onderdeel van het netwerk, niet een toevoeging op de server.

Veelgemaakte fouten en oplossingen

"De server is vol, maar er zit niemand in": dat is een slotuitputting. Controleer met ss -tn dst :7777 | wc -l hoeveel verbindingen er werkelijk open staan, en vergelijk dat met de spelerslijst (serverconsole: playing). Komen de getallen niet overeen, dan bezetten vreemde verbindingen de slots. Tegenmiddelen zijn de bovengrens voor verbindingen per bronadres, een serverwachtwoord en een actuele serverversie.

"Ik heb 7777 UDP vrijgegeven en het verandert niets": klopt, want op 7777 UDP luistert niets. Terraria gebruikt uitsluitend TCP. De UDP-vrijgave schaadt niet direct, maar ze is een onnodige opening en een zeker teken dat er een handleiding voor een ander spel is gekopieerd.

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

"Spelers vliegen eruit hoewel er geen aanval loopt": trekt u uw connlimit-grens te strak, dan treft dat spelers achter gedeelde aansluitingen. Bij TCP gebeurt dat sneller dan bij UDP-spellen, omdat een herverbinding na een onderbreking meteen een nieuwe verbinding aanmaakt terwijl de oude nog in TIME_WAIT hangt. Verhoog de waarde stapsgewijs en houd de tellers in de gaten.

"De server hapert, de lijn is rustig": dat is vaker een mod of een plug-in dan een aanval. Onder tModLoader kost elke extra mod rekentijd in hetzelfde proces, en een wereld met veel entiteiten belast een kern volledig zonder dat er één pakket te veel aankomt. Blijft sar -n DEV 1 10 onopvallend, dan was het geen DDoS-aanval.

"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 Terraria-server heeft precies één open poort nodig: 7777 TCP. Het spel opent geen UDP-socket, heeft geen opvraagprotocol en geen RCON.
• De TShock-REST-API op poort 7878 TCP is het tweede aanvalsoppervlak. Laat RestApiEnabled op false staan of beperk de poort tot uw eigen adres.
• Een serverwachtwoord in de serverconfig.txt is de werkzaamste kosteloze maatregel, omdat een aanvaller zonder correct antwoord op bericht 37 nooit tot de overdracht van de wereld komt.
• Slotuitputting is bij Terraria de goedkoopste aanval: elke aangenomen TCP-verbinding naar 7777 bezet een plaats, geheel zonder noemenswaardige bandbreedte. Daartegen werken een bovengrens per bronadres, een wachtwoord en een actuele serverversie.
• Omdat Terraria TCP gebruikt, laat het bronadres van een opgebouwde verbinding zich niet vervalsen: IP-blokkades werken hier beter dan bij UDP-spellen. Tegen vervalste SYN-vloeden helpen alleen SYN-cookies en filtering ervóór.
• Een UDP-flood legt uw Terraria-server plat hoewel hij geen UDP spreekt, want hij vult de lijn voordat het spelproces ook maar iets ziet.
• Vanaf ongeveer de omvang van uw uplinkbandbreedte beslist uitsluitend het netwerk vóór de server. Bij KernelHost is die filtering in twee lagen opgebouwd, permanent actief en zonder meerprijs in elk serverpakket inbegrepen.

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