Terraria-Server vor DDoS-Angriffen schützen

Wer seinen Terraria-Server vor DDoS-Angriffen schützen will, hat es mit einem Sonderfall zu tun: Terraria spricht ausschließlich TCP. Der Spielverkehr läuft über genau einen Port, 7777 TCP, und einen UDP-Port öffnet das Spiel überhaupt nicht. Fast alle Ratschläge, die im Netz zu Gameserver-Schutz kursieren, sind für UDP-Spiele geschrieben und greifen hier entweder ins Leere oder an der falschen Stelle.

Dieser Beitrag zeigt zuerst, was Sie ohne Zusatzkosten selbst absichern können, danach, wo diese Maßnahmen technisch aufhören, und zum Schluss, was dann im Netz vor dem Server passieren muss. Alle Angaben beziehen sich auf einen Terraria-Dedicated-Server (vanilla, TShock oder tModLoader) unter Debian 12, Debian 13, Ubuntu 22.04 LTS oder Ubuntu 24.04 LTS. Die Befehle sind für root geschrieben, als normaler Benutzer stellen Sie sudo voran. Läuft der Angriff gerade, ändern Sie zuerst nichts an der Konfiguration und starten den Server nicht neu: Sichern Sie die Messwerte (siehe Abschnitt "Protokollieren"), nach dem Angriff sind sie weg.

Warum ausgerechnet Terraria-Server von DDoS-Angriffen getroffen werden

Terraria-Server sind ein bequemes Ziel, weil ihre Adresse zwangsläufig öffentlich ist. Vanilla-Terraria hat keinen eingebauten Serverbrowser: Spieler verbinden sich über "Multiplayer" und "Join via IP", also über eine Adresse, die jemand vorher bekannt gemacht haben muss. Wer neue Spieler will, trägt den Server auf Listenseiten wie terraria-servers.com, tserverweb.com oder topg.org ein oder verteilt die Adresse über Discord. Jeder dieser Wege liefert einem Angreifer dasselbe, was er dem Spieler liefert: IP-Adresse und Port im Klartext.

Wenn ein Terraria-Server ständig offline geht, obwohl sich an Hardware, Welt und Modliste nichts geändert hat, ist ein Angriff deshalb die wahrscheinlichste Erklärung. Dazu kommt die typische Konstellation eines Projekts: feste Spielzeiten, konkurrierende Server, gebannte Spieler und Streit in der Community. Ein Angriff kostet den Auftraggeber weder Können noch nennenswertes Geld, ein Terraria Server Booter wird als Abonnement für wenige Euro im Monat verkauft. Was ein DDoS-Angriff technisch ist und wie er aufgebaut wird, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Terraria läuft über TCP, nicht über UDP

Das ist der wichtigste Unterschied zu praktisch jedem anderen Gameserver. Der Terraria-Dedicated-Server nimmt Verbindungen mit einem TCP-Listener entgegen (in der Spiel-Engine die Klasse Terraria.Net.Sockets.TcpSocket) und öffnet keinen UDP-Socket. Das hat vier Folgen, die Ihre gesamte Verteidigung bestimmen:

• Eine vollständig aufgebaute TCP-Verbindung lässt sich nicht fälschen. Der Angreifer muss das SYN-ACK des Servers empfangen, um den Handschlag abzuschließen. Wer also wirklich verbunden ist, kommt von einer echten Adresse. IP-Sperren und Verbindungsobergrenzen wirken bei Terraria deshalb deutlich besser als bei einem UDP-Spiel.
• Ein SYN-Flood lässt sich sehr wohl fälschen, weil er den Handschlag nie abschließt. Gegen diese Sorte hilft keine IP-Sperre, sondern ausschließlich SYN-Cookies und Filterung davor.
• Jede angenommene TCP-Verbindung zu Port 7777 belegt Ressourcen im Spielprozess, nicht nur im Kernel. Das macht Slot-Erschöpfung zum wirksamsten Angriff mit der geringsten Bandbreite.
• Ein UDP-Flood trifft Ihren Server trotzdem. Die Pakete müssen nicht angenommen werden, um Ihre Leitung zu füllen. Dass Terraria kein UDP spricht, schützt die Leitung nicht, es verhindert nur, dass der Spielprozess selbst die Pakete verarbeitet.

