TeamSpeak-3-Server vor DDoS-Angriffen schützen

Ein TeamSpeak-Server ist für einen Clan das Nervenzentrum. Wer ihn ausschaltet, beendet nicht nur ein Gespräch, sondern das Training, den Scrim oder den Raid. Genau deshalb landen Voiceserver oft im Visier, meist von Leuten aus dem eigenen Umfeld: verlorene Runde, Bann, Streit zwischen zwei Clans.

Dieser Beitrag zeigt, was Sie ohne Zusatzkosten selbst absichern können, wo diese Maßnahmen an ihre Grenze stoßen und was danach bleibt. Die Befehle sind für Debian 12, Debian 13, Ubuntu 22.04 LTS und Ubuntu 24.04 LTS geschrieben. Wo root nötig ist, steht es dabei.

Warum gerade Voiceserver so häufig angegriffen werden

Drei nüchterne Gründe, keiner davon hat mit der Größe Ihres Projekts zu tun.

Erstens ist Sprache in Echtzeit unbarmherzig. Eine Webseite mit zwei Prozent Paketverlust merkt niemand, weil TCP die fehlenden Segmente noch einmal schickt. Bei Sprache gibt es keine Wiederholung: Ein verlorenes Paket ist eine Lücke im Ton, und die hört jeder am Tisch sofort. Ein Angriff muss Ihre Leitung also gar nicht sättigen, um sie unbrauchbar zu machen.

Zweitens ist der Sprachkanal verbindungslos. TeamSpeak überträgt Sprache über UDP. Es gibt keinen Handschlag und keinen Zustand, bevor das erste Paket ankommt. Die Absenderadresse lässt sich frei fälschen, und Ihr Server muss jedes ankommende Paket erst ansehen, um es verwerfen zu können. Der Angreifer braucht weder Zugang noch Passwort, nur Ihre IP-Adresse und die Portnummer. Was dabei technisch passiert, beschreibt der Beitrag Was ist ein DDoS-Angriff?.

Drittens ist genau diese Adresse öffentlich. Sie steht im Discord, auf der Webseite und, sofern eingeschaltet, in der TeamSpeak-Serverliste. Ein Voiceserver, den niemand findet, ist nutzlos. Anonymität ist deshalb keine Schutzstrategie.

Die Standardports von TeamSpeak 3

Bevor Sie irgendetwas absichern, sollten Sie wissen, was überhaupt offen ist. Das sind die Werkseinstellungen eines TeamSpeak-3-Servers:

Die wichtigste Zeile dieser Tabelle: Aus dem Internet erreichbar sein muss einzig 9987/UDP. Alles andere ist optional oder gehört hinter eine Zugangsbeschränkung.

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

Die folgenden zehn Schritte kosten nichts und helfen gegen die Angriffsarten, die einen Voiceserver am häufigsten treffen: Query-Fluten, Join-Spam und kleinere UDP-Fluten aus wenigen Quellen.

1. Bestandsaufnahme: was lauscht wirklich

Regeln für Dienste, die es nicht gibt, sind harmlos. Ein übersehener offener Port kostet Sie den Abend. Verschaffen Sie sich als root zuerst einen Überblick:

ss -lntup

Interessant ist die Spalte Local Address:Port. Steht dort 0.0.0.0:10011 oder [::]:10011, ist Ihr ServerQuery-Zugang aus dem gesamten Internet erreichbar. Steht dort 127.0.0.1:10011, ist er nur lokal ansprechbar und braucht keine Firewall-Regel mehr.

2. Alles schließen, was nicht gebraucht wird

Eine Firewall mit einer Standardregel "alles Eingehende verwerfen" ist die Grundlage. Achten Sie dabei auf die Reihenfolge, sonst sperren Sie sich selbst aus. Den vollständigen Ablauf inklusive Rettungsweg beschreibt die Anleitung UFW-Firewall einrichten, ohne sich selbst auszusperren. Für einen TeamSpeak-Server sieht das Ergebnis so aus:

ufw allow 22/tcp
ufw allow 9987/udp
ufw allow 30033/tcp
ufw default deny incoming
ufw default allow outgoing
ufw enable

