Skydda Terraria-servern mot DDoS-attacker
Varför Terraria bara talar TCP, vilka portar servern verkligen behöver, hur du säkrar serverconfig.txt, TShock och REST-API:t på 7878, och från vilken attackstorlek bara filtrering i nätet framför servern hjälper.
Den som vill skydda sin Terraria-server mot DDoS-attacker har att göra med ett specialfall: Terraria talar uteslutande TCP. Speltrafiken går över exakt en port, 7777 TCP, och någon UDP-port öppnar spelet över huvud taget inte. Nästan alla råd om skydd av spelservrar som cirkulerar på nätet är skrivna för UDP-spel och griper här antingen i tomma luften eller på fel ställe.
Det här inlägget visar först vad du kan säkra själv utan extra kostnad, därefter var de åtgärderna tar slut rent tekniskt, och till sist vad som då måste hända i nätet framför servern. Alla uppgifter gäller en Terraria Dedicated Server (vanilla, TShock eller tModLoader) under Debian 12, Debian 13, Ubuntu 22.04 LTS eller Ubuntu 24.04 LTS. Kommandona är skrivna för root, som vanlig användare sätter du sudo framför. Pågår attacken just nu ändrar du först ingenting i konfigurationen och startar inte om servern: säkra mätvärdena (se avsnittet "Logga"), efter attacken är de borta.
Varför just Terraria-servrar träffas av DDoS-attacker
Terraria-servrar är ett bekvämt mål, eftersom deras adress ofrånkomligen är offentlig. Vanilla-Terraria har ingen inbyggd serverlista: spelarna ansluter via "Multiplayer" och "Join via IP", alltså via en adress som någon måste ha gjort känd i förväg. Den som vill ha nya spelare för in servern på listsidor som terraria-servers.com, tserverweb.com eller topg.org, eller sprider adressen via Discord. Var och en av de vägarna ger en angripare exakt det den ger spelaren: IP-adress och port i klartext.
Går en Terraria-server ständigt offline trots att ingenting har ändrats i hårdvara, värld och modlista är en attack därför den mest sannolika förklaringen. Till det kommer ett projekts typiska sammansättning: fasta speltider, konkurrerande servrar, bannlysta spelare och gräl i communityn. En attack kostar beställaren varken kunnande eller nämnvärda pengar, en Terraria Server Booter säljs som abonnemang för några få euro i månaden. Vad en DDoS-attack är rent tekniskt och hur den byggs upp förklarar inlägget Vad är en DDoS-attack?.
Terraria går över TCP, inte över UDP
Det är den viktigaste skillnaden mot praktiskt taget varje annan spelserver. Terraria Dedicated Server tar emot anslutningar med en TCP-lyssnare (i spelmotorn klassen Terraria.Net.Sockets.TcpSocket) och öppnar ingen UDP-socket. Det har fyra följder som bestämmer hela ditt försvar:
- En fullständigt upprättad TCP-anslutning går inte att förfalska. Angriparen måste ta emot serverns SYN-ACK för att fullborda handskakningen. Den som alltså verkligen är ansluten kommer från en äkta adress. IP-spärrar och övre gränser för antalet anslutningar verkar därför betydligt bättre hos Terraria än hos ett UDP-spel.
- En SYN-flood går däremot mycket väl att förfalska, eftersom den aldrig fullbordar handskakningen. Mot den sorten hjälper ingen IP-spärr, utan uteslutande SYN-cookies och filtrering framför.
- Varje mottagen TCP-anslutning till port 7777 upptar resurser i spelprocessen, inte bara i kärnan. Det gör platsutmattning till den verksammaste attacken med minst bandbredd.
- En UDP-flood träffar din server ändå. Paketen måste inte tas emot för att fylla din ledning. Att Terraria inte talar UDP skyddar inte ledningen, det förhindrar bara att spelprocessen själv bearbetar paketen.
Ett undantag finns: startar man Dedicated Server med -steam och -lobby friends eller -lobby private går anslutningen över Steam-nätverket och därmed över UDP-portar i området 27000 till 27100. Det är ett annat driftläge och inte den klassiska servern som nås via IP-adressen.
Portarna som det faktiskt handlar om
En Terraria-server behöver exakt en port i det öppna nätet: 7777 TCP. Allt annat i den här tabellen hör antingen inte alls hemma på internet eller bara på din egen adress.
| Ändamål | Port | Protokoll | Var det ställs in | Ut i det öppna nätet? |
|---|---|---|---|---|
| Terraria-speltrafik | 7777 | TCP | serverconfig.txt: port=7777 |
ja, som enda |
| Terraria över UDP | ingen | inget | spelet öppnar ingen UDP-socket | nej |
| Query- eller statusport | ingen | inget | Vanilla-Terraria har inget eget förfrågningsprotokoll | nej |
| RCON | ingen | inget | Terraria har inget RCON, fjärrstyrning bara via TShock | nej |
| TShock REST-API | 7878 | TCP | tshock/config.json: RestApiPort |
nej |
| tModLoader-server | 7777 | TCP | samma serverconfig.txt |
ja, som enda |
Steam-läge (-steam -lobby) |
27000 till 27100 | UDP | bara i Steam-driftläget | nej |
| Pterodactyl Wings | 8080 | TCP | panelens bakgrundstjänst | nej, bara egen adress |
| Pterodactyl SFTP | 2022 | TCP | panelens SFTP | nej, bara egen adress |
| SSH | 22 | TCP | /etc/ssh/sshd_config |
bara egen adress |
Att Terraria varken känner till en query-port eller RCON är goda nyheter för säkringen: de två slutpunkter som hos Counter-Strike, Rust eller ARK regelbundet missbrukas för reflektionsattacker finns helt enkelt inte här. I gengäld är angreppsytan desto hårdare koncentrerad till port 7777, och den som använder TShock skaffar sig med port 7878 en andra yta till.
Vad du kan göra själv innan du lägger ut pengar
Det här avsnittet är det längsta, och det är avsiktligt. En rent konfigurerad Terraria-server klarar små och medelstora attacker av egen kraft, oavsett hos vem den står.
1. Inventering: vad lyssnar egentligen?
Innan du skriver en enda regel tittar du efter vad din server erbjuder utåt. Inte gissa, titta efter:
ss -lntup
Intressant är kolumnen med den lokala adressen. 0.0.0.0:7777 betyder "nåbar från hela internet", 127.0.0.1:7878 betyder "bara lokalt" och behöver ingen brandväggsregel. Dyker det upp en UDP-post för din Terraria-process i den listan körs servern i Steam-läget. Angriparens vy får du med en portskanning utifrån:
nmap -Pn -p- --min-rate 1000 DIN.SERVER.IP.ADRESS
2. Lämna bara 7777 TCP öppen, stäng allt annat
För Terraria räcker en enda öppning utåt. Någon UDP-regel behöver du inte, och en UDP-regel för 7777 vore helt enkelt fel: den släpper igenom trafik till en port där ingenting alls lyssnar. Med UFW ser det ut så här, och då i exakt den ordningen så att du inte låser ute dig själv:
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
Ersätt 203.0.113.10 med din egen adress. Den fullständiga anvisningen inklusive räddningsvägen hittar du i Sätta upp UFW-brandväggen utan att låsa ute dig själv. Den som driver en panel begränsar även 8080 och 2022 till den egna adressen.
3. serverconfig.txt: sätt lösenord, maxplayers och secure rätt
Terraria-serverns centrala konfigurationsfil heter serverconfig.txt och skickas med vid start via -config serverconfig.txt. Fyra direktiv är avgörande för säkringen:
port=7777
maxplayers=16
password=EttLångtSlumpmässigtLösenord
secure=1
upnp=0
banlist=banlist.txt
password= är den verksammaste kostnadsfria åtgärden mot anslutningsfloder som tar den reguljära vägen. Skälet ligger i protokollet: en klient skickar först meddelande 1 med sin versionsbeteckning (till exempel Terraria279), servern svarar vid satt lösenord med meddelande 37, klienten måste svara korrekt med meddelande 38, och först därefter skickar servern med meddelande 3 tillträdet inklusive spelarplats. Utan rätt lösenord kommer en angripare alltså aldrig fram till världsöverföringen, som är den dyra delen av en anslutning.
maxplayers tar värden från 1 till 255, förinställningen är 16 (före version 1.4.0.1 var det 8). Den övre gränsen på 255 är ingen godtycklig siffra: Terraria adresserar spelare med en enda byte. Sätt inte maxplayers högre än du verkligen behöver, för varje plats är en resurs som en angripare kan uppta. secure=1 slår på den inbyggda fuskkontrollen (på kommandoraden -secure), upnp=0 förhindrar att servern på eget bevåg öppnar portar i en router.
4. Säkra TShock: REST-API på 7878 och inloggningsflod
TShock är den mest utbredda serverutökningen för Terraria och för med REST-API:t med sig en andra, fullvärdig angreppsyta. Det ligger som standard på port 7878 TCP och konfigureras i tshock/config.json, alltså inte i serverconfig.txt. I leveransskicket är det avstängt ("RestApiEnabled": false), och precis så bör det förbli så länge du inte behöver det.
Behöver du det är de här värdena relevanta:
"RestApiEnabled": true,
"RestApiPort": 7878,
"EnableTokenEndpointAuthentication": true,
"LogRest": true,
"RESTMaximumRequestsPerInterval": 5,
"RESTRequestBucketDecreaseIntervalMinutes": 1
Två saker är viktiga med det. För det första levererar slutpunkten /status ut servernamn, port, spelarantal och spelarnamn utan token, så länge EnableTokenEndpointAuthentication står på false. Det är bekvämt för statussidor och Discord-bottar och samtidigt gratis spaning för varje angripare som vill veta när en attack lönar sig. För det andra skapar slutpunkten /v2/token/create ett åtkomsttoken ur användarnamn och lösenord, och den är nåbar utifrån så snart port 7878 står öppen: en lösenordsgissningsattack mot ditt adminkonto, som på köpet kostar beräkningstid. Hinken ur RESTMaximumRequestsPerInterval och RESTRequestBucketDecreaseIntervalMinutes bromsar det, men ersätter ingen brandväggsregel.
För själva spelåtkomsten griper ytterligare TShock-värden. MaximumLoginAttempts står på 3 och kastar ut en spelare efter tre misslyckade försök. RequireLogin (standard false) kräver ett konto för varje spelare. EnableIPBans (standard true) och KickProxyUsers (standard true) är särskilt verksamma hos ett TCP-spel, eftersom källadressen till en upprättad anslutning just inte kan vara förfalskad. Mot griefing, som ofta rapporteras som attack, verkar tröskelvärdena TileKillThreshold (60), TilePlaceThreshold (20), TileLiquidThreshold (15) och ProjectileThreshold (50), var och en åtgärder per sekund.
5. Begränsa anslutningar per källadress och kontrollera SYN-cookies
Eftersom Terraria går över TCP är den verksammaste lokala regeln en övre gräns för samtidiga anslutningar per källadress. En äkta spelare behöver exakt en:
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
Den första regeln förkastar nya anslutningar så snart en adress har mer än tre av dem öppna samtidigt. Den andra begränsar frekvensen av anslutningsförsök från samma källa till tio per minut med ett spelrum på 20. Båda siffrorna är startvärden, inga sanningar: en server bakom en gemensam anslutning (kollektiv, skolnät, mobiloperatör) ser flera legitima spelare under samma adress. Mät först en vecka i normal drift.
Rena iptables-regler är borta efter en omstart, under Debian och Ubuntu säkrar man dem så här:
apt-get install -y iptables-persistent
netfilter-persistent save
Under UFW hör sådana regler hemma i /etc/ufw/before.rules, eftersom de annars försvinner vid nästa ufw reload. Mot förfalskade SYN-paket, som aldrig fullbordar handskakningen, hjälper ingen av de reglerna, utan kärnan själv. Kontrollera de tre värdena:
sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn
net.ipv4.tcp_syncookies måste stå på 1, på Debian och Ubuntu är det i regel redan fallet. SYN-cookies avstår från kön av halvöppna anslutningar och rekonstruerar tillståndet ur klientens svar, en SYN-flood löper därmed ut i tomma luften så länge ledningen inte är full. net.core.somaxconn står sedan Linux 5.4 på 4096 och dessförinnan på 128: är värdet litet förkastar kärnan färdigt upprättade anslutningar innan spelprocessen över huvud taget kan ta emot dem.
6. Förhindra platsutmattning: varför en portskanning fyller din server
Platsutmattning är den billigaste verksamma attacken mot en Terraria-server: angriparen öppnar så många TCP-anslutningar till port 7777 som servern har spelarplatser, och håller dem öppna. Det kostar honom nästan ingen bandbredd, men fyller servern. Äkta spelare ser "Server is full" och kommer inte längre in, trots att ingenting anmärkningsvärt händer på din ledning. Just det är skälet till att serverägare hos Terraria ofta inte märker att de angrips.
Orsaken ligger i räknesättet: en anslutning tas emot innan klienten över huvud taget har skickat sin versionsbeteckning. Historiskt förblev sådana spökanslutningar upptagna tills TCP-sessionen hade löpt ut. 1.4.5-serien har dämpat det, där reserveras inga platser längre för klienter som genast kopplar ner igen. I de första utgåvorna av 1.4.5.7 och 1.4.5.8 kraschade Dedicated Server dock med ett obehandlat ObjectDisposedException så snart en TCP-anslutning öppnades och handskakningen inte fullbordades. Ett nc -z eller en nåbarhetskontroll från en övervakning räckte. Felet åtgärdades tyst inom några veckor, i äldre containeravbildningar sitter det delvis kvar. Håll därför din serverversion aktuell, det är här ingen självklarhet utan en konkret tillgänglighetsfråga.
Två inställningar hjälper därutöver. Den som använder TShock sätter MaxSlots på det önskade spelarantalet och maxplayers i serverconfig.txt två platser högre: då förkastar TShock överflödiga anslutningar med ett rent meddelande, i stället för att spelprocessen släpper in dem i den sista luckan. Och den övre gränsen för anslutningar ur föregående avsnitt är precis den regel som hindrar en enskild adress från att uppta alla platser på en gång.
7. Stäng av UPnP och publicera inte adressen själv
Terraria-servern försöker som standard att öppna sin port i en router via UPnP. På en hyrd server är det verkningslöst, i ett hemnätverk öppnar det portar som du senare inte vet om längre. Stäng av det med upnp=0 i serverconfig.txt eller med -noupnp på kommandoraden.
Här lönar sig dessutom ärlighet i stället för önsketänkande: din IP-adress går inte att hålla hemlig. Varje spelare som en gång har varit ansluten känner till den, och en post på en listsida publicerar den ändå. Verksamma är två vanor. Publicera aldrig den råa IP-adressen själv, utan anslut dina spelare via ett värdnamn: Terraria-klienten slår upp ett värdnamn, du kan alltså byta adress i nödfall utan att alla hänvisningar bryts. Och rensa bort gamla DNS-poster, för en bortglömd A-post mot den tidigare adressen gör varje byte verkningslöst.
8. Mellanlagra statusförfrågningar i stället för att skicka dem vidare
Eftersom Terraria inte har något förfrågningsprotokoll tar statussidor, Discord-bottar och listsidor reda på din servers tillstånd på ett av två sätt: de upprättar en äkta TCP-anslutning till 7777 och utger sig för att vara klient, eller så frågar de TShocks REST-API. Båda kostar din server arbete, och båda skalar med antalet frågeställare.
Motåtgärden kostar ingenting: fråga aldrig från besökaren. Låt en enda tjänst hämta statusen med fasta intervall (30 eller 60 sekunder räcker), mellanlagra resultatet och leverera det mellanlagrade läget till alla besökare. Därmed skapar en välbesökt statussida en förfrågan per intervall i stället för en per besökare. Den som använder REST-API:t för det begränsar port 7878 till adressen för den enda tjänsten.
9. Logga, så att du har data när det gäller
Det viktigaste steget är det som nästan ingen gör i förväg: att lägga upp en jämförelsegrund så länge allt går normalt. Utan normalvärde kan du efter en händelse inte säga om 40 000 paket per sekund var mycket eller helt enkelt lördagskväll. Med apt-get install -y vnstat sysstat löper mätningen varaktigt med. Under en händelse räcker fem kommandon:
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
Det tredje kommandot är det terraria-specifika: det räknar de halvöppna anslutningarna. Ett tvåsiffrigt värde är normalt, ett fyr- eller femsiffrigt är en SYN-flood. ss -s visar vid sidan av det det totala antalet TCP-anslutningar, och motsvarar den siffran ungefär ditt maxplayers medan ingen är inne i spelet ser du en platsutmattning. Vid tcpdump gäller: begränsa alltid med -c, en inspelning under full last belastar en redan överbelastad server ytterligare. Hur du tolkar värdena står i Känna igen en DDoS-attack.
Var de här åtgärderna tar slut
Nu den del som ingen konfigurationsfil kan lösa. Alla åtgärder hittills körs på din server, alltså i änden av ledningen. En brandväggsregel beslutar om ett paket som redan har färdats över kabeln. Du kan förkasta det, men du kan inte göra det osänt.
Räkna efter en gång. En typisk spelserver hänger på 1 Gbit/s, det är 125 megabyte per sekund, och ledningen är full så snart någon skickar mer. Attacker mot spelserverprojekt av den här storleken ligger vanligtvis mellan 5 och 50 Gbit/s, alltså på fem till femtio gånger din ledning. Om din connlimit-regel bakom är bra spelar då ingen roll längre, eftersom dina spelares paket redan dessförinnan inte kommer fram. Precis så uppstår laggspikar på en Terraria-server, där processorbelastningen ser normal ut.
Den andra storheten är paketfrekvensen, och den slår ofta till tidigare än bandbredden. Vid små paket på 64 byte får runt 1,49 miljoner paket per sekund plats i en ledning på 1 Gbit/s. En normal serverkärna bearbetar beroende på processor och nätverkskort några hundratusen av dem innan den börjar förkasta. Vid en SYN-flood ligger gränsen ännu lägre, eftersom varje SYN-paket utlöser ett tillståndsbeslut: redan några tiotusen SYN-paket per sekund räcker för att slå ut anslutningsmottagningen i ett vanligt Linux, långt innan ledningen är full. Serverägare upplever det som "belastningen var ju inte ens hög, ändå var allt borta".
Och den tredje punkten är den som hos Terraria förbises oftast: en angripare rättar sig inte efter ditt protokoll. Han skickar UDP-floder och reflektionstrafik mot din adress, trots att ingenting lyssnar på någon UDP-port. Din server förkastar de paketen korrekt, men de har redan upptagit din ledning, och din Terraria-server går offline utan att ett enda paket har nått spelprocessen. För att sätta storleksordningarna i sammanhang: på KernelHost-servrar har bland annat en attack med över 473,4 Gbit/s vid över 41,5 miljoner paket per sekund och en UDP-flood med över 112,2 Gbit/s mot en spelserver filtrerats bort. För detta finns ingen lokal inställning. Volymetriska attacker måste ta slut i nätet framför servern.
Vad KernelHost ställer emot
Det permanenta skyddet som ingår i varje server
KernelHosts DDoS-skydd är uppbyggt i två steg och permanent aktivt, utan att du behöver slå på, beställa eller konfigurera någonting:
- Steg 1: 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket. Volymetriska attacker rensas nära sin källa, innan de når datacentret.
- Steg 2: Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main. Direkt framför servern känns protokollspecifika mönster igen och förkastas, paket för paket. För Terraria betyder det konkret: SYN-floder och anslutningsfloder mot 7777 TCP tar slut här, inte på ditt nätverkskort.
Två egenskaper är avgörande. Skyddet löper permanent och behöver inte först reagera på en attack, det finns alltså inga minuter i början där servern är borta. Och ingen null-routing används: din IP-adress stannar i nätet, bara de skadliga paketen förkastas. Den som tar bort IP-adressen ur nätet uppnår för din del samma resultat som angriparen. Platsen är Frankfurt am Main. Vilka spel och protokoll som täcks listar DDoS-skydd för spelservrar i realtid.
Advanced DDoS Protection för projekt under ständig beskjutning
Vissa projekt angrips inte tillfälligtvis, utan målinriktat och under flera veckor. För det finns Advanced DDoS Protection från 50,00 EUR i månaden, PrePaid, utan bindningstid och utan uppläggningsavgift. Skillnaden ligger inte i mer kapacitet, utan i kontrollen:
- Dedikerad skydds-IP ur Frankfurt-kärnan, som din server ställs om till inom vårt eget nät. På din sida krävs ingen ombyggnad.
- Skyddsregler per port och protokoll som du hanterar själv i kundportalen: du ställer in vad som är tillåtet på 7777 TCP och kan stänga allt annat, utan att skriva ett ärende för det.
- Ändringar slår igenom i realtid, du kan alltså justera under en pågående attack, till exempel dra åt den tillåtna anslutningsfrekvensen per källadress.
- Skyddsprofil som passar applikationen. För TCP-spel som Terraria och för egna eller modifierade applikationer på valfria TCP- eller UDP-portar finns passande profiler.
De två stegen i jämförelse
| Egenskap | Inkluderat permanent DDoS-skydd | Advanced DDoS Protection |
|---|---|---|
| Pris | ingår i varje serverpaket, utan extra kostnad | från 50,00 EUR i månaden, PrePaid |
| Filterkapacitet | 17 Tbps globalt scrubbing plus Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main | samma filtrering i två steg |
| IP-adress | din servers IP-adress | ytterligare dedikerad skydds-IP |
| Regelverk | automatiska profiler, ingen konfiguration behövs | egna regler per port och protokoll i kundportalen |
| Ändringar | följer med automatiskt | slår igenom i realtid, även under en attack |
| Profil för Terraria | automatisk profil för TCP-spelservrar | eget regelverk för 7777 TCP, även för tModLoader och TShock |
| Null-routing | nej | nej |
| Löptid | bunden till serverpaketet | PrePaid, ingen bindningstid, ingen uppsägningstid, ingen uppläggningsavgift |
För de flesta Terraria-projekt räcker det inkluderade permanenta skyddet tillsammans med en ren serverkonfiguration. Advanced DDoS Protection är svaret på att någon tar det personligt. Den som för närvarande driver sin server någon annanstans får inte skyddet eftermonterat, utan genom flytten till KernelHost: filtreringen är en del av nätet, inte ett tillägg på servern.
Vanliga fel och lösningar
"Servern är full, men det är ingen inne": det är en platsutmattning. Kontrollera med ss -tn dst :7777 | wc -l hur många anslutningar som faktiskt är öppna, och jämför det med spelarlistan (serverkonsolen: playing). Stämmer siffrorna inte överens upptar främmande anslutningar platserna. Motmedlen är den övre gränsen för anslutningar per källadress, ett serverlösenord och en aktuell serverversion.
"Jag har öppnat 7777 UDP och det ändrar ingenting": korrekt, för på 7777 UDP lyssnar ingenting. Terraria använder uteslutande TCP. UDP-öppningen skadar inte direkt, men den är en onödig öppning och ett säkert tecken på att en anvisning för ett annat spel har kopierats.
"Mina iptables-regler griper inte": tre orsaker är vanliga. Reglerna står bakom UFW-kedjorna och nås aldrig, de var borta efter den senaste omstarten (då hjälper netfilter-persistent save eller en post i /etc/ufw/before.rules), eller så är attacken volymetrisk och regeln arbetar korrekt vid en ledning som redan är full. Kontrollera med iptables -L INPUT -n -v om träffräknarna stiger. Stannar de på noll nås regeln inte.
"Spelare åker ut trots att ingen attack pågår": drar du din connlimit-gräns för snävt träffar det spelare bakom gemensamma anslutningar. Hos TCP händer det snabbare än hos UDP-spel, eftersom en återanslutning efter ett avbrott genast skapar en ny anslutning medan den gamla fortfarande hänger i TIME_WAIT. Höj värdet stegvis och håll ögonen på träffräknarna.
"Servern hackar, ledningen är lugn": det är oftare en mod eller ett tillägg än en attack. Under tModLoader kostar varje ytterligare mod beräkningstid i samma process, och en värld med många entiteter lastar en kärna fullt utan att ett enda paket för mycket kommer fram. Förblir sar -n DEV 1 10 oanmärkningsvärt var det ingen DDoS-attack.
"Min tidigare leverantör spärrade min IP-adress": det är null-routing. Leverantören skyddar därmed sitt eget nät, för dig är resultatet identiskt med en lyckad attack, oftast i ytterligare timmar efteråt. Fråga vid tveksamhet efter om det filtreras eller null-routas. Svaret avgör mer om din tillgänglighet än någon hårdvaruuppgift.
"I tcpdump ser jag inget anmärkningsvärt": om trafiken redan filtreras i nätet framför kommer det som väntat ingenting fram till servern. Det är normalfallet vid fungerande filtrering. Omvänt gäller: är ledningen mättad når du under vissa omständigheter inte ens SSH-sessionen som du ville mäta med. Använd då VNC-konsolen i kundportalen, som fungerar oberoende av gästsystemets nätverk.
Kort sammanfattat
- En Terraria-server behöver exakt en öppen port: 7777 TCP. Spelet öppnar ingen UDP-socket, har inget förfrågningsprotokoll och inget RCON.
- TShocks REST-API på port 7878 TCP är den andra angreppsytan. Låt
RestApiEnabledstå påfalseeller begränsa porten till din egen adress. - Ett serverlösenord i
serverconfig.txtär den verksammaste kostnadsfria åtgärden, eftersom en angripare utan korrekt svar på meddelande 37 aldrig kommer fram till världsöverföringen. - Platsutmattning är hos Terraria den billigaste attacken: varje mottagen TCP-anslutning till 7777 upptar en plats, helt utan nämnvärd bandbredd. Mot det verkar en övre gräns per källadress, ett lösenord och en aktuell serverversion.
- Eftersom Terraria använder TCP går källadressen till en upprättad anslutning inte att förfalska: IP-spärrar verkar här bättre än hos UDP-spel. Mot förfalskade SYN-floder hjälper bara SYN-cookies och filtrering framför.
- En UDP-flood slår ut din Terraria-server trots att den inte talar UDP, för den fyller ledningen innan spelprocessen ser någonting alls.
- Från ungefär storleken på din uppströmsbandbredd avgör uteslutande nätet framför servern. Hos KernelHost är den filtreringen uppbyggd i två steg, permanent aktiv och ingår utan extra kostnad i varje serverpaket.
Körs ditt projekt redan hos KernelHost är filtreringen aktiv utan att du behöver göra något. Märker du ändå avvikelser öppnar du ett supportärende, så att filterreglerna för din IP-adress justeras. Vid en pågående attack når du oss dessutom via WhatsApp-nödchatten på +43 650 8209883.
Vanliga frågor
Vilken port och vilket protokoll behöver en Terraria-server?
Varför är det viktigt att Terraria använder TCP i stället för UDP?
Min Terraria-server meddelar Server is full trots att ingen spelar. Vad är det?
Hjälper ett serverlösenord mot attacker?
Hur säkrar jag TShocks REST-API på port 7878?
Hur många spelare ska jag skriva in i maxplayers?
Kan jag värja mig mot en DDoS-attack med iptables eller UFW?
Från vilken attackstorlek klarar min Terraria-server det inte längre ensam?
Varför träffar en UDP-attack mig fast Terraria inte använder UDP alls?
Går min server hos KernelHost offline under en attack?
Kostar DDoS-skyddet extra hos KernelHost?
När behöver jag Advanced DDoS Protection dessutom?
2026 KernelHost GmbH. Alla rättigheter förbehållna. Den här guiden är skyddad av upphovsrätt. Publicering på andra webbplatser, helt, delvis eller i bearbetad form, är inte tillåten utan vårt skriftliga medgivande. Citat med källhänvisning och länk är uttryckligen välkomna.