Eine Ausnahme gibt es: Startet man den Dedicated-Server mit -steam und -lobby friends oder -lobby private, läuft die Verbindung über das Steam-Netzwerk und damit über UDP-Ports im Bereich 27000 bis 27100. Das ist ein anderer Betriebsmodus und nicht der klassische, über die IP-Adresse erreichbare Server.

Die Ports, um die es tatsächlich geht

Ein Terraria-Server braucht genau einen Port im offenen Netz: 7777 TCP. Alles andere in dieser Tabelle gehört entweder gar nicht ins Internet oder nur auf Ihre eigene Adresse.

Dass Terraria weder einen Query-Port noch RCON kennt, ist für die Absicherung eine gute Nachricht: Die beiden Endpunkte, die bei Counter-Strike, Rust oder ARK regelmäßig für Reflection-Angriffe missbraucht werden, existieren hier schlicht nicht. Dafür ist die Angriffsfläche umso stärker auf Port 7777 konzentriert, und wer TShock einsetzt, holt sich mit Port 7878 eine zweite Fläche dazu.

Was Sie selbst tun können, bevor Sie Geld ausgeben

Dieser Abschnitt ist der längste, und das mit Absicht. Ein sauber konfigurierter Terraria-Server hält kleine und mittlere Angriffe aus eigener Kraft aus, unabhängig davon, bei wem er steht.

1. Bestandsaufnahme: was lauscht überhaupt?

Bevor Sie eine einzige Regel schreiben, sehen Sie nach, was Ihr Server nach außen anbietet. Nicht raten, nachsehen:

ss -lntup

Interessant ist die Spalte mit der lokalen Adresse. 0.0.0.0:7777 bedeutet "aus dem ganzen Internet erreichbar", 127.0.0.1:7878 bedeutet "nur lokal" und braucht keine Firewall-Regel. Wenn in dieser Liste ein UDP-Eintrag für Ihren Terraria-Prozess auftaucht, läuft der Server im Steam-Modus. Die Sicht des Angreifers liefert ein Portscan von außen:

nmap -Pn -p- --min-rate 1000 IHRE.SERVER.IP.ADRESSE

2. Nur 7777 TCP offen lassen, alles andere schließen

Für Terraria genügt eine einzige Freigabe nach außen. Eine UDP-Regel brauchen Sie nicht, und eine UDP-Regel für 7777 wäre schlicht falsch: Sie lässt Verkehr auf einen Port durch, auf dem gar nichts lauscht. Mit UFW sieht das so aus, und zwar genau in dieser Reihenfolge, damit Sie sich nicht selbst aussperren:

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

Ersetzen Sie 203.0.113.10 durch Ihre eigene Adresse. Die vollständige Anleitung samt Rettungsweg finden Sie unter UFW-Firewall einrichten, ohne sich selbst auszusperren. Wer ein Panel betreibt, beschränkt auch 8080 und 2022 auf die eigene Adresse.

3. serverconfig.txt: Passwort, maxplayers und secure richtig setzen

Die zentrale Konfigurationsdatei des Terraria-Servers heißt serverconfig.txt und wird beim Start mit -config serverconfig.txt übergeben. Vier Direktiven sind für die Absicherung entscheidend:

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

password= ist die wirksamste kostenlose Maßnahme gegen Beitritts-Fluten, die den regulären Weg nehmen. Der Grund liegt im Protokoll: Ein Client schickt zuerst Nachricht 1 mit seiner Versionskennung (zum Beispiel Terraria279), der Server antwortet bei gesetztem Passwort mit Nachricht 37, der Client muss mit Nachricht 38 korrekt antworten, und erst danach schickt der Server mit Nachricht 3 die Freigabe samt Spielerslot. Ohne das richtige Passwort kommt ein Angreifer also nie bis zur Weltübertragung, die der teure Teil eines Beitritts ist.

maxplayers nimmt Werte von 1 bis 255 an, die Voreinstellung ist 16 (vor Version 1.4.0.1 waren es 8). Die Obergrenze von 255 ist keine willkürliche Zahl: Terraria adressiert Spieler mit einem einzelnen Byte. Setzen Sie maxplayers nicht höher als Sie wirklich brauchen, denn jeder Slot ist eine Ressource, die ein Angreifer belegen kann. secure=1 schaltet die eingebaute Cheat-Prüfung ein (auf der Kommandozeile -secure), upnp=0 verhindert, dass der Server auf eigene Faust Ports an einem Router öffnet.