Brauchen Sie den ServerQuery-Zugang wirklich von außen, geben Sie ihn nur für Ihre eigene Adresse frei. Ersetzen Sie 203.0.113.10 durch Ihre tatsächliche IP-Adresse:

ufw allow from 203.0.113.10 to any port 10011 proto tcp

Die ausgehenden Verbindungen dürfen Sie nicht komplett zumauern. Ohne Zugriff auf den Lizenz- und Abrechnungsdienst startet der TeamSpeak-Server nicht sauber durch.

3. Den ServerQuery-Port aus dem Internet nehmen

Der ServerQuery-Zugang ist die unterschätzteste Angriffsfläche eines TeamSpeak-Servers. Über Port 10011 lassen sich Zugangsdaten durchprobieren und Befehle im Sekundentakt absetzen. Das ist kein volumetrischer Angriff, sondern ein sehr sparsamer ohne Botnetz.

Am saubersten binden Sie den Query-Dienst gar nicht erst nach außen. Öffnen Sie die ts3server.ini im Serververzeichnis und setzen Sie:

query_ip=127.0.0.1
query_protocols=raw
query_ip_allowlist=query_ip_allowlist.txt
query_ip_denylist=query_ip_denylist.txt
logquerycommands=1

Damit lauscht der Query-Dienst nur noch auf dem Server selbst, und Sie erreichen ihn bei Bedarf über einen SSH-Tunnel. Wichtig ist, dass die Datei beim Start auch tatsächlich gelesen wird. Der Startparameter dafür lautet:

./ts3server_startscript.sh restart inifile=ts3server.ini

Die Datei query_ip_allowlist.txt enthält die Adressen, die von der Flutkontrolle des Query-Dienstes ausgenommen sind, query_ip_denylist.txt die gesperrten. Ab Serverversion 3.12 heißen die Dateien so, ältere Versionen verwenden query_ip_whitelist.txt und query_ip_blacklist.txt. Tragen Sie in die Allowlist nur ein, was dort hingehört, typischerweise 127.0.0.1. Jede weitere Adresse ist eine Ausnahme von genau dem Schutz, den Sie gerade einschalten.

4. Die Flutkontrolle der Instanz nachschärfen

Der Server bringt eine eigene Bremse für ServerQuery mit. Melden Sie sich als serveradmin an, ohne einen virtuellen Server auszuwählen, und sehen Sie sich zuerst die aktuellen Werte an:

instanceinfo

Enger stellen Sie sie so:

instanceedit serverinstance_serverquery_flood_commands=10 serverinstance_serverquery_flood_time=3 serverinstance_serverquery_ban_time=600

Das erlaubt zehn Befehle in drei Sekunden und sperrt eine Adresse danach für zehn Minuten. Falls Ihre Serverversion in der Ausgabe von instanceinfo zusätzlich eine Obergrenze für gleichzeitige Query-Verbindungen je Adresse zeigt, setzen Sie diese ebenfalls auf einen kleinen Wert.

5. Query-Bots niemals mit dem Serveradmin-Zugang betreiben

Ranksystem, Musikbot, Statistik-Skript: Fast jeder davon läuft mit den vollen Zugangsdaten des serveradmin. Wird der Bot kompromittiert oder liegt sein Passwort in einer öffentlichen Konfigurationsdatei, gehört der Server jemand anderem.

Legen Sie stattdessen einen eigenen Query-Zugang an, der an eine bestimmte Client-Identität gebunden ist, und geben Sie dieser Identität nur die Rechte, die der Bot braucht:

queryloginadd client_login_name=ranksystem cldbid=42

Die Datenbank-ID Ihres Bots finden Sie über clientdblist. Das Passwort gibt der Server einmalig aus, danach nicht mehr.

6. Anti-Flood des virtuellen Servers einstellen

Neben der Instanzbremse hat jeder virtuelle Server ein eigenes Punktesystem gegen Befehlsspam. Jeder Befehl eines Clients kostet Punkte, pro Sekunde werden Punkte abgebaut. Zwei Schwellen führen zur Reaktion: die erste blockiert weitere Befehle, die zweite sperrt die Adresse. Wählen Sie den virtuellen Server aus und passen Sie die Werte an:

use sid=1
serveredit virtualserver_antiflood_points_tick_reduce=5 virtualserver_antiflood_points_needed_command_block=150 virtualserver_antiflood_points_needed_ip_block=250