4. TShock absichern: REST-API auf 7878 und Login-Flood

TShock ist die verbreitetste Servererweiterung für Terraria und bringt mit der REST-API eine zweite, vollwertige Angriffsfläche mit. Sie liegt standardmäßig auf Port 7878 TCP und ist in tshock/config.json konfiguriert, also nicht in der serverconfig.txt. Im Auslieferungszustand ist sie abgeschaltet ("RestApiEnabled": false), und genau so sollte sie bleiben, solange Sie sie nicht brauchen.

Wenn Sie sie brauchen, sind diese Werte relevant:

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

Zwei Dinge sind daran wichtig. Erstens liefert der Endpunkt /status ohne Token Servername, Port, Spielerzahl und Spielernamen aus, solange EnableTokenEndpointAuthentication auf false steht. Das ist bequem für Statusseiten und Discord-Bots und zugleich eine kostenlose Aufklärung für jeden Angreifer, der wissen will, wann sich ein Angriff lohnt. Zweitens erzeugt der Endpunkt /v2/token/create aus Benutzername und Passwort ein Zugangstoken, und er ist von außen erreichbar, sobald Port 7878 offen steht: ein Passwort-Rateangriff gegen Ihr Admin-Konto, der nebenbei Rechenzeit kostet. Der Eimer aus RESTMaximumRequestsPerInterval und RESTRequestBucketDecreaseIntervalMinutes bremst das, ersetzt aber keine Firewall-Regel.

Für den Spielzugang selbst greifen weitere TShock-Werte. MaximumLoginAttempts steht auf 3 und wirft einen Spieler nach drei Fehlversuchen heraus. RequireLogin (Standard false) verlangt ein Konto für jeden Spieler. EnableIPBans (Standard true) und KickProxyUsers (Standard true) sind bei einem TCP-Spiel besonders wirksam, weil die Quelladresse einer aufgebauten Verbindung eben nicht gefälscht sein kann. Gegen Griefing, das oft als Angriff gemeldet wird, wirken die Schwellwerte TileKillThreshold (60), TilePlaceThreshold (20), TileLiquidThreshold (15) und ProjectileThreshold (50), jeweils Aktionen pro Sekunde.

5. Verbindungen je Quelladresse begrenzen und SYN-Cookies prüfen

Weil Terraria auf TCP läuft, ist die wirksamste lokale Regel eine Obergrenze gleichzeitiger Verbindungen je Quelladresse. Ein echter Spieler braucht genau eine:

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

Die erste Regel verwirft neue Verbindungen, sobald eine Adresse mehr als drei davon gleichzeitig offen hat. Die zweite begrenzt die Rate der Verbindungsversuche derselben Quelle auf zehn pro Minute mit einem Spielraum von 20. Beide Zahlen sind Startwerte, keine Wahrheiten: Ein Server hinter einem gemeinsamen Anschluss (Wohngemeinschaft, Schulnetz, Mobilfunk-Provider) sieht mehrere legitime Spieler unter derselben Adresse. Messen Sie erst eine Woche im Normalbetrieb.

Reine iptables-Regeln sind nach einem Neustart weg, unter Debian und Ubuntu sichert man sie so:

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

Unter UFW gehören solche Regeln in /etc/ufw/before.rules, weil sie sonst beim nächsten ufw reload verschwinden. Gegen gefälschte SYN-Pakete, die den Handschlag nie abschließen, hilft keine dieser Regeln, sondern der Kernel selbst. Prüfen Sie die drei Werte:

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

net.ipv4.tcp_syncookies muss auf 1 stehen, auf Debian und Ubuntu ist das in der Regel bereits der Fall. SYN-Cookies verzichten auf die Warteschlange halboffener Verbindungen und rekonstruieren den Zustand aus der Antwort des Clients, ein SYN-Flood läuft damit ins Leere, solange die Leitung nicht voll ist. net.core.somaxconn steht seit Linux 5.4 auf 4096 und davor auf 128: Ist der Wert klein, verwirft der Kernel fertig aufgebaute Verbindungen, bevor der Spielprozess sie überhaupt annehmen kann.

6. Slot-Erschöpfung verhindern: warum ein Portscan Ihren Server füllt

Slot-Erschöpfung ist der billigste wirksame Angriff auf einen Terraria-Server: Der Angreifer öffnet so viele TCP-Verbindungen zu Port 7777, wie der Server Spielerslots hat, und hält sie offen. Das kostet ihn fast keine Bandbreite, füllt aber den Server. Echte Spieler sehen "Server is full" und kommen nicht mehr herein, obwohl auf Ihrer Leitung nichts Auffälliges passiert. Genau das ist der Grund, warum Betreiber bei Terraria oft nicht merken, dass sie angegriffen werden.

Die Ursache liegt in der Zählweise: Eine Verbindung wird angenommen, bevor der Client überhaupt seine Versionskennung geschickt hat. Historisch blieben solche Geisterverbindungen belegt, bis die TCP-Sitzung abgelaufen war. Die 1.4.5er-Reihe hat das entschärft, dort werden für Clients, die sich sofort wieder trennen, keine Slots mehr reserviert. In den Erstfassungen von 1.4.5.7 und 1.4.5.8 stürzte der Dedicated-Server allerdings mit einer unbehandelten ObjectDisposedException ab, sobald eine TCP-Verbindung geöffnet und der Handschlag nicht abgeschlossen wurde. Ein nc -z oder eine Erreichbarkeitsprüfung eines Monitorings genügte. Der Fehler wurde innerhalb weniger Wochen still behoben, in älteren Container-Abbildern steckt er teilweise noch. Halten Sie Ihre Serverversion deshalb aktuell, das ist hier kein Allgemeinplatz, sondern eine konkrete Verfügbarkeitsfrage.

Zwei Einstellungen helfen zusätzlich. Wer TShock nutzt, setzt MaxSlots auf die gewünschte Spielerzahl und maxplayers in der serverconfig.txt zwei Plätze höher: Dann verwirft TShock überzählige Verbindungen mit einer sauberen Meldung, statt dass der Spielprozess sie in die letzte Lücke lässt. Und die Verbindungsobergrenze aus dem vorherigen Abschnitt ist genau die Regel, die eine einzelne Adresse daran hindert, alle Slots auf einmal zu belegen.

7. UPnP abschalten und die Adresse nicht selbst veröffentlichen

Der Terraria-Server versucht standardmäßig, seinen Port per UPnP an einem Router zu öffnen. Auf einem gemieteten Server ist das wirkungslos, in einem Heimnetz öffnet es Ports, von denen Sie später nichts mehr wissen. Schalten Sie es mit upnp=0 in der serverconfig.txt oder mit -noupnp auf der Kommandozeile ab.

Hier lohnt sich außerdem Ehrlichkeit statt Wunschdenken: Ihre IP-Adresse lässt sich nicht geheim halten. Jeder Spieler, der einmal verbunden war, kennt sie, und ein Eintrag auf einer Listenseite veröffentlicht sie ohnehin. Wirksam sind zwei Gewohnheiten. Veröffentlichen Sie die rohe IP-Adresse nirgends selbst, sondern verbinden Sie Ihre Spieler über einen Hostnamen: Der Terraria-Client löst einen Hostnamen auf, Sie können die Adresse im Ernstfall also wechseln, ohne dass alle Verweise brechen. Und räumen Sie alte DNS-Einträge weg, denn ein vergessener A-Eintrag auf die vorherige Adresse macht jeden Wechsel wirkungslos.

8. Statusabfragen zwischenspeichern statt durchreichen

Weil Terraria kein Abfrageprotokoll hat, ermitteln Statusseiten, Discord-Bots und Listenseiten den Zustand Ihres Servers auf einem von zwei Wegen: Sie bauen eine echte TCP-Verbindung zu 7777 auf und geben sich als Client aus, oder sie fragen die TShock-REST-API ab. Beides kostet Ihren Server Arbeit, und beides skaliert mit der Zahl der Abfragenden.