Das sind die Standardwerte. Bei anhaltendem Join- und Poke-Spam senken Sie die beiden Schwellen schrittweise ab und beobachten Sie das Log. Zu aggressive Werte treffen Ihre eigenen Mitglieder.

7. Identitätsstufe anheben gegen automatisierten Join-Spam

Jede TeamSpeak-Identität hat eine Sicherheitsstufe, die durch Rechenaufwand erzeugt wird. Der Server kann eine Mindeststufe verlangen, ab Werk ist das Stufe 8. Wer massenhaft Wegwerf-Identitäten erzeugen will, muss für jede einzelne rechnen:

serveredit virtualserver_needed_identity_security_level=10

Das wirkt gegen Bot-Wellen, hat aber einen Preis: Bestehende Mitglieder müssen ihre Identität einmalig nachbessern, und ab etwa Stufe 12 dauert das auf schwächeren Geräten unangenehm lange. Kündigen Sie eine Erhöhung an, statt sie mitten in der Primetime zu setzen.

8. Serverliste, Serverpasswort und echte Zugangsbeschränkung

Der Eintrag in der öffentlichen Serverliste macht Ihre Adresse maschinenlesbar auffindbar und bringt einem geschlossenen Clan-Server nichts. Abschalten:

serveredit virtualserver_weblist_enabled=0

Seien Sie dabei ehrlich zu sich selbst: Das entfernt einen bequemen Weg, Ihre Adresse zu finden, versteckt sie aber nicht. Ein Scan über den Adressbereich findet einen offenen UDP-Port 9987 ohnehin.

Eine echte Zugangsbeschränkung gibt es auf zwei Wegen. Innerhalb von TeamSpeak setzen Sie ein Serverpasswort und arbeiten mit Tokens für die Gruppenzuweisung. Auf Netzwerkebene, deutlich härter, geben Sie 9987/UDP nur für bekannte Adressen frei oder betreiben den Voiceserver innerhalb eines VPN. Für einen festen Kreis von zehn Leuten ist das praktikabel, für eine offene Community nicht.

Wollen Sie einen Namen statt einer IP-Adresse verteilen, nutzen Sie einen SRV-Eintrag der Form _ts3._udp.ihre-domain.de. Der Client löst ihn samt Portnummer selbst auf, und bei einem IP-Wechsel ändern Sie nur diesen einen Eintrag.

9. Ratenbegrenzung auf dem Host, mit ehrlicher Einordnung

Auf allen vier genannten Systemen arbeitet der Paketfilter unter der Haube mit nftables. Damit lässt sich die Paketrate je Absenderadresse begrenzen. Legen Sie dazu eine eigene Tabelle an, damit Sie eine bestehende UFW-Konfiguration nicht anfassen müssen:

table inet ts3 {
    chain input {
        type filter hook input priority filter; policy accept;
        udp dport 9987 meter ts3flood { ip saddr limit rate over 400/second burst 800 packets } counter drop
    }
}

Speichern Sie das als /etc/nftables.d/ts3.nft, legen Sie das Verzeichnis bei Bedarf vorher an und laden Sie die Datei als root:

nft -f /etc/nftables.d/ts3.nft
nft list table inet ts3

Rückgängig machen Sie es mit nft delete table inet ts3. Nach einem Neustart ist die Tabelle weg, sofern die Datei nicht aus /etc/nftables.conf eingebunden wird.

Zur Größenordnung: Ein sprechender Client sendet bei 20-Millisekunden-Frames rund 50 Pakete pro Sekunde. 400 pro Sekunde lassen also mehreren Personen hinter einem Anschluss reichlich Luft, und der Zähler zeigt, ob die Regel überhaupt gegriffen hat.

Und jetzt die ehrliche Einordnung: Gegen einen verteilten Angriff hilft diese Regel kaum. Sie zählt je Absenderadresse, und ein Angreifer fälscht die Absenderadresse in jedem Paket neu. Sie ist gut gegen einzelne Störer und gegen fehlkonfigurierte Clients. Sie ist keine DDoS-Abwehr.

10. Protokollieren, damit Sie im Ernstfall Zahlen haben