Die Gegenmaßnahme kostet nichts: Fragen Sie nie vom Besucher aus ab. Lassen Sie einen einzelnen Dienst den Status in festen Abständen holen (30 oder 60 Sekunden genügen), speichern Sie das Ergebnis zwischen und liefern Sie allen Besuchern den zwischengespeicherten Stand aus. Damit erzeugt eine viel besuchte Statusseite eine Abfrage pro Intervall statt einer pro Besucher. Wer die REST-API dafür nutzt, beschränkt Port 7878 auf die Adresse dieses einen Dienstes.

9. Protokollieren, damit Sie im Ernstfall Daten haben

Der wichtigste Schritt ist der, den fast niemand vorher macht: eine Vergleichsbasis anlegen, solange alles normal läuft. Ohne Normalwert können Sie nach einem Vorfall nicht sagen, ob 40.000 Pakete pro Sekunde viel waren oder einfach Samstagabend. Mit apt-get install -y vnstat sysstat läuft die Messung dauerhaft mit. Während eines Vorfalls genügen fünf Befehle:

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

Der dritte Befehl ist der terraria-spezifische: Er zählt die halboffenen Verbindungen. Ein zweistelliger Wert ist normal, ein vier- oder fünfstelliger ist ein SYN-Flood. ss -s zeigt daneben die Gesamtzahl der TCP-Verbindungen, und wenn diese Zahl ungefähr Ihrem maxplayers entspricht, während im Spiel niemand ist, sehen Sie eine Slot-Erschöpfung. Bei tcpdump gilt: immer mit -c begrenzen, ein Mitschnitt unter Volllast belastet einen ohnehin überlasteten Server zusätzlich. Wie Sie die Werte auswerten, steht in DDoS-Angriff erkennen.

Wo diese Maßnahmen aufhören

Jetzt der Teil, den keine Konfigurationsdatei lösen kann. Alle bisherigen Maßnahmen laufen auf Ihrem Server, also am Ende der Leitung. Eine Firewall-Regel entscheidet über ein Paket, das bereits über das Kabel gelaufen ist. Sie können es verwerfen, aber nicht ungesendet machen.

Rechnen Sie einmal mit. Ein typischer Gameserver hängt an 1 Gbit/s, das sind 125 Megabyte pro Sekunde, und die Leitung ist voll, sobald jemand mehr schickt. Angriffe gegen Gameserver-Projekte dieser Größe liegen üblicherweise zwischen 5 und 50 Gbit/s, also beim Fünf- bis Fünfzigfachen Ihrer Leitung. Ob Ihre connlimit-Regel dahinter gut ist, spielt dann keine Rolle mehr, denn die Pakete Ihrer Spieler kommen schon vorher nicht durch. Genau so entstehen Terraria Server Lag-Spikes, bei denen die CPU-Auslastung normal aussieht.

Die zweite Größe ist die Paketrate, und sie schlägt oft früher zu als die Bandbreite. Bei kleinen Paketen von 64 Byte passen in eine Leitung mit 1 Gbit/s rund 1,49 Millionen Pakete pro Sekunde. Ein normaler Serverkernel verarbeitet je nach CPU und Netzwerkkarte einige hunderttausend davon, bevor er anfängt zu verwerfen. Bei einem SYN-Flood liegt die Grenze noch niedriger, weil jedes SYN-Paket eine Zustandsentscheidung auslöst: Schon einige zehntausend SYN-Pakete pro Sekunde reichen aus, um die Verbindungsannahme eines Standard-Linux lahmzulegen, lange bevor die Leitung voll ist. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem war alles weg".

Und der dritte Punkt ist der, der bei Terraria am häufigsten übersehen wird: Ein Angreifer richtet sich nicht nach Ihrem Protokoll. Er schickt UDP-Fluten und Reflection-Verkehr auf Ihre Adresse, obwohl auf keinem UDP-Port etwas lauscht. Ihr Server verwirft diese Pakete korrekt, aber sie haben Ihre Leitung bereits belegt, und Ihr Terraria Server geht offline, ohne dass ein einziges Paket den Spielprozess erreicht hat. Zur Einordnung, welche Größenordnungen real vorkommen: Auf KernelHost-Servern wurden unter anderem ein Angriff mit über 473,4 Gbit/s bei über 41,5 Millionen Paketen pro Sekunde und ein UDP-Flood mit über 112,2 Gbit/s auf einen Gameserver gefiltert. Dafür gibt es keine lokale Einstellung. Volumetrische Angriffe müssen im Netz vor dem Server enden.