Wenn es losgeht, brauchen Sie Messwerte und nicht das Gefühl, dass es hakt. Die Paket- und Fehlerzähler der Netzwerkkarte lesen Sie so:

ip -s link show eth0

Zweimal im Abstand von zehn Sekunden ausgeführt und die Differenz gebildet, ergibt das Ihre Paketrate. Wer gerade Verbindungen zum Voice-Port hält, zeigt:

ss -uan 'sport = :9987'

Eine kleine Stichprobe des ankommenden Verkehrs liefert:

tcpdump -ni eth0 udp port 9987 -c 20

Die Logdateien des Servers liegen im Unterverzeichnis logs/. Mit logquerycommands=1 aus Schritt 3 stehen dort auch die abgesetzten Query-Befehle, was einen Missbrauch nachträglich sichtbar macht. Woran Sie einen Angriff von einem Konfigurationsfehler unterscheiden, zeigt der Beitrag DDoS-Angriff am Server erkennen.

Wo diese Maßnahmen aufhören

Alle zehn Schritte haben eines gemeinsam: Sie greifen erst, wenn das Paket schon da ist. Bei kleinen Störungen reicht das völlig, bei einem volumetrischen Angriff nicht, und zwar aus einem Grund, der nichts mit Ihrer Konfiguration zu tun hat.

Rechnen Sie mit: Eine Anbindung mit 1 Gbit/s überträgt rund 125 Megabyte pro Sekunde und bei kleinsten Paketen etwa 1,49 Millionen Pakete pro Sekunde. Bei 10 Gbit/s sind es entsprechend rund 14,9 Millionen Pakete pro Sekunde. Das ist die harte Obergrenze der Leitung, unabhängig davon, was auf dem Server läuft.

Ein real gemessener Angriff auf einen TeamSpeak-Server auf Port 9987 UDP lag bei über 473,4 Gbit/s und über 41,5 Millionen Paketen pro Sekunde. Das ist etwa das 470-Fache einer 1-Gbit/s-Anbindung und immer noch fast das Dreifache der Paketrate, die eine 10-Gbit/s-Anbindung überhaupt transportieren kann.

Entscheidend ist, wo dieser Verkehr aufläuft: nicht auf Ihrer Netzwerkkarte, sondern auf der Leitung davor. Ist dieses Stück Weg voll, gehen die Pakete Ihrer Mitglieder dort verloren, bevor Ihr Server sie je zu sehen bekommt. Eine Firewall-Regel im Betriebssystem kann eine Leitung nicht entlasten, die vor dem Betriebssystem endet.

Dazu kommt die Rechenzeit. Selbst wenn Ihr Kernel Millionen Pakete pro Sekunde verwerfen könnte, kostet jede dieser Entscheidungen CPU. Ein Voiceserver, der mit dem Wegwerfen beschäftigt ist, klingt genauso kaputt wie einer, der gar nicht mehr antwortet.

Was KernelHost dagegenstellt

Stufe 1: der inkludierte Dauerschutz auf jedem Server

Bei jedem Server von KernelHost läuft die DDoS-Filterung permanent mit, ohne Aufpreis und ohne dass Sie etwas einschalten oder konfigurieren müssten. Sie ist zweistufig aufgebaut:

• Ebene 1: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk. Volumetrische Angriffe werden nah an ihrer Quelle abgefangen, lange bevor sie das Rechenzentrum erreichen. Genau das ist die Ebene, die eine Leitung entlastet, die Sie selbst nicht entlasten können.
• Ebene 2: 3,2 Tbps Arbor-Echtzeitfilterung im maincubes Premium Datacenter in Frankfurt am Main. Direkt vor dem Server werden protokollspezifische Muster erkannt und Paket für Paket verworfen, darunter UDP-Fluten auf den typischen Voice- und Gameserver-Ports.

Zwei Punkte sind dabei wichtiger, als sie klingen. Erstens ist der Schutz dauerhaft aktiv und muss nicht erst anspringen, es gibt also keine Anlaufphase, in der ein Angriff durchgeht. Zweitens wird keine angegriffene IP-Adresse aus dem Netz genommen: Kein Nullrouting bedeutet, dass Ihre Mitglieder weiterreden, während gefiltert wird. Wie das für andere Titel und Protokolle aussieht, beschreibt der Beitrag Gameserver-DDoS-Schutz in Echtzeit.