Was KernelHost dagegen stellt

Der Dauerschutz, der auf jedem Server inklusive ist

Der DDoS-Schutz von KernelHost ist zweistufig aufgebaut und dauerhaft aktiv, ohne dass Sie etwas einschalten, bestellen oder konfigurieren müssen:

• Stufe 1: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk. Volumetrische Angriffe werden nah an ihrer Quelle bereinigt, bevor sie das Rechenzentrum erreichen.
• Stufe 2: Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main. Direkt vor dem Server werden protokollspezifische Muster erkannt und verworfen, Paket für Paket. Für Terraria heißt das konkret: SYN-Fluten und Verbindungsfluten gegen 7777 TCP enden hier, nicht auf Ihrer Netzwerkkarte.

Zwei Eigenschaften sind entscheidend. Der Schutz läuft permanent und muss nicht erst auf einen Angriff reagieren, es gibt also keine Minuten am Anfang, in denen der Server weg ist. Und es wird kein Nullrouting eingesetzt: Ihre IP-Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete. Wer die IP-Adresse aus dem Netz nimmt, erreicht für Sie dasselbe Ergebnis wie der Angreifer. Der Standort ist Frankfurt am Main. Welche Spiele und Protokolle abgedeckt sind, listet Gameserver-DDoS-Schutz in Echtzeit.

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Projekte werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen. Dafür gibt es die Advanced DDoS Protection ab 50,00 EUR im Monat, PrePaid, ohne Mindestlaufzeit und ohne Einrichtungsgebühr. Der Unterschied liegt nicht in mehr Kapazität, sondern in der Kontrolle:

• Dedizierte Schutz-IP aus dem Frankfurter Kern, auf die Ihr Server im eigenen Netz umgestellt wird. Auf Ihrer Seite ist kein Umbau nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich: Sie stellen ein, was auf 7777 TCP erlaubt ist, und können alles andere zumachen, ohne dafür ein Ticket zu schreiben.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren, etwa die erlaubte Verbindungsrate je Quelladresse enger ziehen.
• Schutzprofil passend zur Anwendung. Für TCP-Spiele wie Terraria und für eigene oder modifizierte Anwendungen auf beliebigen TCP- oder UDP-Ports gibt es passende Profile.

Die beiden Stufen im Vergleich

Für die meisten Terraria-Projekte reicht der inkludierte Dauerschutz zusammen mit einer sauberen Serverkonfiguration. Die Advanced DDoS Protection ist die Antwort darauf, dass jemand es persönlich nimmt. Wer seinen Server derzeit woanders betreibt, bekommt den Schutz nicht nachgerüstet, sondern durch den Umzug zu KernelHost: Die Filterung ist Teil des Netzes, nicht ein Zusatz auf dem Server.

Häufige Fehler und Lösungen

"Der Server ist voll, aber es ist niemand drin": Das ist eine Slot-Erschöpfung. Prüfen Sie mit ss -tn dst :7777 | wc -l, wie viele Verbindungen tatsächlich offen sind, und vergleichen Sie das mit der Spielerliste (Serverkonsole: playing). Stimmen die Zahlen nicht überein, belegen Fremdverbindungen die Slots. Gegenmittel sind die Verbindungsobergrenze je Quelladresse, ein Serverpasswort und eine aktuelle Serverversion.

"Ich habe 7777 UDP freigegeben und es ändert nichts": Korrekt, denn auf 7777 UDP lauscht nichts. Terraria nutzt ausschließlich TCP. Die UDP-Freigabe schadet nicht direkt, sie ist aber eine unnötige Öffnung und ein sicheres Zeichen dafür, dass eine Anleitung für ein anderes Spiel kopiert wurde.

"Meine iptables-Regeln greifen nicht": Drei Ursachen sind häufig. Die Regeln stehen hinter den UFW-Ketten und werden nie erreicht, sie waren nach dem letzten Neustart weg (dann helfen netfilter-persistent save oder ein Eintrag in /etc/ufw/before.rules), oder der Angriff ist volumetrisch und die Regel arbeitet korrekt an einer Leitung, die schon voll ist. Prüfen Sie mit iptables -L INPUT -n -v, ob die Trefferzähler steigen. Bleiben sie bei null, wird die Regel nicht erreicht.