Stufe 2: Advanced DDoS Protection für dauerhaft angegriffene Projekte

Manche Projekte werden nicht einmal getroffen, sondern über Wochen. Für diese Fälle gibt es die Advanced DDoS Protection ab 50,00 EUR im Monat, PrePaid und ohne Mindestlaufzeit. Sie ergänzt den inkludierten Dauerschutz um drei Dinge:

• Eine dedizierte Schutz-IP aus dem Frankfurter Kern, auf die Ihr Server umgestellt wird. Auf Ihrer Seite ist dafür kein Umbau nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich. Sie stellen die Filterung für 9987/UDP anders ein als für 30033/TCP, ohne ein Ticket zu schreiben, und Änderungen greifen in Echtzeit.
• Ein Schutzprofil passend zum jeweiligen Spiel oder Dienst, mit fertigen Profilen für über 40 Spiele und Protokolle, TeamSpeak eingeschlossen.

PrePaid heißt hier genau das: keine Mindestlaufzeit, keine Kündigungsfrist, kein Vertrag, keine Einrichtungsgebühr. Sie nehmen den Schutz für die Dauer einer Angriffswelle dazu und lassen ihn danach auslaufen.

Die beiden Stufen im Vergleich

Häufige Fehler und Lösungen

Der Voice-Port wird geändert, damit der Angriff ins Leere läuft: Das wirkt genau so lange, bis jemand einen Portscan laufen lässt, also meist wenige Minuten. Gleichzeitig müssen alle Mitglieder ihre Lesezeichen anpassen. Sinnvoll ist ein anderer Port nur, wenn Sie ohnehin mehrere Instanzen auf einem Server betreiben.

ServerQuery bleibt offen, weil ein Bot ihn braucht: Der Bot läuft in aller Regel auf demselben Server, dann genügt query_ip=127.0.0.1. Läuft er woanders, geben Sie den Port nur für dessen feste IP-Adresse frei und legen Sie ihm über queryloginadd einen eingeschränkten Zugang an.

Die Firewall wird scharfgeschaltet und der Zugang ist weg: Bei KVM-Rootservern und Dedicated Servern von KernelHost kommen Sie über die VNC-Konsole im Kundenbereich auf das System. Diese Konsole hängt nicht am Netzwerkstack des Gastsystems, eine Firewall-Regel kann sie also nicht blockieren. Melden Sie sich dort als root an und schalten Sie die Firewall mit ufw disable ab, bevor Sie die Ursache suchen.

Die Ratenbegrenzung ist zu eng gesetzt und trifft die eigenen Mitglieder: Typisch ist ein Wohnheim oder eine Familie hinter einem gemeinsamen Anschluss. Für den Filter sieht das aus wie eine einzelne Adresse mit auffällig vielen Paketen. Prüfen Sie den Zähler mit nft list table inet ts3: Steigt er, obwohl kein Angriff läuft, ist der Wert zu niedrig.

Der Server startet nach der Änderung an der ts3server.ini nicht mehr: Fast immer wurde die Datei bearbeitet, aber beim Start nicht übergeben, oder umgekehrt. Prüfen Sie beides und sehen Sie in die neueste Datei unter logs/, dort steht die Ursache im Klartext.

Alle Maßnahmen sind umgesetzt und der Server ist trotzdem weg: Dann liegt ein volumetrischer Angriff vor, und Sie haben auf dem Server selbst nichts mehr in der Hand. Sammeln Sie die Werte aus ip -s link sowie den Zeitpunkt der ersten Auffälligkeit und geben Sie beides an Ihren Anbieter weiter. Bei KernelHost eröffnen Sie ein Ticket im Kundenbereich; bei laufendem Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfall-Chat unter +43 650 8209883.

Kurzcheck für den Ernstfall

1. Messen statt raten: ip -s link show eth0 zweimal ausführen und die Differenz bilden.
2. Prüfen, ob nur 9987/UDP und 30033/TCP offen sind, und den Query-Port schließen.
3. Flutkontrolle der Instanz und Anti-Flood des virtuellen Servers kontrollieren.
4. Wenn die Leitung selbst dicht ist: Zahlen und Zeitpunkt sichern, dann den Anbieter einschalten.