"Spieler fliegen raus, obwohl kein Angriff läuft": Ziehen Sie Ihre connlimit-Grenze zu eng, trifft es Spieler hinter gemeinsamen Anschlüssen. Bei TCP ist das schneller passiert als bei UDP-Spielen, weil eine Wiederverbindung nach einem Aussetzer sofort eine neue Verbindung erzeugt, während die alte noch in TIME_WAIT hängt. Erhöhen Sie den Wert schrittweise und beobachten Sie die Trefferzähler.

"Der Server ruckelt, die Leitung ist ruhig": Das ist häufiger ein Mod oder ein Plugin als ein Angriff. Unter tModLoader kostet jeder zusätzliche Mod Rechenzeit im selben Prozess, und eine Welt mit vielen Entitäten lastet einen Kern voll aus, ohne dass ein Paket zu viel ankommt. Bleibt sar -n DEV 1 10 unauffällig, war es kein DDoS-Angriff.

"Mein bisheriger Anbieter hat meine IP-Adresse gesperrt": Das ist Nullrouting. Der Anbieter schützt damit sein eigenes Netz, für Sie ist das Ergebnis identisch mit einem erfolgreichen Angriff, meist noch für Stunden danach. Fragen Sie im Zweifel nach, ob gefiltert oder nullgeroutet wird. Die Antwort entscheidet mehr über Ihre Verfügbarkeit als jede Hardwareangabe.

"Im tcpdump sehe ich nichts Auffälliges": Wenn der Verkehr schon im Netz davor gefiltert wird, kommt auf dem Server erwartungsgemäß nichts an. Das ist der Normalfall bei funktionierender Filterung. Umgekehrt gilt: Ist die Leitung gesättigt, erreicht Sie unter Umständen nicht einmal mehr die SSH-Sitzung, mit der Sie messen wollten. Nutzen Sie dann die VNC-Konsole im Kundenbereich, die unabhängig vom Netzwerk des Gastsystems funktioniert.

Kurz zusammengefasst

• Ein Terraria-Server braucht genau einen offenen Port: 7777 TCP. Das Spiel öffnet keinen UDP-Socket, hat kein Abfrageprotokoll und kein RCON.
• Die TShock-REST-API auf Port 7878 TCP ist die zweite Angriffsfläche. Lassen Sie RestApiEnabled auf false oder beschränken Sie den Port auf Ihre eigene Adresse.
• Ein Serverpasswort in der serverconfig.txt ist die wirksamste kostenlose Maßnahme, weil ein Angreifer ohne korrekte Antwort auf Nachricht 37 nie bis zur Weltübertragung kommt.
• Slot-Erschöpfung ist bei Terraria der billigste Angriff: Jede angenommene TCP-Verbindung zu 7777 belegt einen Platz, ganz ohne nennenswerte Bandbreite. Dagegen wirken eine Obergrenze je Quelladresse, ein Passwort und eine aktuelle Serverversion.
• Weil Terraria TCP nutzt, lässt sich die Quelladresse einer aufgebauten Verbindung nicht fälschen: IP-Sperren wirken hier besser als bei UDP-Spielen. Gegen gefälschte SYN-Fluten helfen nur SYN-Cookies und Filterung davor.
• Ein UDP-Flood legt Ihren Terraria-Server lahm, obwohl er kein UDP spricht, denn er füllt die Leitung, bevor der Spielprozess irgendetwas sieht.
• Ab etwa der Größe Ihrer Uplink-Bandbreite entscheidet ausschließlich das Netz vor dem Server. Bei KernelHost ist diese Filterung zweistufig, dauerhaft aktiv und ohne Aufpreis in jedem Serverpaket enthalten.

Läuft Ihr Projekt bereits bei KernelHost, ist die Filterung aktiv, ohne dass Sie etwas tun müssen. Bemerken Sie trotzdem Auffälligkeiten, eröffnen Sie ein Support-Ticket, damit die Filterregeln für Ihre IP-Adresse nachjustiert werden. Bei einem laufenden Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfallchat unter +43 650 8209883.